Wie ein einziger fehlerhafter API-Aufruf einen ganzen Ceph-Cluster lahmlegte

Es begann mit einem einzigen Befehl — einer simplen curl-Anfrage, die eigentlich nur ein paar harmlose Statistiken abrufen sollte. Stattdessen zwang sie einen ganzen Ceph-Cluster in die Knie.

Ein Homelab-Admin, der mit Cephs RESTful API herumbastelte, schickte, was eigentlich ein Routineaufruf hätte sein sollen:

curl -k -X POST "https://USERNAME:API_KEY@HOSTNAME:PORT/request?wait=1" -d '{"prefix": "df", "detail": 1}'

Diese Zeile sieht nicht gefährlich aus. Es ist die Art von Einzeiler, den wohl jeder, der Ceph betreibt, schon in irgendeiner Form benutzt oder getestet hat — ein kurzer Blick auf Pool-Statistiken, etwas, das man normalerweise mit ceph df detail abrufen könnte. Aber diesmal löste dieser winzige detail-Parameter — "detail": 1 — etwas weitaus Schlimmeres aus als einen Parsing-Fehler. Innerhalb von Sekunden stürzten die Monitor-Dienste (ceph-mon) im gesamten Cluster ab.

Jede VM, die am System hing, fror ein. Das Proxmox-Dashboard färbte sich rot. Storage-Daemons schrien lautlos. Der Cluster — das schlagende Herz einer selbstgehosteten Infrastruktur — war tot.

Und das alles wegen einer einzigen fehlerhaften API-Anfrage.

Der Tag, an dem die Monitore starben

Zunächst sah es nach einem kleinen Ausrutscher aus. Der Admin, der unter dem Namen packetsar auftritt, bemerkte, dass Cephs Monitore Fehler warfen. Aber statt sich zu erholen, stürzten sie ab — und stürzten immer wieder ab. Die Logs füllten sich mit einer unheimlich präzisen Meldung:

ceph-mon[278661]: terminate called after throwing an instance of 'ceph::common::bad_cmd_get'
ceph-mon[278661]: what():  bad or missing field 'detail'

Jeder, der schon mal mit Ceph gerungen hat, weiß: Wenn die Monitore (MONs) ausfallen, ist das kein kleines Problem. MONs behalten die Cluster-Map im Blick — sie wissen, welche OSDs welche Daten halten, wo Pools liegen, wer im Quorum ist. Sind sie offline, verliert der Cluster effektiv sein Gedächtnis.

Aber das war kein einzelner Node-Absturz. Es kaskadierte über alle Monitore hinweg. Jeder einzelne holte sich die vergiftete Anfrage aus einer gemeinsamen Datenbank und stürzte damit geradewegs die Klippe hinunter. Jeder Neustartversuch wiederholte nur den Fehler.

„Reboots, Dienst-Neustarts — nichts hat funktioniert", schrieb packetsar. „Ceph- und Proxmox-Cluster sind komplett down, und die VMs sind an diesem Punkt gestoppt."

Die selbstverschuldete Giftpille

Das Seltsamste daran? Der Befehl hätte gar nicht so schädlich sein dürfen. Cephs API soll Eingaben eigentlich validieren — fehlerhaftes JSON oder unbekannte Felder sauber abfangen. Stattdessen wurde der Parameter "detail": 1 so interpretiert, dass er eine fatale Exception im MON-Prozess auslöste.

Im Grunde nahm Ceph die fehlerhafte Anfrage auf, verschluckte sich daran — und speicherte sie dann ab, um denselben ungültigen Befehl bei jedem Neustartversuch der Monitore erneut abzuspielen. Es ist wie ein Crash-Loop-Zyklus: Der Cluster erinnerte sich an den fehlerhaften Befehl und fütterte sich immer wieder selbst damit.

„Sieht so aus, als wäre die Anfrage in einer gemeinsamen ceph-mon-Datenbank gelandet und hätte alle Monitor-Dienste zum Absturz gebracht", schrieb der Admin.

Es war nicht nur ein fehlerhafter Befehl, es war eine dauerhafte Korruption. Der vergiftete Zustand steckte im Monitor-Store selbst, sodass ihn nicht einmal saubere Neustarts abschütteln konnten.

Ein Kommentar brachte es perfekt auf den Punkt:

„Noch ein Beispiel für schlechte Eingabevalidierung? Nicht vergessen, das als Bug an Ceph zu melden."

Es ist eine einfache, aber brutale Wahrheit: Wenn Sie verteilte Systeme bauen, ist Eingabevalidierung keine Option, sondern Pflicht. Ein einziges ungeprüftes Feld kann alles zum Einsturz bringen.

„Man kann den ganzen Cluster mit einem einzigen REST-Aufruf vergiften"

So beschrieb es packetsar später im Thread. Das klingt übertrieben — bis man sich an Cephs Architektur erinnert.

