tl;dr
Am 03. September 2025 kam es bei uns zu einem schweren Ausfall. Ursache war ein Fehler in der eingesetzten Storage-Software Ceph, auf der unser Hosting basiert.
In der Folge waren Webseiten und E-Mails für viele Kund:innen mehrere Tage lang nur eingeschränkt oder gar nicht erreichbar. Besonders kritisch war, dass wir zunächst nicht wussten, ob sich alle Daten vollständig wiederherstellen lassen würden. Zwar standen uns Backups zur Verfügung, diese waren jedoch nicht tagesaktuell.
Unser Ziel war es, so schnell wie möglich wieder grundlegende Funktionen wie den Versand und Empfang von E-Mails bereitzustellen. Das gelang uns am Abend des 05. September. Wenige Tage später konnten wir dann auch die vollständigen Datenbestände sichern und Schritt für Schritt zurückbringen. Am 09. September stand fest: Es ist kein Datenverlust entstanden.
Wer sich für die technischen Hintergründe interessiert, wie es zu dem Ausfall kam und welche Lehren wir daraus gezogen haben, findet die Details im Anschluss.
Die Details des Ausfalls
Am Abend des 03. September führten wir ein Upgrade unseres produktiven Ceph-Clusters von Version 18 auf 19 durch. Der Cluster ist seit Jahren die Grundlage unseres Hostings und wird sowohl für virtuelle Maschinen (in Gestalt von RBD-Disks) in Verbindung mit Proxmox als auch (als CephFS) im Web- und Mailhosting genutzt.
In diesem Artikel werden immer wieder folgende zentrale Dienste genannt:
- MONs (Monitore): Verwalten Cluster-Zustand und Konfiguration. Sie bilden ein Quorum, das jederzeit bestehen muss.
- MDS (Metadaten-Server): Verantwortlich für die Verwaltung der Metadaten im CephFS.
Ein kurzer Überblick über die betroffene Infrastruktur
Das betroffene Setup besteht aus sechs physischen Servern mit jeweils zwölf Festplatten (bzw. HDDs/SSDs) und einem CephFS Metadaten-Server (MDS), verteilt auf zwei Rechenzentren, sowie einem weiteren virtuellen Server, der lediglich einen Ceph-Monitor bereitstellt.
Ceph ist ein verteiltes Speichersystem, das Daten redundant über mehrere (physische) Server hinweg ablegt. Grundlage ist hierbei RADOS (reliable autonomic distributed object store). Ein objektbasierter Speicher, bei dem Daten als „Blobs“ mit Metadaten gespeichert werden.
Unser Ceph wurde auf zwei Arten genutzt:
- Block-Speicher (RBD): Häufig in Verbindung mit Virtualisierung, wo Ceph virtuelle „Disks“ bereitstellt, die wie herkömmliche Laufwerke mit Dateisystemen (z. B. ext4, xfs, NTFS) genutzt werden. Wir nutzen Ceph in Verbindung mit der Virtualisierungsumgebung Proxmox und stellen so unseren VMs Speicher zur Verfügung.
- CephFS: Ein Dateisystem, das direkt eingebunden werden kann und parallelen Zugriff mehrerer Systeme erlaubt (ähnlich wie NFS). Wir nutzten CephFS als Dateisystem für die Ablage unserer Web- und Mail-Hosting-Daten.
CephFS speichert hierbei eine sehr große Menge an Daten in einem einzigen Verzeichnisbaum, auf dem eine sehr große Anzahl an parallelen Zugriffen stattfindet. Daher ist es wichtig zu verstehen, dass dieser Verzeichnisbaum von mehreren der oben genannten MDS verwaltet wird. Ceph nennt dieses Feature “Dynamic Subtree Partitioning” und nur dieses Feature erlaubt eine ausreichende Responsivität des Dateisystems. Wir setzten hier fünf dieser MDS parallel ein.
Der Beginn des Problems
Das Upgrade sollte nach der offiziellen Ceph-Dokumentation erfolgen. Man beginnt nach einigen Schritten der Vorbereitung damit, die Anzahl der aktiven MDS auf einen zu reduzieren. Anschließend wurde das Update der Pakete auf den Hardware-Servern gestartet.
Bereits beim Versuch, dies umzusetzen, begann hier jedoch das Unheil: Ab etwa 17:30 Uhr stellten wir Probleme mit CephFS fest. Ein Teil der MDS-Server fiel aus, bzw. ließ sich nach dem Update nicht mehr starten. Ein Teil des CephFS war ebenfalls nicht mehr abrufbar.
Die erste Reaktion war zu versuchen, die vermutete Ursache, also die MDS-Server wieder in Betrieb zu nehmen. Als das fehlschlug, versuchten wir die MDS aus der Konfiguration zu entfernen, wonach jedoch überraschend drei der sieben MONs ausfielen. Die verbliebenen Monitore verloren ihr Quorum, wodurch keine Interaktion mit Ceph mehr möglich war.
Unklar war insbesondere, ob auch die RBD-Disks betroffen sein würden – ein Totalausfall hätte bedeutet, dass auch unsere Virtualisierungsumgebung nicht mehr funktionsfähig gewesen wäre. Glücklicherweise fiel keine der RBD-Disks über den gesamten Vorfall hinweg aus, sodass auch kein Datenverlust entstanden ist.
INWX verfügt selbstverständlich über redundante Backups dieser Daten. Die Wiederherstellung der gesamten Infrastruktur hätte jedoch mehrere Tage in Anspruch genommen.
Stillstand und Unsicherheit
Die Stimmung war hier selbstverständlich etwas angespannt. Wir waren davon ausgegangen ein reguläres Update einer Software durchzuführen, die wir schon seit vielen Jahren einsetzen. Auch derartige Updates waren in der Vergangenheit nichts besonderes gewesen. Die Unklarheit, wie es in so kurzer Zeit zu einem Totalausfall kommen konnte, sowie die Kritikalität eines solchen Vorfalls, versetzen uns erst einmal unter Schock.
Der Ausfall der Monitore lies sich schnell darauf zurückführen, dass die MONs auch Zustände der MDS halten, wodurch nicht nur das CephFS betroffen war.
Wir stellten ebenfalls schnell fest, dass die Monitore in einem, für uns, irreparablen Zustand waren. Wir vermuteten, dass einer der fehlgeschlagenen Reparaturversuche dazu geführt hatte, dass die Monitore einen fehlerhaften Zustand des Clusters hielten.
Trotz der jahrelangen Erfahrung mit Ceph, waren wir nun auf externe Hilfe angewiesen.
Unterstützung durch croit und erste Wiederherstellung der Services
Einige Stunden später zogen wir ein externes Unternehmen, die croit GmbH, hinzu. Deren Spezialisten analysierten die Situation und stellten nach einiger Zeit fest, dass wir tatsächlich auf einen Bug in Ceph gestoßen waren.
Beim Versuch, die Anzahl der MDS zu reduzieren, griff der Ceph-Monitor auf eine leere interne Datenstruktur zu und stürzte ab. Exakt dieser Fehler wurde bereits einen Tag später durch croit im Ceph Pull-Request #65413 an das Ceph-Projekt gemeldet. Eine gute Sache hat der Vorfall. Er fließt direkt in die Weiterentwicklung von Ceph ein.
Parallel dazu arbeiteten wir bei INWX an der Wiederherstellung der Hosting-Services.
Wir hatten ein Backup der Hosting-Daten, dieses war jedoch aus technischen Gründen 48 Stunden vor dem Ausfall abgeschlossen worden. Zudem dauerte die Erstellung eines Backups bei dieser Datenmenge etwa acht Stunden, sodass der Datenbestand in sich nicht vollständig “atomar” war. Die Datenbanken des Webhostings lagen glücklicherweise außerhalb von CephFS und waren nicht betroffen. Dennoch zögerten wir lange mit einer Rücksicherung, denn gerade im Zusammenspiel zwischen Webseiten-Dateien und Datenbanken bestand die Gefahr, dass Inkonsistenzen entstehen würden, wenn wir auf den Stand des Backups zurückgingen.
Das croit-Team stellte uns bereits zum Abend des 04.09. gepatchte Monitor-Binaries zur Verfügung, mit denen der Cluster wieder quorate (beschlussfähig) wurde. Dieser erste Teilerfolg bedeutete, dass unser Cluster im Sinne der RBDs wieder voll betriebsfähig war und wir keine Ausfälle unserer virtuellen Maschinen mehr befürchten mussten.
CephFS war jedoch nach wie vor nicht erreichbar, woraufhin ab dem nächsten Morgen am Freitag, den 05.09., croit unermüdlich weiter Debugging der Ceph Software betrieb und uns am Abend eine weitere, neue gepatchte Version zur Verfügung stellte. Direkt im Anschluss und noch am Samstag wurde diese neue Version von uns und croit getestet, leider nicht mit dem nötigen Erfolg.
Zwischenlösungen für unsere Kund:innen
Die Tage bis zur endgültigen Wiederherstellung waren für unsere Kund:innen nicht minder belastend.
Wichtig war für unsere Kund:innen insbesondere, dass sie wieder Mails senden und empfangen konnten. Daher fokussierten wir uns am Freitag darauf zumindest diese Funktionalität wiederherzustellen.
Am Freitagabend, den 05.09., gelang es uns, unter Einsatz einer ZFS- und NFS-basierten Speicherlösung, das Mailhosting rudimentär wiederherzustellen: Postfächer und Adressen waren wieder erreichbar, neue Mails konnten wieder empfangen und versendet werden. Alte Mails fehlten zunächst, aber die Erfahrung zeigte uns, wie wichtig es war, wenigstens diesen Teilbetrieb wieder zu ermöglichen.
Wir setzten uns auch eine feste Deadline für den folgenden Montag um 24:00 Uhr, zu der wir in jedem Fall den Datenbestand des Backups einspielen würden und trafen bereits die hierfür nötigen Vorbereitungen.
Weiterhin entschieden wir uns dafür, über das Wochenende einen Notfallsupport bereitzustellen und auf Wunsch auch die Wiederherstellung der Hostingpakete aus dem Backup anzubieten.
Einspielen des Backups
Am Montag zeichnete sich bereits ab, dass wir wieder Zugriff auf das CephFS bekommen würden, jedoch war nicht klar, in welcher Form und wie vollständig dieser Zugriff sein würde. Als wir dann unsere selbstgesetzte Deadline erreichten, trafen wir die Entscheidung das Backup einzuspielen.
Glücklicherweise kam es beim Webhosting nur vereinzelt zu Problemen.
Das Backup der Mailhosting-Daten führten wir mit den Mails, welche seit Freitag eingegangen waren zusammen. Hier folgte auch durch die Neuindizierung aller Postfächer direkt der erste Lasttest für die neue Speicherinfrastruktur.
CephFS wieder verfügbar
Erst durch einen Session-Reset der MDS, auf Basis der potentiell destruktiven Disaster-Recovery-Prozedur in Verbindung mit für uns modifizierten Ceph Binaries, gelang es croit, das Filesystem wieder zum Leben zu erwecken. Eine außergewöhnliche Leistung!
Am 09. September, sechs Tage nach Beginn des Ausfalls, konnten wir CephFS wieder mounten und mit rsync sichern. Dabei zeigte sich: Es war kein Datenverlust entstanden.
Wir begannen sofort, die fehlenden Mails ebenfalls wiederherzustellen. Das geschah in zwei Schritten:
- Der Bestand zwischen Ende des Backups und dem Ausfall ließ sich anhand der Änderungszeiten eindeutig filtern.
- Der Bestand zwischen Anfang und Ende des Backups konnte theoretisch Duplikate enthalten. Diese ermittelten wir mit dem Tool
rdfindund entfernten sie. Anschließend ließen sich die Nachrichten sauber in den Datenbestand integrieren.
Dieser Prozess zog sich noch bis zum folgenden Wochenende, doch am Ende stand fest: es ging keine einzige Mail verloren.
Kommunikation nach außen
Parallel zum Incident hielten wir unsere Kund:innen bereits seit Mittwoch Abend auf dem Laufenden mit Statusmeldungen unter https://is.inwx.online. Da die Statusseite nicht allen Kund:innen bekannt war, erfolgte am Freitag zusätzlich eine erste E-Mail an unsere Kund:innen.
Teilweise waren unsere Formulierungen sehr vorsichtig. Aus Kund:inensicht wäre es hilfreicher gewesen, die Ursache des Ausfalls genauer zu benennen, auch wenn das ggf. zu technisch klingt.
Auch möchten wir über bevorstehende Wartungsarbeiten noch aktiver informieren als bisher, wo dies nur auf der Statusseite erfolgt ist. Der INWX Tech-Newsletter soll wieder mehr für Ankündigungen von Wartungsarbeiten der INWX-Infrastruktur genutzt werden.
Lessons Learned
Wir haben viel gelernt in dieser Woche. Clustersysteme wie Ceph bergen das Risiko, dass eine einzelne Konfigurationsänderung die gesamte Umgebung lahmlegt. Das wussten wir zwar schon vorher, jedoch haben wir das für Ceph deutlich zu gering eingeschätzt. Künftig werden wir daher stärker auf Redundanz durch mehrere Cluster setzen.
Besonders kritisch ist, dass Ceph bei Ausfall der Monitore, kaum Möglichkeiten bietet Daten wiederherzustellen. Für Systeme, bei denen höchste Verfügbarkeit zählt, werden wir daher auf andere Storage-Technologien ausweichen. Ceph kommt zwar weiterhin zum Einsatz, wir verzichten aber bereits jetzt schon auf den Einsatz von CephFS und haben die Hosting-Infrastruktur auf ZFS und NFS umgestellt.
Wir haben auch erkannt: Wenn ein so zentrales System wie Ceph betrieben wird, ist ein guter Partner wie croit unverzichtbar. Ohne die Hilfe der Ceph-Entwickler wäre ein Datenverlust kaum zu verhindern gewesen.
Schlussendlich: Backups und Snapshots. Mit ZFS können wir Snapshots erzeugen und damit Backups häufiger machen als uns bislang technisch möglich war. Unser Ziel ist es damit, zusätzlich zu unseren täglichen Backups, noch stündliche Datensicherungen zu haben.
Fazit
Der Ausfall unseres Ceph-Clusters war eine der kritischsten Situationen der letzten 10 Jahre. Er hat uns Nerven und Zeit gekostet und uns einiges an grauen Haaren beschert – hat aber eben auch dazu geführt, dass ein Bugfix in Ceph entstanden ist und wir selbst wertvolle Erkenntnisse gewonnen haben.
Die Tatsache, dass wir tatsächlich keine Daten verloren haben, ist jedoch einzig und allein dem croit-Team zu verdanken. Nur durch deren unermüdlichen Einsatz und tiefgehendes Verständnis von Ceph konnte der Cluster wiederhergestellt werden. Die Tiefe in die hier eingestiegen werden musste, kann in der Kürze dieses Artikels (und “kurz” ist hier auch nicht mehr wirklich anwendbar) sicherlich nicht genügend gewürdigt werden. Mitglieder des Ceph Steering Committee und Component Leads der verwendeten Software waren (durch croit) direkt involviert.
Für unsere Kund:innen war es eine harte Woche, für uns ebenso. Dass wir am Ende ohne Datenverlust davongekommen sind, ist dem Engagement unseres Teams, der Geduld unserer Kund:innen und der Unterstützung von croit und der Ceph-Community zu verdanken.
