{"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 opportuno 'spegnere' i server se il test di fumo del data center ha segnalato problemi?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cosa pensereste se, un bel giorno d'estate, il data center con le vostre attrezzature apparisse in questo modo?<\/p>\n

\"\u00c8
\n
\nCiao a tutti! Mi chiamo Dmitry Samsonov e lavoro come amministratore di sistema senior presso \"Odnoklassniki<\/a><\/noindex>\". 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\u00e0: server, sistemi di storage, attrezzature di rete, ecc. \u2014 quasi un terzo di tutta la nostra attrezzatura.
\nLa maggior parte dei server utilizza Linux. Ci sono anche alcune decine di server Windows (MS SQL) \u2014 il nostro lascito, dal quale ci stiamo gradualmente disfacendo da anni.
\nDunque, il 5 giugno 2019 alle 14:35, gli ingegneri di uno dei nostri data center hanno segnalato un allarme incendio.
\n<\/a><\/noindex><\/p>\n

Negazione<\/h4>\n

\n14:45. Gli incidenti minori di fumi nei data center accadono pi\u00f9 frequentemente di quanto si possa pensare. I valori all'interno delle sale erano nella norma, quindi la nostra prima reazione \u00e8 stata relativamente calma: abbiamo imposto un divieto di lavoro su produzione, cio\u00e8 su qualsiasi modifica delle configurazioni, distribuzioni di nuove versioni, ecc., a meno che non riguardassero la riparazione di qualcosa.<\/p>\n

Rabbia<\/h4>\n

\nAvete mai provato a chiedere ai vigili del fuoco dove esattamente sul tetto \u00e8 scoppiato l'incendio, o a salire sulla copertura in fiamme per valutare la situazione? Quale sar\u00e0 il grado di fiducia nelle informazioni ottenute attraverso cinque persone?<\/p>\n

14:50. Sono arrivate notizie che il fuoco si sta avvicinando al sistema di raffreddamento.<\/b>Ma arriver\u00e0? L'amministratore di sistema di guardia sta estraendo il traffico esterno dai fronti di questo data center.<\/p>\n

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

\nFinora l'incendio non ha avuto alcun impatto su di noi \u2014 n\u00e9 gli utenti n\u00e9 l'attrezzatura hanno subito danni. \u00c8 un'emergenza? La prima sezione del documento \"Piano di azione in caso di emergenza\" d\u00e0 una definizione del concetto di \"Emergenza\", e termina con queste parole:
\n\u00abIn caso di dubbi, se c'\u00e8 un'emergenza o meno, \u00e8 un'emergenza!<\/u>\u00bb<\/b><\/p>\n

14:53. Viene nominato un coordinatore di 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 di azione in caso di emergenza\", recluta il personale necessario, controlla il completamento della riparazione, soprattutto delega qualsiasi compito. In altre parole, \u00e8 la persona che gestisce l'intero processo di risoluzione dell'emergenza.<\/p><\/blockquote>\n

<\/p>\n

Mercanteggiamento<\/h4>\n

\n15:01. Iniziamo a spegnere i server che non sono collegati alla produzione.
\n15:03. Spegniamo correttamente tutti i servizi riservati.
\nQuesti comprendono non solo i fronti (ai quali a questo punto gli utenti non hanno gi\u00e0 accesso) e i loro servizi ausiliari (logica di business, cache, ecc.), ma anche diversi database con un fattore di replica di 2 o superiore (Cassandra<\/a><\/noindex>, storage di dati binari<\/a><\/noindex>, storage freddo<\/a><\/noindex>, NewSQL<\/a><\/noindex> e altro).
\n15:06. Sono arrivate notizie che il fuoco 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 notevolmente la situazione.
\n(Si \u00e8 poi scoperto che non c'era alcuna minaccia fisica per la sala, poich\u00e9 era ermeticamente isolata dal tetto. L'unica minaccia era per il sistema di raffreddamento di quella sala.)
\n15:07. Autorizziamo l'esecuzione di comandi sui server in modo accelerato senza ulteriori controlli (senza il nostro amato calcolatore.<\/a><\/noindex>).
\n15:08. La temperatura nelle sale \u00e8 normale.
\n15:12. \u00c8 stato registrato un aumento della temperatura nelle sale.<\/b>
\n15:13. Pi\u00f9 della met\u00e0 dei server nel data center sono spenti. Continuiamo.
\n15:16. \u00c8 stata presa la decisione di spegnere tutta l'attrezzatura.
\n15:21. Iniziamo a scollegare l'alimentazione dei server stateless senza un correttore di spegnimento dell'applicazione e del sistema operativo.
\n15:23. Viene assegnato un gruppo responsabile per MS SQL (ce ne sono pochi, la dipendenza dei servizi da loro non \u00e8 alta, ma la procedura di ripristino \u00e8 pi\u00f9 lunga e complessa rispetto a, ad esempio, a Cassandra).<\/p>\n

Depressione<\/h4>\n

\n15:25. Sono arrivate notizie della disattivazione dell'alimentazione in quattro sale su 16 (n. 6, 7, 8, 9).<\/b> Nelle sale 7 e 8 si trovano le nostre attrezzature. Non abbiamo informazioni su altre due sale (n. 1 e 3).
\nDi 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 \u00e8 stata disattivata ovunque e immediatamente, ma solo secondo necessit\u00e0.
\n(Si \u00e8 poi scoperto che l'alimentazione nelle sale 8 e 9 non era stata mai disattivata.)
\n15:28. Iniziamo a ripristinare i database MS SQL da backup in altri data center.
\nQuanto tempo sar\u00e0 necessario? La larghezza di banda della rete sar\u00e0 sufficiente lungo tutto il percorso?
\n15:37. \u00c8 stato registrato un'interruzione in alcune sezioni della rete.<\/b>
\nLa rete di gestione e quella di produzione sono fisicamente isolate. Se la rete di produzione \u00e8 disponibile, puoi accedere al server, fermare 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 due reti \u00e8 disponibile, non puoi fare nulla. \"Grazie, capitano!\", penserai.
\n\"E anche, che caos!\", potresti pensare anche tu.
\nIl punto \u00e8 che i server generano un'enorme quantit\u00e0 di calore, anche senza incendi. Pi\u00f9 precisamente, quando c'\u00e8 il raffreddamento, generano calore, e quando non c'\u00e8, creano un caldo infernale che nel migliore dei casi scioglier\u00e0 parte dell'hardware e spegner\u00e0 l'altra parte, e nel peggiore... provocher\u00e0 un incendio nella sala, che praticamente garantir\u00e0 la distruzione di tutto.<\/p>\n

\"\u00c8
\n
\n15:39. Registriamo i 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 stesso pu\u00f2 comunque funzionare.<\/p><\/blockquote>\n

\n15:41. I sensori di temperatura sull'attrezzatura di rete Core registrano valori vicini ai limiti consentiti. Questa \u00e8 una scatola che occupa un\u2019intera rack e gestisce tutte le reti all'interno del data center.<\/p>\n

\"\u00c8
\n
\n15:42. Issue tracker e wiki non sono disponibili, passiamo a standby.
\nNon \u00e8 produzione, ma in caso di emergenza la disponibilit\u00e0 di qualsiasi knowledge base pu\u00f2 essere critica.
\n15:50. Si \u00e8 spenta una delle sistema di monitoraggio.
\nCe 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\u00e8 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.
\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. Attraverso IPMI abbiamo spento tutti i server senza un corretto shutdown, tranne MS SQL.
\nSiete pronti a gestire i server in modo massivo tramite IPMI se necessario?<\/p>\n

Questo \u00e8 il 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 prendersi una pausa.<\/i>
\n16:13. \u00c8 arrivata la notizia che i tubi del refrigerante dei condizionatori sul tetto si sono rotti: questo ritarder\u00e0 l'avvio del data center dopo la riparazione dell'incendio.<\/b>
\n16:19. Secondo le informazioni ricevute dal personale tecnico del data center, l'aumento della temperatura nelle sale si \u00e8 arrestato.
\n17:10. Abbiamo ripristinato il funzionamento del database conf. Ora possiamo cambiare le impostazioni delle applicazioni.
\nPerch\u00e9 \u00e8 cos\u00ec importante, se tutto \u00e8 ridondante e funziona anche senza un data center?
\nInnanzitutto, non tutto \u00e8 ridondante. Ci sono vari servizi secondari che attualmente non reagiscono bene alla perdita 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' emergenza sugli utenti, anche in condizioni difficili.
\nIn secondo luogo, \u00e8 diventato chiaro che nel prossimo futuro il funzionamento del data center non si riprender\u00e0 completamente, quindi era necessario adottare misure affinch\u00e9 la prolungata indisponibilit\u00e0 delle repliche non portasse a ulteriori problemi, come il riempimento dei dischi negli altri data center.
\n17:29. \u00c8 tempo di pizza! Abbiamo persone che lavorano, non robot.<\/p>\n

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

Riabilitazione<\/h4>\n

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

Attualmente, stiamo avviando i server nelle sale 1, 3 e 8, iniziando dai pi\u00f9 critici. Viene verificata 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 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.
\n20:18. Il personale tecnico del data center sta soffiando aria nella sala senza condizionatori attraverso condotti mobili, installati attraverso i corridoi.
\n23: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.
\n02:56. Abbiamo avviato tutto ci\u00f2 che era possibile. Stiamo facendo un grande controllo di tutti i servizi con test automatici.<\/p>\n

\"\u00c8
\n
\n03:02. L'aria condizionata nell'ultima sala, la settima, \u00e8 stata ripristinata.
\n03:36. Abbiamo introdotto i server nel data center nella rotazione DNS. Da questo momento inizia ad arrivare il traffico degli utenti.
\nStiamo rimandando la maggior parte del team di amministratori a casa. Ma alcuni li teniamo.<\/p>\n

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

\n7:40. L'ultimo amministratore (coordinatore) \u00e8 andato a dormire. I lavori del primo giorno sono 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 abbiamo completato nelle altre sale: sostituzione di dischi\/memoria\/server, riparazione di tutto ci\u00f2 che 'sta bruciando' nel monitoraggio, commutazione inversa dei ruoli negli schemi master-standby e altri piccoli dettagli, che per\u00f2 sono comunque molti.
\n17:08. Consentiamo tutti i lavori di routine con il production.
\n21:45. I lavori del secondo giorno sono completati.
\n09:45. Oggi \u00e8 venerd\u00ec. Nel monitoraggio ci sono ancora molti problemi minori. Ci aspettano il fine settimana e tutti vogliono riposare. Continuiamo a riparare massivamente tutto ci\u00f2 che \u00e8 possibile. Le attivit\u00e0 di gestione che potevano essere posticipate sono state posticipate. Nuovo coordinatore.
\n15:40. Improvvisamente, met\u00e0 del stack Core dell'equipaggiamento di rete in un ALTRO data center \u00e8 riavviato. Abbiamo escluso i server dalla rotazione per minimizzare i rischi. Non ci sono effetti per gli utenti. Successivamente si \u00e8 scoperto che si trattava di uno chassis guasto. Il coordinatore sta lavorando per risolvere immediatamente due emergenze.
\n17:17. Il lavoro della rete in un altro data center \u00e8 stato ripristinato, tutto \u00e8 stato controllato. Il data center \u00e8 stato riportato nella rotazione.
\n18:29. I lavori del terzo giorno e in generale il ripristino dopo l'emergenza sono terminati.<\/p>\n

Epifania<\/h4>\n

\n04.04.2013, nel giorno del 404\u00b0 errore<\/a><\/noindex>, \"Od\u043d\u043e\u043alass\u043d\u0438\u043a\u0438\" ha subito la pi\u00f9 grande emergenza<\/a><\/noindex> \u2014 per tre giorni il portale \u00e8 stato completamente o parzialmente inaccessibile. Durante tutto questo tempo, oltre 100 persone provenienti da diverse citt\u00e0 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.
\nAbbiamo tratto delle conclusioni. Per evitare che ci\u00f2 si ripeta, abbiamo svolto e continuiamo a svolgere extensive operazioni.<\/p>\n

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