Zusammenfassung
Zwischen dem 29. Oktober und dem 1. November 2024 haben 41 Enterprise-NVMe-Laufwerke auf vier Standorten aufgehört, Befehle zu einer festgelegten Anzahl von Betriebsstunden anzunehmen – ein Firmware-Fehler in einer Fertigungscharge. Spiegelung hat 39 dieser Ausfälle ohne Auswirkungen für Kunden aufgefangen. Ein Knoten in Warschau verlor beide Hälften eines Spiegels innerhalb von 40 Minuten, weil beide Laufwerke aus derselben Charge stammten und am selben Tag eingebaut wurden. Zwei Instanzen auf diesem Knoten haben Daten verloren. Dieser zweite Teil war unser Fehler, nicht der des Herstellers.
Zeitverlauf
Alle Zeiten in UTC.
| Zeit | Ereignis |
|---|---|
| 29. Okt. 03:11 | Laufwerk fällt auf einem Warschauer Knoten vom Bus ab. Spiegel degradiert, Hot Spare beginnt mit dem Rebuild. Routine, keine Seite. |
| 29. Okt. 03:49 | Zweites Laufwerk im selben Spiegel fällt aus. Knoten verliert seinen Root-Pool und stoppt. |
| 29. Okt. 03:52 | Seite wird ausgelöst. Bereitschaft ist um 03:55 online. |
| 29. Okt. 04:20 | Knoten wird als vor Ort nicht wiederherstellbar erklärt. Rebuild vom Hot Spare ist unmöglich; der Spare war mitten im Rebuild von einer Quelle, die nicht mehr antwortet. |
| 29. Okt. 05:40 | Ingenieur, der Laufwerkslogs prüft, bemerkt, dass die beiden Ausfälle 18 Betriebsstunden auseinanderliegen, nicht 18 Monate. Verdacht wechselt von Pech zu einer Kohorte. |
| 29. Okt. 06:15 | Flottenweite Abfrage nach Chargen-ID und Betriebsstunden. 206 Laufwerke sind in der betroffenen Charge. 31 haben die Anzahl bereits überschritten und sind ausgefallen; der Rest ist zwischen 40 und 900 Stunden davon entfernt. |
| 29. Okt. 07:30 | Hersteller kontaktiert. Fehler innerhalb von vier Stunden bestätigt: ein Zähler in der Wear-Leveling-Telemetrie läuft bei 1.536 Betriebsstunden über und blockiert den Controller. Ein Firmware-Update, das das behebt, war sechs Wochen zuvor leise ausgeliefert worden. |
| 29. Okt. 09:00 | Rollierendes Firmware-Update beginnt, priorisiert nach verbleibenden Stunden. |
| 30. Okt. 22:40 | Letztes Laufwerk der Charge aktualisiert oder ersetzt. |
| 1. Nov. 14:00 | Betroffene Kundeninstanzen wiederhergestellt oder erstattet. |
Grundursache
Zwei Ursachen, und nur eine gehört dem Laufwerkshersteller.
Ihre: Ein Telemetriezähler lief bei einer festen Anzahl von Betriebsstunden über und hing den Controller auf. Das Laufwerk übersteht einen Neustart, kommt zurück und blockiert innerhalb von Minuten erneut. Die Daten auf dem Datenträger sind intakt und unerreichbar – die schlimmste Kombination für jeden, der um vier Uhr morgens diagnostiziert.
Unsere: Wir haben Spiegel aus Laufwerken gebaut, die in derselben Lieferung ankamen. Ein Spiegel soll zwei unabhängige Ausfalldomänen sein, und zwei Laufwerke aus einer Charge, am selben Nachmittag eingebaut, innerhalb derselben Stunde eingeschaltet, sind in keiner relevanten Hinsicht unabhängig. Elf Spiegel in der Flotte wurden so gebaut. Zehn hatten Glück, dass der Hot Spare zuerst fertig rebuildete. Einer nicht.
Wir wussten das seit Jahren prinzipiell. Niemand hatte es in den Build-Prozess geschrieben, und der Build-Prozess ist das, was man um zwei Uhr morgens unter Liefertermin befolgt.
Auswirkungen
- Neununddreißig Ausfälle durch Spiegel aufgefangen, ohne für Kunden sichtbaren Effekt.
- Ein Knoten neun Stunden und achtzehn Minuten offline.
- Vierzehn Instanzen auf diesem Knoten aus Off-Node-Backups wiederhergestellt, mit maximal elf Minuten Verlust an Schreibvorgängen.
- Zwei Instanzen ohne Backup jeglicher Art. Beide haben alles auf dem Knoten verloren.
Was wir geändert haben
- Kaufchargen werden getrennt. Keine zwei Laufwerke aus derselben Charge dürfen einen Spiegel bilden, und der Hot Spare, der ein Paar schützt, stammt aus einer dritten Charge. Durchgesetzt durch die Build-Tools, nicht durch ein Dokument. Erledigt am 4. November.
- Kohorten-Alerting auf Betriebsstunden. Wir alerten jetzt, wenn mehr als vier Laufwerke mit derselben Chargen-ID innerhalb von hundert Stunden voneinander liegen und sich einer runden Stundenzahl nähern. Es ist eine grobe Heuristik und hätte diesen Fall neunzehn Tage früher erkannt.
- Firmware-Soak vor Produktion. Eine neue Laufwerksfamilie läuft zweitausend Betriebsstunden in einem Testrack, bevor sie Kundendaten trägt. Dieser Fehler wäre bei 1.536 aufgetreten.
- Wir lesen jetzt Hersteller-Firmware-Versionshinweise nach Plan. Der Fix existierte sechs Wochen, bevor wir ihn brauchten. Niemand war zum Lesen eingeteilt, also las niemand.
Was wir nicht geändert haben und warum
Wir haben Laufwerksfamilie oder -hersteller nicht gewechselt. Der Fehler war real und die Offenlegung schlecht, aber unser Verlust kam von korrelierter Chargenbildung, die wir mit jedem Hersteller reproduziert hätten. Ein Wechsel hätte entschlossen gewirkt und nichts gefixt.
Off-Node-Backup bleibt ein Add-on für neun Euro pro fünfhundert Gigabyte. Es universell zu machen bedeutet, jeden Kunden für einen Dienst zu belasten, den die meisten selbst replizieren, und wir werden Leuten nicht für den Anschein von Sicherheit Rechnung stellen. Was sich geändert hat, ist das Bestellformular, das jetzt klar sagt, dass Instanzspeicher gespiegelt ist und gespiegelt kein Backup ist, und der Bestätigungsschritt lässt diesen Satz nicht mehr stillschweigend überspringen.
Wir sind nicht zu Triple-Mirroring übergegangen. Es kostet ein Drittel mehr pro Gigabyte und adressiert nicht korrelierte Ausfälle, die hier der eigentliche Mechanismus waren. Zwei unabhängige Domänen schlagen drei abhängige.
Die zwei Kunden
Beide wurden vollständig für den betroffenen Zeitraum erstattet, in dem Vermögenswert, mit dem sie bezahlt hatten, ohne dass sie etwas rechtfertigen mussten. Einer ging. Der andere blieb und kauft jetzt das Backup-Add-on, nachdem er denselben Satz auf dem Bestellformular gelesen hat, der in schwächerer Form schon die ganze Zeit dort stand.
Keines dieser Ergebnisse lag in unserer Hand. Das Einzige, was in unserer Hand lag, war, den Spiegel richtig zu bauen, und das haben wir nicht getan.