A quanti anni corrispondono 34 anni IBM?

Il 18 Gennaio scorso abbiamo scoperto che 34 anni sono un battito d’ali 

Ci lasciamo alle spalle un fine settimana difficile, alle prese con un guasto tecnico che ha coinvolto uno degli storage che usiamo impattando una porzione significativa della nostra infrastruttura cloud del datacenter di Milano Caldera.

Siamo rimasti sorpresi dalla entità del problema che, francamente, non ci aspettavamo dal tipo di apparecchiatura che usiamo, sorpresi al punto che abbiamo pensato di rendevi partecipi, nel dettaglio, dell’accaduto. Condivideremo con voi:

    • il contesto
    • la natura dell’accaduto
    • come il guasto sia stato gestito
    • le nostre conclusioni

 

Prima di entrare nel vivo del racconto occorre una premessa: da un paio d’anni abbiamo sostituito tutti i nostri storage con delle macchine di tecnologia moderna e molto performanti basate sulla cosiddetta “tecnologia full flash micro latency”.

Per darvi un elemento di paragone, si tratta di una tecnologia che ha prestazioni di un ordine di grandezza migliore rispetto ai dispositivi SSD oggi molto diffusi: dopo un’accurata selezione di mercato la nostra scelta è caduta sugli storage IBM A9000. Tra i motivi della scelta, oltre alle performance di vertice, le caratteristiche di affidabilità indicate dal vendor su queste macchine che IBM identifica in 99,999% , dichiarando una probabilità di guasto grave di una volta ogni 34 anni.

In realtà – dopo pochi mesi di utilizzo – una delle macchine A9000 il 3 dicembre scorso ha evidenziato un problema piuttosto grave mettendo senza apparente motivo i volumi in stato inaccessibile e provocando un disservizio, non particolarmente grave e lungo ma comunque inatteso.  IBM, che ha la completa gestione proattiva di questi sistemi, è intervenuta rassicurandoci che erano state fatte tutte le verifiche e riparazioni e che lo storage era pienamente funzionante rilasciando in tal senso sia un report di intervento, sia un incident report.

Stando ai dati pubblicizzati pensavamo di poter stare tranquilli per i prossimi 34 anni visti i dati di MTBC (Mean Time Between Customer Impact Events) che IBM, fieramente, indicava (e indica) per questa apparecchiatura.

L’immagine dello storage A9000 come pubblicizzata sul sito IBM

Invece sabato 18 gennaio abbiamo scoperto che 34 anni sono in realtà un attimo fuggente.

Tutto è iniziato alle ore 14:59  quando un modulo di uno degli storage IBM A9000 di Milano a servizio di alcuni cluster di Cloud Server e Foundation Server ha segnalato degli errori non recuperabili.
Questo tipo di storage è costruito per continuare a funzionare anche a seguito di un guasto del genere e nulla, in principio, era accaduto sui servizi: abbiamo tuttavia tempestivamente coinvolto IBM che ha in gestione la manutenzione di queste macchine.

Alle ore 15:36 la doccia fredda: è accaduto che tutti i volumi serviti dalla macchina sono andati offline con l’errore “Data reduction tier moved to offline mode”, di qui:

    • tutti i dati sono divenuti inaccessibili
    • i server (Cloud Server e Foundation Server) hanno smesso di funzionare
    • abbiamo quindi prontamente fatto escalation del problema verso IBM.

 

Alle ore 17:36 IBM ci informa che ha bisogno di una ulteriore ora per stimare i tempi di soluzione: la situazione sembra richiedere una rigenerazione dell’indice dei metadati a partire da quelli scritti sulle unità flash in quanto la macchina ha perso la consistenza degli stessi, fatto alquanto grave per le caratteristiche di un sistema come l’A9000.

Alle ore 18:33 IBM ci aggiorna ulteriormente: ha deciso di riavviare una procedura batch di ricostruzione completa dei metadati. Il tempo necessario? E’ stimato in 7 ore, sulla base della quantità di dati e di oggetti singoli presenti nello storage. Sono colpiti:

    • i cluster cs03, cs06, cs14, cs66c, cs67, cs68, cs69, cs71, cs72, cs78, cs92, cs93, cs94, cs96, cs97, cs98 dedicati ai Cloud Server
    • i cluster blade123, blade104, blade96, blade88, blade67 per quanto concerne i Foundation Server

 

Alle ore 21.54 IBM conferma  la ricostruzione degli indici dovrebbe completarsi tra le 01.00 ele 02.00 del giorno 19/1.

Immagine dell’A9000 in uno dei datacenter Seeweb

Alle ore 02:20 del 19/01 lo storage torna a essere disponibile. Di qui, molti servizi sono tornati immediatamente attivi: parliamo della quasi totalità dei Cloud Server. A seguire, i tecnici hanno iniziato a lavorare sia alle verifiche di regolare funzionamento sia al riavvio di tutti i cluster VMware su Foundation Server che non sono ripartiti quando lo storage è tornato disponibile.

Alle ore 06:09 il 99% dei servizi era regolarmente online.
Si sono verificati casi specifici di corruzione di alcuni database: questi, sono stati gestiti singolarmente.
Fortunatamente, non c’è stata alcuna perdita di dati ma solo delle corruzioni a livello file system e database tutte gestite e recuperate.

Fin qui la nuda cronaca dei fatti, oltre questa e le formalità che culmineranno con il nostro incident report ufficiale vogliamo però spendere qualche parola forse più emotiva ma non per questo meno importante:

  • le prime e più importanti parole vanno ai nostri clienti che sono rimasti coinvolti nel problema: siamo veramente costernati e lo siamo ancor di più perché eravamo convinti di aver acquistato il meglio disponibile sul mercato quanto a qualità e affidabilità. E di avervi messo a disposizione il massimo in termini di prestazioni e affidabilità;
  • le seconde che ci piacerebbe considerare come ex aequo alle prime vanno ai nostri tecnici: hanno lavorato ininterrottamente per 20 ore, tutti si sono messi a disposizione nonostante il fine settimana; vi garantiamo che hanno fatto la differenza e a loro va il nostro grazie incondizionato. Mantenere la calma e la concentrazione per così tanto tempo con la pressione dei clienti, le centinaia di trouble ticket pendenti, la necessità di recuperare enormi quantità di dati non è da tutti e sono stati grandi;
  • le terze vanno a IBM che ci ha deluso, ci ha deluso perché definire adatta a sistemi mission critical una apparecchiatura che ha fallito la sopravvivenza in 2 casi su 2 oltretutto rimanendo fuori servizio per 11 ore significa che il marketing anche per loro ha preso il posto della tecnica e della responsabilità e questo per big blue è un po’ come rinunciare ai valori industriali costruiti in più di 100 anni.
Tags:
No Comments

Post a Comment

9 + 1 =

Accedi

Password dimenticata?