{"id":34264,"date":"2019-10-31T21:57:17","date_gmt":"2019-10-31T18:57:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom\/"},"modified":"2019-10-31T21:57:17","modified_gmt":"2019-10-31T18:57:17","slug":"glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/glavnaya-prichina-avarij-v-data-tsentrah-prokladka-mezhdu-kompyuterom-i-kreslom","title":{"rendered":"La principale causa di incidenti nei data center \u00e8 il cablaggio tra il computer e la sedia.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il tema dei grandi incidenti nei moderni data center solleva domande a cui non erano state date risposte nel primo articolo \u2014 abbiamo deciso di approfondire l'argomento.<\/em><\/p>\n

\n\"La<\/a><\/noindex><\/p>\n

Se crediamo alle statistiche dell'Uptime Institute, la maggior parte degli incidenti nei data center \u00e8 legata ai guasti del sistema di alimentazione \u2014 rappresentano il 39% degli eventi. Seguono il fattore umano, che contribuisce al 24% degli incidenti. La terza causa pi\u00f9 significativa (15%) \u00e8 stata il guasto del sistema di climatizzazione, mentre al quarto posto (12%) ci sono stati i disastri naturali. La percentuale totale di altri problemi ammonta solo al 10%. Senza mettere in dubbio i dati di un'organizzazione rispettabile, mettiamo in evidenza degli elementi comuni tra i diversi incidenti e cerchiamo di capire se fossero evitabili. Spoiler: nella maggior parte dei casi s\u00ec.<\/p>\n

<\/p>\n

La scienza dei contatti<\/h2>\n

<\/p>\n

In poche parole, ci sono solo due problemi con l'alimentazione elettrica: o non c'\u00e8 contatto dove dovrebbe esserci, oppure c'\u00e8 contatto dove non dovrebbe essercene. Si pu\u00f2 discutere a lungo sull'affidabilit\u00e0 dei moderni sistemi di alimentazione ininterrotta, ma non offre sempre la soluzione. Prendiamo ad esempio il noto caso del centro dati di British Airways, di propriet\u00e0 della societ\u00e0 madre International Airlines Group. Nelle vicinanze dell'aeroporto di Heathrow si trovano due di queste strutture: Boadicea House e Comet House. Nel primo di essi, il 27 maggio 2017, si \u00e8 verificata una disconnessione accidentale dell'alimentazione, che ha portato a un sovraccarico e al guasto del sistema UPS. Di conseguenza, parte dell'attrezzatura IT \u00e8 stata fisicamente danneggiata, e ci sono voluti tre giorni per risolvere l'ultimo guasto. <\/p>\n

<\/p>\n

Le compagnie aeree hanno dovuto cancellare o spostare oltre mille voli, circa 75.000 passeggeri non sono riusciti a decollare in tempo: per il risarcimento sono stati spesi 128 milioni di dollari, senza contare i costi necessari per ripristinare il funzionamento dei data center. La questione delle cause del blackout rimane poco chiara. Se si crede alle dichiarazioni dell'amministratore delegato di International Airlines Group, Willie Walsh, l'incidente \u00e8 dovuto a un errore degli ingegneri. Tuttavia, il sistema di alimentazione ininterrotta avrebbe dovuto poter sostenere un'interruzione simile: \u00e8 proprio per questo motivo che \u00e8 stato installato. I data center erano gestiti da specialisti della societ\u00e0 di outsourcing CBRE Managed Services, quindi British Airways ha tentato di recuperare la somma dei danni tramite il tribunale di Londra. <\/p>\n

\n\"La<\/p>\n

Le interruzioni di corrente si verificano secondo scenari simili: inizialmente c'\u00e8 un'interruzione causata dal fornitore di energia elettrica, a volte a causa di condizioni meteorologiche avverse o problemi interni (inclusi errori del personale), e poi il sistema di alimentazione ininterrotta non riesce a gestire il carico o un'interruzione temporanea dell'onda sinusoidale provoca il malfunzionamento di molti servizi, il ripristino dei quali richiede un'enorme quantit\u00e0 di tempo e denaro. \u00c8 possibile evitare interruzioni simili? Assolutamente. Se si progetta il sistema correttamente, ma anche i creatori di grandi data center non sono immuni agli errori. <\/p>\n

<\/p>\n

Fattore umano<\/h2>\n

<\/p>\n

Quando le azioni errate del personale del data center diventano la causa diretta di un incidente, i problemi colpiscono spesso (ma non sempre) la parte software dell\u2019infrastruttura IT. Tali guasti si verificano anche nelle grandi aziende. Nel febbraio 2017, un errore di digitazione di un membro del team di supporto tecnico di uno dei data center ha causato lo spegnimento di una parte dei server di Amazon Web Services. L'errore \u00e8 avvenuto durante il debug del processo di fatturazione dei clienti del servizio di archiviazione cloud Amazon Simple Storage Service (S3). Il dipendente stava cercando di eliminare alcuni dei server virtuali utilizzati dal sistema di fatturazione, ma ha colpito un cluster pi\u00f9 grande.<\/p>\n

\n\"La<\/p>\n

A causa di un errore dell'ingegnere, sono stati cancellati i server su cui erano attivati importanti moduli software del servizio di archiviazione cloud di Amazon. In particolare, \u00e8 stata colpita la sottosistema di indicizzazione, contenente informazioni sui metadati e sulla posizione di tutti gli oggetti S3 nella regione americana US-EAST-1. L'incidente ha anche coinvolto il sottosistema utilizzato per l'hosting dei dati e la gestione dello spazio di archiviazione disponibile. Dopo la cancellazione delle macchine virtuali, queste due sottosistemi hanno richiesto un riavvio completo, e gli ingegneri di Amazon hanno dovuto affrontare una sorpresa: per un lungo periodo, il servizio di archiviazione cloud pubblico non \u00e8 stato in grado di gestire le richieste dei clienti. <\/p>\n

<\/p>\n

L'effetto si \u00e8 rivelato vasto, poich\u00e9 molti grandi servizi utilizzano Amazon S3. Le interruzioni hanno colpito Trello, Coursera, IFTTT e, cosa pi\u00f9 sgradevole, i servizi dei principali partner di Amazon nella lista S&P 500. Valutare i danni in tali situazioni \u00e8 complicato, ma si stima che siano nell'ordine di centinaia di milioni di dollari USA. Come potete vedere, per mettere fuori uso il servizio della pi\u00f9 grande piattaforma cloud, basta un comando errato. Questo non \u00e8 un caso isolato, il 16 maggio 2019, durante lavori di manutenzione, il servizio Yandex.Cloud ha cancellato<\/a><\/noindex> macchine virtuali degli utenti nella zona ru-central1-c, che erano state almeno una volta nello stato SUSPENDED. Qui sono gi\u00e0 stati compromessi i dati dei clienti, parte dei quali \u00e8 stata persa in modo irreversibile. Certo, le persone non sono perfette, ma i moderni sistemi di sicurezza informatica sanno ormai controllare le azioni degli utenti privilegiati prima che vengano eseguiti i comandi da loro inseriti. Se soluzioni di questo tipo fossero implementate in Yandex o Amazon, incidenti simili potrebbero essere evitati.<\/p>\n

\n\"La<\/p>\n

raffreddamento congelato<\/h2>\n

<\/p>\n

A gennaio 2017 si \u00e8 verificato un grave incidente nel data center di Dmitrov dell'azienda \"Megafon\". In quel periodo, la temperatura nella regione di Mosca \u00e8 scesa fino a -35 \u00b0C, causando il malfunzionamento dei sistemi di raffreddamento dell'impianto. Il servizio stampa dell'operatore non ha rilasciato molte informazioni sulle cause dell'incidente: le aziende russe tendono a essere estremamente reticenti nel parlare di incidenti nei propri impianti, e in termini di trasparenza restiamo molto indietro rispetto all'Occidente. Nei social network circolava la voce che il fluido refrigerante fosse congelato nei tubi posati lungo la strada, causando una perdita di etilenglicole. Se si pu\u00f2 credere a questa versione, il servizio di manutenzione non \u00e8 riuscito, a causa delle lunghe festivit\u00e0, a ricevere rapidamente 30 tonnellate di refrigerante e ha tentato di cavarsela con mezzi di fortuna, organizzando un raffreddamento improvvisato in violazione delle norme operative del sistema. I forti freddi hanno aggravato il problema: a gennaio, in Russia \u00e8 arrivata all'improvviso l'inverno, sebbene nessuno lo aspettasse. Di conseguenza, il personale ha dovuto disattivare parte delle rack server, rendendo alcuni servizi dell'operatore non disponibili per due giorni. <\/p>\n

\n\"La<\/p>\n

Probabilmente si pu\u00f2 parlare anche di un'anomalia climatica, ma tali gelate non sono affatto insolite per la regione metropolitana. Durante l'inverno, la temperatura nella regione di Mosca pu\u00f2 scendere anche a valori molto pi\u00f9 bassi, perci\u00f2 i data center sono costruiti tenendo conto di un funzionamento affidabile a \u221242 \u00b0C. Pi\u00f9 spesso, i sistemi di raffreddamento si guastano al freddo a causa di una concentrazione di glicoli non sufficientemente alta e di un eccesso d'acqua nella soluzione del fluido refrigerante. Ci sono problemi anche con l'installazione delle tubature o con errori nel progetto e nella testatura del sistema, legati principalmente al desiderio di risparmiare. Di conseguenza, si verifica un serio incidente che sarebbe stato possibile evitare.<\/p>\n

<\/p>\n

Catastrofi naturali <\/h2>\n

<\/p>\n

Le tempeste e\/o gli uragani interrompono pi\u00f9 frequentemente il funzionamento dell'infrastruttura ingegneristica del data center, causando l'interruzione dei servizi e\/o danni fisici all'attrezzatura. Gli incidenti provocati dal maltempo si verificano con una certa frequenza. Nel 2012, lungo la costa occidentale degli Stati Uniti, si \u00e8 abbattuto l'uragano Sandy, accompagnato da forti piogge. Il data center Peer 1, situato in un grattacielo a Lower Manhattan, ha perso l'alimentazione elettrica esterna<\/a><\/noindex>, dopo che l'acqua salata del mare ha allagato i sotterranei. I generatori di emergenza erano posizionati al 18\u00b0 piano, e la scorta di carburante per essi era limitata: le norme introdotte a New York dopo gli attacchi dell'11 settembre vietano di conservare grandi quantit\u00e0 di carburante ai piani superiori. <\/p>\n

\n