Bericht über einen CEPH Ausfall am 11. März 2025

Am 10. März 2025 kam es bei den von uns bereitgestellten Diensten zu einem etwa zweistündigen Ausfall, der sich auf virtuelle Maschinen und andere Dienste auswirkte und durch intermittierende Probleme beim Speicherzugriff verursacht wurde. Nachfolgend finden Sie eine detaillierte Analyse des Vorfalls, seine Ursache und die Maßnahmen, die wir ergreifen, um zukünftige Vorfälle zu verhindern.

Zunächst möchten wir uns bei allen Kunden für die Unannehmlichkeiten entschuldigen, die wir durch die Nichtverfügbarkeit des Blockspeichers und die verminderte IO-Leistung vom 9. März bis zum 11. März verursacht haben.

Der folgende Störungsbericht soll ein klares Verständnis und eine transparente Sicht auf die von uns durchgeführten Maßnahmen vermitteln, die uns veranlasst haben, am 10. März von UTC 17:41 bis UTC 19:44 eine unvermeidliche Notfallwartung durchzuführen.

Getroffene Maßnahmen

Upgrades auf neue Major-Releases werden um 6 Monate nach dem EOL der aktuellen Version verzögert, da Fehlerbehebungen aktiv zurückportiert werden. Die Speicherkapazität wird auf einem viel höheren Niveau als bisher reserviert, um uns mehr Zeit zu verschaffen, wenn kritische Probleme auftreten. Wir sind jetzt in das Ticket-System von Croit eingebunden und werden mit ihnen in Kontakt bleiben, um einen Partner an unserer Seite zu haben, der in der Lage ist, schwerwiegende CEPH-Probleme anzugehen.

Fachbegriffe:
CEPH = Open Source Enterprise Storage Clustering Lösung
OSD = Object Storage Daemon zur Bereitstellung von Speicherplatz für Datenpools in CEPH
CEPHADM = Lösung für die einfache Bereitstellung und Wartung von CEPH-Clustern
PG = Platzierungsgruppen, die die Datenzuweisung für Datenpools an OSDs im CEPH organisieren

Ereignisse

11. Februar

Wir haben Routinearbeiten an unserer allgemeinen Staging-Umgebung durchgeführt und beschlossen, die CEPH-Komponenten von CEPH Reef auf Squid zu aktualisieren, da das letzte CEPH-Upgrade bereits ein Jahr zurückliegt. Mit dem heutigen Tag (11. März) ist die Staging-Umgebung immer noch voll funktionsfähig auf CEPH Squid.

19. Februar

Mit Hilfe von CEPHADM haben wir das Upgrade von CEPH Reef auf Squid in der Produktionsumgebung angestoßen. Das Upgrade wurde vollständig automatisiert durch CEPHADM durchgeführt, ohne dass während oder nach dem Upgrade Probleme auftraten.

5. März

UTC 20:06

Aufgrund der wachsenden Kundennachfrage nach Speicherkapazität wurde dem Cluster auf Host A ein neuer OSD hinzugefügt.

6. März

UTC 14:13

Nachdem uns unser Monitoring auf das neue OSD Flapping aufmerksam gemacht hatte, führten wir Routinechecks durch, um die Funktionalität der jeweiligen Hosts zu bewerten und überprüften auch den Cluster-Status, der zu diesem Zeitpunkt ebenfalls noch betriebsbereit war. Da wir keinen konkreten Hinweis auf ein Problem mit dem OSD gefunden hatten und der Cluster sich in einem akzeptablen Betriebszustand befand, setzten wir das flatternde OSD erneut ein, in der Hoffnung, dass das Problem damit verschwinden würde.

UTC 14:41

Da das OSD immer wieder abzustürzen schien, haben wir begonnen, das OSD zu debuggen und die Logs zu untersuchen. Dabei sind uns Meldungen aufgefallen, die auf Probleme hinweisen, die damit zusammenhängen, dass OSDs ihr maximales Speicherziel erreichen oder die Bluestore-Komponente wegen erreichter Grenzen für die Bluefs-Allokationsgröße, den Allocater im Allgemeinen und die Startbahnprotokolle einen Segfault verursacht. Diese Probleme legen nahe, diese Einstellungen zu ändern und wurden daher von uns unter fortgesetzter Untersuchung angewendet.

UTC 16:26

Das OSD stürzte immer wieder ab und schließlich beschlossen wir, das OSD von Host A auf Host B zu verschieben, da wir die Oculink-Verkabelung zur Backplane des Hosts als mögliche Ursache für die aufgetretenen Probleme vermuteten. Das Ceph-Tool ceph-bluestore-tool meldete nicht behebbare Fehler im bluestore-Dateisystem.

