Ceph ist ein verteiltes, selbstverwaltetes Open-Source-Speichersystem, das Block-, Datei- und
Objektspeicher in einer einzigen Plattform vereint. Entwickelt wurde es ursprünglich von Sage Weil
im Rahmen seiner Dissertation an der University of California, Santa Cruz. Heute wird Ceph von der
Community unter dem Dach der Linux Foundation weiterentwickelt und gilt als eine der ausgereiftesten
Open-Source-Storage-Lösungen für den Enterprise-Bereich.
Das Herzstück von Ceph ist RADOS – der Reliable Autonomic Distributed Object
Store. RADOS ist ein selbstheilendes, selbstverwaltendes Objektspeicher-Fundament, auf dem alle
höheren Ceph-Dienste aufgebaut sind. Daten werden intern immer als Objekte gespeichert, unabhängig
davon, ob sie über ein Block-Interface, ein Dateisystem oder ein S3-kompatibles Gateway eingestellt
wurden.
Ein zentrales Designziel von Ceph ist die vollständige Eliminierung von Single Points of Failure
(SPOF). Im Gegensatz zu klassischen SAN- oder NAS-Systemen, die auf dedizierte Controller-Hardware
angewiesen sind, gibt es in Ceph keine zentrale Instanz, deren Ausfall den gesamten Speicher
unverfügbar machen würde. Metadaten, Replikationslogik und Datenzugriff werden auf alle Knoten
verteilt. Fällt ein Knoten aus, übernehmen die verbleibenden Knoten automatisch die Replikation und
stellen den Cluster in den Zielzustand zurück. Dieser Prozess läuft vollständig autonom, ohne
manuellen Eingriff.
Ceph skaliert horizontal: Neue Knoten und Festplatten können dem Cluster im laufenden Betrieb
hinzugefügt werden, woraufhin Ceph die Daten automatisch neu verteilt. Das macht Ceph besonders
attraktiv für wachsende Umgebungen, da die Kapazität inkrementell erweitert werden kann, ohne die
gesamte Infrastruktur neu zu planen.
2. Architektur und Komponenten
Ein Ceph-Cluster besteht aus mehreren Diensten, die zusammen eine vollständige Speicherlösung
bilden. Jeder Dienst hat eine klar definierte Aufgabe und kann auf dedizierter Hardware oder
gemeinsam auf denselben Knoten betrieben werden.
2.1 OSD – Object Storage Daemon
Der OSD ist der eigentliche Speicherdienst. Für jede Festplatte oder SSD im Cluster wird ein
eigener OSD-Prozess gestartet. Der OSD ist verantwortlich für das Speichern und Lesen von Objekten,
die Replikation zu anderen OSDs sowie die Erkennung und Meldung von Fehlerzuständen. In der modernen
Ceph-Version (ab Luminous) nutzt der OSD standardmäßig BlueStore als
lokales Speicher-Backend. BlueStore schreibt Daten direkt auf das Blockgerät, ohne ein
zwischengelagertes Dateisystem, was die Latenz reduziert und eine bessere Integritätsprüfung
ermöglicht.
2.2 MON – Monitor
Die Monitor-Daemons pflegen die autoritativen Cluster-Maps: die OSD-Map, die CRUSH-Map, die
Monitor-Map und die PG-Map. Diese Maps beschreiben den aktuellen Zustand des gesamten Clusters.
Clients kontaktieren zunächst einen Monitor, um die aktuelle Cluster-Map zu erhalten, und kommunizieren
danach direkt mit den OSDs. Für ein produktionsfähiges Quorum werden mindestens drei
Monitor-Instanzen benötigt. Monitore nutzen den Paxos-Algorithmus, um Konsistenz über alle
Monitor-Knoten sicherzustellen. Ein Monitor-Ausfall ist tolerierbar, solange mehr als die Hälfte
der Monitore erreichbar bleiben.
2.3 MGR – Manager
Der Manager-Daemon (MGR) ergänzt den Monitor und übernimmt Aufgaben wie die Bereitstellung von
Metriken, das Cluster-Dashboard und die Verwaltung von Plugins. Über den MGR werden Funktionen wie
das integrierte Ceph Dashboard (eine Weboberfläche zur Clusterverwaltung),
Prometheus-Metriken-Exporte und Balancer-Funktionen bereitgestellt. Auch der MGR sollte in
Hochverfügbarkeitskonfigurationen auf mindestens zwei Knoten betrieben werden, wobei ein Knoten
aktiv und der andere im Standby läuft.
2.4 MDS – Metadata Server
Der Metadata Server wird ausschließlich für CephFS benötigt, das verteilte
Ceph-Dateisystem. Der MDS verwaltet den Verzeichnisbaum und die Dateimetadaten (Inode-Informationen,
Berechtigungen, Zeitstempel), während die eigentlichen Dateiinhalte weiterhin in RADOS als Objekte
abgelegt werden. Für reine Block- oder Objektspeicher-Anwendungsfälle (RBD oder RGW) ist kein MDS
erforderlich.
3. Der CRUSH-Algorithmus
Das Herzstück der Datenzuteilung in Ceph ist der CRUSH-Algorithmus (Controlled
Replication Under Scalable Hashing). CRUSH ermöglicht es Clients und OSDs, den Speicherort von
Daten algorithmisch zu berechnen, ohne eine zentrale Metadaten-Datenbank zu befragen. Jeder Ceph-Client,
der die aktuelle Cluster-Map besitzt, kann deterministisch berechnen, auf welchen OSDs ein bestimmtes
Objekt liegt – ohne zusätzlichen Netzwerk-Roundtrip zu einem zentralen Lookup-Dienst.
CRUSH arbeitet auf Basis einer hierarchischen Topologiebeschreibung, der sogenannten
CRUSH-Map. Diese Map bildet die physische Infrastruktur ab: Festplatten gehören zu
Hosts, Hosts befinden sich in Racks, Racks stehen in Reihen, Reihen befinden sich in Rechenzentren.
Diese Hierarchieebenen nennt man Bucket-Typen.
Über sogenannte Failure Domains kann festgelegt werden, auf welcher Ebene der
Hierarchie Ceph Replikate verteilen soll. In einer Standardkonfiguration wird als Failure Domain
host verwendet, was bedeutet, dass keine zwei Replikate desselben Objekts auf dem
gleichen physischen Host landen. Wird die Failure Domain auf rack gesetzt, verteilt
Ceph die Replikate auf unterschiedliche Racks, was selbst bei einem vollständigen Rack-Ausfall
Datenverfügbarkeit gewährleistet.
Diese algorithmusbasierte Platzierung bedeutet auch, dass beim Hinzufügen oder Entfernen von OSDs
nur ein Bruchteil der Daten umgeschichtet werden muss – nämlich genau der Anteil, der auf die neuen
bzw. weggefallenen OSDs entfällt. Eine zentrale Metadaten-Datenbank müsste hingegen vollständig
aktualisiert werden, was einen erheblichen Flaschenhals darstellen würde.
Die CRUSH-Map kann manuell bearbeitet werden, um besondere Topologien abzubilden oder bestimmte
OSDs von bestimmten Pools auszuschließen. Das ist beispielsweise sinnvoll, wenn schnelle NVMe-SSDs
in einem separaten Pool für latenzempfindliche Workloads zusammengefasst werden sollen, während HDDs
einen eigenen Pool für kapazitätsorientierte Workloads bilden.
4. Zugriffs-Interfaces
Ceph stellt drei unterschiedliche Zugriffs-Interfaces zur Verfügung, die alle auf dem gleichen
RADOS-Fundament aufsetzen und sich gegenseitig nicht ausschließen – alle drei können gleichzeitig
betrieben werden.
4.1 RBD – RADOS Block Device
RBD stellt virtuelle Blockgeräte bereit, die sich wie eine lokale Festplatte verhalten. Diese
werden typischerweise als VM-Festplatten in Virtualisierungsumgebungen wie Proxmox, OpenStack oder
Kubernetes (über den Ceph CSI-Treiber) verwendet. RBD-Images werden intern in Objekte fester Größe
(standardmäßig 4 MiB) aufgeteilt und über RADOS im Cluster verteilt. RBD unterstützt Snapshots,
Klone und thin provisioning, was es zu einer leistungsstarken Alternative zu klassischen SAN-LUNs
macht. Die Kernel-Integration erfolgt über das rbd-Kernelmodul oder über
librbd.
4.2 CephFS – Verteiltes Dateisystem
CephFS ist ein POSIX-konformes verteiltes Dateisystem, das über den Kernel-Client oder
ceph-fuse eingebunden werden kann. Es eignet sich für Anwendungsfälle, bei denen
mehrere Clients gleichzeitig auf denselben Dateibaum zugreifen müssen – etwa für
Kubernetes Persistent Volumes mit ReadWriteMany-Semantik oder für gemeinsam genutzte Daten in
Cluster-Umgebungen. CephFS benötigt mindestens einen laufenden MDS-Daemon. Für Hochverfügbarkeit
empfehlen sich mindestens zwei MDS-Instanzen (eine aktiv, eine als Standby).
4.3 RADOS Gateway (RGW) – Objektspeicher
Der RADOS Gateway stellt eine S3-kompatible (Amazon S3 API) und Swift-kompatible
(OpenStack Object Storage API) HTTP-Schnittstelle bereit. Damit kann Ceph als Objektspeicher-Backend
für Applikationen verwendet werden, die nativ S3-Zugriff unterstützen – etwa Backup-Software,
Media-Asset-Verwaltung oder Cloud-native Anwendungen. RGW läuft als eigenständiger HTTP-Daemon
(radosgw) und benötigt keinen MDS. Über Multisites lassen sich RGW-Instanzen
georedundant über mehrere Ceph-Cluster hinweg replizieren.
5. Ceph in Proxmox VE
Proxmox VE (PVE) bringt eine native Ceph-Integration mit, die es ermöglicht, einen vollständigen
Ceph-Cluster direkt über die PVE-Weboberfläche oder die Kommandozeile aufzubauen und zu verwalten.
Ceph-Pakete sind in den Proxmox-Repositories enthalten und können ohne externe Paketquellen
installiert werden.
5.1 Ceph installieren
Die Installation erfolgt auf jedem Cluster-Knoten. Über die PVE-Weboberfläche navigiert man zu
Datacenter → Node → Ceph und klickt auf „Install Ceph". Alternativ kann die
Installation auf der Kommandozeile durchgeführt werden:
# Ceph-Pakete installieren (auf jedem Node ausführen)
pveceph install --version reef
# Ceph initialisieren (nur auf dem ersten Node)
pveceph init --network 10.10.20.0/24
Das Netzwerk-Argument definiert das dedizierte Ceph-Cluster-Netzwerk. Es empfiehlt sich, dieses
Netzwerk von dem Netzwerk zu trennen, über das VMs kommunizieren (Public Network vs. Cluster Network).
5.2 Monitor und Manager anlegen
Auf jedem der drei Knoten muss ein Monitor und ein Manager-Dienst gestartet werden:
OSDs werden für jede physische Festplatte oder SSD angelegt, die dem Ceph-Cluster zugewiesen
werden soll. Die Festplatten müssen unformatiert und ungemountet sein:
# OSD auf Gerät /dev/sdb anlegen
pveceph osd create /dev/sdb
# OSD mit dedizierter WAL/DB-Partition auf NVMe anlegen
pveceph osd create /dev/sdb --wal-dev /dev/nvme0n1 --db-dev /dev/nvme0n1
BlueStore erlaubt es, Write-Ahead-Log (WAL) und Datenbank (DB) auf einem schnelleren NVMe-Gerät
abzulegen, während die eigentlichen Daten auf langsamen HDDs verbleiben. Dadurch wird die
Schreib-Latenz erheblich reduziert.
5.4 Pool anlegen und als VM-Storage verwenden
Nachdem OSDs laufen, kann ein Replikations-Pool erstellt und als Storage-Backend für VMs konfiguriert
werden:
# RBD-Pool für VMs anlegen (Replikationsfaktor 3, Mindestrepliken 2)
pveceph pool create vmpool --size 3 --min_size 2 --pg_autoscale_mode on
# Pool als Proxmox-Storage registrieren
pvesm add rbd vmpool --monhost 10.10.20.1,10.10.20.2,10.10.20.3 \
--content images,rootdir --pool vmpool
Nach dieser Konfiguration steht vmpool in der Proxmox-Weboberfläche beim Anlegen
einer VM als Speicher-Backend zur Auswahl. VM-Festplatten werden dann als RBD-Images im Ceph-Cluster
gespeichert und profitieren von Cephs Replikation, Snapshots und Live-Migration-Fähigkeiten.
5.5 VM-Live-Migration mit Ceph
Ein besonderer Vorteil der Ceph-Integration in Proxmox ist die nahtlose Live-Migration von VMs
zwischen Cluster-Knoten. Da alle Knoten denselben Ceph-Storage lesen und schreiben können,
muss bei der Migration kein Speicherinhalt über das Netzwerk kopiert werden. Die Migration
beschränkt sich auf den VM-Arbeitsspeicherzustand (RAM), was deutlich schneller ist als bei lokalem
Storage. In Proxmox wird dazu in der Migrationsdialogs die Option „Online" gewählt; der Ceph-Storage
wird automatisch erkannt und entsprechend behandelt.
6. Dimensionierung und Hardware
Die korrekte Dimensionierung eines Ceph-Clusters ist entscheidend für Leistung, Verfügbarkeit
und Betriebsstabilität. Folgende Grundregeln sollten beachtet werden.
6.1 Mindestanforderungen
Ein produktionsfähiger Ceph-Cluster benötigt mindestens drei Knoten. Drei Knoten
sind das Minimum, um einen Replikationsfaktor von 3 zu gewährleisten und gleichzeitig den Ausfall
eines Knotens zu tolerieren. Mit nur zwei Knoten würde beim Ausfall eines Knotens der Schreibbetrieb
eingestellt, da das Quorum nicht mehr erfüllt werden kann.
Für den Monitor-Quorum sind mindestens drei Monitor-Instanzen auf separaten Knoten notwendig.
Eine gerade Anzahl von Monitoren ist zu vermeiden, da dies Split-Brain-Szenarien begünstigen kann.
Auch für den Arbeitsspeicher gilt ein Richtwert: pro OSD sollten mindestens 1 GiB RAM reserviert
sein, zusätzlich zu den Anforderungen des Betriebssystems und der Hypervisor-Schicht.
6.2 OSD-Festplatten
Für OSD-Festplatten empfehlen sich dedizierte Datenträger ohne weitere Partitionen oder
Betriebssystem. HDDs eignen sich für kosteneffiziente Kapazitätsspeicherung, NVMe-SSDs für
latenzempfindliche Workloads. Als Faustregel gilt: nicht mehr als 10–15 HDDs pro CPU-Kern,
der für Ceph-OSDs reserviert ist. Alle OSD-Festplatten innerhalb eines Clusters sollten annähernd
gleich groß sein, da CRUSH die Daten gewichtet nach der Festplattenkapazität verteilt. Stark
unterschiedliche Festplattengrößen führen zu ungleichmäßiger Auslastung.
6.3 Netzwerk-Architektur
Ceph unterscheidet zwischen zwei logischen Netzwerken:
Public Network: Über dieses Netzwerk kommunizieren Clients (z. B. Proxmox-Hypervisor,
VMs) mit dem Ceph-Cluster. Mindestempfehlung: 10 GbE pro Knoten.
Cluster Network (Backend): Dieses Netzwerk wird ausschließlich für die
OSD-zu-OSD-Replikation und Recovery-Traffic genutzt. Es sollte mindestens so schnell wie das
Public Network sein, idealerweise 25 GbE oder gebondetes 2x 10 GbE, da hier erheblicher Datenverkehr
bei Replikation und Wiederherstellung entsteht.
Die Trennung der Netzwerke verhindert, dass Replikations-Traffic den Client-Traffic beeinträchtigt
und umgekehrt. In Proxmox wird das Cluster-Netzwerk beim Ausführen von pveceph init
mit dem Parameter --cluster-network gesondert angegeben.
6.4 SSD und NVMe für WAL und DB
BlueStore verwendet zwei interne Komponenten, die auf schnellere Medien ausgelagert werden können:
WAL (Write-Ahead Log): Kleine, sequenzielle Schreiboperationen. Wenige GiB pro
OSD sind ausreichend (typisch: 1–2 GiB).
RocksDB-DB: Enthält OSD-Metadaten. Empfohlene Größe: 4 % der jeweiligen
OSD-Kapazität, bei großen HDDs also 20–40 GiB pro OSD.
Eine NVMe-SSD kann als gemeinsames WAL/DB-Gerät für mehrere HDDs dienen. Als Faustregel gilt: eine
NVMe-Partition pro HDD-OSD, wobei eine NVMe-SSD mit 1 TB typischerweise 4–6 HDD-OSDs bedienen kann,
ohne zum Engpass zu werden. Für sehr leistungsanspruchsvolle Umgebungen empfiehlt sich ein dediziertes
NVMe-Gerät pro OSD.
7. Monitoring und Troubleshooting
Ceph bietet umfangreiche Werkzeuge zur Überwachung und Fehlerdiagnose. Der Einstieg erfolgt über
die Kommandozeile auf einem beliebigen Cluster-Knoten mit Root-Rechten.
# Ausführliche Beschreibung von Warnungen und Fehlern
ceph health detail
# OSD-Baum anzeigen – Topologie, Status und Gewichte der OSDs
ceph osd tree
7.3 Placement Groups verstehen
Placement Groups (PGs) sind die logischen Einheiten, in die Ceph Objekte gruppiert,
bevor sie auf OSDs verteilt werden. Jede PG hat einen Status, der Auskunft über den Zustand der
darin enthaltenen Daten gibt:
active+clean: Normalbetrieb. Alle Replikate sind vorhanden und konsistent.
degraded: Mindestens ein Replikat fehlt. Der Cluster arbeitet weiter, aber die
Redundanz ist eingeschränkt. Typisch direkt nach einem OSD-Ausfall.
recovering: Ceph stellt fehlende Replikate aktiv wieder her. Dieser Zustand
löst sich nach dem Recovery-Prozess von selbst auf.
backfilling: Ähnlich wie recovering, aber für neu hinzugefügte OSDs. Ceph
verteilt Daten auf die neuen OSDs um.
stale: Der primäre OSD für diese PG hat sich längere Zeit nicht beim Monitor
gemeldet. Deutet auf einen OSD-Ausfall oder ein Netzwerkproblem hin.
undersized: Die PG hat weniger Replikate als konfiguriert, ist aber noch
schreibbar, sofern min_size erfüllt ist.
peering: OSDs einigen sich auf den aktuellen Zustand der PG. Kurzlebiger
Übergangszustand, z. B. nach einem OSD-Neustart.
7.4 OSD-spezifische Diagnose
# Füllstand und Gewichtung aller OSDs anzeigen
ceph osd df
# OSD-Performance und I/O-Statistiken
ceph osd perf
# Einen OSD manuell aus dem Cluster nehmen (z. B. für Wartung)
ceph osd out osd.3
# OSD-Dienst stoppen (auf dem betroffenen Host)
systemctl stop ceph-osd@3
# OSD nach Wartung wieder einbinden
ceph osd in osd.3
7.5 Logs auswerten
Ceph-Logs befinden sich standardmäßig unter /var/log/ceph/. Die wichtigsten
Log-Dateien sind ceph.log (allgemeines Cluster-Log) und die OSD-spezifischen Logs
(z. B. ceph-osd.3.log). Bei schwer reproduzierbaren Problemen kann das Log-Level
temporär erhöht werden:
# Log-Level für alle OSDs temporär erhöhen
ceph tell osd.* injectargs '--debug-osd 10'
# Danach wieder zurücksetzen
ceph tell osd.* injectargs '--debug-osd 0'
Mit den vorgestellten Werkzeugen lässt sich der Zustand eines Ceph-Clusters jederzeit transparent
nachvollziehen. In Kombination mit dem integrierten Ceph-Dashboard und optional einem
Prometheus/Grafana-Stack (über das MGR-Prometheus-Plugin) entsteht eine vollständige
Monitoring-Infrastruktur für den produktiven Betrieb. Gerade in Proxmox-Umgebungen liefert das
PVE-Webinterface unter Datacenter → Ceph eine kompakte Echtzeit-Übersicht über OSD-Status,
PG-Zustände und Cluster-Gesundheit, die für den täglichen Betrieb vollkommen ausreicht.