Virtualisierung & Proxmox

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.

6 Kapitel mit allen Befehlen
Zwei Administratoren planen im Serverraum eine Migration
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

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.

Miniatur-Szene: ein physischer Server links, virtuelle Maschinen als schwebende Würfel rechts, dazwischen eine Brücke
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Von der Anforderung zum laufenden Ceph-Cluster

  1. 01 Workload und Zugriffsweg klären: RBD, CephFS oder S3
  2. 02 Failure Domain und Replikation festlegen
  3. 03 Knoten, OSDs und NVMe für DB und WAL dimensionieren
  4. 04 Public- und Cluster-Netz trennen und redundant auslegen
  5. 05 Pools, PGs und CRUSH-Regeln anlegen
  6. 06 Monitoring, Rebuild und Wartungsabläufe testen
Was du mitnimmst

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.

Tutorial

Von der Netzprüfung bis zum ersten Pool: Cluster aufbauen und nachmessen

Der Aufbau läuft in der Reihenfolge, in der Fehler teuer werden: erst Zeit, MTU und Datenträger prüfen, dann den Cluster ausrollen, OSDs anlegen und die Ausfalldomäne kontrollieren, danach Pools mit expliziter Replikation, zuletzt messen. Produktionsdaten kommen erst darauf, wenn du einen Knotenausfall einmal absichtlich ausgelöst hast.

01

Voraussetzungen prüfen, bevor der erste Befehl läuft

Drei Dinge entscheiden vorab über den Betrieb: die Uhren, die MTU und die Datenträger. Alle drei prüfst du in zehn Minuten, falsch kosten sie dich später Tage.

Zeit, Netz und Datenträger prüfen
# Zeitsynchronisation: Monitore verlieren bei Drift das Quorum
chronyc sources -v
chronyc tracking | grep -E 'System time|Last offset'

# MTU wirklich messen, nicht nur konfigurieren (9000 minus 28 Byte Overhead)
ping -M do -s 8972 -c 3 10.10.20.12

# Datenträger müssen roh sein: keine Partition, keine Signatur, kein LVM
lsblk -o NAME,SIZE,ROTA,TYPE,MOUNTPOINT,FSTYPE
sudo wipefs -a /dev/sdb        # entfernt Signaturen, die Daten sind danach weg

Antwortet ping -M do mit Frag needed, ist die MTU auf dem Weg kleiner als konfiguriert, meist an einem Switch-Port. Ceph läuft trotzdem an und bricht erst unter Last mit sporadischen Zeitüberschreitungen ein.

02

Cluster ausrollen mit cephadm

cephadm rollt die Dienste als Container aus und verwaltet sie über den Orchestrator. Wichtig ist, dass du das Cluster-Netz von Anfang an mitgibst.

Bootstrap, Knoten aufnehmen, Monitore festlegen
# Auf dem ersten Knoten: öffentliches Netz und Cluster-Netz trennen
sudo cephadm bootstrap --mon-ip 10.10.10.11 \
  --cluster-network 10.10.20.0/24

# Öffentlichen Schlüssel verteilen, dann die weiteren Knoten aufnehmen
sudo ceph cephadm get-pub-key > /tmp/ceph.pub
ssh-copy-id -f -i /tmp/ceph.pub root@ceph02
sudo ceph orch host add ceph02 10.10.10.12

# Monitore auf genau drei Knoten festnageln statt dem Zufall überlassen
sudo ceph orch host label add ceph01 mon
sudo ceph orch host label add ceph02 mon
sudo ceph orch host label add ceph03 mon
sudo ceph orch apply mon --placement="label:mon"

sudo ceph -s
sudo ceph orch ls

Die Zahl der Monitore muss ungerade sein, sonst gibt es kein eindeutiges Quorum. Drei vertragen den Ausfall eines Knotens, fünf den Ausfall von zweien.

03

OSDs anlegen und die Ausfalldomäne prüfen

Ein OSD je Datenträger, die Metadaten-Datenbank auf NVMe, wenn die Datenträger drehen. Danach prüfst du, ob die CRUSH-Map die Domäne abbildet, gegen die du dich absichern willst.

OSDs gezielt anlegen und kontrollieren
# Welche Datenträger akzeptiert der Orchestrator?
sudo ceph orch device ls --wide

# Gezielt statt pauschal: Daten auf HDD, DB auf NVMe
sudo ceph orch daemon add osd \
  ceph02:data_devices=/dev/sdb,db_devices=/dev/nvme0n1

# Ergebnis prüfen: Baum, Geräteklassen, Auslastung je OSD
sudo ceph osd tree
sudo ceph osd df tree
sudo ceph osd crush class ls

