In klassischen Rechenzentren sind Compute und Storage getrennt: Server auf der einen, SAN oder NAS auf der anderen Seite. Hyperkonvergente Infrastruktur (HCI) vereint beides auf denselben Knoten — und Proxmox VE bringt mit seiner nativen Ceph-Integration alles mit, um genau das umzusetzen. Ohne zusätzliche Lizenzen, ohne proprietäre Appliances und ohne Vendor-Lock-in.

Dieser Artikel zeigt, wie eine Proxmox-Ceph-Architektur aufgebaut ist, worauf Sie bei der Dimensionierung achten sollten und welche Best Practices sich im produktiven Betrieb bewährt haben.

1. Was ist Ceph?

Ceph ist ein verteiltes Storage-System, das Daten automatisch über mehrere Knoten repliziert. Es kennt keinen Single Point of Failure — fällt ein Knoten oder eine Festplatte aus, reorganisiert Ceph die Daten selbstständig auf die verbleibenden Ressourcen. Dieses Verhalten wird als Self-Healing bezeichnet.

Die Grundlage bildet RADOS (Reliable Autonomic Distributed Object Store), eine objekt-basierte Speicherschicht. Darauf aufbauend stellt Ceph drei Storage-Typen bereit:

Protokoll	Verwendung	Typischer Einsatz
RBD (RADOS Block Device)	Block-Storage	VM-Disks in Proxmox VE
CephFS	POSIX-Dateisystem	Shared File Storage zwischen VMs
RGW (RADOS Gateway)	Objekt-Storage (S3/Swift)	Backups, Medien-Archivierung

Für Proxmox-Umgebungen ist RBD der zentrale Baustein: VM-Festplatten und Container-Volumes werden als Block-Devices direkt im Ceph-Cluster gespeichert und stehen allen Cluster-Knoten gleichzeitig zur Verfügung. Das ermöglicht Live-Migration ohne Shared-Filesystem.

2. Architekturüberblick: Proxmox + Ceph

In einer hyperkonvergenten Konfiguration übernimmt jeder Knoten eine Doppelrolle — er stellt sowohl Rechenleistung (Hypervisor) als auch Speicher (Ceph OSD) bereit. Zusätzlich laufen auf jedem Knoten Ceph-Dienste zur Koordination.

Dienste pro Knoten

Dienst	Funktion
Proxmox VE	Hypervisor (KVM/LXC), Management-GUI
Ceph OSD	Object Storage Daemon — verwaltet die lokalen Datenträger
Ceph Monitor (MON)	Hält die Cluster-Map, überwacht den Cluster-Zustand
Ceph Manager (MGR)	Stellt Metriken, Dashboard und Module bereit

Mindestanforderung: 3 Knoten

Ceph benötigt eine ungerade Anzahl von Monitoren für das Quorum. Drei Knoten sind das Minimum für einen funktionsfähigen Cluster. Bei drei Knoten und einem Replikationsfaktor von 3 überlebt der Cluster den Ausfall eines kompletten Knotens, ohne Datenverlust.

3. Hardware-Dimensionierung

Die richtige Dimensionierung entscheidet über die Stabilität und Leistung des gesamten Clusters. Ceph ist ressourcenintensiv — unterschätzte OSD-Anforderungen führen zu Performance-Problemen unter Last.

Komponente	Minimum	Empfohlen
Knoten	3	5+
CPU	1 Kern pro OSD + VM-Kerne	2 Kerne pro OSD + VM-Kerne
RAM	5 GB pro OSD + VM-RAM	8 GB pro OSD + VM-RAM
OSD-Datenträger	NVMe SSDs	Enterprise NVMe (DWPD >= 1)
Netzwerk	10 GbE	25 GbE
WAL/DB	Auf dem OSD-Datenträger	Separate NVMe fuer WAL/DB bei HDD-OSDs
Boot-Disk	64 GB SSD	128 GB SSD (ZFS-Mirror)

Hinweis: Die RAM- und CPU-Angaben fuer Ceph kommen zusaetzlich zum Bedarf Ihrer VMs und Container. Planen Sie beides gemeinsam, um Ueberprovisionierung zu vermeiden.

4. Netzwerk-Design

Das Netzwerk ist die kritischste Komponente einer Ceph-Umgebung. Unzureichende Bandbreite oder fehlende Trennung fuehren zu Latenzen, die sich direkt auf die VM-Performance auswirken.

Zwei getrennte Netzwerke

Netzwerk	Zweck	Beschreibung
Public Network	Client-Zugriff	VMs greifen ueber dieses Netz auf Ceph-Storage zu
Cluster Network	OSD-Replikation	Interne Datenreplikation zwischen den OSDs

Die Trennung ist essenziell: Ohne separates Cluster-Netzwerk konkurriert die OSD-Replikation mit dem VM-Traffic auf derselben Leitung. Bei einem Knotenausfall steigt der Replikations-Traffic massiv an — das kann ein ungetrenntes Netzwerk ueberlasten.

Empfehlungen

VLAN-Trennung oder physisch getrennte Interfaces fuer Public und Cluster Network
Jumbo Frames (MTU 9000) auf allen Ceph-Interfaces aktivieren — reduziert CPU-Overhead und erhoeht den Durchsatz
Bonding / LACP fuer Redundanz und Bandbreitenaggregation
MTU-Werte muessen auf allen Switches und Knoten identisch konfiguriert sein

