Cosa pensereste se, un bel giorno d'estate, il data center con le vostre attrezzature apparisse in questo modo?
Ciao a tutti! Mi chiamo Dmitry Samsonov e lavoro come amministratore di sistema senior presso "". Nella foto si vede uno dei quattro data center dove sono installate le attrezzature che supportano il nostro progetto. Dietro queste mura ci sono circa 4.000 unità: server, sistemi di storage, attrezzature di rete, ecc. — quasi un terzo di tutta la nostra attrezzatura.
La maggior parte dei server utilizza Linux. Ci sono anche alcune decine di server Windows (MS SQL) — il nostro lascito, dal quale ci stiamo gradualmente disfacendo da anni.
Dunque, il 5 giugno 2019 alle 14:35, gli ingegneri di uno dei nostri data center hanno segnalato un allarme incendio.
Negazione
14:45. Gli incidenti minori di fumi nei data center accadono più frequentemente di quanto si possa pensare. I valori all'interno delle sale erano nella norma, quindi la nostra prima reazione è stata relativamente calma: abbiamo imposto un divieto di lavoro su produzione, cioè su qualsiasi modifica delle configurazioni, distribuzioni di nuove versioni, ecc., a meno che non riguardassero la riparazione di qualcosa.
Rabbia
Avete mai provato a chiedere ai vigili del fuoco dove esattamente sul tetto è scoppiato l'incendio, o a salire sulla copertura in fiamme per valutare la situazione? Quale sarà il grado di fiducia nelle informazioni ottenute attraverso cinque persone?
14:50. Sono arrivate notizie che il fuoco si sta avvicinando al sistema di raffreddamento.Ma arriverà? L'amministratore di sistema di guardia sta estraendo il traffico esterno dai fronti di questo data center.
Al momento, i fronti di tutti i nostri servizi sono duplicati in tre data center, utilizzando il bilanciamento a livello di DNS, il che consente di rimuovere gli indirizzi di un data center dal DNS, proteggendo così gli utenti da potenziali problemi di accesso ai servizi. Nel caso in cui si fossero già verificati problemi nel data center, esso esce automaticamente dalla rotazione. Maggiori dettagli possono essere trovati qui:
Finora l'incendio non ha avuto alcun impatto su di noi — né gli utenti né l'attrezzatura hanno subito danni. È un'emergenza? La prima sezione del documento "Piano di azione in caso di emergenza" dà una definizione del concetto di "Emergenza", e termina con queste parole:
«In caso di dubbi, se c'è un'emergenza o meno, è un'emergenza!»
14:53. Viene nominato un coordinatore di emergenza.
Il coordinatore è la persona che controlla la comunicazione tra tutti i partecipanti, valuta l'entità dell'emergenza, utilizza il "Piano di azione in caso di emergenza", recluta il personale necessario, controlla il completamento della riparazione, soprattutto delega qualsiasi compito. In altre parole, è la persona che gestisce l'intero processo di risoluzione dell'emergenza.
Mercanteggiamento
15:01. Iniziamo a spegnere i server che non sono collegati alla produzione.
15:03. Spegniamo correttamente tutti i servizi riservati.
Questi comprendono non solo i fronti (ai quali a questo punto gli utenti non hanno già accesso) e i loro servizi ausiliari (logica di business, cache, ecc.), ma anche diversi database con un fattore di replica di 2 o superiore (, , , e altro).
15:06. Sono arrivate notizie che il fuoco minaccia una delle sale del data center. In questa sala non abbiamo attrezzature, ma il fatto che il fuoco possa propagarsi dal tetto alle sale cambia notevolmente la situazione.
(Si è poi scoperto che non c'era alcuna minaccia fisica per la sala, poiché era ermeticamente isolata dal tetto. L'unica minaccia era per il sistema di raffreddamento di quella sala.)
15:07. Autorizziamo l'esecuzione di comandi sui server in modo accelerato senza ulteriori controlli ().
15:08. La temperatura nelle sale è normale.
15:12. È stato registrato un aumento della temperatura nelle sale.
15:13. Più della metà dei server nel data center sono spenti. Continuiamo.
15:16. È stata presa la decisione di spegnere tutta l'attrezzatura.
15:21. Iniziamo a scollegare l'alimentazione dei server stateless senza un correttore di spegnimento dell'applicazione e del sistema operativo.
15:23. Viene assegnato un gruppo responsabile per MS SQL (ce ne sono pochi, la dipendenza dei servizi da loro non è alta, ma la procedura di ripristino è più lunga e complessa rispetto a, ad esempio, a Cassandra).
Depressione
15:25. Sono arrivate notizie della disattivazione dell'alimentazione in quattro sale su 16 (n. 6, 7, 8, 9). Nelle sale 7 e 8 si trovano le nostre attrezzature. Non abbiamo informazioni su altre due sale (n. 1 e 3).
Di solito, in caso di incendi, l'alimentazione elettrica viene disattivata immediatamente, ma in questo caso, grazie al lavoro coordinato dei vigili del fuoco e del personale tecnico del data center, non è stata disattivata ovunque e immediatamente, ma solo secondo necessità.
(Si è poi scoperto che l'alimentazione nelle sale 8 e 9 non era stata mai disattivata.)
15:28. Iniziamo a ripristinare i database MS SQL da backup in altri data center.
Quanto tempo sarà necessario? La larghezza di banda della rete sarà sufficiente lungo tutto il percorso?
15:37. È stato registrato un'interruzione in alcune sezioni della rete.
La rete di gestione e quella di produzione sono fisicamente isolate. Se la rete di produzione è disponibile, puoi accedere al server, fermare l'applicazione e spegnere il sistema operativo. Se non è disponibile, puoi accedere tramite IPMI, fermare l'applicazione e spegnere il sistema operativo. Se nessuna delle due reti è disponibile, non puoi fare nulla. "Grazie, capitano!", penserai.
"E anche, che caos!", potresti pensare anche tu.
Il punto è che i server generano un'enorme quantità di calore, anche senza incendi. Più precisamente, quando c'è il raffreddamento, generano calore, e quando non c'è, creano un caldo infernale che nel migliore dei casi scioglierà parte dell'hardware e spegnerà l'altra parte, e nel peggiore... provocherà un incendio nella sala, che praticamente garantirà la distruzione di tutto.
15:39. Registriamo i problemi con il database conf.
Il database conf è il backend per il servizio omonimo, utilizzato da tutte le applicazioni di produzione per modificare le impostazioni in tempo reale. Senza questo database non possiamo gestire il funzionamento del portale, ma il portale stesso può comunque funzionare.
15:41. I sensori di temperatura sull'attrezzatura di rete Core registrano valori vicini ai limiti consentiti. Questa è una scatola che occupa un’intera rack e gestisce tutte le reti all'interno del data center.
15:42. Issue tracker e wiki non sono disponibili, passiamo a standby.
Non è produzione, ma in caso di emergenza la disponibilità di qualsiasi knowledge base può essere critica.
15:50. Si è spenta una delle sistema di monitoraggio.
Ce ne sono vari, e si occupano di diversi aspetti del funzionamento dei servizi. Alcuni di essi sono configurati per funzionare autonomamente all'interno di ogni data center (cioè monitorano solo il proprio data center), altri sono composti da componenti distribuiti, che continuano a funzionare anche in caso di perdita di qualsiasi data center.
In questo caso ha smesso di funzionare , che opera in modalità master-standby. Siamo passati a standby.
Accettazione
15:51. Attraverso IPMI abbiamo spento tutti i server senza un corretto shutdown, tranne MS SQL.
Siete pronti a gestire i server in modo massivo tramite IPMI se necessario?
Questo è il momento in cui il salvataggio dell'hardware nel data center è completato. Tutto ciò che si poteva fare è stato fatto. Alcuni colleghi possono prendersi una pausa.
16:13. È arrivata la notizia che i tubi del refrigerante dei condizionatori sul tetto si sono rotti: questo ritarderà l'avvio del data center dopo la riparazione dell'incendio.
16:19. Secondo le informazioni ricevute dal personale tecnico del data center, l'aumento della temperatura nelle sale si è arrestato.
17:10. Abbiamo ripristinato il funzionamento del database conf. Ora possiamo cambiare le impostazioni delle applicazioni.
Perché è così importante, se tutto è ridondante e funziona anche senza un data center?
Innanzitutto, non tutto è ridondante. Ci sono vari servizi secondari che attualmente non reagiscono bene alla perdita di un data center, e ci sono database in modalità master-standby. La possibilità di gestire le impostazioni consente di fare tutto il necessario per minimizzare l'impatto delle conseguenze di un' emergenza sugli utenti, anche in condizioni difficili.
In secondo luogo, è diventato chiaro che nel prossimo futuro il funzionamento del data center non si riprenderà completamente, quindi era necessario adottare misure affinché la prolungata indisponibilità delle repliche non portasse a ulteriori problemi, come il riempimento dei dischi negli altri data center.
17:29. È tempo di pizza! Abbiamo persone che lavorano, non robot.
Riabilitazione
18:02. Nelle sale 8 (nostra), 9, 10 e 11 la temperatura si è stabilizzata. In una di quelle che rimangono spente (n. 7) si trova la nostra attrezzatura e la temperatura continua a salire.
18:31. È stato dato il via libera per avviare l'attrezzatura nelle sale 1 e 3: queste sale non sono state colpite dall'incendio.
Attualmente, stiamo avviando i server nelle sale 1, 3 e 8, iniziando dai più critici. Viene verificata la correttezza del funzionamento di tutti i servizi avviati. Ci sono ancora problemi con la sala n. 7.
18:44. Il personale tecnico del data center ha scoperto che nella sala n. 7 (dove ci sono solo le nostre attrezzature) molti server non sono stati spenti. Secondo i nostri dati, ci sono 26 server accesi. Dopo una ulteriore verifica, scopriamo che ci sono 58 server.
20:18. Il personale tecnico del data center sta soffiando aria nella sala senza condizionatori attraverso condotti mobili, installati attraverso i corridoi.
23:08. Abbiamo mandato il primo amministratore a casa. Qualcuno deve riposare di notte per continuare i lavori domani. Proseguiamo inviando a casa anche altri amministratori e sviluppatori.
02:56. Abbiamo avviato tutto ciò che era possibile. Stiamo facendo un grande controllo di tutti i servizi con test automatici.
03:02. L'aria condizionata nell'ultima sala, la settima, è stata ripristinata.
03:36. Abbiamo introdotto i server nel data center nella rotazione DNS. Da questo momento inizia ad arrivare il traffico degli utenti.
Stiamo rimandando la maggior parte del team di amministratori a casa. Ma alcuni li teniamo.
Piccolo FAQ:
D: Cosa è successo tra le 18:31 e le 02:56?
R: Seguendo il "Piano d'azione in caso di emergenza", avviamo tutti i servizi, partendo da quelli più critici. Nel frattempo, il coordinatore nella chat assegna il servizio a un amministratore disponibile, che controlla se il sistema operativo e l'applicazione si sono avviati, se ci sono errori e se i parametri sono nella norma. Alla fine dell'avvio, informa la chat che è disponibile e riceve un nuovo servizio dal coordinatore.
Il processo è ulteriormente rallentato dall'hardware guasto. Anche se l'arresto del sistema operativo e la disattivazione dei server sono avvenuti correttamente, alcuni server non ritornano a causa di dischi, memorie e chassis guasti inaspettatamente. In caso di perdita di alimentazione, la percentuale di guasti aumenta.
D: Perché non è possibile semplicemente avviare tutto insieme e poi risolvere ciò che appare nel monitoraggio?
R: Tutto deve essere fatto gradualmente, perché ci sono delle dipendenze tra i servizi. E bisogna controllare tutto subito, senza aspettare il monitoraggio — perché è meglio risolvere i problemi immediatamente piuttosto che aspettare che si aggravino.
7:40. L'ultimo amministratore (coordinatore) è andato a dormire. I lavori del primo giorno sono completati.
8:09. I primi sviluppatori, ingegneri nei data center e amministratori (incluso il nuovo coordinatore) hanno iniziato i lavori di ripristino.
09:37. Iniziamo a ripristinare la sala n. 7 (l'ultima).
Parallelamente continuiamo a ripristinare ciò che non abbiamo completato nelle altre sale: sostituzione di dischi/memoria/server, riparazione di tutto ciò che 'sta bruciando' nel monitoraggio, commutazione inversa dei ruoli negli schemi master-standby e altri piccoli dettagli, che però sono comunque molti.
17:08. Consentiamo tutti i lavori di routine con il production.
21:45. I lavori del secondo giorno sono completati.
09:45. Oggi è venerdì. Nel monitoraggio ci sono ancora molti problemi minori. Ci aspettano il fine settimana e tutti vogliono riposare. Continuiamo a riparare massivamente tutto ciò che è possibile. Le attività di gestione che potevano essere posticipate sono state posticipate. Nuovo coordinatore.
15:40. Improvvisamente, metà del stack Core dell'equipaggiamento di rete in un ALTRO data center è riavviato. Abbiamo escluso i server dalla rotazione per minimizzare i rischi. Non ci sono effetti per gli utenti. Successivamente si è scoperto che si trattava di uno chassis guasto. Il coordinatore sta lavorando per risolvere immediatamente due emergenze.
17:17. Il lavoro della rete in un altro data center è stato ripristinato, tutto è stato controllato. Il data center è stato riportato nella rotazione.
18:29. I lavori del terzo giorno e in generale il ripristino dopo l'emergenza sono terminati.
Epifania
04.04.2013, , "Odнокlassники" — per tre giorni il portale è stato completamente o parzialmente inaccessibile. Durante tutto questo tempo, oltre 100 persone provenienti da diverse città e da diverse aziende (ancora grazie mille!), hanno riparato migliaia di server, sia da remoto che direttamente nei data center, in modo manuale e automatico.
Abbiamo tratto delle conclusioni. Per evitare che ciò si ripeta, abbiamo svolto e continuiamo a svolgere extensive operazioni.
Quali sono le principali differenze tra l'attuale emergenza e il 404?
- Abbiamo realizzato il "Piano d'azione in caso di emergenza". Ogni trimestre svolgiamo delle esercitazioni — simuliamo una situazione di emergenza che un gruppo di amministratori (tutti a turno) deve risolvere, utilizzando il "Piano d'azione in caso di emergenza". I principali amministratori di sistema, a turno, praticano il ruolo di coordinatore.
- Ogni trimestre testiamo isolando i data center (tutti a turno) dalla rete LAN e WAN, il che ci consente di identificare tempestivamente i colli di bottiglia.
- Meno dischi guasti, perché abbiamo inasprito i requisiti: meno ore di lavoro, soglie più severe per il S.M.A.R.T.,
- Abbiamo completamente abbandonato BerkeleyDB — un vecchio database instabile che richiedeva molto tempo per il ripristino dopo il riavvio del server.
- Abbiamo ridotto il numero di server con MS SQL e diminuito la dipendenza dagli altri.
- Abbiamo il nostro , dove negli ultimi due anni stiamo migrando attivamente tutti i servizi. Il cloud semplifica notevolmente l'intero ciclo di lavoro con l'applicazione e, in caso di emergenza, fornisce strumenti unici, come:
- fermo corretto di tutte le applicazioni con un clic;
- facile migrazione delle applicazioni dai server guasti;
- avvio automatico (in ordine di priorità dei servizi) di un intero data center.
L'incidente descritto in questo articolo è stato il più grande dal 404. Certo, non tutto è andato per il verso giusto. Ad esempio, durante l'inaccessibilità del data center danneggiato, un disco di uno dei server in un altro data center è saltato, il che significa che solo una delle tre repliche nel cluster Cassandra era disponibile, causando l'impossibilità per il 4,2% degli utenti delle applicazioni mobili di accedere. Tuttavia, gli utenti già connessi continuavano a lavorare. In totale, dall'incidente sono emersi oltre 30 problemi, da banali bug a carenze nell'architettura dei servizi.
Ma la principale differenza tra l'incidente attuale e il 404 è che, mentre affrontavamo le conseguenze dell'incendio, gli utenti continuavano a scrivere e effettuare videochiamate su , giocavano, ascoltavano musica, si scambiavano regali, guardavano video, serie e canali TV su , e trasmettevano in diretta su .
Come gestite i vostri incidenti?
Fonte: habr.com
