Proxmox VE Ceph Cluster
hyperkonvergente HA-Virtualisierung

Aktueller Stand: Proxmox VE 9.2 und Ceph

Proxmox VE 9.2 wurde im Mai 2026 veröffentlicht und basiert auf Debian 13.5 „Trixie“. Zu den integrierten Komponenten gehören unter anderem QEMU 11.0, LXC 7.0, ZFS 2.4 sowie Ceph Tentacle 20.2. Proxmox VE 9.2 bietet darüber hinaus Funktionen wie den Dynamic Load Balancer für eine bessere Verteilung der Cluster-Ressourcen.

Stand dieser Seite: September 2026. Die konkret eingesetzten Softwarestände werden bei neuen Installationen vor der Inbetriebnahme geprüft und an die jeweilige produktive Umgebung angepasst.

Weitere Informationen: Proxmox VE 9.2

Ceph als Shared Storage bei Proxmox

Proxmox VE unterstützt unterschiedliche Storage-Architekturen. Interne Datenträger eines Nodes können beispielsweise mit ZFS genutzt werden. ZFS ist in einer solchen Konfiguration zunächst lokaler Storage und kein gemeinsam von allen Nodes verwendeter Shared Storage.

Proxmox VE kann VM-Datenträger auf lokalem ZFS über Storage Replication asynchron auf andere Cluster-Nodes übertragen. Hochverfügbarkeit ist deshalb grundsätzlich auch ohne Ceph beziehungsweise klassischen Shared Storage möglich. Zwischen zwei Replikationsläufen besteht jedoch ein mögliches Recovery Point Objective (RPO): Fällt ein Node ungeplant aus, können Änderungen seit der letzten erfolgreichen Replikation fehlen.

Ceph verfolgt einen anderen Ansatz. Bei Proxmox wird Ceph RBD typischerweise als verteilter Shared Block Storage eingesetzt. Die virtuellen Datenträger liegen damit im Ceph-Cluster und sind nicht fest an den lokalen Storage des gerade ausführenden Proxmox-Nodes gebunden. Dadurch können die VM-Datenträger auch von anderen berechtigten Cluster-Nodes erreicht werden.

Bei einem typischen replizierten Ceph-Pool mit size=3 werden drei Instanzen eines RADOS-Objekts gespeichert. Bei einer entsprechend konfigurierten CRUSH-Regel werden diese auf unterschiedliche OSDs beziehungsweise Hosts verteilt. Das bedeutet ausdrücklich nicht, dass sämtliche Daten auf jedem Node des Clusters vollständig identisch vorhanden sein müssen.

Fällt ein Proxmox-Node aus, kann eine als HA-Ressource konfigurierte VM nach dem erforderlichen Cluster- und Fencing-Prozess auf einem anderen verfügbaren Node neu gestartet werden. Ihre virtuellen Datenträger bleiben über Ceph RBD verfügbar, solange das Ceph-Cluster über ausreichend OSDs und Replikate für den weiteren Betrieb verfügt.

Auch bei Migrationen bietet Shared Storage einen erheblichen Vorteil: Die kompletten virtuellen Festplatten müssen nicht zwischen den Virtualisierungs-Hosts kopiert werden, weil sie bereits über Ceph erreichbar sind.

Proxmox Cluster Sizing

Beim Sizing eines hyperkonvergenten Proxmox-VE-Clusters müssen die Ressourcen für Virtualisierung und Ceph gemeinsam betrachtet werden. CPU, RAM, Storage-Kapazität, Anzahl der OSDs und Netzwerkbandbreite beeinflussen sich gegenseitig.

CPU:
Ceph MON- und MGR-Dienste benötigen im Vergleich zu den eigentlichen Storage-Diensten normalerweise relativ wenig CPU-Leistung. Bei einem typischen Proxmox-Cluster mit Ceph RBD entsteht ein wesentlicher Teil der Storage-Last auf den OSDs. Deshalb müssen ausreichend CPU-Ressourcen für Ceph verfügbar bleiben und dürfen nicht vollständig von virtuellen Maschinen belegt werden.

Ein Ceph Metadata Server (MDS) wird insbesondere für CephFS benötigt. Für den typischen Block-I/O einer virtuellen Maschine auf Ceph RBD befindet sich der MDS nicht im eigentlichen Datenpfad. Wird CephFS zusätzlich verwendet, muss dessen MDS-Ressourcenbedarf gesondert berücksichtigt werden.

RAM:
Der Arbeitsspeicherbedarf hängt unter anderem von Anzahl und Kapazität der OSDs, dem verwendeten Storage, dem Workload und der Ceph-Konfiguration ab. Der von Ceph benötigte RAM muss zusätzlich zum Speicherbedarf der virtuellen Maschinen und Container eingeplant werden. Ein Cluster, dessen RAM bereits vollständig durch VMs ausgeschöpft wird, besitzt keine ausreichende Reserve für Storage-, Recovery- und Cluster-Prozesse.

