{"id":84108,"date":"2020-06-05T07:42:44","date_gmt":"2020-06-05T05:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra"},"modified":"2020-06-05T07:42:44","modified_gmt":"2020-06-05T05:42:44","slug":"tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"\u00c8 il caso di \"spegnere\" i server, se il test di fumo del data center \"prende fuoco\"?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cosa provereste se, in un bel giorno d'estate, il data center con la vostra attrezzatura apparisse in questo modo?<\/p>\n

\"\u00c8
\n
\nCiao a tutti! Mi chiamo Dmitrij Samsonov, lavoro come amministratore di sistema senior in \"Odnoklassniki<\/a><\/noindex>\". Nella foto c'\u00e8 uno dei quattro data center in cui \u00e8 installata l'attrezzatura che gestisce il nostro progetto. Dietro queste mura ci sono circa 4.000 unit\u00e0 di hardware: server, sistemi di storage, attrezzature di rete, ecc. - quasi un terzo di tutta la nostra attrezzatura.
\nLa maggior parte dei server \u00e8 Linux. Ci sono anche alcune decine di server Windows (MS SQL) - il nostro retaggio, da cui ci stiamo allontanando gradualmente nel corso degli anni.
\nQuindi, il 5 giugno 2019 alle 14:35 gli ingegneri di uno dei nostri data center hanno segnalato un allerta incendio.
\n<\/a><\/noindex><\/p>\n

Negazione<\/h4>\n

\n14:45. I piccoli incidenti di fumi nei data center accadono pi\u00f9 frequentemente di quanto si pensi. I parametri all'interno delle sale erano nella norma, quindi la nostra prima reazione \u00e8 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.<\/p>\n

Rabbia<\/h4>\n

\nAvete 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\u00e0 il grado di fiducia nelle informazioni ottenute attraverso cinque persone?<\/p>\n

14:50. \u00c8 stata ricevuta l'informazione che il fuoco si sta avvicinando al sistema di raffreddamento<\/b>. Ma arriver\u00e0? L'amministratore di sistema di turno sta scollegando il traffico esterno dai fronti di questo data center.<\/p>\n

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\u00ec gli utenti da potenziali problemi di accesso ai servizi. Nel caso in cui si siano gi\u00e0 verificati problemi nel data center, esso viene automaticamente escluso dalla rotazione. Maggiori dettagli possono essere letti qui: Bilanciamento del carico e tolleranza ai guasti in \"Odnoklassniki\".<\/a><\/noindex><\/p><\/blockquote>\n

\nFinora, l'incendio non ci ha influenzato - n\u00e9 gli utenti n\u00e9 l'attrezzatura hanno subito danni. \u00c8 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:
\n\u00abSe ci sono dubbi, se si tratta di un incidente o meno, allora \u00e8 un incidente!<\/u>\u00bb<\/b><\/p>\n

14:53. Viene nominato un coordinatore per l'emergenza.<\/p>\n

Il coordinatore \u00e8 la persona che controlla la comunicazione tra tutti i partecipanti, valuta l'entit\u00e0 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, \u00e8 colui che gestisce l'intero processo di eliminazione dell'emergenza.<\/p><\/blockquote>\n

<\/p>\n

Mercato<\/h4>\n

