Analyse eines NVMe-Ausfalls: die toten Kondensatoren, die alles verlangsamten

Festplattenausfälle im Film sind binär: Es funktioniert, dann ist es tot. Echte Ausfälle sind heimtückischer. Dieser hier hat einen produktiven Hypervisor zweieinhalb Monate lang beeinträchtigt, ohne jemals etwas „kaputtzumachen“: kein ausgefallener Datenträger, keine verlorenen Daten, kein roter Alarm, nur sporadische Timeouts in der Nacht und ein Bauteil von wenigen Millimetern, das seine Arbeit eingestellt hatte. Eine vollständige Analyse, denn diese Art von Ausfall kann jeden Server treffen.

PLP: das Bauteil, über das niemand spricht #

Die Power Loss Protection unterscheidet eine Enterprise-SSD von einer Consumer-SSD. Eine SSD bedient „sichere“ Schreibvorgänge (sync) auf zwei Arten: Entweder schreibt sie tatsächlich in den NAND, bevor sie antwortet (langsam), oder sie antwortet aus ihrem DRAM und verpflichtet sich, die Arbeit zu Ende zu bringen. Dieses Versprechen kann sie bei einem Stromausfall nur dank einer Reserve eingebauter Kondensatoren halten, die ihr die nötigen Millisekunden lassen, um ihren Cache zu leeren. Diese Kondensatoren sind die PLP. Ohne sie muss eine SSD, die ehrlich bleiben will, ihren sync-Schreibcache abschalten, und ihre Leistung bricht ein. Für ein Dateisystem wie ZFS, das sehr viele synchrone Schreibvorgänge erzeugt, ist die PLP kein Luxus: Sie ist die Voraussetzung für die angegebenen Latenzen.

Das Symptom: Timeouts in der Nacht, sonst nichts #

Alles beginnt mit fehlgeschlagenen ZFS-Replikationen: zfs snapshot … got timeout, sporadisch, gebündelt in einem Fenster von einer Handvoll Minuten jede Nacht, genau dann, wenn Backups auf Anwendungsebene die Gäste mit Schreibvorgängen belasteten. Zweihundertsechsundvierzig Fehlschläge sammelten sich an, bevor die Untersuchung zur Quelle vordrang. Die Messung, die alles offenlegte: die Schreiblatenz der beiden NVMe des Mirrors. Der gesunde Datenträger antwortete in 52 Mikrosekunden; sein Zwilling in 4 bis 6 Millisekunden, hundertmal mehr. Und ein Mirror bewegt sich im Takt des langsamsten Mitglieds: Der gesamte Pool wartete.

smartctl -H /dev/nvme1
# SMART overall-health self-assessment test result: FAILED!
# - volatile memory backup device has failed

smartctl -a /dev/nvme1 | grep -i critical
# Critical Warning: 0x10   <- Bit 4: Ausfall des Backups für den flüchtigen Speicher

# Und trotzdem war der NAND GESUND:
# Percentage Used: 5% · Media and Data Integrity Errors: 0

Das SMART-Urteil passt in eine Zeile: volatile memory backup device has failed: Die PLP-Kondensatoren waren tot. Der Controller hatte, ehrlich, wie er war, seinen Schreibcache abgeschaltet und verarbeitete jeden sync mit NAND-Geschwindigkeit. Der Datenträger war weder tot noch im Sterben: Sein NAND zeigte 5 % Verschleiß und null Fehler. Ein Sicherheitsbauteil hatte versagt, und die einzige Spur war eine SMART-Zeile, die niemand liest… da der Datenträger ja „funktioniert“. Das erste Auftreten des Fehlers in den Logs lag elf Wochen vor der Diagnose. Lektion Nummer eins: das SMART-Detail überwachen (den Health Status und die Critical Warnings), nicht nur „der Datenträger antwortet“.

Der Austausch: was bei einem Hoster wirklich passiert #

Bei einem dedizierten Server tauscht man den Datenträger nicht selbst: Man eröffnet beim Hoster (hier OVH) ein Ticket mit der Seriennummer des Datenträgers und dem SMART-Bericht, plant das Zeitfenster, und ein Techniker im Rechenzentrum tauscht den Datenträger. Auf unserer Seite läuft die Wiederinbetriebnahme eines Mirror-Mitglieds in vier Handgriffen ab, jeder mit seiner Falle:

1. Die Partitionstabelle vom verbliebenen Datenträger kopieren: sgdisk -R <destination> <source>, dann -G, um die GUIDs neu zu erzeugen. Klassische Falle: Die Reihenfolge der Argumente lautet Ziel zuerst: Vertauschen Sie sie, überschreiben Sie die Tabelle des gesunden Datenträgers.
2. Jede Schicht wieder einbinden: die md-Partitionen (mdadm --add), den Swap, neu angelegt mit seiner ursprünglichen UUID (mkswap -U …), damit die bestehende Konfiguration ihn beim Booten wiederfindet.
3. zpool replace auf der ZFS-Partition: Der Resilver kopierte 218 GB in fünf Minuten.
4. Die Enumeration prüfen: Beim nächsten Neustart hatten /dev/nvme0 und /dev/nvme1 ihre Namen getauscht. Alles, was auf einen Datenträger verweist, muss das über eine stabile Kennung tun (/dev/disk/by-id/, Seriennummer), nie über die Enumerationsnummer.

Gemessenes Ergebnis nach dem Austausch: 236 µs Schreiblatenz, symmetrisch auf beiden Datenträgern, bei knapp 4.000 IOPS. Die nächtlichen Timeouts verschwanden noch am selben Abend.

Die finale Wendung: 20.000 schlafende Fehler #

Der Resilver hatte einen wertvollen Nebeneffekt: Er war das erste vollständige Lesen des Pools seit seiner Erstellung. Und dieses Lesen förderte mehr als zwanzigtausend Prüfsummenfehler in kalten Daten zutage: alte, eingefrorene Replikate, seit Monaten nicht mehr gelesen, deren Beschädigung daher nie gesehen worden war. Keine Produktionsdaten waren betroffen, die Bereinigung genügte; aber die Lehre ist genau die aus unserem Artikel über Scrubs, hier in Flammenschrift geschrieben: Daten, die nie gelesen werden, können seit Monaten beschädigt sein, ohne dass irgendeine Warnleuchte angeht. Seitdem gibt es auf jedem Knoten einen geplanten und geprüften monatlichen Scrub: So hatte der Ausfall wenigstens etwas Gutes.

Diese Spurensuche (nächtliche Timeouts, ein Backup-Fenster und eine SMART-Zeile miteinander in Beziehung setzen) ist der Alltag unserer Managed Services: Zuverlässigkeit bedeutet nicht, keine Ausfälle zu haben, sondern sie zu sehen, bevor sie Kosten verursachen. Wenn Ihre Server älter als zwei Jahre sind und noch nie jemand ihre SMART-Daten im Detail gelesen hat, ist jetzt der richtige Zeitpunkt.