UTC 19:39

Das OSD wurde verschoben und der Wiederherstellungsvorgang für nicht vollständig replizierte PGs gestartet.

UTC 23:40

The OSD crashed again on Host B, at that point we suspected a firmware issue of the 15.36 TB NVMe pm9a3 to be the issue as another user reported on reddit: https://www.reddit.com/r/ceph/comments/1j07rwr/got_4_new_disks_all_4_have_the_same_issue/ Es wurde eine neuere NVMe-Firmware installiert und das OSD wieder in Betrieb genommen. Da der Speicherbedarf weiter anstieg und die Idee, dass die Firmware der Schuldige war, wurde eine weitere 15,36 TB NVMe von Solidigm bestellt.

7. März

6:34 UTC

Der Cluster war in der Lage, alle nicht replizierten Shards wiederherzustellen, um eine volle 2-fache Fehlertoleranz mit 3 Kopien zu gewährleisten, war aber immer noch damit beschäftigt, verlegte Daten zu verschieben, um einen optimalen OSD-Füllstand zu erreichen.

10:55 UTC

Wir haben die Solidigm NVMe per transoflex express am ersten Morgen nach der Bestellung erhalten und beschlossen, sie dem Cluster hinzuzufügen, um die immer noch wachsenden Speicheranforderungen unserer Kunden zu erfüllen.

17:14 UTC

Das Solidigm NVMe OSD stürzte unerwartet ab und versetzte uns in einen Alarmzustand, da dies eher auf einen Fehler in Ceph hinweist. Wir haben daher damit begonnen, viele Schwankungen aus unserer Umgebung zu entfernen, wie z.B. Verbesserungen der Speicherleistung und andere spezifische Konfigurationen, die im Laufe von 6 Jahren Betrieb hinzugefügt wurden. Die Debug-Protokollierung wurde ebenfalls erhöht, was eine höhere CPU-Auslastung und eine geringere IO-Leistung zur Folge hatte.

19:04 UTC

Das Solidigm OSD stürzte erneut ab und wir begannen erneut, die Logs der Bluestore-Komponente zu untersuchen. Wir erkannten, dass bestimmte RBD-Instanzdaten Abstürze verursachten, da ihre Datenblöcke auf Sektoren platziert worden waren, die den Inhalt anderer Datenblöcke überlappten. Wir haben uns entschlossen, diese RBD-Images aus dem entsprechenden Pool zu entfernen und in eine andere Speicherquelle zu migrieren.

8. März

07:28 UTC

Das neu hinzugefügte pm9a3 OSD ist erneut abgestürzt und hat den Cluster in einen eher riskanten Betriebszustand versetzt, da wir die Situation als nicht mehr deterministisch/kontrollierbar genug für den normalen Alltagsbetrieb erachtet haben. Aus diesem Grund wurde die Mindestgröße der verfügbaren Shards aus unseren Erasure Coded Pools von 5 auf 4 reduziert. Wir haben sofort begonnen, weitere CEPH-gefährdete Benutzer zu erreichen und haben unsere Erkenntnisse mit ihnen geteilt und die Empfehlung erhalten, diese beiden OSDs per NVMe einzusetzen, da die neu hinzugefügten OSDs (15,36tb) doppelt so groß sind wie die alten (7,68tb).

14:50 UTC

Eine der beiden OSDs von einem NVMe stürzte erneut ab, wir ließen sofort das ceph-bluestore-tool im Deep Mode laufen, um den Zustand der Daten zu überprüfen. Wir fanden noch mehr RBD-Instanzdaten-Blobs, die andere überlagerten, obwohl wir viele Anstrengungen unternommen haben.

16:12 UTC

Nachdem wir alle Inspektionen des jüngsten Absturzes abgeschlossen hatten, haben wir CEPH Slack und SCS Matrix Server um weitere Hilfe zu unserem Problem gebeten. Leider gab es keine passenden Fehlerberichte auf dem CEPH Issue Tracker.

19:47 UTC

Da wir uns an viele Leute gewandt haben, sagte uns jemand, dass unsere Situation der von hostup.se ziemlich ähnlich ist. Deren OSDs stürzten ebenfalls ab, wobei nur die EC-Pool-Datenblöcke bei der Ausführung von ceph-bluestore-tool fsck als nicht behebbare Fehler gemeldet wurden. Wir setzten sofort alle weiteren PG-Aktivitäten aus, um sicherzustellen, dass keine weiteren Abstürze auftreten. Aus Vorsicht begannen wir, alle unsere Kerndienste aus dem EC-Pool in einen replizierten Pool zu migrieren.

22:31 UTC