Ceph erkennt die Geräteklasse (hdd, ssd, nvme) selbst, und du kannst Pools später gezielt auf eine Klasse legen. Prüf die Zuordnung trotzdem: virtualisierte Datenträger melden sich gelegentlich als hdd.

Ausfalldomäne über Rack statt über Host
# Buckets anlegen und Hosts einsortieren
sudo ceph osd crush add-bucket rack1 rack
sudo ceph osd crush move rack1 root=default
sudo ceph osd crush move ceph01 rack=rack1

# Regel mit Ausfalldomäne rack, danach den Pool darauf legen
sudo ceph osd crush rule create-replicated rack-rule default rack
sudo ceph osd pool set vmdaten crush_rule rack-rule

# Kontrolle: bleiben alle Placement Groups active+clean?
sudo ceph -s
sudo ceph pg dump_stuck

Wer bei drei Kopien auf rack stellt, aber nur zwei Racks hat, bekommt dauerhaft undersized Placement Groups: Ceph findet für die dritte Kopie kein zulässiges Ziel.

04

Pools, Replikation und Autoscaler

size und min_size sind die beiden Zahlen, an denen dein Datenbestand hängt. Setz sie bewusst.

Pool anlegen und explizit konfigurieren
sudo ceph osd pool create vmdaten
sudo ceph osd pool application enable vmdaten rbd
sudo rbd pool init vmdaten

sudo ceph osd pool set vmdaten size 3
sudo ceph osd pool set vmdaten min_size 2

# Autoscaler arbeiten lassen, aber die Erwartung mitgeben
sudo ceph osd pool set vmdaten pg_autoscale_mode on
sudo ceph osd pool set vmdaten target_size_ratio 0.8
sudo ceph osd pool autoscale-status
sudo ceph df

target_size_ratio sagt dem Autoscaler, welchen Anteil der Pool am Ende belegen soll. Ohne die Angabe skaliert er die Placement Groups erst nach, wenn die Daten schon liegen, und verschiebt dann unnötig viel.

Was size und min_size im Ernstfall bedeuten

size / min_sizeVerkraftetVerhalten bei Ausfall
3 / 2einen Knotenbleibt schreibbar und stellt wieder her, sobald ein Ziel frei ist. Der Normalfall.
3 / 1zwei Knotenschreibbar bis zur letzten Kopie. Fällt sie in diesem Zustand aus, sind die Daten weg.
2 / 2keinenjeder Knotenausfall stoppt Schreibzugriffe sofort, Lesen bleibt möglich.
2 / 1einenläuft weiter, aber keine Mehrheit entscheidet, welche Kopie die richtige ist.
05

Leistung messen, bevor Produktion darauf läuft

Miss in dieser Reihenfolge: erst das Netz, dann den Cluster, dann die Sicht des Clients. Wer mit dem letzten Schritt anfängt, sucht die Ursache an der falschen Stelle.

Netz, Cluster und Client der Reihe nach
# 1. Netz: auf ceph01 als Server, von den anderen Knoten als Client
iperf3 -s
iperf3 -c 10.10.20.11 -P 4 -t 30

# 2. Cluster: Durchsatz schreiben und lesen, danach aufräumen
sudo ceph osd pool create testpool
sudo rados bench -p testpool 60 write --no-cleanup
sudo rados bench -p testpool 60 seq
sudo rados -p testpool cleanup

# 3. Einzelne OSDs vergleichen, Ausreißer fallen sofort auf
sudo ceph tell osd.* bench

# 4. Client-Sicht: die Zahl, die virtuelle Maschinen tatsächlich spüren
sudo rbd bench --io-type write --io-size 4K --io-pattern rand \
  --io-total 1G vmdaten/testimage

Notier die Werte. Ohne Ausgangsmessung kannst du später nicht beurteilen, ob der Cluster langsamer geworden ist oder die Anwendung mehr verlangt. Lösch den Testpool danach wieder.

06

Betrieb: Wartung, Wiederherstellung, Alarme

Der Cluster ist erst fertig, wenn du einen Ausfall ausgelöst und wieder eingefangen hast.

Wartung und Fehlersuche
# Wartung an einem Knoten: Umverteilung aussetzen, sonst wandern Daten grundlos
sudo ceph osd set noout
sudo ceph osd set norebalance
# ... Reboot, Firmware, Plattentausch ...
sudo ceph osd unset norebalance
sudo ceph osd unset noout

# Was ist wirklich kaputt?
sudo ceph health detail
sudo ceph osd tree down
sudo ceph pg dump_stuck inactive

