Was ist geschehen?

Am Morgen des 20.12.2021 kam es zu Unregelmäßigkeiten beim SSD-Cache des Storage-Servers FS1002. Unser Monitoring-System alarmierte unverzüglich unsere Bereitschaft über diesen Vorfall.

Ein SSD-Cache besteht aus 2 NVMe SSDs, welche im RAID-1 Verbund arbeiten und bei Ausfall einer SSD dafür sorgen, dass die Daten erhalten bleiben. Weiterhin ermöglicht diese Konstellation das weitere Arbeiten ohne Einschränkung bis zum Austausch der defekten SSD ohne Performanceeinbußen. Aufgabe eines SSD-Cache ist das Zwischenspeichern von Daten, welche angefragt werden, auf den ultra-schnellen SSDs zwischen zu speichern. Dies gilt für Daten, welche beim Lese- als auch beim Schreibzugriff angefragt werden. Ist das System weniger stark ausgelastet werden die Daten aus dem Cache auf die Festplatten geschrieben, welche ebenfalls in einem RAID-Verbund arbeiten. Ziel eines SSD-Cache ist möglichst viel Speicherplatz kostengünstig anbieten zu können und die Ladezeiten für das Abrufen von Daten so gering wie möglich zu halten. Dies funktioniert sehr gut, da die meisten Daten auf einem Server selten angefragt werden und daher ohne Probleme von den (langsameren) Festplatten gelesen werden können.

Nachdem unser bereitschaftshabender Techniker einen Blick in die Meldung unseres Monitoring-Systems geworfen hatte stand fest, dass bei einer der SSDs des Storage-Servers FS1002 Probleme entstanden sind. Die SSD wies defekte Sektoren auf und machte den Anschein bald auszufallen. Daher entschloss sich der Techniker dazu, die SSD auszuwechseln. Wie bereits hunderte Male zuvor, hat der bereitschaftshabende Techniker die problematische SSD mit einer baugleichen SSD ausgetauscht.

Kurz nach Austausch der defekten SSD wurden von unserem Monitoring-System bei zahlreichen VMs Störungen gemeldet. Nach einer weiteren Problemuntersuchung stand fest, dass all diese VMs den Server FS1002 als Storage-Server aufwiesen.

Bereits bei Überprüfung der betroffenen VMs viel auf, dass stark ausgelastete VMs mehr Probleme im Dateisystem anzeigten als kaum benutze. Daraufhin wurde sofort mit der Evakuierung der intakten VMs auf einen StandBy Storage-Server begonnen. Gleichzeitig wurden für die defekten VMs neue Systeme erstellt, um diese im Anschluß mit den Daten aus den Backups zu befüllen.

Bereits 4 Stunden später, gegen 12:00 Uhr, waren bereits knapp 75% der betroffenen Kunden wieder online.

Leider zeigten sich bei der der Evakuierung und Wiederherstellung schnell 2 Probleme: Zum Einen mussten wir feststellen, dass die von uns eingesetzte Backup-Software Jet-Backup nicht immer in der Lage war alle Kundendaten zu sichern, zum Anderen das unsere Kunden teilweise keinerlei Backups Ihrer Daten vorhalten.

Bei einigen Kunden km es zu Komplikationen da bei diesen Kunden beide Probleme gleichzeitig auftauchten. Dies sorgte für extrem lange Wiederherstellungszeiten oder die Notwendigkeit von immens hohen manuellen Nacharbeiten auf Seiten des Kunden.

Was war die genaue Ursache?

Im Nachgang konnten die betroffenen Bauteile mit Hilfe unseres Lieferanten und des Herstellers untersucht werden. Es stellte sich heraus, dass auch die verbliebene SSD einen Schaden aufwies, welcher vom RAID-Controller nicht bemerkt wurde. Beim Austausch der als defekt gemeldeten SSD nutzte das System daher die vermeintlich intakte SSD und vermischte diese Daten mit denen auf der Festplatte, wodurch im wahrsten Sinne des Wortes ein Datenbrei entstand, welcher nicht mehr zu retten war.

Demnach handelt es sich bei diesem Vorfall um ein technisches Versagen, auf welches wir keinerlei Einfluss nehmen konnten, da es gravierende versteckte Fehler gab, welche uns nicht gemeldet worden sind. Für den RAID-Controller ist bis heute die defekte SSD in Ordnung und zeigt keinerlei Probleme auf. Erst beim Test mit anderen RAID-Controllern wird diese SSD als defekt erkannt und entsprechend abgewiesen. Eine Erklärung für dieses Verhalten konnte uns keiner der involvierten Stellen liefern.

Was wird sich in Zukunft ändern?

Bereits zwischen Weihnachten und Neujahr wurde mit einer Überarbeitung unserer Backup-Infrastruktur begonnen. Wir haben vor ein komplett neues 2,4 PB (1 Petabyte = 1024 TerraByte) großes Backup-System aufzubauen und zu testen. Für dieses Vorhaben konnten wir bereits Geräte einsetzen, welche ursprünglich für ein anderes Projekt bestellt wurden. - Aktuell wird dieses Backup-System in unserem neuen Rechenzentrum getestet. Bei einem Erfolg wird das Backup-System erweitert und für alle Kunden ausgerollt.

Im Gegensatz zu Jet-Backup, welches - vereinfacht gesagt - die Datenbank des Kunden exportiert und die Daten kopiert, arbeitet die neue Lösung Bit-basiert. Eine Sicherung der VM und deren Konfiguration fand bisher nicht statt. Bei stark individualisierten VMs wurde dies jedoch zu einem relativ großen Problem, da anhand der Tickets die VM und deren Konfiguration rekonstruiert werden mussten.

In Zukunft ist es uns nun möglich VMs Bit-basiert wiederherzustellen. Dies sorgt dafür, dass die neue VM exakt der zuvor verunglückten Maschine entspricht. Die Wiederherstellungszeiten in einem solchen Fall verkürzen sich somit extrem, erste Messungen zeigen eine Verkürzung von mehreren Tagen auf wenige Stunden.

In unserem neuen Rechenzentrum kann dieses Problem generell nicht mehr auftreten. Hier haben wir bereits vor längerer Zeit die SSD-Caches durch Full-Flash-Arrays, also reine SSD-NVMe Storage-Server, ersetzt.

Fazit

Der Verlust eines 40 TB Storage-Servers ist neben einem Brand oder ähnlicher Katastrophe als größter anzunehmender Unfall zu bezeichnen. Wir sind daher, trotz aller Probleme und dem ganzen Ärger kurz vor Weihnachten, sehr froh, dass wir diesen Schaden für die meisten Kunden in einer relativ kurzen Zeit beseitigen konnten. Dies lag nicht zuletzt daran, dass uns viele Kunden Ihre Backups zur Verfügung gestellt haben, damit diese nicht vom gnadenlos überlasteten Backup-Netzwerk gezogen werden mussten.

Dieser Vorfall verdeutlicht noch einmal stark, dass Fehler in Hard- als auch Software immer wieder vorkommen können und es daher immens wichtig ist Daten immer an einem dritten Ort zu speichern. In diesem Zusammenhang empfehlen wir die 3-2-1 Backup-Regel, wovon Ziffer 2 durch uns abgedeckt wird und Ziffer 1 eine OffSite-Kopie außerhalb des Hauses / Rechenzentrums vorsieht.

Wir möchten uns an dieser Stelle noch einmal ausdrücklich für das weitestgehend große Verständnis bedanken. Gleichzeitig versichern wir Ihnen, dass wir unser Bestes geben um so einen Unfall in Zukunft zumindest schneller und planbarer beheben zu können.