Ceph Storage einrichten: So planst du einen Cluster, der deine Virtualisierung trägt
Ceph belohnt Planung und bestraft Improvisation. Unter drei Nodes ergibt es keinen Sinn, und die Netzwerkauslegung entscheidet stärker über die Performance als die Wahl der Datenträger.
Warum Ceph der kritische Teil jeder Storage-Entscheidung ist
Wenn ein SAN aus dem Support läuft oder eine VMware-Umgebung nach Proxmox oder KubeVirt wandert, verschiebt sich die Verantwortung für Redundanz vom Storage-Hersteller ins eigene Team. Bei Ceph gibt es keinen Controller mehr, der Konsistenz garantiert, sondern OSDs, Monitore und eine CRUSH-Map, die du selbst so aufsetzt, dass der Ausfall von Platte, Host oder Rack folgenlos bleibt.
Ein Cluster liefert erst dann verlässliche Latenzen, wenn WAL- und DB-Geräte, Netztrennung, Replikationsfaktor und Failure Domains zusammenpassen. Ein Pool mit size=3 und min_size=2 über genau drei Knoten sieht auf dem Papier redundant aus, blockiert aber während eines Rebuilds schnell die Schreibpfade, wenn die verbleibende Kapazität nicht eingeplant wurde.
Die typischen Fehler wiederholen sich: ein gemeinsames Netz für Client- und Cluster-Traffic, HDD-OSDs ohne getrennte DB auf NVMe, RAID-Controller im Write-Back-Modus statt HBA im Pass-through und Pools, deren Placement Groups nie an die gewachsene Kapazität angepasst wurden. Solche Entscheidungen fallen beim ersten Ausfall auf, nicht beim ersten Benchmark.
Von der Anforderung zum laufenden Ceph-Cluster
- 01 Workload und Zugriffsweg klären: RBD, CephFS oder S3
- 02 Failure Domain und Replikation festlegen
- 03 Knoten, OSDs und NVMe für DB und WAL dimensionieren
- 04 Public- und Cluster-Netz trennen und redundant auslegen
- 05 Pools, PGs und CRUSH-Regeln anlegen
- 06 Monitoring, Rebuild und Wartungsabläufe testen
Was du für einen belastbaren Ceph-Cluster brauchst
Ceph lässt sich gut beherrschen, wenn du die Architektur einmal sauber durchdenkst statt sie aus Defaults zu übernehmen. Diese Punkte bilden den Weg von der Planung bis zum Betrieb ab, so wie er auch in unseren Kursen behandelt wird.
Die Rollen im Cluster sauber trennen
MON-Daemons halten die Cluster-Map und brauchen ein ungerades Quorum, meist drei oder fünf Instanzen. MGR liefert Metriken und Module, OSDs verwalten je ein Blockgerät mit BlueStore, MDS kommt nur für CephFS dazu. Wer diese Rollen und ihre Ausfallwirkung kennt, plant Knotenzahl und Wartungsfenster realistisch.
CRUSH-Map und Failure Domain festlegen
Die CRUSH-Regel bestimmt, ob Repliken über Hosts, Racks oder Räume verteilt werden. Erst daraus ergibt sich, wie viele Knoten du mindestens brauchst und wie viel Kapazität für den Rebuild frei bleiben muss. Replikation und Erasure Coding vergleichst du anhand von Nutzkapazität, CPU-Last und Wiederherstellungszeit.
Pools, Placement Groups und Autoscaler verstehen
Placement Groups bestimmen die Verteilungsgranularität. Zu wenige führen zu ungleicher Auslastung, zu viele kosten Speicher und CPU auf den OSDs. Der PG-Autoscaler nimmt dir viel ab, du solltest aber wissen, welche Zielwerte er berechnet und wann du mit pg_num manuell eingreifst.
Netz und Hardware realistisch dimensionieren
Getrennte Netze für Public und Cluster Traffic, mindestens 10 GbE und für NVMe-Pools eher 25 GbE aufwärts, dazu Jumbo Frames und redundante Uplinks. Auf der Hardwareseite gehören HBA statt RAID-Controller, NVMe für DB und WAL sowie eine ehrliche Rechnung zu IOPS und Latenz dazu.
Zugriffswege passend zum Anwendungsfall wählen
RBD liefert Blockgeräte für VMs unter Proxmox oder KubeVirt, CephFS ein POSIX-Dateisystem mit MDS, RGW ein S3-kompatibles Gateway für Objektdaten. Die drei Wege haben unterschiedliche Anforderungen an Metadaten, Caching und Backup, deshalb entscheidest du sie pro Workload.
Betrieb, Monitoring und Recovery einüben
Im Alltag zählen ceph status und ceph osd df genauso wie geübte Abläufe für Plattentausch, Knotenwartung mit noout, Upgrades und Scrubbing-Fenster. Ein Cluster, in dem der Rebuild einmal kontrolliert getestet wurde, verhält sich im Ernstfall vorhersehbar.
Kurse zu Ceph-Storage bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu Ceph-Storage
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktWie viele Knoten braucht ein Ceph-Cluster mindestens?
Was ist der Unterschied zwischen Ceph und einem klassischen SAN?
Wofür sind Placement Groups da und wie viele brauche ich?
Reicht ein 10-GbE-Netz für Ceph aus?
Wie hängen Ceph und Proxmox zusammen?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Ceph gemeinsam mit uns aufbauen
Im Proxmox Aufbaukurs zu Cluster, Ceph und High Availability baust du einen Cluster selbst auf, legst Pools an und übst Ausfall- und Wartungsszenarien. Wenn dir zuvor die Storage-Grundlagen fehlen, ist der Kurs Linux Storage und Dateisysteme der passende Einstieg, und für den Umstieg vom bestehenden Hypervisor gibt es das Training Migration von VMware zu Proxmox. Alle Termine finden vor Ort oder Live-Online statt, sprich uns an, wenn du deine Ausgangslage vorher einordnen möchtest.