Ceph ist um Konsens herum gebaut. Die Monitore replizieren Daten, um das Quorum aufrechtzuerhalten. Bekommt einer schlechte Zustandsdaten, gibt er sie an die anderen weiter, in der Annahme, sie seien gültig. Schafft es also ein fehlerhafter Befehl in die Monitor-Datenbank, wird er getreulich auf alle Nodes kopiert. Das System vertraut seinen Peers — das ist seine Stärke und in diesem Fall seine Schwäche.

Als jemand fragte, ob derselbe Befehl über die CLI problemlos funktionierte, bestätigte der Admin: Ja, ceph df detail lief über die Kommandozeile einwandfrei. Es war die REST-API-Schicht, die nicht richtig validierte. Diese Unterscheidung ist entscheidend, denn sie bedeutet, dass das Problem nicht bei Cephs Logik lag, sondern bei ihrem API-Wrapper — einer Schicht, die Automatisierung eigentlich sicherer und einfacher machen sollte.

Stattdessen wurde sie zum Single Point of Failure.

Wiederaufbau aus der Asche

Als das Ausmaß des Ausfalls klar wurde, stellte sich die eigentliche Frage: Wie bringt man einen toten Ceph-Cluster zurück, wenn nicht einmal die Monitore starten?

Für Cephs Monitor-Datenbank gibt es keinen magischen „Rückgängig"-Knopf. Also musste packetsar old-school vorgehen — die Datenbank manuell aus den OSDs (Object Storage Daemons) neu aufbauen. Das ist eine Methode, die tief in der Ceph-Dokumentation vergraben ist und normalerweise extremen Korruptionsszenarien vorbehalten bleibt.

Hier der vereinfachte Wiederherstellungsprozess:

1. Alle OSDs auf jedem Host herunterfahren, um weitere Schreibvorgänge zu stoppen.
2. Einen Host als Ausgangspunkt wählen und mit den Daten seiner lokalen OSDs eine frische Monitor-Datenbank aufbauen.
3. Dieses neue store.db per Rsync auf die anderen Hosts übertragen, einen nach dem anderen, dabei laufend neu aufbauen und zusammenführen.
4. Sobald die Datenbank vollständig ist, das Produktions-store.db auf allen Monitoren durch das neue ersetzen.
5. Die MONs wieder hochfahren und Quorum erreichen lassen.
6. Zuletzt die Manager-Daemons (mgr) einzeln neu aufbauen und Einstellungen wie das REST-API-Modul neu konfigurieren.

Das macht man nicht leichtfertig. Es ist langsame, nervenaufreibende Arbeit — besonders wenn der Storage-Cluster das Fundament der gesamten Virtualisierungsumgebung ist.

Aber es funktionierte.

„Etwa eine Stunde, nachdem ich mich langsam durch den Wiederaufbauprozess gearbeitet hatte, konnte ich die VMs wieder online bringen", schrieb er.

Das ist bemerkenswerte Resilienz — und ein Beleg dafür, wie tief man Open-Source-Systeme verstehen und reparieren kann, wenn man volle Kontrolle und Geduld hat.

Lehren aus dem Meltdown

Wenn diese Geschichte eine Moral hat, dann nicht „Fassen Sie Ihren Cluster nicht an." Herumbasteln ist, wie man lernt. Aber verteilte Systeme, besonders solche wie Ceph, verlangen einen besonderen Respekt.

Ein paar Erkenntnisse stechen aus diesem Debakel hervor:

1. APIs sind nicht immer sicherer

Wir neigen dazu zu denken, APIs würden Risiko abstrahieren — dass strukturierte Aufrufe statt roher Befehle Automatisierung sicherer machen. Aber dieser Vorfall zeigt, dass das Gegenteil der Fall sein kann, wenn die API Eingaben nicht richtig validiert.

Fehlerhafte Eingaben über eine API sollten nicht den Dienst lahmlegen, den sie eigentlich zugänglich machen soll. Das ist Entwicklung 101.

2. Persistenz ist ein zweischneidiges Schwert

Cephs Design macht es resilient — es hält Daten über Nodes hinweg konsistent, selbst durch Abstürze hindurch. Aber dieselbe Persistenz macht es auch unnachgiebig. Speichert es einen fehlerhaften Zustand, wird dieser fehlerhafte Zustand zum Gesetz, bis er manuell entfernt wird.

3. Testen in Produktion ist kein Testen

Es ist verlockend, „nur eine Kleinigkeit" im Live-Cluster zu testen, besonders wenn man es schon hundertmal getan hat. Aber ein selbstgehostetes Lab ist nicht dasselbe wie eine Sandbox. Ein fehlerhafter Befehl kann aus einem Abendexperiment eine Wiederherstellungssitzung um 4 Uhr morgens machen.

4. Dokumentation ist Überlebenssicherung