Storage-Kapazität:
Bei der Planung darf nicht nur die theoretische Nutzkapazität betrachtet werden. Bei einem replizierten Pool mit size=3 werden drei Instanzen jedes Objekts gespeichert. Die reine Nutzkapazität liegt daher zunächst ungefähr bei einem Drittel der Rohkapazität. Davon müssen zusätzliche Reserven für Ausfälle, Recovery und Rebalancing abgezogen werden.

Fällt ein OSD aus, verteilt Ceph die betroffenen Daten entsprechend der Cluster- und CRUSH-Konfiguration auf verfügbare OSDs. Dafür muss ausreichend freier Speicher vorhanden sein. Ein Cluster sollte daher nicht bis an seine technischen Fullness-Grenzen herangefahren werden.

Ceph verwendet standardmäßig unter anderem folgende Schwellwerte:

nearfull: 85 % – Warnung vor zu hoher OSD-Auslastung
backfillfull: 90 % – kein neuer Backfill auf zu volle OSDs
full: 95 % – Schreibzugriffe werden zum Schutz des Clusters blockiert

Für die Praxis ist besonders wichtig: Nicht nur die durchschnittliche Clusterauslastung betrachten. Entscheidend kann der am stärksten belegte OSD sein. Daher sollten OSD-Auslastung und Datenverteilung kontinuierlich überwacht werden.

Eine betriebliche Warnschwelle deutlich unterhalb der technischen Ceph-Grenzwerte – beispielsweise im Bereich von etwa 70 bis 80 Prozent, abhängig von Clustergröße und Ausfallszenario – schafft Reserve für Rebalancing und den Ausfall eines OSDs oder Nodes.

Tipp: Zusätzliche OSDs beziehungsweise weitere Storage-Kapazität können in ein bestehendes Ceph-Cluster integriert werden. Ceph verteilt die Daten anschließend entsprechend der Konfiguration neu.

Erweiterung des Proxmox Clusters

Die Netzwerkinfrastruktur ist ein zentraler Bestandteil eines Proxmox-Ceph-Clusters. Sie transportiert nicht nur den Datenverkehr der virtuellen Maschinen, sondern auch Cluster-Kommunikation, Ceph-I/O, Replikation, Recovery und Rebalancing.

Für produktive Ceph-Umgebungen ist 10 GbE eine sinnvolle technische Basis. Bei hoher I/O-Last, schnellen NVMe-Datenträgern oder größeren Clustern können 25, 40 oder 100 GbE sinnvoll sein. Die konkrete Auslegung richtet sich nach Anzahl der Nodes, OSDs, Datenträgern und den erwarteten Workloads.

Die Netzwerkverbindungen sollten redundant ausgeführt werden. Der Ceph-Verkehr kann über separate physische Interfaces und Switches oder, bei ausreichender Bandbreite und entsprechender Planung, logisch über VLANs vom VM- und Management-Verkehr getrennt werden.

Bei der Beispielkonfiguration mit vier 10-GbE-Ports pro Server können zwei Verbindungen für Ceph und zwei weitere für VM-, Management- oder Cluster-Verkehr eingeplant werden. Bei einer vollständig redundanten Architektur werden die Verbindungen auf unterschiedliche Switches verteilt.

Für einen kleinen 3-Node-Cluster sind unter bestimmten Voraussetzungen auch Direct-Attached-Verbindungen für dedizierte Storage-Kommunikation möglich. Für größere oder später erweiterbare Cluster ist eine switchbasierte Netzwerkarchitektur normalerweise flexibler.

Cluster erweitern:
Mehr Storage-Kapazität kann durch zusätzliche oder größere OSDs bereitgestellt werden. Bei einem steigenden Kapazitäts- oder Performancebedarf können auch weitere Proxmox-/Ceph-Nodes ergänzt werden. Die Anzahl der Laufwerksschächte sollte deshalb bereits beim ersten Sizing berücksichtigt werden.

Benötigt ein Projekt deutlich mehr Kapazität, können beispielsweise 2-HE-Systeme mit 24 oder mehr SSD-/NVMe-Slots zum Einsatz kommen.

Auch HDDs können technisch als Ceph-OSDs genutzt werden. Für normale produktive Virtualisierungs-Workloads empfehlen sich jedoch typischerweise Enterprise-SSDs oder NVMe-Medien. Für große Datenmengen mit geringeren IOPS-Anforderungen können separate Storage-Tiers oder externe NAS-/SAN-Systeme je nach Anwendung wirtschaftlicher sein.

Enthaltene Dienstleistung im Proxmox Ceph Paket

Ein leistungsfähiges Proxmox-Ceph-System besteht nicht nur aus Servern und Software. Entscheidend sind eine passende Architektur und eine auf den Workload abgestimmte Konfiguration.

Je nach vereinbartem Projektumfang unterstützen wir Sie unter anderem bei:

Wie bei unseren anderen Systemlösungen kann die Hardware vor der endgültigen Inbetriebnahme geprüft und grundkonfiguriert werden. Der konkrete Leistungsumfang wird im Angebot passend zum Projekt festgelegt.