„Wir nehmen einfach drei Server mit ein paar Platten und machen Ceph drauf“ — so beginnen viele Storage-Projekte, und manche enden in Performance-Problemen oder einem Cluster, der ab 70 % Füllgrad anfängt zu schwächeln. Ceph ist ein exzellentes verteiltes Storage-System, aber es verzeiht Dimensionierungsfehler schlechter als ein klassisches RAID — weil viele Entscheidungen sich nachträglich nur mit Datenmigration korrigieren lassen.
Hier, wie wir Ceph-Cluster für Proxmox-Umgebungen auslegen — und welche Zahlen wirklich zählen.
Warum Ceph-Dimensionierung anders funktioniert
Bei einem klassischen RAID-Controller denken Sie in einzelnen Arrays: ein paar Platten, ein RAID-Level, fertig. Ceph verteilt jedes Objekt über den gesamten Cluster und hält automatisch mehrere Kopien vor. Das hat zwei Konsequenzen für die Planung:
- Rohkapazität ist nicht nutzbare Kapazität. Bei dreifacher Replikation steht nur rund ein Drittel der Rohkapazität wirklich zur Verfügung — und auch das nur bis zu einem sicheren Füllgrad.
- Der Cluster muss sich selbst heilen können. Fällt ein Node aus, stellt Ceph die fehlenden Kopien neu her. Dafür braucht es freie Kapazität und Netzbandbreite — beides muss eingeplant sein, nicht nur die Nutzdaten.
Wer Ceph wie ein RAID plant, plant zu knapp. Die folgenden Abschnitte sind die Reihenfolge, in der wir die Auslegung tatsächlich durchgehen.
Die Node-Zahl: drei ist Minimum, fünf ist der Sweet Spot
Ceph braucht für die Monitor-Quorumsbildung eine ungerade Anzahl von mindestens drei Monitoren. Für die Datenhaltung gilt:
- 3 Nodes sind das absolute Minimum für Produktion mit Replikation size=3. Der Haken: Fällt ein Node aus, kann der Cluster die dritte Kopie nirgends mehr ablegen — er läuft weiter, aber ohne Redundanz-Wiederherstellung, bis der Node zurück ist.
- 4 – 5 Nodes sind unsere Empfehlung für ernsthafte Produktion. Erst ab dem vierten Node kann der Cluster nach einem Ausfall wieder vollständige Redundanz herstellen, ohne dass Sie sofort zur Reparatur rennen müssen.
- Ab 5 Nodes wird auch Erasure Coding sinnvoll nutzbar, und die Last verteilt sich so, dass der Ausfall eines einzelnen Nodes nur einen kleinen Anteil der Gesamtkapazität betrifft.
Die häufigste Fehlentscheidung in dieser Phase: aus Kostengründen mit drei Nodes starten und planen, „später zu erweitern“. Das geht — aber die ersten Monate fährt man ohne echte Selbstheilungs-Reserve.
Replikation oder Erasure Coding?
Zwei Verfahren, zwei Anwendungsfälle:
- Replikation (size=3, min_size=2): Drei vollständige Kopien jedes Objekts. Schnell, robust, einfach zu verstehen — und der Standard für VM-Storage in Proxmox. Kostet zwei Drittel der Rohkapazität. min_size=2 bedeutet: der Pool bleibt schreibbar, solange mindestens zwei Kopien existieren.
- Erasure Coding (z. B. 4+2): Spart Kapazität (hier rund 33 % Overhead statt 200 %), kostet aber CPU und Latenz und braucht mehr Nodes. Sinnvoll für große, kalte Datenmengen — Backup-Ziele, Archive, Objektspeicher — nicht für latenzkritischen VM-Betrieb.
Unsere Faustregel: VM-Disks und alles Latenzkritische auf einen replizierten Pool (size=3). Große, selten geänderte Datenmengen auf einen EC-Pool, wenn genug Nodes da sind. Niemals min_size=1 setzen, um „mehr Platz“ zu bekommen — das ist die Einladung zum Datenverlust beim nächsten Plattenfehler während eines Rebuilds.
OSDs, Platten und BlueStore
Jede Datenplatte wird zu einer OSD (Object Storage Daemon). Hier die Punkte, die in der Praxis über Performance entscheiden:
- NVMe oder SSD für VM-Workloads. Spinning Disks haben in einem VM-Cluster nichts mehr verloren — die Random-IO-Last vieler VMs bringt rotierende Platten in die Knie. Für reine Backup-Pools sind HDDs noch vertretbar, dann aber mit SSD für DB/WAL.
- DB/WAL-Sizing nicht vergessen. BlueStore legt Metadaten in einer RocksDB ab. Bei HDD-OSDs gehört die DB auf eine schnelle SSD/NVMe — Faustwert rund 4 % der OSD-Kapazität, damit die Metadaten nicht auf die langsame Platte „spillen“.
- Plattengröße mit Augenmaß. Sehr große OSDs (z. B. 16 TB) verlängern Rebuilds drastisch: Fällt eine aus, müssen alle Daten neu verteilt werden. Mehr, kleinere OSDs heilen schneller und verteilen Last gleichmäßiger.
- Eine OSD pro physischer Platte. Kein RAID-Controller im RAID-Modus darunter — Ceph will die Platten direkt sehen (HBA / IT-Mode).
Das Netzwerk ist der häufigste Engpass
Wir sehen es immer wieder: leistungsfähige NVMe-OSDs, die an einem 10-GbE-Netz verhungern. Ceph erzeugt erheblichen Ost-West-Verkehr — jede Schreiboperation wird repliziert, jeder Rebuild schiebt Terabytes durch den Cluster. Was wir empfehlen:
- Mindestens 25 GbE für produktive NVMe-Cluster, eher 100 GbE bei dichten Nodes.
- Getrenntes Cluster-Netz (Replication/Backfill) vom Public-Netz (Client-IO). Sonst konkurrieren Rebuild-Traffic und VM-IO um dieselbe Leitung — genau dann, wenn ohnehin ein Node fehlt.
- Redundante Switche und Bonding. Ein Single-Switch-Cluster ist kein HA-Cluster, egal wie viele Nodes dranhängen.
Wenn das Budget knapp ist, kürzen Sie eher bei der Plattenkapazität als beim Netz. Ein kapazitätsschwacher, aber schneller Cluster lässt sich erweitern; ein netzlimitierter Cluster bleibt langsam.
Nutzbare Kapazität ehrlich rechnen
Die Rechnung, die in Angeboten oft fehlt. Bei size=3 gilt grob:
- Rohkapazität geteilt durch 3 (Replikation).
- Davon nur bis zum nearfull/full-ratio nutzen — wir planen mit rund 80 – 85 % als praktische Obergrenze, nicht 100 %.
- Kapazität für den Ausfall eines Nodes reservieren, damit der Cluster bei einem Defekt noch heilen kann (Failure-Domain-Reserve).
Beispiel: 5 Nodes à 8 × 4 TB NVMe = 160 TB roh. Geteilt durch 3 ≈ 53 TB. Abzüglich Reserve und Füllgrad landen Sie realistisch bei rund 38 – 42 TB sicher nutzbar. Wer dem Kunden die 160 TB als „Speicher“ verkauft, baut den ersten Konflikt schon ins Projekt ein.
Placement Groups und der Autoscaler
Placement Groups (PGs) sind die Verteilungseinheit zwischen Pools und OSDs. Zu wenige PGs führen zu ungleicher Auslastung, zu viele kosten RAM und CPU auf den OSDs. Moderne Ceph-Versionen haben einen PG-Autoscaler, der das in den meisten Fällen gut löst — wir lassen ihn im Modus on oder zumindest warn laufen und greifen nur bei klar definierten Pools manuell ein. Wichtig ist, beim Anlegen eines Pools eine sinnvolle Ziel-Größe (target_size) zu hinterlegen, damit der Autoscaler nicht ständig nachjustiert.
Stolperfallen aus echten Projekten
- Kein Monitoring auf Füllgrad. Ein Ceph-Cluster, der den full-ratio erreicht, stoppt Schreibvorgänge — und reißt damit VMs mit. Alarmierung gehört auf 75 %, nicht erst auf 95 %.
- Asymmetrische Nodes. Ein Node mit doppelt so viel Kapazität wie die anderen zieht überproportional Last und wird zum Hotspot. Cluster möglichst homogen halten.
- Rebuild-Last unterschätzt. Beim Plattentausch im Betrieb schiebt Ceph Daten um. Ohne getrenntes Cluster-Netz spürt das jede VM. Backfill-Parameter gehören an die Hardware angepasst.
- min_size=1 als „Notlösung“. Klingt nach mehr Platz, ist faktisch ein Single Point of Data Loss. Wir setzen das nie produktiv.
- Ceph und Proxmox auf denselben Platten wie das OS. OSDs gehören auf eigene Datenträger, das Proxmox-OS auf ein separates (gespiegeltes) Boot-Medium.
Fazit
Ceph richtig zu dimensionieren heißt: ehrlich rechnen (Faktor 3, Füllgrad, Failure-Reserve), beim Netz nicht sparen und mit mindestens vier, besser fünf Nodes starten. Wer das von Anfang an einplant, bekommt ein Storage-System, das jahrelang stabil mitwächst — statt eines Clusters, der beim ersten vollen Pool oder dem ersten Plattenausfall die ganze Virtualisierung mitreißt.
Wenn Sie einen Ceph-Cluster planen oder Ihr bestehender an Grenzen stößt: unsere Ceph-Leistung beschreibt, wie wir Auslegung, Aufbau und Betrieb angehen. Eine kurze Einordnung Ihrer Anforderungen gibt es im Erstgespräch — und die Grundbegriffe erklärt unser Glossar-Eintrag zu Ceph.
Ceph-Cluster geplant oder am Limit?
30 Minuten reichen für eine ehrliche Einschätzung. Kostenfrei, ohne Vertriebsdruck.