Was diesen Cluster rettete, war kein Glück — es war Dokumentation. Die Fähigkeit, einen Monitor-Store aus OSDs neu aufzubauen, ist kein Allgemeinwissen. Es ist die Art von Prozess, die tief in Cephs Low-Level-Dokumentation vergraben ist, das Zeug, das am Ende nur verzweifelte Admins lesen. Aber genau das brachte den Cluster zurück.

Die stille Gefahr lautloser Ausfälle

Das war nicht die erste Ceph-Katastrophengeschichte, und es wird nicht die letzte sein. Tatsächlich meldeten sich andere mit unheimlich ähnlichen Erfahrungen zu Wort — Cluster, die sich nach Stromausfällen weigerten, wieder hochzukommen, irreparabel korrumpierte Monitore oder Phantom-Konfigurationen, die einfach nicht sterben wollten.

Ein Nutzer schrieb:

„Habe es geschafft, Ceph durch einen unerwarteten Stromausfall zu zerschießen … es kam nie wieder hoch, und nichts, was ich versuchte, funktionierte. Selbst ein Neuanfang von null holte immer wieder alte Überreste zurück. Ich habe Ceph an den Nagel gehängt und bin zu ZFS mit Replikation gewechselt."

ZFS ist kein verteilter Storage — es tauscht Skalierbarkeit gegen Einfachheit und Zuverlässigkeit. Das ist bezeichnend. Wenn der Wiederherstellungsweg eines Systems schwerer ist als eine komplette Migration, ist das ein Warnsignal.

Ceph ist mächtig, aber nicht nachsichtig. Es gibt Ihnen unglaubliche Flexibilität — Object-, Block- und File-Storage auf einer Plattform —, setzt aber voraus, dass Sie mit dieser Macht verantwortungsvoll umgehen.

„Öffentliche Bloßstellung ist vielleicht die beste Medizin"

Ein Kommentator scherzte halb, dass sich „die Ceph-Entwickler schämen sollten", wenn der Bug reproduzierbar sei. Und ehrlich gesagt, damit liegt er nicht falsch.

Das ist kein obskurer Randfall. Ein authentifizierter REST-Aufruf sollte niemals Kernservices zum Absturz bringen können, Punkt. Ob Sie ein Homelab oder ein Rechenzentrum betreiben — diese Art von Zerbrechlichkeit untergräbt das Vertrauen in den Stack.

Open-Source-Software lebt von Transparenz. Bugs passieren — aber solche wie dieser zeigen, wie sehr besseres Testing bei der API-Eingabevalidierung gebraucht wird, besonders bei Befehlen auf Admin-Ebene.

Nachwirkungen und Reflexion

Die Geschichte hat ein Happy End — der Cluster wurde wiederbelebt, die VMs kamen wieder online, und der Admin lernte in wenigen Stunden mehr über Cephs Interna, als die meisten in Monaten lernen.

Aber es hinterließ auch Spuren. „Es erscheint verrückt, dass man den ganzen Cluster mit einem einzigen REST-Aufruf vergiften kann", sagte er. Und er hat recht.

Verteilte Systeme sollen resilient sein, aber Resilienz bedeutet keine Unbesiegbarkeit. Manchmal bedeutet sie Wiederherstellbarkeit. Und genau das zeigt dieser Fall am deutlichsten — nicht Perfektion, sondern die Fähigkeit, sich zurückzukämpfen, wenn alles schiefgeht.

Das große Ganze

Es gibt hier ein größeres Thema rund um die Zerbrechlichkeit von Automatisierung in moderner Infrastruktur. Wir bauen Schicht um Schicht — APIs auf Daemons, Daemons auf Datenbanken —, alles, um die Verwaltung einfacher zu machen. Aber jede Schicht bringt auch neue Komplexität und neue Wege zum Scheitern mit sich.

In Cloud-nativen Umgebungen vervielfacht sich dieses Risiko. Jeder Dienst spricht über APIs mit einem anderen. Jeder Befehl, jedes Deployment-Skript, jeder Automatisierungsjob trägt das Potenzial in sich, eine Kaskade auszulösen.

Und wenn etwas wie Ceph — eines der angesehensten Open-Source-Storage-Systeme der Welt — durch ein einziges fehlerhaftes JSON-Feld zu Fall gebracht werden kann, ist das eine Erinnerung daran, dass Komplexität immer ihren Preis hat.

Epilog: Eine Zeile, sie zu knechten

Irgendwo in einer Terminal-History liegt dieser schicksalhafte Befehl. Klein, unscheinbar — eine Textzeile, die in einen Tweet passt.

Aber dahinter steckt eine Geschichte über Vertrauen, Zerbrechlichkeit und Resilienz in verteilten Systemen. Darüber, wie selbst die ausgefeilteste Software an einem winzigen Fehler zerbrechen kann. Und darüber, wie sie mit dem richtigen Wissen, Ausdauer und Dokumentation wieder zum Leben erweckt werden kann.

Denn manchmal ist der Unterschied zwischen totalem Datenverlust und Wiederherstellung einfach nur zu wissen, welche Datei als Nächstes per Rsync übertragen werden muss.