Lunedì, 29 Agosto 2016 00:00

Guasto disastroso, danni contenuti

Il fatto: un hard disk di un server si rompe mentre il server è in funzione.
Epilogo finale: quasi tutto è integro e funzionante!

Condivido questa storia perché mi sembra efficace per raccontare tecnologie e pratiche vincenti e, anche, per evitare leggerezze che hanno conseguenze non positive.
I fatti narrati sono tutti veri. Di fantasia, invece, i nomi.
Quindi ora allaccia le cinture; inizia il racconto e la condivisione di alcune considerazioni alla fine.

Scenario

Entriamo nel CED: realizzazione artigianale, componentistica PC e tipologia di servizi erogati semi-enterprise. Questo disegno mostra l'architettura.

Per capire meglio l'architettare ecco una piccola descrizione:

  • switch: modello evoluto, cioè supporta il protocollo 802.3ad ed è del tipo managed per essere controllato via software e monitorato da Zabbix;
  • server2.example.com: server LAMP con dati e servizi per gli utenti non tecnici;
  • storage.example.com: server che condivide spazio disco. Realizzato con CentOS 7 e GlusterFS per creare un filesystem di rete. Ha 1 hard-disk con il sistema operativo (è stata usata una pendrive USB da 16GB) , 5 dischi in RAID 5 (dove è lo spazio esportato) e 3 schede di rete ethernet da 1GB configurate in bounding 4 per sommare la velocità ed avere l'HA (se si rompe/stacca una o due connessioni continua a funzionare la rete). Inoltre la macchina è monitorata da Zabbix (versione 3, per i più curiosi);
  • server1.example.com: serve con i servizi. In particolare condivide e monta il filesystem di rete (vedi il punto sotto "filesystem di rete"). Configurato con 3 hard-disk (1 per il sistema operativo, 2 come disco logico LVM che costituiscono un brick [cioè un pezzo] del volume [cioè disco di rete] GlusterFS. Riguardo ai servizi è un server DB (MariaDB), web (Apache 2.4 con PHP 5.4), Java-AS (OpenJDK 8 e WildFlay 10). Inoltre ha un portale intranet realizzato con Xwiki, un Git (fatto con Gitblit), server OCSInventory, GLPI, server Zabbix, PhpLDAPadmin (per gestire le entry dell'LDAP dell'intranet usato come authentication point), repo RPM per i server, l'immancabile PhpMyAdmin e Samba;
  • backup.example.com: server per il backup centralizzato. Al momento del guasto la macchina non era ancora allestita;
  • filesystem di rete (ovvero: disco di rete): il server storage.example.com esporta un disco di rete con il protocollo gluster configurato in replica distribuita (quindi i dati sono sia in locale sia su storage.example.com). Il volume GlusterFS ospita i dati ed i file di Samba (esporta spazio disco per i PC Windows della rete e gli script Microsoft per le attività automatiche di logon e logout), del DB MariaDB, le webapp (cioè PhpMyAdmin, PhpLDAPadmin, ecc...), gli RPM del repo locale.

A valle di queste specifiche l'allestimento è stato progettato per scalare, cioè poter aggiungere, o togliere, risorse e servizi in modo lineare senza dover spegnere e interrompere (in realtà questa architettura lo permette solo in parte).

Per contenere i costi e per motivi di autorizzazioni (burocratiche) ho usato molto materiale recuperato da hardware dismesso (tra cui i fatidici hard disk di questa storia).

Da sapere assolutamente per capire bene tutto l'accaduto, questa architettura l'ho realizzata progressivamente per rimpiazzare server e servizi precedenti che andavano smantellati. Il tutto senza interrompere i servizi, tenendo tutto trasparente all'utente finale e privilegiando i servizi end-user piuttosto che quelli gestionali-amministrativi o sistemistici. Tradotto: prima ho migrato il sito, samba, ecc... e dopo ho iniziato ad attivare e configurare il monitoring, l'auditing, ecc...

Al momento del guasto stavo, con calma, lavorando su questa ultima parte del progetto.

Il guasto

Dopo un allestimento ed una migrazione dei servizi proceduta quasi senza intoppi, e completamente trasparente agli utenti, un giorno, proprio come all'inizio delle favole (nere), i servizi esposti dal server risultano sensibilmente rallentati senza alcun apparente motivo.

Decido una pausa caffè lunga per analizzare il problema. Infatti il rallentamento generale non accennava a rientrare.

Apro Zabbix e comincio ad analizzare apprati e rete. I cruscotti globali evidenziano dei picchi poco spiegabili. Era da circa 10 giorni che continuavano, in modo non continuo.

Guardo i log del computer. Le applicazioni non danno segni anomali, ma i log di CentOS mostrano diverse righe di errori in coincidenza con i picchi evidenziati da Zabbix. Le righe mostrano errori kernel nell'accedere ad un disco su chiamate fatte da GlusterFS.

Verifica dello status dei dischi: sdc ha uno o più blocchi non leggibili.

Nota 1: il volume LVM locale è composto dal disco sdb e sdc!

Nota 2: il volume LVM è montato in /opt . Se provo ad accedere in /opt o chiedere la lista dei file in /opt ottengo un errore I/O. Se chiedo per una delle sotto-directory tutto funziona correttamente.

Recupero

Scoperto cosa accade mi fermo, con il sangue gelato, a riflettere qualche istante. Il timore è che ho perso tutto!

Come puoi immaginare se il danno ha causato corruzione o perdita di dati è devastante (vedi sopra l'elenco servizi e dei dati)! Una grande mitigazione del danno deriva dal fatto che è da poco tempo in funzione. E' da circa un mese che funziona pertanto i dati raccolti sono pochi. Magra consolazione, ma pur sempre una consolazione.

Continuando a privilegiare l'utente finale decido di migrare subito su server2.example.com i dati e i servizi che impattano direttamente sugli utenti (sono un paio di condivisioni Samba, ed un paio di servizi automatici web via Apache). Grazie a Dio ci sono tutti i file, sono consistenti e le configurazioni sono salve. Impostati i redirect tutto funziona senza alcun disagio per gli utenti.

Inizio a cullare la speranza di poter recuperare tutto con procedure standard di check-&-fix sui dischi e sui filesystem.

Quindi inizio una serrata staffetta:

  • lancio Samba e tutto va ottimamente al primo colpo (stupendo, penso);
  • riattivato il mount automatico dei volumi GlusterFS e li monto. Passo alle applicazioni;
  • torno su server1.example.com per riattivare le applicazioni:
  • mi accorgo che non ho ancora staccato i vecchi brick. Dal momento che non esistono più bisogna forzare lo split e GlusterFS procede senza alcun problema;
  • Prendo atto dell'entità del guasto e sostituisco i due dischi con due nuovi (perché non l'ho fatto prima! Sono stati solo €100 comprese le tasse :=( ); Bello: con i dischi separati il sistema operativo è perfetto, le applicazioni sono integre e tutto funziona. Mi mancano solo i dati che spero siano consistenti. A prima vista storage.example.com ha tutto e sembra completo.
  • il BIOS della macchina, dopo qualche istante, comunica che S.M.A.R.T. predice l’imminente crash del disco. Purtroppo questo BIOS non permette attività ulteriori di analisi o recovery;
  • entro in storage.example.com e creo la copia fisica delle directory esportate da GlusterFS sulla macchina con il guasto. L'operazione è un po' lunga. Mi accorgo che i pochi dati sono circa 1,5TB!
  • stoppo i servizi e smonto il volume Gluster;
  • stoppo i demoni Gluster;
  • A questo punto entro nel CED e mi metto sulla tastiera e sul monitor di server1.example.com:
    • spengo la macchina e la riavvio con un disco di recovery;
    • il BIOS della macchina, dopo qualche istante, comunica che S.M.A.R.T. predice l’imminente crash del disco. Purtroppo questo BIOS non permette attività ulteriori di analisi o recovery;
    • forzo la macchina a procedere e a boottare dal disco di recovery e quindi passo alle attività di analisi ed i relativi tentativi di recovery. Purtroppo, senza entrare nei dettagli, né il disco né il volume LVM sono recuperabili!
  • Prendo atto dell'entità del guasto e sostituisco i due dischi con due nuovi (perché non l'ho fatto prima! Sono stati solo €100 comprese le tasse :=( ); Bello: con i dischi separati il sistema operativo è perfetto, le applicazioni sono integre e tutto funziona. Mi mancano solo i dati che spero siano consistenti. A prima vista storage.example.com ha tutto e sembra completo.
  • Torno su storage.example.com per attaccare i nuovi brick di server1.example.com:
    • mi accorgo che non ho ancora staccato i vecchi brick. Dal momento che non esistono più bisogna forzare lo split e GlusterFS procede senza alcun problema;
    • attacco i nuovi brick e GlusterFS lo fa subito (cioè l'operazione va in porto in pochi secondi. La risincronizzazione prende il suo tempo visto l'ammontare di 1.5TB di dati...);
  • mi faccio l'elenco delle applicazioni per avere una scaletta lavoro che funzioni;
  • lancio Apache e tutto va ottimamente al primo colpo;
  • lancio MariaDB e... non parte. Analizzando il log mancano un paio di file.…

Per farla breve scopro che mancano dei file a macchia di leopardo. Quindi con un po' di pazienza ho isolato e ripristinato i mancanti. E' stato un lavoro impegnativo, ma alla fine tutto è tornato (quasi) come prima.

L'aspetto più critico è stato il DB. Risolti i problemi per farlo girare, ho ricostruito i due utenti che aveva perso e ho recuperato tutti i dati recuperabili. Ho perso i DB di OCSInventory e GLPI. Poco male perché si popolano quasi completamente in modo automatico.

Un problema più subdolo è stato Xwiki: il DB era consistente, ma per funzionare questo wiki deve salvare anche degli altri dati. Visto i pochi contenuti che avevo inserito ho optato per rigenerarlo e reinserire gli articoli estraendoli dal vecchio DB.

Saldo finale:

nella maggior parte i dati sono rimasti;

i dati speciali (come i file di MariaDB) sono stati in parte persi;

per applicazioni speciali (come Xwiki) i dati c'erano, ma non erano più immediatamente utilizzabili;

tempo necessario per ripristina il tutto: quasi una settimana lavorativa (nota: il rescue è stato fatto in parallelo con altre attività ordinarie!);

il guasto è stato quasi invisibile agli utenti.

Dimenticavo: Gitblit l'avevo configurato con un repo esterno all'AS. Questa directory è tra quelle replicate da GlusterFS. Il suo DB, inoltre, era integro. Quando ho deployato nuovamente il pacchetto (magicamente) ho ritrovato tutto!

Conclusioni

Questa esperienza è stata un laboratorio full-immersion. Ho imparato cose che mi piace condividere. Ho verificato la bontà e la robustezza di alcune tecnologie non popolari (e che, quindi, il responsabile acquisti fa fatica a firmare anche se si sono spesi giorni e giorni per spiegargli i pro-e-contro!). E ho sperimentato errori e limiti che si possono evitare pertanto importanti da condividere.

Aspetti buoni

La replica funziona! GlusterFS è stato all'altezza delle sue promesse;

affidarsi a tecnologie speciali paga, anche se i tempi di apprendimento, configurazione e messa in produzione sono decisamente più lunghi:

resistenza a guasti hardware anche con componentistica commodity;

algoritmi validi e potenti liberamente disponibili e già pronti all’uso;

eccellenza della tecnologia usata.

Aspetti brutti

La replica funziona, ma in caso di problemi può replicare anche i problemi copiando dati inconsistenti :( ;

GlusterFS consuma non poca banda. La coppia con connessioni di rete ethernet è poco performante. In combinazione con l’I/O distribuito crea lentezze evidenti;

applicazioni evolute, come Xwiki, è bene configurarle in tutti i suoi aspetti (clustering, data store, ecc…) per evitare spiacevoli sorprese.

Pratiche ed errori da evitare

Qui l’elenco è un po’ più lungo:

evitare di usare hardware recuperato soprattutto per le parti strategiche e soggette a usura e vita limitata (come gli hard disk, appunto!), a meno che non si usino in applicazioni non rilevanti e si ha una piena consapevolezza di quello che si fa;

quando avviene il disastro fare molta attenzione a seguire correttamente e nel giusto ordine le procedure di spegnimento dei servizi e smontaggio. Sequenze non corrette creano danni sui danni già presenti;

attivare subito, in modo completo e correttamente configurato, i sistemi di monitoring e di auditing anche se comporta un ritardo nel mettere in produzione il sistema. Nel mio caso sarei stato avvertito subito al sorgere del problema;

anche la messa in produzione del sistema di backup è altamente (mandatorio?) opportuno farla subito o almeno come primo passo successivo all’accensione dei server;

se si usano degli AS, quando le applicazioni deployate lo prevedono, è buona cosa mettere i dati in una directory esterna all’AS in una parte copiata sullo storage.

Conclusione conclusiva

A conclusione di questa esperienza:

scegliere tecnologie enterprise, anche se non popolari e più complesse, pagano!

l’uso di hardware commodity permette di avere risultati notevoli, anche se con significative limitazioni di performance e una sostanziale assenza di HA per i guasti hardware.

Il punti più debole, con questa architettura è proprio l’impossibilità di un buon livello HA dell’hardware. Ma il punto più delicato è la competenza degli operatori (purtroppo i responsabili acquisti si focalizzano facilmente sui brand dei prodotti). Le conoscenze informatiche di base sono insufficienti in uno scenario simile. Conoscenze superiori, più ampie, sono l’arma vincente.

Resta aperto (e, credo, irrisolto) il problema delle figure politiche che autorizzano o meno. Spesso non sono figure con competenze tecniche e ingegneristiche e non poche volte sono eccessivamente sensibili agli aspetti di colore della comunicazione e non agli aspetti di sostanza e di merito.

Glossario

802.3ad: noto anche con l’acronimo LACP (Link Aggregation Control Protocol) è uno standard che permette di raggruppare insieme più porte fisiche per ottenere un singolo canale logico (multiplazione inversa).

AS: acronimo di Application Server. Indica una sofisticata tipologia di server enterprise adatti per situazioni ad alta complessità.

Brick: parte dell’architettura GlusterFS. Indica un directory esposta da una server del pool GlusterFS.

Filesystem: indica informalmente un meccanismo con il quale i file sono posizionati e organizzati su un dispositivo di archiviazione come un hard disk, un pendrive, ecc… In termini popolari è il tipo di formattazione.

Git: software per il controllo di versione distribuito usato normalmente per sviluppare software.

Gitblit: programma di classe enterprise che offre servizi git.

GLPI: programma web per l’inventariazione e la gestione del parco IT.

GlusterFS: filesystem scalabile di rete concepito per offrire replica e distribuzione dei dati.

HA: acronimo di High Availability. È un termine usato per indicare tecnologie in grado di garantire la massima continuità e disponibilità dei servizi erogati.

LAMP: acronimo di Linux Apache MySQL Perl/PHP. Indica la tecnologia standard per server Linux che espongono servizi web.

LDAP: acronimo di Lightweight Directory Access Protocol. Indica un protocollo standard per l’interrogazione e la manutenzione di servizi directory come elenchi telefonici, agende, ecc...

Logon: procedura per autenticarsi ed accedere ad un sistema, o a un servizio, fornendo credenziali con la username e la password.

Logout: procedura di uscita da una sessione autenticata.

OCSInventory: programma per l’inventariazione automatica del parco hardware.

PhpLDAPadmin: programma, con interfaccia web, creato per gestire database MySQL e MariaDB.

PhpMyAdmin: programma, con interfaccia web, creato per gestire servizi LDAP.

Repo RPM: sigla che indica una tecnologia per distribuire, tramite la rete, software e aggiornamenti per distribuzioni Linux RedHat o derivate.

S.M.A.R.T.: acronimo di Self-Monitoring, Analysis, and Reporting Technology. È un sistema di monitoraggio per dischi rigidi e per SSD, per rilevare e fornire diversi indicatori di affidabilità, nella anticipare i malfunzionamenti, guasti e rotture.

Samba: programma che rende reciprocamente compatibili server UNIX e server Windows per le risorse ed i servizi di rete.

Switch: dispositivo hardware per collegare computer ed apparati tramite un cavo di rete.

Webapp: software che si usa tramite interfacce web.

Xwiki: programma, di livello enterprise, che offre servizi wiki, ovvero un sistema semplice e veloce per pubblicare contenuti su pagine web.

Zabbix: software per monitorare server, pc e apparati digitali in genere.

Questo sito utilizza cookie, anche di terze parti, per migliorare la tua esperienza e offrire servizi in linea con le tue preferenze. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie vai alla sezione Cookie Policy.