{"id":1797,"date":"2020-08-25T11:23:43","date_gmt":"2020-08-25T10:23:43","guid":{"rendered":"https:\/\/blog.imagmbh.de\/?p=1797"},"modified":"2020-08-28T16:12:00","modified_gmt":"2020-08-28T15:12:00","slug":"spass-mit-einem-storageausfall-protokoll-und-vorgehen","status":"publish","type":"post","link":"https:\/\/blog.imagmbh.de\/index.php\/spass-mit-einem-storageausfall-protokoll-und-vorgehen\/","title":{"rendered":"Storageausfall: Protokoll und Vorgehen"},"content":{"rendered":"\n

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?<\/p>\n\n\n\n

Unsere Technik<\/h2>\n\n\n\n

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\u00fcrfen, ohne dass es zu Funktionbeeintr\u00e4chtigungen kommt (RAID6). \u00dcber die jeweiligen Speichereinheiten ist ein SSD-Cache als RAID1 gelegt, um Lese- und Schreibzugriffe zu beschleunigen. Daten werden also von den Rechenservern \u00fcber die 10G-Ethernetanbindung an das Speichersystem \u00fcbergeben, dort im SSD-Cache zwischengespeichert und auf die klassisch drehenden Festplatten geschrieben.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Zus\u00e4tzlich haben wir ein sogenanntes „Offsite-Backup“. Das bedeutet, dass ein vollst\u00e4ndiges Backup au\u00dferhalb des Rechenzentrums, einige Kilometer entfernt, zur Verf\u00fcgung steht. Auf diese Weise k\u00f6nnen Daten auch dann wiederhergestellt werden, wenn ein Feuer ausbricht oder, wie vor einigen Jahren in einem Rechenzentrum in Skandinavien geschehen, durch die Luftdruckerh\u00f6hung beim Eintritt des L\u00f6schgases die Festplattenk\u00f6pfe auf den Platten aufsetzen und damit alle Festplatten zerst\u00f6rt werden.<\/p>\n\n\n\n

Da die Gesamtdatenmenge zu gro\u00df ist, um sie des Nachts komplett durch die Leitungsanbindung zwischen den Standorten zu \u00fcbertragen, arbeiten wir mit einer Snapshottechnik und \u00fcbertragen blockweise nur die \u00c4nderungen seit der letzten Sicherung.<\/p>\n\n\n\n

Der Vorfall<\/h2>\n\n\n\n

Pl\u00f6tzlich schaltete sich ein Teil des Speichersystems ab. In den Protokolldateien konnten wir sp\u00e4ter 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\u00e4tte, um Datenverluste oder Dateninkonsistenzen zu vermeiden.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Wir haben also das System neu gestartet und erlebten eine b\u00f6se \u00dcberraschung: Eine der Speichereinheiten des ZFS-Systems meldete eine Inkonsistenz in den Daten und weigerte sich im aktuellen Zustand zu starten.<\/p>\n\n\n\n

Wie oben geschrieben, nutzen wir Systeme, die einen gleichzeitigen Ausfall von zwei Platten in einer Speichereinheit verkraften. Dies funktioniert mittels Pr\u00fcfsummen, die eine entsprechende Redundanz gew\u00e4hrleisten: Die Daten von ausgefallenen Festplatten k\u00f6nnen mit Hilfe der Daten der noch laufenden Festplatten errechnet werden. Diese Pr\u00fcfsummen dienen aber auch der Konsistenzpr\u00fcfung: Wenn die errechneten Daten nicht mit den realen Daten \u00fcbereinstimmen, 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.<\/p>\n\n\n\n

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\u00fchrt, dass auf den unterschiedlichen Platten inkonsistente Daten geschrieben worden waren.<\/p>\n\n\n\n

Inkonsistente Daten sind ein GAU, da hilft nur der R\u00fcckgriff auf ein Backup.<\/p>\n\n\n\n

Also haben wir das Backupsystem eingebunden. Wenige Stunden vorher war dieses ja auf das Offsite-System \u00fcbertragen worden. Bei diesem \u00dcbertragen mussten die Daten ja auch gelesen werden und es fand auch eine Konsistenzpr\u00fcfung statt und diese war erfolgreich durchgelaufen. Die Backupdaten sollten also in Ordnung sein.<\/p>\n\n\n\n

Unser Erschrecken war gro\u00df, 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 \u00fcbertragen. Die auf den physischen Platten geschriebenen Daten, die nun nach dem Neustart wieder eingelesen wurden, waren aber nicht konsistent. Auch ein R\u00fcckgriff auf \u00e4ltere Snapshots lieferte gleich erschreckende Erkenntnisse. Das \u00fcber Monate laufende System hatte also die Cache-Daten nicht korrekt auf die physischen, drehenden Platten geschrieben.<\/p>\n\n\n\n

Eine Pr\u00fcfung des Offsite-Backups ergab schnell, dass dort die Daten tats\u00e4chlich konsistent vorlagen, was die Theorie mit dem Cache-Fehler best\u00e4tigte.<\/p>\n\n\n\n

Das R\u00fcckkopieren<\/h2>\n\n\n\n

Wir hatten also korrekte Daten, diese lagen aber im Offsite-System. Und weil diese Datenmenge mehrere TB betrug, war eine \u00dcbertragung \u00fcber Datenleitung nicht gangbar.<\/p>\n\n\n\n

Also mussten die Daten vom Offsite-System auf Transportdatentr\u00e4ger kopiert und im Rechenzentrum dann wieder ins Produktionssystem kopiert werden. Bei einigen TB an Daten dauert dieser Kopierprozess dummerweise einige Stunden.<\/p>\n\n\n\n

Der Prozess h\u00e4tte evtl. verk\u00fcrzt werden k\u00f6nnen, wenn wir das Offsitebackup direkt physisch ins Rechenzentrum transportiert und dann dort kopiert h\u00e4tten. Davon haben wir abgesehen, da uns das Transportrisiko zu gro\u00df erschien: W\u00e4re auf dem Transport ein Unfall passiert, w\u00e4re dann auch das Backup zerst\u00f6rt gewesen und wir h\u00e4tten wirklichen Datenverlust erlitten.<\/p>\n\n\n\n

Res\u00fcm\u00e9<\/h2>\n\n\n\n

Auch wenn die Systeme durch diesen Vorfall einige Stunden nicht erreichbar waren, so ist auch in der Nachschau das Vorgehen als korrekt anzusehen:<\/p>\n\n\n\n