Storage-Reise, Teil 1: Was uns Ceph gelehrt hat

Beim Wechsel zu Proxmox stellte sich sofort die Storage-Frage: kein zentrales SAN mehr, sondern software-defined storage auf den Nodes selbst. Der naheliegende Start war Ceph — Proxmox integriert es direkt.

Was Ceph richtig macht

Ceph ist ein verteiltes Objekt-, Block- und Dateisystem mit Selbstheilung und beliebiger Skalierung. Drei Eigenschaften haben uns überzeugt:

• Keine Single Points of Failure — Daten werden über CRUSH auf viele OSDs verteilt.
• Skalierung in die Breite — Nodes hinzufügen, Kapazität wächst mit.
• Block-Storage (RBD) integriert sich sauber in Proxmox.

Die Hardware-Wahrheit

Ceph belohnt gute Hardware und bestraft Sparsamkeit gnadenlos. Drei Dinge sind nicht verhandelbar:

• Netzwerk: Ceph kommt erst ab 10 GbE richtig in Fahrt. Ein dediziertes Storage-Netz (getrenntes Public- und Cluster-Netz) und durchgängige Jumbo Frames (MTU 9000) über den gesamten Pfad sind Pflicht — sonst sägt schon ein einzelner Rebalancing-Vorgang die VM-Performance ab.
• Datenträger: Enterprise-SSDs/NVMe mit Power-Loss-Protection. Consumer-NVMe stützt sich auf SLC-Caching und bricht ein, sobald der Cache voll ist — und Ceph erzeugt genau die kleinen, zufälligen Schreibzugriffe und Metadaten-Operationen, die diesen Cache füllen.
• RAM und CPU: Jeder OSD-Daemon will mehrere Gigabyte RAM. Bei einem Node-Ausfall schiessen die CPU-Lasten hoch, weil Daten neu verteilt (Backfill/Recovery) werden.

Replikation und Failure Domains

Standard ist size=3 / min_size=2: drei Kopien, Schreibzugriffe bei mindestens zwei verfügbaren Kopien. Die Failure Domain sollte auf Host-Ebene liegen, damit jede Replik auf einem anderen Server landet. Drei Nodes sind das absolute Minimum — wohlfühlen tut sich Ceph erst mit deutlich mehr.

Wo es für uns geklemmt hat

Ceph ist für grosse Cluster gebaut. In kleineren Setups zeigt sich der Preis:

• Ressourcenhunger: RAM und CPU pro OSD summieren sich; die Empfehlung von vielen Nodes ist real, nicht akademisch.
• Latenz: Für sehr schreibintensive, latenzsensible VM-Workloads war die Write-Latenz höher als gewünscht — ohne dediziertes 10-GbE-Storage-Netz war das Plateau schnell erreicht.
• Operativer Aufwand: Recovery- und Rebalancing-Vorgänge wollen verstanden und überwacht werden — ceph -s und Prometheus/Grafana sind Pflicht, kein Nice-to-have.

Fazit

Ceph war kein Fehler — es hat uns das Denken in verteiltem Storage beigebracht. Aber für unsere Node-Anzahl und unser Latenzprofil suchten wir etwas Schlankeres und Schnelleres. Das führte uns zu Vitastor — dazu Teil 2.