\n15:01. Iniziamo a spegnere i server non collegati alla produzione.
\n15:03. Spegniamo correttamente tutti i servizi riservati.
\nQuesti includono non solo i front-end (a cui a questo punto gli utenti non accedono pi\u00f9) e i loro servizi ausiliari (logica di business, cache, ecc.), ma anche vari database con un fattore di replica di 2 o pi\u00f9 (Cassandra<\/a><\/noindex>, archivio di dati binari<\/a><\/noindex>, archivio freddo<\/a><\/noindex>, NewSQL<\/a><\/noindex> ecc.).
\n15:06. \u00c8 giunta notizia che un incendio minaccia una delle sale del data center.<\/b> In questa sala non abbiamo attrezzature, ma il fatto che il fuoco possa propagarsi dal tetto alle sale cambia radicalmente la situazione.
\n(In seguito si \u00e8 scoperto che non c'era una minaccia fisica per la sala, poich\u00e9 era ermeticamente isolata dal tetto. La minaccia era solo per il sistema di raffreddamento di quella sala.)
\n15:07. Autorizziamo l'esecuzione di comandi sui server in modalit\u00e0 accelerata senza verifiche aggiuntive (senza il nostro amato calcolatore<\/a><\/noindex>).
\n15:08. La temperatura nelle sale \u00e8 entro i limiti normali.
\n15:12. \u00c8 stato registrato un aumento della temperatura nelle sale.<\/b>
\n15:13. Pi\u00f9 della met\u00e0 dei server nel data center \u00e8 spenta. Continuiamo.
\n15:16. \u00c8 stata presa la decisione di spegnere tutta l'attrezzatura.
\n15:21. Iniziamo a scollegare l'alimentazione dai server stateless senza un'adeguata chiusura dell'applicazione e del sistema operativo.
\n15:23. Viene formata un gruppo di responsabili per MS SQL (sono pochi, la dipendenza dei servizi da loro non \u00e8 alta, ma la procedura di ripristino della funzionalit\u00e0 richiede pi\u00f9 tempo ed \u00e8 pi\u00f9 complessa rispetto a quella di Cassandra).<\/p>\n

Depressione<\/h4>\n

\n15:25. \u00c8 giunta notizia dello spegnimento dell'alimentazione in quattro sale su 16 (n\u00b0 6, 7, 8, 9).<\/b> Nelle sale 7 e 8 si trova la nostra attrezzatura. Non abbiamo informazioni su altre due nostre sale (n\u00b0 1 e 3).
\nDi 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 \u00e8 stata spenta ovunque e subito, ma solo quando necessario.
\n(In seguito si \u00e8 scoperto che l'alimentazione nelle sale 8 e 9 non era stata disattivata.)
\n15:28. Iniziamo a ripristinare i database MS SQL dai backup in altri data center.
\nQuanto tempo ci vorr\u00e0 per questo? La larghezza di banda della rete sar\u00e0 sufficiente per tutto il percorso?
\n15:37. \u00c8 stata registrata la disconnessione di alcune parti della rete.<\/b>
\nLa rete di gestione e quella di produzione sono fisicamente isolate l'una dall'altra. Se la rete di produzione \u00e8 disponibile, puoi accedere al server, arrestare l'applicazione e spegnere il sistema operativo. Se non \u00e8 disponibile, puoi accedere tramite IPMI, fermare l'applicazione e spegnere il sistema operativo. Se nessuna delle reti \u00e8 disponibile, non puoi fare nulla. 'Grazie, Capitano!', penserai.
\n'E in generale, c'\u00e8 un po' troppa confusione', potresti anche pensare.
\nIl fatto \u00e8 che i server generano anche senza incendio un'enorme quantit\u00e0 di calore. Pi\u00f9 precisamente, quando c'\u00e8 raffreddamento, generano calore, e quando non c'\u00e8, 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\u00e0 quasi certamente tutto.<\/p>\n

\"\u00c8
\n
\n15:39. Registriamo problemi con il database conf.<\/p>\n

Il database conf \u00e8 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\u00f2 comunque funzionare.<\/p><\/blockquote>\n

\n15:41. I sensori di temperatura sull'attrezzatura di rete Core registrano valori vicini ai limiti consentiti. \u00c8 un'unit\u00e0 che occupa un intero rack e garantisce il funzionamento di tutte le reti all'interno del data center.<\/p>\n

\"\u00c8
\n
\n15:42. L'issue tracker e la wiki non sono disponibili, passiamo a standby.
\nQuesta non \u00e8 la produzione, ma in caso di emergenza la disponibilit\u00e0 di qualsiasi knowledge base pu\u00f2 essere critica.
\n15:50. Si \u00e8 disattivato uno dei sistemi di monitoraggio.
\nCe 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\u00e8 monitorano solo il loro data center), altri consistono in componenti distribuiti, che sopportano senza problemi la perdita di qualsiasi data center.
\nIn questo caso, ha smesso di funzionare il sistema di rilevamento delle anomalie dei parametri di business logic<\/a><\/noindex>, che opera in modalit\u00e0 master-standby. Siamo passati a standby.<\/p>\n

Accettazione<\/h4>\n

\n15:51. Tramite IPMI abbiamo spento tutti i server senza un corretto spegnimento tranne MS SQL.
\nSiete pronti per gestire massivamente i server tramite IPMI, se necessario?<\/p>\n

\u00c8 quel momento in cui il salvataggio dell'hardware nel data center \u00e8 completato. Tutto ci\u00f2 che si poteva fare \u00e8 stato fatto. Alcuni colleghi possono riposare.<\/i>
\n16:13. \u00c8 giunta notizia che i tubi del refrigerante dell'aria condizionata sul tetto si sono rotti, il che ritarder\u00e0 l'avvio del data center dopo l'estinzione dell'incendio.<\/b>
\n16:19. Secondo le informazioni ricevute dal personale tecnico del data center, l'aumento della temperatura nelle sale \u00e8 cessato.
\n17:10. Abbiamo ripristinato il funzionamento del database conf. Ora possiamo modificare le impostazioni delle applicazioni.
\nPerch\u00e9 \u00e8 cos\u00ec importante, se tutto \u00e8 ridondante e funziona anche senza un data center?
\nIn primo luogo, non tutto \u00e8 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\u00e0 master-standby. La possibilit\u00e0 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.
\nIn secondo luogo, \u00e8 diventato chiaro che nel prossimo futuro il funzionamento del data center non sar\u00e0 completamente ripristinato, quindi era necessario adottare misure per evitare che la prolungata indisponibilit\u00e0 delle repliche portasse a ulteriori problemi come il riempimento dei dischi nei data center rimanenti.
\n17:29. \u00c8 l'ora della pizza! Abbiamo persone che lavorano, non robot.<\/p>\n

\"\u00c8
\n<\/p>\n

Riabilitazione<\/h4>\n

\n18:02. Nelle sale n. 8 (nostra), 9, 10 e 11 la temperatura si \u00e8 stabilizzata. In una di quelle che restano spente (n. 7), si trova la nostra attrezzatura e la temperatura l\u00ec continua a salire.
\n18:31. \u00c8 stato dato il via libera all'accensione dell'attrezzatura nelle sale n. 1 e 3 \u2014 queste sale non sono state toccate dall'incendio.<\/p>\n

Attualmente stiamo avviando i server nelle sale n. 1, 3, 8, partendo dai pi\u00f9 critici. Si verifica la correttezza del funzionamento di tutti i servizi avviati. Ci sono ancora problemi con la sala n. 7.<\/i><\/p>\n

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.
\n20:18. Il personale tecnico del data center sta soffiando aria nella sala senza aria condizionata tramite condotte mobili posizionate nei corridoi.
\n23: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.
\n02:56. Abbiamo avviato tutto ci\u00f2 che potevamo avviare. Stiamo effettuando un ampio controllo di tutti i servizi con test automatici.<\/p>\n

\"\u00c8
\n
\n03:02. Il condizionamento nell'ultima sala, la 7, \u00e8 stato ripristinato.
\n03:36. Abbiamo attivato i fronti nel data center per la rotazione nel DNS. Da questo momento iniziano ad arrivare il traffico degli utenti.
\nSciogliamo la maggior parte del team di amministratori per tornare a casa. Ma ne lasciamo alcuni.<\/p>\n

Piccolo FAQ:
\nD: Cosa \u00e8 successo dalle 18:31 alle 02:56?
\nR: Seguendo il \"Piano d'azione in caso di emergenza\", avviamo tutti i servizi, partendo da quelli pi\u00f9 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 \u00e8 libero e riceve un nuovo servizio dal coordinatore.
\nIl processo \u00e8 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.
\nD: Perch\u00e9 non possiamo semplicemente avviare tutto insieme e poi sistemare ci\u00f2 che emerge dal monitoraggio?
\nR: Tutto deve essere fatto gradualmente, perch\u00e9 ci sono delle dipendenze tra i servizi. E bisogna controllare tutto subito, senza attendere il monitoraggio, perch\u00e9 \u00e8 meglio risolvere i problemi immediatamente, anzich\u00e9 aspettare che si aggravino.<\/p><\/blockquote>\n

\n7:40. L'ultimo admin (coordinatore) \u00e8 andato a dormire. I lavori del primo giorno sono stati completati.
\n8:09. I primi sviluppatori, ingegneri nei data center e amministratori (incluso il nuovo coordinatore) hanno iniziato i lavori di ripristino.
\n09:37. Iniziamo a ripristinare la sala n. 7 (l'ultima).
\nParallelamente continuiamo a ripristinare ci\u00f2 che non \u00e8 stato completato nelle altre sale: sostituzione di dischi\/memoria\/server, riparazione di tutto ci\u00f2 che \"brucia\" nel monitoraggio, inversione dei ruoli negli schemi master-standby e altre piccole cose, che comunque sono numerose.
\n17:08. Permettiamo tutte le operazioni standard con il production.
\n21:45. I lavori del secondo giorno sono stati completati.
\n09:45. Oggi \u00e8 venerd\u00ec. Nel monitoraggio ci sono ancora molti piccoli problemi. Il fine settimana \u00e8 alle porte, tutti vogliono riposare. Continuiamo a riparare a tappeto tutto ci\u00f2 che \u00e8 possibile. I compiti amministrativi che potevano essere rimandati sono stati rimandati. Il coordinatore \u00e8 nuovo.
\n15:40. Inaspettatamente si \u00e8 riavviato met\u00e0 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\u00f9 tardi si \u00e8 scoperto che si trattava di uno chassis difettoso. Il coordinatore sta lavorando per riparare due guasti contemporaneamente.
\n17:17. Il funzionamento della rete in un altro data center \u00e8 stato ripristinato, tutto \u00e8 stato controllato. Il data center \u00e8 stato reinserito nella rotazione.
\n18:29. I lavori del terzo giorno e il ripristino complessivo dopo l'emergenza sono stati completati.<\/p>\n

Postfazione<\/h4>\n

\n04.04.2013, il giorno dell'errore 404<\/a><\/noindex>, \"Odnoklassniki\" ha subito il pi\u00f9 grande guasto<\/a><\/noindex> \u2014per tre giorni il portale \u00e8 stato completamente o parzialmente non disponibile. Durante tutto questo tempo, pi\u00f9 di 100 persone da diverse citt\u00e0, da diverse aziende (ancora una volta, grazie!), hanno riparato migliaia di server in remoto e direttamente nei data center, manualmente e automaticamente.
\nAbbiamo tratto delle conclusioni. Per evitare che ci\u00f2 si ripeta, abbiamo condotto e continuiamo a condurre fino ad oggi ampie riparazioni.<\/p>\n

Quali sono le principali differenze tra il guasto attuale e il 404?<\/p>\n