Nachdem wir die Migrationen abgeschlossen haben, haben wir begonnen, alle Möglichkeiten zu evaluieren, um Daten aus dem CEPH-Cluster zu migrieren.

22:56 UTC

Obwohl alle PG-Aktivitäten eingestellt wurden, ist ein weiterer OSD-Absturz aufgetreten und wir haben uns sofort entschlossen, unser Problem an den Notfall-Support der croit GmbH zu eskalieren.

9. März

02:11 UTC

Wir haben unser erstes Telefonat mit croit beendet und sind zu dem Schluss gekommen, dass wir auf die Erreichbarkeit der ceph-Entwickler bei croit warten müssen. Von nun an haben wir den Zustand des Clusters rund um die Uhr in rotierenden Schichten beobachtet, um jeden abgestürzten OSD so schnell wie möglich wieder zum Laufen zu bringen, während wir an Lösungen für die Migration der Daten auf sicherere/stabilere Speicher-Backends arbeiten.

6:40 UTC

Nachdem wir viele Mitbewerber kontaktiert haben, haben wir mit der Migration von Kundendaten auf temporäre Speicherlösungen von synlinq, informaten und dataforest begonnen, während wir gleichzeitig große Anstrengungen unternommen haben, um die Verfügbarkeit des Speicher-Backends und die Datenintegrität aufrecht zu erhalten.

11:20 UTC

Während die Migration auf andere Backends mit eher gedeckelten Geschwindigkeiten weiterlief, haben wir damit begonnen, lokale Softraids zu Hypervisoren hinzuzufügen, um Kunden auf lokale Storage-Backends migrieren zu können.

12:30 UTC

Wir haben die Backup-Management-Funktionalität für unsere Kunden teilweise deaktiviert und damit begonnen, Backups von allen Maschinen zu erstellen, die keine Backups zur Verfügung hatten und sich noch im EC-Pool befanden. Die Situation blieb für die nächste Zeit so, wobei wir versuchten, die Auswirkungen zu minimieren.

10. März

7:20 UTC

Die Entwickler von Croit begannen mit der Arbeit an unserem Problem und waren bereits in der Lage, das Problem, das in unserer CEPH-Umgebung aufgetreten war, zurückzuverfolgen.

10:23 UTC

Der Support in Croit hat gesagt, dass es sehr wichtig wäre, die von uns hinzugefügten OSDs loszuwerden, da diese die einzigen sind, die sich falsch verhalten. Dank unserer Kollegen, die uns eine Menge Speicherplatz zur Verfügung stellen, konnten wir diesen Ansatz verfolgen. Später funktionierte dieser Ansatz leider nicht mehr, da eines der OSDs abstürzte und wir die PG-Operationen erneut stoppten, um weitere Auswirkungen zu vermeiden.

15:23 UTC

Da ein weiteres OSD ebenfalls abstürzte und uns eine noch schlechtere Datenredundanz bescherte, haben wir aufgehört, neue Möglichkeiten für eine Migration ohne Auswirkungen zu prüfen und Croit um weitere Lösungen gebeten. Die letzte realistische Chance, Datenverluste und einen größeren Ausfall zu vermeiden, bestand darin, PGs von den betroffenen OSDs weg zu migrieren, während der Cluster pausiert. Wir haben ein Notfall-Wartungszeitfenster von 2 Stunden ab 17:30 UTC angekündigt.

19:41 UTC

Die Notfallwartung wurde von croit mit unserer Begleitung und Unterstützung erfolgreich durchgeführt. Der Cluster befand sich nach fast 2 Tagen der Unsicherheit in einer stabilen Situation.

11. März

4:17 UTC

Alle Shards und Replikate konnten alle ihre fehlenden Kopien wiederherstellen, so dass der Ceph-Cluster wieder gesund ist.

7:13 UTC

Wir haben eines der OSDs mit einer speziellen Konfiguration wieder hinzugefügt, die darauf abzielt, eine neue Funktion in CEPH Squid zu deaktivieren, die dazu führte, dass Bluestore Daten auf eine falsche Art und Weise schrieb, was letztendlich zu OSD-Abstürzen führte.

16:34 UTC

Ab sofort läuft das OSD bereits seit über 9 Stunden stabil, ohne irgendwelche verdächtigen Fehler oder Warnungen zu melden, die wir zuvor gesehen haben. Fast alle Daten wurden zurück in unseren CEPH-Cluster migriert. Wir werden die Situation weiter beobachten und neue OSDs hinzufügen, sobald wir in der Lage sind, sicherzustellen, dass keine weiteren Probleme auftreten werden.

Der eigentliche Bugreport: https://tracker.ceph.com/issues/70390