# Datenträger im Betrieb tauschen
sudo ceph orch osd rm 7 --replace
sudo ceph orch device zap ceph02 /dev/sdb --force

# Version wechseln, cephadm macht es rollierend
sudo ceph orch upgrade start --ceph-version <zielversion>

noout hält Ceph davon ab, die Daten des abwesenden Knotens umzuverteilen. Vergiss das Zurücksetzen nicht, sonst sitzt der Cluster den nächsten echten Ausfall geduldig aus.

Bevor der erste Produktivdatensatz auf den Cluster kommt

  • Einen Knoten hart ausgeschaltet und die Wiederherstellung bis active+clean beobachtetWie lange sie dauert und wie stark sie den Betrieb bremst, weißt du erst nach dem ersten Mal. Die Zahl brauchst du für jede Wartungsplanung.
  • Einen Datenträger im laufenden Betrieb ersetztDer Ablauf aus osd rm mit --replace, Tausch und Wiederaufnahme hat Stolperstellen. Der erste Versuch soll nicht der mit degradierten Produktionsdaten sein.
  • Monitoring auf HEALTH_WARN alarmiert, nicht erst auf HEALTH_ERRBei HEALTH_ERR ist die Redundanz in der Regel bereits aufgebraucht. HEALTH_WARN ist der Zeitpunkt, zu dem du noch in Ruhe handeln kannst.
  • Kapazitätsgrenze bei rund 70 Prozent Belegung gesetztCeph braucht freien Platz, um nach einem Ausfall wiederherzustellen. Ab nearfull warnt der Cluster, ab full stoppt er Schreibzugriffe, und dann hilft nur noch Hardware.
  • Ein Backup außerhalb des Clusters eingerichtet und zurückgespieltReplikation ist kein Backup. Ein versehentliches rbd rm wirkt sofort auf alle drei Kopien, danach zählt nur die Sicherung außerhalb.
Gut zu wissen

Häufige Fragen zu Ceph-Storage

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie viele Knoten braucht ein Ceph-Cluster mindestens?
Technisch läuft Ceph ab drei Knoten, weil du für das MON-Quorum ein ungerades Maß und für die übliche Dreifachreplikation drei getrennte Failure Domains benötigst. Für den produktiven Betrieb sind vier bis fünf Knoten deutlich angenehmer, weil dann beim Ausfall eines Hosts genug Kapazität und Leistung für den Rebuild übrig bleibt.
Was ist der Unterschied zwischen Ceph und einem klassischen SAN?
Ein SAN ist ein geschlossenes System, in dem der Hersteller Controller, Firmware und Redundanz verantwortet und dir eine LUN präsentiert. Ceph verteilt die Daten softwareseitig über Standardserver und skaliert horizontal, verlangt dafür aber eigenes Know-how bei Netz, CRUSH-Regeln und Betrieb. Beide Ansätze sind tragfähig, sie unterscheiden sich vor allem darin, wo die Verantwortung und die laufenden Kosten liegen.
Wofür sind Placement Groups da und wie viele brauche ich?
Placement Groups sind die Zwischenschicht zwischen Objekten und OSDs und bestimmen, wie fein Ceph die Daten verteilt. Als Faustwert liegt man bei etwa 100 PGs pro OSD über alle Pools hinweg. In aktuellen Releases übernimmt der PG-Autoscaler die Berechnung, du solltest sein Ergebnis aber prüfen, weil er die künftige Kapazität nur anhand der gesetzten Zielgröße abschätzen kann.
Reicht ein 10-GbE-Netz für Ceph aus?
Für HDD-basierte Pools mit moderater Last reicht 10 GbE meist aus, sofern Public- und Cluster-Traffic getrennt geführt werden. Sobald NVMe-OSDs im Spiel sind oder viele VMs gleichzeitig schreiben, wird das Netz zum Flaschenhals, insbesondere während eines Rebuilds. Dann sind 25 GbE oder mehr die vernünftigere Auslegung.
Wie hängen Ceph und Proxmox zusammen?
Proxmox VE bringt Ceph als integrierte Storage-Option mit und verwaltet MONs, MGRs und OSDs über die eigene Oberfläche und das Werkzeug pveceph. Die VM-Disks liegen dann als RBD-Images im Cluster, was Live-Migration und Hochverfügbarkeit ohne externes SAN ermöglicht. Die zugrunde liegenden Ceph-Konzepte musst du trotzdem verstehen, weil die Oberfläche die Planungsentscheidungen nicht abnimmt.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

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.