Come ti sentiresti se in una bella giornata estiva il data center con le tue apparecchiature assomigliasse a questo?
Ciao a tutti! Mi chiamo Dmitry Samsonov, lavoro come amministratore di sistema leader presso "" La foto mostra uno dei quattro data center in cui sono installate le apparecchiature a servizio del nostro progetto. Dietro queste mura si trovano circa 4mila apparecchiature: server, sistemi di archiviazione dati, apparecchiature di rete, ecc. - quasi ⅓ di tutta la nostra attrezzatura.
La maggior parte dei server sono Linux. Esistono anche diverse dozzine di server su Windows (MS SQL): la nostra eredità, che abbandoniamo sistematicamente da molti anni.
Pertanto, il 5 giugno 2019 alle 14:35, i tecnici di uno dei nostri data center hanno segnalato un allarme antincendio.
negazione
14:45. Piccoli incidenti legati al fumo nei data center sono più comuni di quanto si pensi. Gli indicatori all'interno dei padiglioni erano normali, quindi la nostra prima reazione è stata relativamente calma: hanno introdotto il divieto di lavorare con la produzione, cioè di qualsiasi modifica alla configurazione, di lanciare nuove versioni, ecc., Ad eccezione dei lavori relativi alla correzione di qualcosa.
Rabbia
Hai mai provato a chiedere ai vigili del fuoco esattamente dove si è verificato l'incendio sul tetto o a salire tu stesso su un tetto in fiamme per valutare la situazione? Quale sarà il grado di fiducia nelle informazioni ricevute attraverso cinque persone?
14: 50. È stata ricevuta l'informazione che l'incendio si sta avvicinando al sistema di raffreddamento. Ma arriverà? L'amministratore di sistema di turno rimuove il traffico esterno dai fronti di questo data center.
Al momento i fronti di tutti i nostri servizi sono duplicati in tre data center, il bilanciamento viene utilizzato a livello DNS, che ci consente di rimuovere gli indirizzi di un data center dal DNS, proteggendo così gli utenti da potenziali problemi con l'accesso ai servizi . Se si sono già verificati problemi nel data center, esce automaticamente dalla rotazione. Puoi leggere di più qui:
L'incendio non ci ha ancora colpito in alcun modo: né gli utenti né le attrezzature hanno subito danni. È un incidente? La prima sezione del documento “Piano d’azione contro l’incidente” definisce il concetto di “Incidente”, e la sezione termina così:
«Se c'è qualche dubbio sul fatto che si sia verificato un incidente o meno, allora è un incidente!»
14:53. Viene nominato un coordinatore dell'emergenza.
Il coordinatore è la persona che controlla la comunicazione tra tutti i partecipanti, valuta l'entità dell'incidente, utilizza il piano d'azione di emergenza, attira il personale necessario, monitora il completamento delle riparazioni e, soprattutto, delega eventuali compiti. In altre parole, questa è la persona che gestisce l’intero processo di risposta all’emergenza.
vendita all'asta
15:01. Iniziamo a disabilitare i server che non sono legati alla produzione.
15:03. Disattiviamo correttamente tutti i servizi riservati.
Ciò include non solo i front (a cui ormai gli utenti non accedono più) e i loro servizi ausiliari (logica di business, cache, ecc.), ma anche vari database con fattore di replica 2 o più (, , , eccetera.).
15: 06. Sono state ricevute informazioni secondo cui un incendio minaccia una delle sale del data center. Non disponiamo di attrezzature in questa stanza, ma il fatto che l’incendio possa propagarsi dal tetto ai corridoi cambia notevolmente il quadro di ciò che sta accadendo.
(In seguito si è scoperto che non vi era alcun pericolo fisico per la sala, poiché era ermeticamente sigillata dal tetto. La minaccia riguardava solo il sistema di raffreddamento di questa sala.)
15:07. Permettiamo l'esecuzione dei comandi sui server in modalità accelerata senza controlli aggiuntivi ().
15:08. La temperatura nei padiglioni rientra nei limiti normali.
15: 12. È stato registrato un aumento della temperatura nei corridoi.
15:13. Più della metà dei server del data center sono spenti. Continuiamo.
15:16. È stata presa la decisione di spegnere tutte le apparecchiature.
15:21. Iniziamo a spegnere i server stateless senza chiudere correttamente l'applicazione e il sistema operativo.
15:23. Viene assegnato un gruppo di persone responsabili di MS SQL (ce ne sono pochi, la dipendenza dei servizi da loro non è eccezionale, ma la procedura per ripristinare la funzionalità richiede più tempo ed è più complicata rispetto, ad esempio, a Cassandra).
Депрессия
15: 25. Sono arrivate informazioni sull'interruzione della corrente elettrica in quattro padiglioni su 16 (n. 6, 7, 8, 9). Le nostre attrezzature si trovano nei padiglioni 7 e 8. Non ci sono informazioni sulle nostre due sale (n. 1 e 3).
Di solito, durante gli incendi, l'alimentazione viene immediatamente interrotta, ma in questo caso, grazie al lavoro coordinato dei vigili del fuoco e del personale tecnico del data center, non è stata interrotta ovunque e non immediatamente, ma quando necessario.
(Si è poi scoperto che la corrente non era stata spenta nei padiglioni 8 e 9.)
15:28. Stiamo iniziando a distribuire database MS SQL dai backup in altri data center.
Quanto tempo ci vorrà? La capacità della rete è sufficiente per l'intero percorso?
15: 37. È stato registrato un arresto di alcune parti della rete.
La direzione e la rete produttiva sono fisicamente isolate l'una dall'altra. Se la rete di produzione è disponibile, puoi andare al server, interrompere l'applicazione e spegnere il sistema operativo. Se non è disponibile, puoi accedere tramite IPMI, interrompere l'applicazione e spegnere il sistema operativo. Se non è presente alcuna rete, non puoi fare nulla. “Grazie, Cap!”, penserai.
“E in generale c’è molta agitazione”, potresti anche pensare.
Il fatto è che i server, anche senza fuoco, generano un'enorme quantità di calore. Più precisamente, quando c'è raffreddamento, generano calore, e quando non c'è raffreddamento, creano un inferno infernale, che, nella migliore delle ipotesi, scioglierà parte dell'attrezzatura e spegnerà un'altra parte, e nella peggiore delle ipotesi... causerà un incendio all'interno della sala, che quasi sicuramente distruggerà tutto.
15:39. Risolviamo i problemi con il database conf.
Il database conf è il backend per il servizio con lo stesso nome, utilizzato da tutte le applicazioni di produzione per modificare rapidamente le impostazioni. Senza questa base non possiamo controllare il funzionamento del portale, ma il portale stesso può funzionare.
15:41. I sensori di temperatura sulle apparecchiature della rete Core registrano letture vicine al massimo consentito. Si tratta di una scatola che occupa un intero rack e garantisce il funzionamento di tutte le reti all'interno del data center.
15:42. Il tracker dei problemi e la wiki non sono disponibili, passa alla modalità standby.
Non si tratta di produzione, ma in caso di incidente la disponibilità di qualsiasi base di conoscenza può essere fondamentale.
15:50. Uno dei sistemi di monitoraggio si è spento.
Ce ne sono diversi e sono responsabili di diversi aspetti dei servizi. Alcuni di essi sono configurati per funzionare in modo autonomo all'interno di ciascun data center (ovvero monitorano solo il proprio data center), altri sono costituiti da componenti distribuiti che sopravvivono in modo trasparente alla perdita di qualsiasi data center.
In questo caso ha smesso di funzionare , che funziona in modalità master-standby. Passato in standby.
Adozione
15:51. Tutti i server tranne MS SQL sono stati spenti tramite IPMI senza arrestarsi correttamente.
Sei pronto per la gestione massiccia dei server tramite IPMI, se necessario?
Il momento stesso in cui il salvataggio delle apparecchiature nel data center è completato in questa fase. Tutto quello che poteva essere fatto è stato fatto. Alcuni colleghi possono riposarsi.
16: 13. Sono state ricevute informazioni secondo cui i tubi del freon dei condizionatori d'aria sono scoppiati sul tetto: ciò ritarderà il lancio del data center dopo l'eliminazione dell'incendio.
16:19. Secondo i dati ricevuti dal personale tecnico del data center, l'aumento della temperatura nelle sale si è fermato.
17:10. Il database conf è stato ripristinato. Ora possiamo modificare le impostazioni dell'applicazione.
Perché è così importante se tutto è tollerante ai guasti e funziona anche senza un data center?
Innanzitutto, non tutto è tollerante ai guasti. Esistono vari servizi secondari che non sono ancora sopravvissuti abbastanza bene al guasto di un data center e vi sono database in modalità master-standby. La possibilità di gestire le impostazioni consente di fare tutto il necessario per ridurre al minimo l'impatto delle conseguenze di un incidente sugli utenti anche in condizioni difficili.
In secondo luogo, è diventato chiaro che il funzionamento del data center non sarebbe stato completamente ripristinato nelle prossime ore, quindi è stato necessario adottare misure per garantire che l'indisponibilità a lungo termine delle repliche non portasse a ulteriori problemi, come ad esempio i dischi pieni in i restanti data center.
17:29. È l'ora della pizza! Impieghiamo persone, non robot.
Reinserimento
18:02. Nei padiglioni n. 8 (il nostro), 9, 10 e 11 la temperatura si è stabilizzata. In uno di quelli che restano offline (il numero 7) si trova la nostra attrezzatura e lì la temperatura continua a salire.
18:31. È stato dato il via libera alla messa in funzione delle attrezzature nei padiglioni n. 1 e 3: questi padiglioni non sono stati colpiti dall'incendio.
Attualmente i server vengono lanciati nei padiglioni n. 1, 3, 8, a partire da quelli più critici. Viene controllato il corretto funzionamento di tutti i servizi in esecuzione. Ci sono ancora problemi con la sala n. 7.
18:44. Il personale tecnico del data center ha scoperto che nella stanza n. 7 (dove si trovano solo le nostre apparecchiature) molti server non sono spenti. Secondo i nostri dati, lì sono online 26 server. Dopo un secondo controllo, troviamo 58 server.
20:18. I tecnici del data center soffiano aria in una stanza non climatizzata attraverso condotti mobili che attraversano i corridoi.
23:08. Il primo amministratore è stato rimandato a casa. Qualcuno ha bisogno di dormire la notte per poter continuare a lavorare domani. Successivamente, rilasceremo altri amministratori e sviluppatori.
02:56. Abbiamo lanciato tutto ciò che poteva essere lanciato. Effettuiamo molti controlli su tutti i servizi utilizzando test automatici.
03:02. L'aria condizionata nell'ultima sala 7 è stata restaurata.
03:36. Abbiamo messo in rotazione i fronti del data center in DNS. Da questo momento inizia ad arrivare il traffico di utenti.
Manderemo a casa la maggior parte del personale amministrativo. Ma lasciamo indietro alcune persone.
Piccole domande frequenti:
D: Cosa è successo dalle 18:31 alle 02:56?
R: Seguendo il “Piano d'azione in caso di catastrofe”, lanciamo tutti i servizi, a partire da quelli più importanti. In questo caso, il coordinatore nella chat consegna il servizio a un amministratore gratuito, che controlla se il sistema operativo e l'applicazione sono stati avviati, se ci sono errori e se gli indicatori sono normali. Una volta completato il lancio, segnala alla chat che è libero e riceve un nuovo servizio dal coordinatore.
Il processo è ulteriormente rallentato dall'hardware guasto. Anche se l'arresto del sistema operativo e lo spegnimento dei server sono andati a buon fine, alcuni server non si riavviano a causa di un guasto improvviso di dischi, memoria e chassis. Quando viene a mancare l'alimentazione, il tasso di guasto aumenta.
D: Perché non è possibile eseguire tutto in una volta e quindi correggere ciò che emerge durante il monitoraggio?
R: Tutto deve essere fatto gradualmente, perché ci sono dipendenze tra i servizi. E tutto va controllato subito, senza aspettare il monitoraggio. Perché è meglio affrontare i problemi subito, senza aspettare che peggiorino.
7:40. L'ultimo amministratore (coordinatore) è andato a letto. Il lavoro del primo giorno è stato completato.
8:09. I primi sviluppatori, ingegneri e amministratori del data center (compreso il nuovo coordinatore) hanno iniziato i lavori di restauro.
09:37. Abbiamo iniziato a rialzare il padiglione n. 7 (l'ultimo).
Allo stesso tempo, continuiamo a ripristinare ciò che non è stato risolto in altre stanze: sostituendo dischi/memoria/server, sistemando tutto ciò che “brucia” nel monitoraggio, invertendo nuovamente i ruoli negli schemi master-standby e altre piccole cose, di cui esistono comunque parecchio.
17:08. Consentiamo tutto il lavoro regolare con la produzione.
21:45. Il lavoro del secondo giorno è terminato.
09:45. Oggi è venerdì. Ci sono ancora alcuni piccoli problemi nel monitoraggio. Il fine settimana è alle porte, tutti vogliono rilassarsi. Continuiamo a riparare in modo massiccio tutto ciò che possiamo. Le normali attività amministrative che avrebbero potuto essere rinviate sono state rinviate. Il coordinatore è nuovo.
15:40. All'improvviso metà dello stack di apparecchiature di rete Core in UN ALTRO data center è stata riavviata. I fronti sono stati esclusi dalla rotazione per ridurre al minimo i rischi. Non ci sono effetti per gli utenti. Successivamente si è scoperto che si trattava di un telaio difettoso. Il coordinatore sta lavorando per riparare due incidenti contemporaneamente.
17:17. Il funzionamento della rete in un altro data center è stato ripristinato, tutto è stato controllato. Il data center viene messo in rotazione.
18:29. I lavori del terzo giorno e, in generale, il restauro dopo l'incidente sono stati completati.
postfazione
04.04.2013 g., , "Compagne di classe" —per tre giorni il portale è stato completamente o parzialmente non disponibile. Durante tutto questo tempo, più di 100 persone provenienti da diverse città, da diverse aziende (molte grazie ancora!), da remoto e direttamente nei data center, manualmente e automaticamente, hanno riparato migliaia di server.
Abbiamo tratto delle conclusioni. Per evitare che ciò accada di nuovo, abbiamo svolto e continuiamo a svolgere un ampio lavoro fino ad oggi.
Quali sono le principali differenze tra l’incidente attuale e il 404?
- Abbiamo un “Piano d’azione in caso di incidente”. Una volta ogni trimestre conduciamo esercizi: giochiamo a una situazione di emergenza che un gruppo di amministratori (tutti a turno) deve eliminare utilizzando il "Piano d'azione di emergenza". I principali amministratori di sistema si alternano nel ruolo di coordinatore.
- Trimestralmente, in modalità test, isoliamo i data center (tutti a turno) tramite reti LAN e WAN, il che ci consente di identificare tempestivamente i colli di bottiglia.
- Meno dischi rotti, perché abbiamo inasprito gli standard: meno ore di funzionamento, soglie più severe per SMART,
- Abbiamo abbandonato completamente BerkeleyDB, un database vecchio e instabile che richiedeva molto tempo per il ripristino dopo il riavvio del server.
- Abbiamo ridotto il numero di server con MS SQL e ridotto la dipendenza da quelli rimanenti.
- Abbiamo il nostro , dove stiamo migrando attivamente tutti i servizi ormai da due anni. Il cloud semplifica notevolmente l'intero ciclo di lavoro con l'applicazione e, in caso di incidente, fornisce strumenti unici come:
- arresto corretto di tutte le applicazioni in un clic;
- facile migrazione delle applicazioni da server guasti;
- lancio automatico classificato (in ordine di priorità dei servizi) di un intero data center.
L'incidente descritto in questo articolo è stato il più grande dal 404esimo giorno. Naturalmente non tutto è andato liscio. Ad esempio, durante l'indisponibilità di un data center danneggiato da un incendio in un altro data center, un disco su uno dei server si è guastato, ovvero solo una delle tre repliche nel cluster Cassandra è rimasta accessibile, motivo per cui il 4,2% dei dispositivi mobili gli utenti dell'applicazione non sono riusciti ad accedere. Allo stesso tempo, gli utenti già connessi hanno continuato a lavorare. In totale, a seguito dell'incidente, sono stati identificati più di 30 problemi, dai bug banali alle carenze nell'architettura del servizio.
Ma la differenza più importante tra l'incidente attuale e il 404° è che mentre stavamo eliminando le conseguenze dell'incendio, gli utenti continuavano a mandare messaggi e a fare videochiamate a , giocavamo, ascoltavamo musica, ci scambiavamo regali, guardavamo video, serie TV e canali TV , e anche in streaming .
Come vanno i tuoi incidenti?
Fonte: habr.com