Gestern gab es bei uns erhebliche IT-Probleme. Ursache war ein der Ausfall eines Speichersystems. Doch was war genau passiert, wie sind wir damit umgegangen, muss man mit solchen Fehlern rechnen und was kann verbessert werden?
Unsere Technik
Wir betreiben im Rechenzentrum einen Server-Cluster aus mehreren Hardware-Maschinen. An diese ist per 10G-Ethernet ein Speichersystem angeschlossen. Auf diesem Speichersystem werden die Daten im ZFS-Dateisystem abgelegt. Dieses System ist so konfiguriert, dass zwei Festplatten einer Speichereinheit ausfallen dürfen, ohne dass es zu Funktionbeeinträchtigungen kommt (RAID6). Über die jeweiligen Speichereinheiten ist ein SSD-Cache als RAID1 gelegt, um Lese- und Schreibzugriffe zu beschleunigen. Daten werden also von den Rechenservern über die 10G-Ethernetanbindung an das Speichersystem übergeben, dort im SSD-Cache zwischengespeichert und auf die klassisch drehenden Festplatten geschrieben.
Im Rechenzentrum wird ein Onsite-Backup gemacht, welches auf der gleichen Technik beruht. Die Backups werden also ebenfalls auf drehenden Festplatten gespeichert, die ebenfalls durch SSDs gecached werden.
Zusätzlich haben wir ein sogenanntes „Offsite-Backup“. Das bedeutet, dass ein vollständiges Backup außerhalb des Rechenzentrums, einige Kilometer entfernt, zur Verfügung steht. Auf diese Weise können Daten auch dann wiederhergestellt werden, wenn ein Feuer ausbricht oder, wie vor einigen Jahren in einem Rechenzentrum in Skandinavien geschehen, durch die Luftdruckerhöhung beim Eintritt des Löschgases die Festplattenköpfe auf den Platten aufsetzen und damit alle Festplatten zerstört werden.
Da die Gesamtdatenmenge zu groß ist, um sie des Nachts komplett durch die Leitungsanbindung zwischen den Standorten zu übertragen, arbeiten wir mit einer Snapshottechnik und übertragen blockweise nur die Änderungen seit der letzten Sicherung.
Der Vorfall
Plötzlich schaltete sich ein Teil des Speichersystems ab. In den Protokolldateien konnten wir später lesen, dass im Cache-Programmcode ein Zustand aufgetreten war, mit dem die Programmierer nicht gerechnet hatten, ein klassischer Bug. Der Kernel meldete, dass er daher die betroffenen Platten vom System abgemeldet hätte, um Datenverluste oder Dateninkonsistenzen zu vermeiden.
Durch das Abschalten der Platten konnte das Speichersystem seinen Aufgaben nicht mehr nachkommen und dem Cluster keinen Speicher mehr bereit stellen, so dass alle virtuellen Maschinen, die im Cluster laufen, schlagartig keine Festplatten mehr hatten und zusammenbrachen.
Wir haben also das System neu gestartet und erlebten eine böse Überraschung: Eine der Speichereinheiten des ZFS-Systems meldete eine Inkonsistenz in den Daten und weigerte sich im aktuellen Zustand zu starten.
Wie oben geschrieben, nutzen wir Systeme, die einen gleichzeitigen Ausfall von zwei Platten in einer Speichereinheit verkraften. Dies funktioniert mittels Prüfsummen, die eine entsprechende Redundanz gewährleisten: Die Daten von ausgefallenen Festplatten können mit Hilfe der Daten der noch laufenden Festplatten errechnet werden. Diese Prüfsummen dienen aber auch der Konsistenzprüfung: Wenn die errechneten Daten nicht mit den realen Daten übereinstimmen, ist das System inkonsistent und damit defekt. Genau dieser Zustand wurde nun beim Hochfahren des Systems entdeckt, zumindest in Systembereichen war einen solche Inkonsistenz vorhanden.
Wir konnten nun das System durch manuellen Eingriff wieder bereitstellen und auf die dort gespeicherten Daten zugreifen. Bei einigen Daten auf der Speichereinheit wurde der Zugriff jedoch abgelehnt, weil genau bei diesen Daten wieder eine Inkonsistenz festgestellt wurde. Der oben beschriebene Fehler im Cache-System hatte also dazu geführt, dass auf den unterschiedlichen Platten inkonsistente Daten geschrieben worden waren.
Inkonsistente Daten sind ein GAU, da hilft nur der Rückgriff auf ein Backup.
Also haben wir das Backupsystem eingebunden. Wenige Stunden vorher war dieses ja auf das Offsite-System übertragen worden. Bei diesem Übertragen mussten die Daten ja auch gelesen werden und es fand auch eine Konsistenzprüfung statt und diese war erfolgreich durchgelaufen. Die Backupdaten sollten also in Ordnung sein.
Unser Erschrecken war groß, als wir feststellten, dass auch die Snapshotdaten des Backups im Rechenzentrum fehlerhaft waren. Scheinbar hatte das System die Daten aus dem Cache, der konsistent war, gelesen und übertragen. Die auf den physischen Platten geschriebenen Daten, die nun nach dem Neustart wieder eingelesen wurden, waren aber nicht konsistent. Auch ein Rückgriff auf ältere Snapshots lieferte gleich erschreckende Erkenntnisse. Das über Monate laufende System hatte also die Cache-Daten nicht korrekt auf die physischen, drehenden Platten geschrieben.
Eine Prüfung des Offsite-Backups ergab schnell, dass dort die Daten tatsächlich konsistent vorlagen, was die Theorie mit dem Cache-Fehler bestätigte.
Das Rückkopieren
Wir hatten also korrekte Daten, diese lagen aber im Offsite-System. Und weil diese Datenmenge mehrere TB betrug, war eine Übertragung über Datenleitung nicht gangbar.
Also mussten die Daten vom Offsite-System auf Transportdatenträger kopiert und im Rechenzentrum dann wieder ins Produktionssystem kopiert werden. Bei einigen TB an Daten dauert dieser Kopierprozess dummerweise einige Stunden.
Der Prozess hätte evtl. verkürzt werden können, wenn wir das Offsitebackup direkt physisch ins Rechenzentrum transportiert und dann dort kopiert hätten. Davon haben wir abgesehen, da uns das Transportrisiko zu groß erschien: Wäre auf dem Transport ein Unfall passiert, wäre dann auch das Backup zerstört gewesen und wir hätten wirklichen Datenverlust erlitten.
Resümé
Auch wenn die Systeme durch diesen Vorfall einige Stunden nicht erreichbar waren, so ist auch in der Nachschau das Vorgehen als korrekt anzusehen:
- Gegen Programmfehler kann man sich leider nicht schützen. Die eingesetzten Treiber und Softwaresystemkomponenten werden seit Jahren weltweit eingesetzt und gelten „eigentlich“ als stabil.
- Die Prüfsummenverfahren sind sehr sinnvoll und haben zurecht „zugeschlagen“: So wurden Inkonsistenzen erkannt, denn Datenveränderungen sind häufig schlimmer als Datenverlust. Letztendlich garantierten die Prüfsummenverfahren auch, dass das Offsite-Backup korrekt war.