Zwei Tage Ceph: Zwischen Magie, Frust und dem Wunsch nach Kontrolle

Das ermöglicht:

• ✅ Flexibles Hinzufügen von Speicher
• ✅ Automatische Replikation & Redundanz
• ✅ Ausfallsicherheit über viele Knoten
• ✅ Kosteneffizienz durch Standard-Hardware

Was ist Ceph überhaupt?

Ceph ist eines der bekanntesten Open-Source-Projekte im SDS (Software Defined Storage) Bereich. Es kann Objekte, Blöcke und Dateien speichern – und das auf vielen Knoten gleichzeitig, mit automatischer Redundanz und Ausfallsicherheit. Kurz gesagt:

Ceph ist das Schweizer Taschenmesser für Software-Defined Storage.

Ceph verspricht:

• ✅ Hochverfügbarkeit
• ✅ Selbstheilung
• ✅ Skalierbarkeit bis ins Unendliche
• ✅ Offene Architektur, die sich in viele Umgebungen integrieren lässt

Aber wie schlägt es sich in der Praxis, wenn man mit einem 4-Node-Cluster loslegt, der produktionsreif werden soll?

Wir wollten es richtig machen. Keine halben Sachen. Unsere Architektur war klar definiert:

• 4 Nodes mit Ubuntu für den Speicherplatz
• 2 Management Nodes für die Verwaltung
• Insgesamt rund 200 HDDs und eine große SSD pro Node
• Proxmox als Compute-Cluster
• Ceph als reines Storage-Backend
• Separater Proxmox Backup Server (PBS) mit JBOD für die Datensicherung

Ziel: Eine klare Trennung zwischen Compute und Storage. Clean. Stabil. Wartbar.

Erste Wahl: Ceph mit Container-Magie (cephadm + Dashboard)

Ceph mit Orchestrator – schön gedacht, aber nicht ganz zu Ende geführt
Seit Version 15 wird Ceph standardmäßig containerisiert ausgeliefert – mithilfe des Ceph Orchestrators, der auf Technologien wie Docker (bzw. Podman) und systemd basiert. Der Orchestrator übernimmt dabei die Verwaltung der Ceph-Dienste: Monitore, Manager, OSDs, MDS, RGW etc. werden nicht mehr direkt als systemweite Dienste installiert, sondern als Container ausgeführt. Das soll die Wartung vereinfachen und Upgrades sicherer machen. In der Praxis führt das jedoch zu einer zusätzlichen Abstraktionsschicht, die Fehlersuche, Logging und Debugging deutlich erschwert – insbesondere, wenn Dinge nicht wie erwartet funktionieren. Die Flexibilität ist hoch – die Transparenz leidet. Und gerade bei Storage will man eines ganz sicher: Vertrauen, Stabilität und Kontrolle.

Die Probleme im Detail

• Im ceph orch-Modul (das ist die Oberfläche die die Software auf allen Nodes koordiniert einrichtet) klappte das Anlegen von OSDs (Object Storage Devie = 1 Festplatte) manchmal, manchmal nicht.
• Das Anlegen der OSD über YAML-Dateien wurden ohne Fehlermeldung akzeptiert, aber es passierte… nichts. Kein Fehler, keine OSD.
• Das Dashboard zeigte einenn der 4 Nodes (cephs1r) nicht mehr an – obwohl er laut Benutzeroberfläche korrekt registriert war.
• Alte OSDs ließen sich nicht richtig löschen: Im osd tree weg, aber ceph orch ps listete sie weiter auf
• Debugging der Container? Ohne Logs? Ohne Transparenz? Viel Spaß.

 Am Ende hatten wir:

• Kein einziger OSD lief.
• Der Cluster sagte er sei gesund, aber leer.
• Die Anzeigen im Dashboard und den unterschiedlichen Tools waren inkonsistent
• Der Frust war groß.

Erkenntnis: Ceph funktioniert. Mit Cephadm verliert man das Vertrauen

Wir lieben die Idee hinter Ceph. Und: Wir glauben immer noch daran. Aber:

Cephadm ist für den professionellen Einsatz nicht stabil genug.

Der Container-Ansatz entzieht einem zu viel Kontrolle:

• Man sieht nicht, was schiefgeht
• Man kann nicht eingreifen
• Selbst einfache Dinge wie das Entfernen alter OSDs sind ein Alptraum
• Nichts funktioniert wie es soll

Das schöne Dashboard und die versprochene Magie hilft nichts, wenn man immer hinterher aufräumen muss. 

Fazit nach 2 Tagen mit Cephadm

• ❌ Cephadm verspricht einfache Verwaltung, liefert aber Intransparenz
• ❌ Die Kombination von ceph orch, YAML-Deployments und DB-Devices funktioniert nicht konsistent
• ❌ Debugging ist fast unmöglich, wenn Container nicht tun was sie sollen
• ❌ Auch das CLI sagt manchmal was anderes als das Dashboard

Kurz: Wer glaubt, Cephadm ist Plug&Play, wird bitter enttäuscht. Wenn das bereits im Testbetrieb so ein Albtraum ist, was ist dann, wenn wirklich einmal etwas schief geht?

Wie geht’s weiter?

Wir bauen den Cluster neu auf. Ohne Container.

• Klassische installiert ohne Container
• Volle Kontrolle über OSD-Setup
• Kein versteckter Zauber, sondern nachvollziehbare Schritte

Was wir brauchen ist Zuverlässigkeit, Transparenz und Kontrolle. Der Orchestrator wäre ein nettes Feature, wenn es tun würde, was man ihm sagt. 

Vielleicht kommt Cephadm in ein paar Releases dorthin. Heute ist es noch nicht so weit.

Und hey: Wir schreiben das nicht aus Trotz. Sondern aus Erfahrung.

Du willst mehr über unsere Architektur wissen, oder wie wir Ceph „klassisch“ neu aufsetzen? Schreib uns. Oder bleib dran: Teil 2 folgt bald.