5. Ceph-Pool-Konfiguration

Ceph organisiert Daten in Pools, die jeweils eigene Replikations- und Performance-Parameter besitzen.

Replikation

Parameter	Typischer Wert	Bedeutung
size	3	Anzahl der Kopien jedes Objekts
min_size	2	Minimale Kopien fuer Schreiboperationen

Bei size=3 und min_size=2 akzeptiert der Pool weiterhin Schreibzugriffe, wenn eine Kopie fehlt (z. B. bei OSD-Ausfall). Faellt eine zweite Kopie aus, wird der Pool read-only — das schuetzt vor Datenverlust.

Placement Groups (PGs)

Placement Groups sind die interne Verteilungseinheit von Ceph. Zu wenige PGs fuehren zu ungleichmaessiger Datenverteilung, zu viele belasten RAM und CPU. Aktuelle Proxmox-Versionen unterstuetzen PG-Autoscaling, das die Anzahl automatisch anpasst — nutzen Sie diese Funktion.

Erasure Coding vs. Replikation

Methode	Speichereffizienz	Performance	Empfehlung
Replikation (3x)	33 %	Hoch (schnelle Reads/Writes)	Standard fuer VM-Disks
Erasure Coding (k+m)	50—75 %	Niedriger (hoehere CPU-Last)	Archiv-Daten, Backups

Fuer VM-Workloads ist Replikation die empfohlene Wahl. Erasure Coding eignet sich fuer grosse Datenmengen mit geringeren IOPS-Anforderungen, z. B. Backup-Pools.

6. Best Practices fuer den produktiven Betrieb

Homogene Hardware: Verwenden Sie identische Hardware auf allen Knoten. Unterschiedliche Disk-Groessen oder CPU-Generationen fuehren zu ungleichmaessiger Lastverteilung.
HDD und SSD nicht mischen: Erstellen Sie getrennte Pools fuer unterschiedliche Datentraegertypen. Gemischte Pools erzeugen unvorhersagbare Latenzen.
OSD-Auslastung ueberwachen: Halten Sie die Belegung unter 85 %. Ab diesem Wert beginnt Ceph mit aggressivem Rebalancing, das die Performance erheblich beeintraechtigt.
Regelmaessiges Scrubbing: Ceph prueft Datenintegritaet durch Scrubbing. Planen Sie Deep-Scrubs in Zeiten geringer Last (z. B. nachts).
Failover-Szenarien testen: Simulieren Sie den Ausfall von OSDs und Knoten vor dem Produktivbetrieb. Pruefen Sie, ob der Cluster korrekt rebalanciert und VMs erreichbar bleiben.
Proxmox-Dashboard nutzen: Die integrierte Web-GUI zeigt Ceph-Status, OSD-Auslastung, Pool-Gesundheit und Performance-Metriken — nutzen Sie diese fuer das taegliche Monitoring.
Ceph-Versionen synchron halten: Aktualisieren Sie alle Knoten auf dieselbe Ceph-Version. Gemischte Versionen sind temporaer moeglich, aber kein Dauerzustand.

7. Wann ist Ceph die richtige Wahl?

Ceph in Kombination mit Proxmox eignet sich hervorragend, wenn Sie:

3 oder mehr Knoten betreiben und Shared Storage ohne externes SAN benoetigen
Hochverfuegbare VMs betreiben, die bei Knotenausfall automatisch migrieren sollen
Skalierbar wachsen wollen — weitere Knoten und OSDs lassen sich im laufenden Betrieb hinzufuegen
Unabhaengig von proprietaeren Storage-Anbietern bleiben moechten

Wann ist Ceph nicht die beste Wahl?

Einzelne Knoten: Ceph benoetigt mindestens 3 Knoten. Fuer Single-Node-Setups ist lokales ZFS die bessere Wahl.
Sehr kleine Umgebungen: Wenn 2 Knoten mit wenigen VMs genuegen, ist der Ceph-Overhead nicht gerechtfertigt. Nutzen Sie stattdessen lokalen Storage mit Replikation oder ein externes TrueNAS als iSCSI/NFS-Backend.
Hohe Anforderungen an sequentiellen Durchsatz: Fuer grosse Dateien und Streaming-Workloads kann ein dediziertes NAS-System performanter sein.

8. DATAZONE: Ihr Partner fuer Proxmox und Ceph

Wir planen, implementieren und betreuen Proxmox-Ceph-Cluster — von der initialen Architektur ueber die Netzwerk-Planung bis zum laufenden Betrieb. Unsere Erfahrung aus zahlreichen produktiven Umgebungen stellen wir Ihnen zur Verfuegung.

Wenn ein hyperkonvergenter Ansatz nicht zu Ihrem Szenario passt, beraten wir Sie gerne zu externen Storage-Loesungen auf Basis von TrueNAS — als iSCSI-, NFS- oder SMB-Backend fuer Ihre Proxmox-Umgebung.

Jetzt kostenlose Erstberatung anfragen

DATAZONE unterstuetzt Sie bei der Umsetzung — kontaktieren Sie uns fuer eine unverbindliche Beratung.

Proxmox VE mit Ceph: Hyperkonvergente Infrastruktur richtig aufbauen