Cosa provereste se, in un bel giorno d'estate, il data center con la vostra attrezzatura apparisse in questo modo?
Ciao a tutti! Mi chiamo Dmitrij Samsonov, lavoro come amministratore di sistema senior in "". Nella foto c'è uno dei quattro data center in cui è installata l'attrezzatura che gestisce il nostro progetto. Dietro queste mura ci sono circa 4.000 unità di hardware: server, sistemi di storage, attrezzature di rete, ecc. - quasi un terzo di tutta la nostra attrezzatura.
La maggior parte dei server è Linux. Ci sono anche alcune decine di server Windows (MS SQL) - il nostro retaggio, da cui ci stiamo allontanando gradualmente nel corso degli anni.
Quindi, il 5 giugno 2019 alle 14:35 gli ingegneri di uno dei nostri data center hanno segnalato un allerta incendio.
Negazione
14:45. I piccoli incidenti di fumi nei data center accadono più frequentemente di quanto si pensi. I parametri all'interno delle sale erano nella norma, quindi la nostra prima reazione è stata relativamente tranquilla: abbiamo imposto un divieto sulle operazioni in produzione, ossia su qualsiasi modifica delle configurazioni, rilascio di nuove versioni e simili, ad eccezione di lavori legati alla riparazione di qualcosa.
Rabbia
Avete mai provato a chiedere ai pompieri dove esattamente sul tetto sia scoppiato l'incendio, o a salire sul tetto in fiamme per valutare la situazione? Quale sarà il grado di fiducia nelle informazioni ottenute attraverso cinque persone?
14:50. È stata ricevuta l'informazione che il fuoco si sta avvicinando al sistema di raffreddamento. Ma arriverà? L'amministratore di sistema di turno sta scollegando il traffico esterno dai fronti di questo data center.
Attualmente, i fronti di tutti i nostri servizi sono duplicati in tre data center, utilizzando un bilanciamento a livello DNS, 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 siano già verificati problemi nel data center, esso viene automaticamente escluso dalla rotazione. Maggiori dettagli possono essere letti qui:
Finora, l'incendio non ci ha influenzato - né gli utenti né l'attrezzatura hanno subito danni. È un incidente? La prima sezione del documento "Piano d'azione in caso di emergenza" fornisce una definizione del concetto di "incidente", e termina la sezione nel seguente modo:
«Se ci sono dubbi, se si tratta di un incidente o meno, allora è un incidente!»
14:53. Viene nominato un coordinatore per l'emergenza.
Il coordinatore è la persona che controlla la comunicazione tra tutti i partecipanti, valuta l'entità dell'emergenza, utilizza il "Piano d'azione per l'emergenza", coinvolge il personale necessario, supervisiona il completamento delle riparazioni e, soprattutto, delega qualsiasi compito. In altre parole, è colui che gestisce l'intero processo di eliminazione dell'emergenza.
Mercato
15:01. Iniziamo a spegnere i server non collegati alla produzione.
15:03. Spegniamo correttamente tutti i servizi riservati.
Questi includono non solo i front-end (a cui a questo punto gli utenti non accedono più) e i loro servizi ausiliari (logica di business, cache, ecc.), ma anche vari database con un fattore di replica di 2 o più (, , , ecc.).
15:06. È giunta notizia che un incendio 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 radicalmente la situazione.
(In seguito si è scoperto che non c'era una minaccia fisica per la sala, poiché era ermeticamente isolata dal tetto. La minaccia era solo per il sistema di raffreddamento di quella sala.)
15:07. Autorizziamo l'esecuzione di comandi sui server in modalità accelerata senza verifiche aggiuntive ().
15:08. La temperatura nelle sale è entro i limiti normali.
15:12. È stato registrato un aumento della temperatura nelle sale.
15:13. Più della metà dei server nel data center è spenta. Continuiamo.
15:16. È stata presa la decisione di spegnere tutta l'attrezzatura.
15:21. Iniziamo a scollegare l'alimentazione dai server stateless senza un'adeguata chiusura dell'applicazione e del sistema operativo.
15:23. Viene formata un gruppo di responsabili per MS SQL (sono pochi, la dipendenza dei servizi da loro non è alta, ma la procedura di ripristino della funzionalità richiede più tempo ed è più complessa rispetto a quella di Cassandra).
Depressione
15:25. È giunta notizia dello spegnimento dell'alimentazione in quattro sale su 16 (n° 6, 7, 8, 9). Nelle sale 7 e 8 si trova la nostra attrezzatura. Non abbiamo informazioni su altre due nostre sale (n° 1 e 3).
Di solito, in caso di incendi, l'alimentazione viene subito interrotta, ma in questo caso, grazie al lavoro coordinato dei vigili del fuoco e del personale tecnico del data center, non è stata spenta ovunque e subito, ma solo quando necessario.
(In seguito si è scoperto che l'alimentazione nelle sale 8 e 9 non era stata disattivata.)
15:28. Iniziamo a ripristinare i database MS SQL dai backup in altri data center.
Quanto tempo ci vorrà per questo? La larghezza di banda della rete sarà sufficiente per tutto il percorso?
15:37. È stata registrata la disconnessione di alcune parti della rete.
La rete di gestione e quella di produzione sono fisicamente isolate l'una dall'altra. Se la rete di produzione è disponibile, puoi accedere al server, arrestare 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 reti è disponibile, non puoi fare nulla. 'Grazie, Capitano!', penserai.
'E in generale, c'è un po' troppa confusione', potresti anche pensare.
Il fatto è che i server generano anche senza incendio un'enorme quantità di calore. Più precisamente, quando c'è raffreddamento, generano calore, e quando non c'è, creano un'inferno che nel migliore dei casi fonde alcune attrezzature e spegne altre, mentre nel peggiore dei casi... provoca un incendio all'interno della sala, che distruggerà quasi certamente tutto.
15:39. Registriamo 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 può comunque funzionare.
15:41. I sensori di temperatura sull'attrezzatura di rete Core registrano valori vicini ai limiti consentiti. È un'unità che occupa un intero rack e garantisce il funzionamento di tutte le reti all'interno del data center.
15:42. L'issue tracker e la wiki non sono disponibili, passiamo a standby.
Questa non è la produzione, ma in caso di emergenza la disponibilità di qualsiasi knowledge base può essere critica.
15:50. Si è disattivato uno dei sistemi di monitoraggio.
Ce ne sono diversi, e ciascuno si occupa di differenti aspetti del funzionamento dei servizi. Alcuni di essi sono configurati per lavorare autonomamente all'interno di ogni data center (cioè monitorano solo il loro data center), altri consistono in componenti distribuiti, che sopportano senza problemi la 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. Tramite IPMI abbiamo spento tutti i server senza un corretto spegnimento tranne MS SQL.
Siete pronti per gestire massivamente i server tramite IPMI, se necessario?
È quel momento in cui il salvataggio dell'hardware nel data center è completato. Tutto ciò che si poteva fare è stato fatto. Alcuni colleghi possono riposare.
16:13. È giunta notizia che i tubi del refrigerante dell'aria condizionata sul tetto si sono rotti, il che ritarderà l'avvio del data center dopo l'estinzione dell'incendio.
16:19. Secondo le informazioni ricevute dal personale tecnico del data center, l'aumento della temperatura nelle sale è cessato.
17:10. Abbiamo ripristinato il funzionamento del database conf. Ora possiamo modificare le impostazioni delle applicazioni.
Perché è così importante, se tutto è ridondante e funziona anche senza un data center?
In primo luogo, non tutto è ridondante. Ci sono vari servizi secondari che non riescono ancora a gestire bene il guasto 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 guasto sugli utenti, anche in condizioni difficili.
In secondo luogo, è diventato chiaro che nel prossimo futuro il funzionamento del data center non sarà completamente ripristinato, quindi era necessario adottare misure per evitare che la prolungata indisponibilità delle repliche portasse a ulteriori problemi come il riempimento dei dischi nei data center rimanenti.
17:29. È l'ora della pizza! Abbiamo persone che lavorano, non robot.
Riabilitazione
18:02. Nelle sale n. 8 (nostra), 9, 10 e 11 la temperatura si è stabilizzata. In una di quelle che restano spente (n. 7), si trova la nostra attrezzatura e la temperatura lì continua a salire.
18:31. È stato dato il via libera all'accensione dell'attrezzatura nelle sale n. 1 e 3 — queste sale non sono state toccate dall'incendio.
Attualmente stiamo avviando i server nelle sale n. 1, 3, 8, partendo dai più critici. Si verifica 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 si trova solo la nostra attrezzatura) molti server non sono stati spenti. Secondo i nostri dati, restano accesi 26 server. Dopo un ulteriore controllo troviamo 58 server.
20:18. Il personale tecnico del data center sta soffiando aria nella sala senza aria condizionata tramite condotte mobili posizionate nei corridoi.
23:08. Liberato il primo admin per tornare a casa. Qualcuno deve riposarsi di notte per continuare il lavoro domani. Poi liberiamo anche altri amministratori e sviluppatori.
02:56. Abbiamo avviato tutto ciò che potevamo avviare. Stiamo effettuando un ampio controllo di tutti i servizi con test automatici.
03:02. Il condizionamento nell'ultima sala, la 7, è stato ripristinato.
03:36. Abbiamo attivato i fronti nel data center per la rotazione nel DNS. Da questo momento iniziano ad arrivare il traffico degli utenti.
Sciogliamo la maggior parte del team di amministratori per tornare a casa. Ma ne lasciamo alcuni.
Piccolo FAQ:
D: Cosa è successo dalle 18:31 alle 02:56?
R: Seguendo il "Piano d'azione in caso di emergenza", avviamo tutti i servizi, partendo da quelli più importanti. Il coordinatore nella chat assegna un servizio a un amministratore libero, che verifica se il sistema operativo e l'applicazione si sono avviati, se ci sono errori, se i parametri sono nella norma. Una volta completato l'avvio, comunica in chat che è libero e riceve un nuovo servizio dal coordinatore.
Il processo è ulteriormente rallentato da attrezzature guaste. Anche se l'arresto del sistema operativo e lo spegnimento dei server sono avvenuti correttamente, alcuni server non tornano online a causa di dischi, memoria o chassis guasti in modo imprevisto. In caso di blackout, la percentuale di guasti aumenta.
D: Perché non possiamo semplicemente avviare tutto insieme e poi sistemare ciò che emerge dal monitoraggio?
R: Tutto deve essere fatto gradualmente, perché ci sono delle dipendenze tra i servizi. E bisogna controllare tutto subito, senza attendere il monitoraggio, perché è meglio risolvere i problemi immediatamente, anziché aspettare che si aggravino.
7:40. L'ultimo admin (coordinatore) è andato a dormire. I lavori del primo giorno sono stati 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 è stato completato nelle altre sale: sostituzione di dischi/memoria/server, riparazione di tutto ciò che "brucia" nel monitoraggio, inversione dei ruoli negli schemi master-standby e altre piccole cose, che comunque sono numerose.
17:08. Permettiamo tutte le operazioni standard con il production.
21:45. I lavori del secondo giorno sono stati completati.
09:45. Oggi è venerdì. Nel monitoraggio ci sono ancora molti piccoli problemi. Il fine settimana è alle porte, tutti vogliono riposare. Continuiamo a riparare a tappeto tutto ciò che è possibile. I compiti amministrativi che potevano essere rimandati sono stati rimandati. Il coordinatore è nuovo.
15:40. Inaspettatamente si è riavviato metà dello stack di hardware di rete in UN ALTRO data center. Abbiamo escluso i fronti dalla rotazione per ridurre i rischi. Non ci sono effetti per gli utenti. Più tardi si è scoperto che si trattava di uno chassis difettoso. Il coordinatore sta lavorando per riparare due guasti contemporaneamente.
17:17. Il funzionamento della rete in un altro data center è stato ripristinato, tutto è stato controllato. Il data center è stato reinserito nella rotazione.
18:29. I lavori del terzo giorno e il ripristino complessivo dopo l'emergenza sono stati completati.
Postfazione
04.04.2013, , "Odnoklassniki" —per tre giorni il portale è stato completamente o parzialmente non disponibile. Durante tutto questo tempo, più di 100 persone da diverse città, da diverse aziende (ancora una volta, grazie!), hanno riparato migliaia di server in remoto e direttamente nei data center, manualmente e automaticamente.
Abbiamo tratto delle conclusioni. Per evitare che ciò si ripeta, abbiamo condotto e continuiamo a condurre fino ad oggi ampie riparazioni.
Quali sono le principali differenze tra il guasto attuale e il 404?
- Abbiamo creato un "Piano di emergenza". Ogni trimestre eseguiamo esercitazioni — simuliamo una situazione di emergenza che un gruppo di amministratori (tutti a turno) deve risolvere utilizzando il "Piano di emergenza". Gli amministratori di sistema senior si alternano nel ruolo di coordinatore.
- Ogni trimestre, in modalità di test, isolo i data center (tutti a turno) per le reti LAN e WAN, il che consente di identificare in tempo i colli di bottiglia.
- Meno dischi rotti, perché abbiamo inasprito le normative: meno ore di funzionamento, soglie più severe per S.M.A.R.T.,
- Abbiamo completamente abbandonato BerkeleyDB — un database vecchio e instabile, che richiedeva molto tempo per riprendersi dopo il riavvio del server.
- Abbiamo ridotto il numero di server con MS SQL e diminuito la dipendenza dagli altri.
- Abbiamo il nostro , dove stiamo migrando attivamente tutti i servizi da due anni. Il cloud semplifica notevolmente l'intero ciclo di lavoro con l'applicazione e, in caso di emergenza, offre strumenti unici come:
- fermata corretta di tutte le applicazioni con un solo clic;
- migrazione semplice delle applicazioni da server malfunzionanti;
- avvio automatico e ordinato (in base alla priorità dei servizi) dell'intero data center.
L'incidente descritto in questo articolo è stato il più grande dal giorno 404. Certamente, non tutto è andato liscio. Ad esempio, durante l'inaccessibilità del data center danneggiato, in un altro data center è andato in crash un disco su uno dei server, il che ha lasciato disponibile solo una delle tre repliche nel cluster Cassandra, impedendo il login al 4,2% degli utenti delle applicazioni mobili. Tuttavia, gli utenti già connessi continuavano a lavorare. In totale, sono state riscontrate oltre 30 problematiche a seguito dell'incidente — da bug banali a carenze architetturali dei servizi.
Ma la principale differenza tra l'attuale incidente e il 404 è che mentre stavamo gestendo le conseguenze dell'incendio, gli utenti continuavano a comunicare e a fare videochiamate in , giocavano, ascoltavano musica, si scambiavano regali, guardavano video, serie e canali TV in , e trasmettevano in streaming su .
E come si svolgono i vostri incidenti?
Fonte: habr.com
