Riepilogo
Tra il 29 ottobre e il 1º novembre 2024, quarantuno unità NVMe enterprise in quattro sedi hanno smesso di accettare comandi a un conteggio fisso di ore di accensione, un difetto del firmware in un lotto di produzione. Il mirroring ha assorbito trentanove di questi guasti senza impatto per i clienti. Un nodo a Varsavia ha perso entrambe le metà di un mirror in quaranta minuti, perché entrambe le unità provenivano dallo stesso lotto ed erano state installate lo stesso giorno. Due istanze su quel nodo hanno perso dati. Quella seconda parte è stata colpa nostra, non del fornitore.
Cronologia
Tutti gli orari UTC.
| Ora | Evento |
|---|---|
| 29 ott 03:11 | L'unità cade dal bus su un nodo di Varsavia. Il mirror si degrada, lo spare hot inizia la ricostruzione. Routine, nessuna pagina. |
| 29 ott 03:49 | La seconda unità nello stesso mirror cade. Il nodo perde il pool root e si ferma. |
| 29 ott 03:52 | La pagina scatta. L'ingegnere di turno online alle 03:55. |
| 29 ott 04:20 | Il nodo è dichiarato irrecuperabile sul posto. La ricostruzione dallo spare hot è impossibile; lo spare era a metà della ricostruzione da una sorgente che non risponde più. |
| 29 ott 05:40 | L'ingegnere che esamina i log delle unità nota che i due guasti sono distanti diciotto ore di accensione, non diciotto mesi. Il sospetto passa dalla sfortuna a una coorte. |
| 29 ott 06:15 | Query su tutta la flotta per identificativo del lotto e ore di accensione. Duecentosei unità sono nel lotto interessato. Trentuno hanno già superato il conteggio e si sono guastate; le restanti sono tra quaranta e novecento ore dal raggiungerlo. |
| 29 ott 07:30 | Contattato il fornitore. Difetto confermato entro quattro ore: un contatore nella telemetria del wear-levelling va in overflow a 1.536 ore di accensione e blocca il controller. Una revisione del firmware che lo corregge era stata rilasciata, silenziosamente, sei settimane prima. |
| 29 ott 09:00 | Inizia l'aggiornamento progressivo del firmware, con priorità alle ore rimanenti. |
| 30 ott 22:40 | Ultima unità del lotto aggiornata o sostituita. |
| 1º nov 14:00 | Istanze dei clienti interessate ripristinate o rimborsate. |
Causa principale
Due cause, e solo una appartiene al produttore delle unità.
Loro: un contatore di telemetria è andato in overflow a un conteggio fisso di ore di accensione e ha appeso il controller. L'unità sopravvive a un ciclo di alimentazione, torna attiva e si blocca di nuovo entro minuti. I dati sul piatto sono intatti e irraggiungibili, che è la combinazione peggiore per chi cerca di fare diagnosi alle quattro del mattino.
Nostra: abbiamo costruito mirror con unità arrivate nella stessa consegna. Un mirror dovrebbe essere due domini di guasto indipendenti, e due unità dello stesso lotto, installate lo stesso pomeriggio, accese entro la stessa ora, non sono indipendenti in alcun senso che conti. Undici mirror in tutta la flotta erano costruiti così. Dieci sono stati fortunati: lo spare hot ha finito la ricostruzione prima. Uno no.
Lo sapevamo da anni, in linea di principio. Nessuno l'aveva scritto nella procedura di build, e la procedura di build è ciò che la gente segue alle due del mattino sotto una scadenza di consegna.
Impatto
- Trentanove guasti assorbiti dai mirror senza effetti visibili per i clienti.
- Un nodo offline per nove ore e diciotto minuti.
- Quattordici istanze su quel nodo ripristinate da backup fuori nodo, con al massimo undici minuti di scritture perse.
- Due istanze senza alcun tipo di backup. Entrambe hanno perso tutto sul nodo.
Cosa abbiamo cambiato
- I lotti di acquisto sono suddivisi. Nessuna coppia di unità dello stesso lotto può formare un mirror, e lo spare hot a protezione di una coppia proviene da un terzo lotto. Imposto dagli strumenti di build, non da un documento. Fatto il 4 novembre.
- Allarmi di coorte sulle ore di accensione. Ora generiamo un allarme quando più di quattro unità con lo stesso identificativo di lotto sono entro cento ore l'una dall'altra e si avvicinano a un numero tondo di ore. È un'euristica grossolana ma avrebbe intercettato questo diciannove giorni prima.
- Soak del firmware prima della produzione. Una nuova famiglia di unità esegue duemila ore di accensione in un rack di test prima di portare dati dei clienti. Questo difetto sarebbe emerso a 1.536.
- Ora leggiamo le note di rilascio del firmware del fornitore secondo un programma. La correzione esisteva sei settimane prima che ne avessimo bisogno. Nessuno era assegnato a guardare, quindi nessuno ha guardato.
Cosa non abbiamo cambiato, e perché
Non abbiamo cambiato famiglia o fornitore di unità. Il difetto era reale e la divulgazione scarsa, ma la nostra perdita derivava dal batching correlato, che avremmo riprodotto con qualsiasi produttore. Cambiare sarebbe sembrato deciso e non avrebbe risolto nulla.
Il backup fuori nodo resta un extra da nove euro per cinquecento gigabyte. Renderlo universale significa far pagare a ogni cliente un servizio che la maggior parte replica da sé, e non fattureremo alla gente per l'apparenza di sicurezza. Ciò che è cambiato è il modulo d'ordine, che ora dichiara esplicitamente che l'archiviazione delle istanze è con mirror e che il mirror non è un backup, e la fase di conferma non permette più che quella frase venga saltata in silenzio.
Non siamo passati al mirroring triplo. Costa un terzo in più per gigabyte e non affronta il guasto correlato, che era il meccanismo effettivo qui. Due domini indipendenti battono tre dipendenti.
I due clienti
Entrambi sono stati rimborsati integralmente per il periodo interessato, nell'asset con cui hanno pagato, senza dover giustificare nulla. Uno è andato via. L'altro è rimasto e ora acquista l'extra backup, avendo letto la stessa frase sul modulo d'ordine che era lì, in forma più debole, da sempre.
Nessuno di questi esiti era in nostro potere. L'unica cosa in nostro potere era costruire il mirror correttamente, e non l'abbiamo fatto.