Ceph mit Proxmox: Wann verteilter Storage sinnvoll ist — und wann nicht

Ceph taucht in vielen Proxmox-Diskussionen auf — manchmal als Wundermittel, manchmal als Warnung. Beides hat seine Berechtigung. Hier ist meine ehrliche Einschätzung aus der Praxis.

Vergleich aller Storage-Optionen: → NAS & Storage: Welches System passt wann?

Was Ceph ist (und was nicht)

Ceph ist ein verteiltes Storage-System — kein klassisches NAS. Es speichert Daten als Objekte und repliziert sie automatisch über mehrere Server (Nodes). Für Proxmox bedeutet das: VMs liegen nicht auf einer lokalen Festplatte eines Nodes, sondern auf einem Cluster-Storage, auf den alle Nodes gleichzeitig zugreifen können.

Das ermöglicht:

• Live-Migration: VMs ohne Downtime zwischen Nodes verschieben
• Hochverfügbarkeit: Fällt ein Node aus, starten VMs automatisch auf einem anderen
• Keine externe SAN-Hardware: der Storage-Cluster läuft auf denselben Servern wie die VMs

Was Ceph nicht ist: ein einfacher Fileserver oder NAS-Ersatz. Für Dateifreigaben (SMB, NFS) mit Bitrot-Schutz bleibt TrueNAS + ZFS die bessere Wahl.

Die Mindestanforderung: drei Nodes

Das ist keine Empfehlung, sondern eine technische Notwendigkeit. Ceph repliziert Daten standardmäßig dreifach (Replica 3). Für eine korrekte Quorum-Bildung braucht der Cluster mindestens drei Nodes mit Ceph-Monitoren.

Mit zwei Nodes kann Ceph keinen Quorum bilden — bei einem Ausfall würde das gesamte Cluster in Read-Only-Modus gehen. Ein 2-Node-Cluster mit Ceph ist also eigentlich kein hochverfügbares Setup, auch wenn es sich so anfühlt.

Minimum für produktiven Ceph-Einsatz:

• 3 Nodes (besser: 5 für höhere Ausfalltoleranz)
• 10 GbE zwischen den Nodes (1 GbE ist zu langsam für Rebalancing und VM-Traffic)
• Dedizierte SSDs als Ceph-OSD-Journal/WAL (NVMe empfohlen)
• Separates Netzwerk für Ceph-Cluster-Traffic

Typisches Setup in einer Proxmox-Umgebung

Für eine Umgebung mit drei identischen Nodes könnte das so aussehen:

• Jeder Node: 2× 10-GbE-NICs (eine für VM-Traffic/Management, eine für Ceph), 256 GB RAM, 2× NVMe für OS+VMs, 4× SAS/SATA HDDs als Ceph-OSDs
• Netzwerk: dediziertes VLAN oder Switch für Ceph-Cluster-Traffic
• Ceph-Konfiguration: 3 Monitore (je einen pro Node), 12 OSDs gesamt, Replica-3
• Proxmox: CephFS oder RBD (RADOS Block Device) als Storage für VMs und Container

In dieser Konfiguration kann ein kompletter Node ausfallen — alle VMs laufen weiter, ohne dass jemand eingreifen muss.

Was Ceph wirklich kostet

Nicht nur in Hardware, sondern in Betrieb:

Rebalancing: Wenn ein OSD ausfällt, rebalanced Ceph automatisch. Das erzeugt erheblichen Netzwerk- und Schreib-Traffic. Bei langsamem Netzwerk (1 GbE) kann das stundenlang dauern und die Performance des gesamten Clusters beeinträchtigen.

Komplexität im Fehlerfall: Ein Ceph-Problem zu debuggen erfordert Kenntnisse über MONs, OSDs, PGs (Placement Groups), CRUSH-Maps — das ist nichts für eine kurze Google-Session. Im Ernstsfall ist tiefes Linux-Wissen gefragt.

Kapazität: Bei Replica-3 stehen nur ein Drittel der rohen Speicherkapazität nutzbar zur Verfügung. 30 TB OSD-Kapazität = ~10 TB nutzbar.

Wann ich Ceph empfehle

• Proxmox-Cluster mit ≥ 3 identischen (oder ähnlichen) Nodes
• Wenn echte Hochverfügbarkeit ohne externe SAN-Hardware gefordert ist
• Wenn 10-GbE-Netzwerk vorhanden oder geplant ist
• Wenn das Team Linux-Erfahrung und die Bereitschaft hat, Ceph zu betreiben

Wann ich Ceph nicht empfehle

• 1- oder 2-Node-Setups (dort lieber lokalen ZFS-Storage auf den Proxmox-Nodes)
• Wenn kein 10-GbE-Netzwerk vorhanden ist
• Als Fileserver oder NAS-Ersatz
• Wenn kein Mensch im Team Ceph jemals angefasst hat und kein Budget für externe Unterstützung existiert

Für kleinere Proxmox-Umgebungen ohne Hochverfügbarkeitsanforderung ist lokaler ZFS-Storage (direkt auf den Proxmox-Nodes) oft die pragmatischere Wahl — weniger Komplexität, weniger Overhead, ähnliche Datensicherheit.