Storage & Protokolle
Ceph
Ceph ist ein verteiltes Open-Source-Speichersystem für Block-, Datei- und Objektspeicher, das auf Standard-Hardware ausfallsicher skaliert.
- Open Source
- Horizontal skalierbar
- Hohe Ausfallsicherheit
- Herstellerunabhängig
- Für Standard-Hardware
Wer im Rechenzentrum Speicher plant, stößt schnell an die Grenzen klassischer SAN-Systeme: Sie skalieren nach oben statt in die Breite, binden an einen Hersteller und werden mit jedem Ausbau teurer. Ceph verfolgt einen anderen Ansatz und bündelt viele handelsübliche Server zu einem gemeinsamen Speicher, der Block-, Datei- und Objektspeicher zugleich liefert und beim Ausfall einzelner Komponenten weiterläuft. Vereinfacht gesagt: ein SAN auf Ethernet-Basis, ohne Fibre-Channel-Fabric und ohne proprietären Controller.
Der wichtigste Punkt vorweg: Ceph ist kein besseres NAS für einen einzelnen Server. Es lohnt sich, wenn mehrere Knoten, Ausfallsicherheit, Wachstum und ein planbarer Betrieb zusammenkommen. Für kleine Einzelserver-Umgebungen ist lokaler Speicher wie ZFS oft einfacher, günstiger und stabiler.
Dieser Artikel ordnet ein, wie Ceph aufgebaut ist, wie es Daten schützt, wie Hosts angebunden werden, welche Hardware und welches Netz es braucht und wann sich der Betrieb lohnt. Wo Pfade technisch nur über Umwege oder mit Einschränkungen gehen, sagen wir das offen.
1. Was Ceph ist
Ceph ist ein quelloffenes, softwaredefiniertes Speichersystem. Statt Speicher in einer dedizierten Appliance zu bündeln, verteilt Ceph ihn über viele Standard-Server und fasst deren Datenträger zu einem einzigen, logischen Speicherpool zusammen. Wächst der Bedarf, kommen weitere Knoten hinzu, ohne den Betrieb zu unterbrechen.
Das Fundament bildet RADOS (Reliable Autonomic Distributed Object Store). Darauf setzen die drei Zugangsarten auf, die Ceph zu einem vereinheitlichten Speicher machen: Blockgeräte für virtuelle Maschinen, ein verteiltes Dateisystem und ein S3-kompatibler Objektspeicher.
Eine Besonderheit ist der CRUSH-Algorithmus. Clients berechnen anhand einer Cluster-Karte selbst, auf welchen Datenträgern ein Objekt liegt. Es gibt keinen zentralen Index, der zum Engpass oder zur einzelnen Fehlerquelle werden könnte. Das ist der Grund, warum Ceph über viele Knoten hinweg mitwächst.
2. Die Bausteine eines Ceph-Clusters
Ein Ceph-Cluster besteht aus mehreren Diensten, die sich die Aufgaben teilen. Für einen verlässlichen Betrieb laufen die zentralen Dienste mehrfach und über getrennte Server verteilt.
- MON (Monitor) verwaltet die Cluster-Karte und das Quorum. Für stabile Mehrheitsentscheidungen laufen typischerweise drei oder fünf Monitore.
- MGR (Manager) liefert Metriken, das Dashboard und Schnittstellen für Monitoring und Automatisierung.
- OSD (Object Storage Daemon) verwaltet je einen Datenträger und speichert die eigentlichen Daten. Ein Cluster hat so viele OSDs wie Datenträger, oft Dutzende bis Hunderte.
- MDS (Metadata Server) hält die Metadaten für das Dateisystem CephFS vor, etwa Verzeichnisbäume und Berechtigungen.
- RGW (RADOS Gateway) stellt den Objektspeicher über eine S3- und Swift-kompatible Schnittstelle bereit.
3. Wie Ceph Daten schützt
Ceph hält jedes Objekt redundant vor. Dafür gibt es zwei Verfahren, die sich je Pool festlegen lassen.
- Replikation Ceph legt mehrere identische Kopien an, im Standard drei (size 3), und bleibt schreibfähig, solange mindestens zwei erreichbar sind (min_size 2). Einfach und schnell, aber speicherintensiv.
- Erasure Coding Daten werden in Fragmente plus Paritätsanteile zerlegt, vergleichbar mit RAID über Knoten hinweg. Das nutzt die Kapazität deutlich besser, kostet aber mehr CPU und Latenz. Sinnvoll vor allem für große, eher selten geänderte Datenmengen.
4. Selbstheilung und Datenintegrität
Über die CRUSH-Regeln legen Sie die Fehlerdomäne fest: Kopien dürfen dann zum Beispiel nie auf demselben Server oder im selben Rack liegen. Fällt eine Komponente aus, stellt Ceph die fehlende Redundanz selbsttätig auf den verbleibenden Knoten wieder her.
Gegen stille Datenfehler arbeitet Ceph mit Prüfsummen und regelmäßigem Scrubbing: Es vergleicht die Kopien und repariert Abweichungen, bevor sie auffallen.
Recovery ist Teil des Normalbetriebs. Nach einem Ausfall verteilt Ceph Daten neu, das erzeugt zusätzliche Last. Ein Cluster wird deshalb nicht nur für den Normalfall dimensioniert, sondern auch für den Fehlerfall.
5. Block, Datei oder Objekt: die drei Zugänge
Derselbe Cluster bedient drei sehr unterschiedliche Speicherbedürfnisse. Das macht Ceph für gemischte Umgebungen attraktiv.
- RBD (RADOS Block Device) liefert virtuelle Blockgeräte, etwa als Festplatten für virtuelle Maschinen. Das ist der häufigste Einsatz, zum Beispiel unter Proxmox VE.
- CephFS ist ein POSIX-kompatibles Dateisystem, das viele Clients gleichzeitig einhängen können. Es nutzt den Metadaten-Dienst MDS.
- RGW (Objektspeicher) stellt Speicher über die S3- und Swift-kompatible Schnittstelle bereit, inklusive Versionierung und Object Lock für unveränderliche Ablage. Ein typisches Ziel für Backups und Archive.
6. Zwei Netz-Ebenen, bitte nicht verwechseln
Rund um Ceph und Netzwerkprotokolle entsteht oft Verwirrung, weil zwei völlig verschiedene Ebenen vermischt werden.
- Host-Zugriff (Initiator zum Cluster) Wie ein Server oder Hypervisor den Speicher nutzt: über librbd nativ, über das iSCSI- oder das NVMe-oF-Gateway.
- Cluster-interner Messenger (OSD zu OSD) Wie die Ceph-Knoten untereinander sprechen: klassisch über TCP, theoretisch auch über RDMA.
Wer „Ceph mit RoCE" hört, meint fast immer den internen Messenger. Wer „Ceph als iSCSI-Laufwerk für Windows" sagt, meint den Host-Zugriff. Beides bei Planung und Erwartung sauber trennen.
7. Wie Hosts an Ceph kommen: die Zugriffspfade
Auf der Host-Ebene gibt es mehrere Wege, einen Ceph-Pool zu nutzen. Sie unterscheiden sich in Tempo, Aufwand und Reifegrad erheblich.
Die offizielle Ceph-Dokumentation beschreibt die Gateways samt Einrichtung, etwa den NFS-Zugang über RGW und CephFS über NFS.
| Pfad | Transport | Typische Initiatoren | Status / Hinweis |
|---|---|---|---|
| librbd (nativ) | RADOS direkt | KVM/QEMU, Proxmox VE, OpenStack, Kubernetes (CSI) | Schnellster Weg, kein Gateway. Der Normalfall, wo der Host Ceph nativ spricht. |
| NFS-Gateway | NFS (CephFS via nfs-ganesha, RGW via NFS) | Clients ohne nativen Ceph-Treiber: ältere Linux, Windows, OLVM | Häufigster Datei-Zugang: nfs-ganesha exportiert CephFS über Standard-NFS. Bringt Ceph z. B. als NFS-Storage-Domain in OLVM, je nach Setup mit pNFS/RDMA. |
| iSCSI-Gateway | iSCSI über TCP | Windows, ältere VMware-Stacks, Hosts ohne librbd | Maintenance-Modus seit November 2022, keine Weiterentwicklung. Für Neuprojekte nicht erste Wahl. |
| NVMe-oF-Gateway | NVMe/TCP | moderne Linux-Initiatoren, VMware | Offiziell nur TCP. Tech Preview ab Reef, produktionsnah ab Tentacle (v20). Empfohlener Nachfolger des iSCSI-Gateways. |
Was nicht sauber geht: FC und iSER
Einen nativen Fibre-Channel-Target hat Ceph nicht, und auch FC-NVMe ist kein dokumentierter Ceph-Pfad. iSER (iSCSI über RDMA) wird vom Ceph-iSCSI-Gateway nicht offiziell unterstützt. Beides ginge allenfalls über Drittlösungen außerhalb des Ceph-Projekts und ist nichts, was wir als sauberen Standardweg empfehlen. Praxisnäher ist der umgekehrte Weg: bestehende FC-LUNs auf RBD oder NVMe/TCP migrieren und die FC-Fabric ablösen.
8. Ceph als Storage für Virtualisierung
Der häufigste Grund für Ceph im Mittelstand ist gemeinsamer Speicher für Virtualisierung. Liegen die VM-Festplatten als RBD im Cluster statt lokal auf einem Host, werden Live-Migration und Hochverfügbarkeit ohne separates SAN möglich.
- Proxmox VE integriert Ceph direkt, inklusive Einrichtung über die Weboberfläche. Die VM-Disks liegen nativ als RBD im Pool. Hintergrund unter Proxmox VE.
- KVM / libvirt und OpenStack sprechen RBD nativ über librbd, bei OpenStack über Cinder. Das ist der saubere, dokumentierte Weg.
- OLVM / oVirt kann Ceph über dessen NFS-Gateway als NFS-Storage-Domain einbinden (siehe Zugriffspfade oben).
9. Netzwerk und Hardware
Ceph stellt keine exotischen Anforderungen, aber das Netzwerk entscheidet über Stabilität und Tempo, und Ceph will die Datenträger direkt verwalten, ohne RAID-Controller dazwischen.
- Netzwerk Ein schnelles Netz ist die Lebensader. Üblich sind mindestens 10 GbE, realistisch 25 GbE und mehr, oft mit getrenntem öffentlichem und Cluster-Netz, damit die Wiederherstellung nach einem Ausfall den normalen Betrieb nicht ausbremst.
- Datenträger NVMe oder SSD bestimmen die Leistung. Wichtig: Ceph will die Platten direkt ansprechen, also HBA oder IT-Mode statt RAID-Controller. Ein RAID darunter behindert die Selbstheilung und verschleiert Fehler. Für schreibintensive Workloads keine Desktop-SSDs ohne Power Loss Protection.
- Arbeitsspeicher und CPU Pro OSD sind einige GByte RAM einzuplanen (Standardziel rund 4 GiB), dazu ausreichend CPU-Kerne, besonders bei Erasure Coding und NVMe.
- Knotenzahl und Blast Radius Drei Knoten sind das praktikable Minimum für Quorum und dreifache Replikation. Mehrere kleinere Knoten sind oft robuster als wenige sehr große, weil bei einem Ausfall weniger Daten neu verteilt werden müssen.
10. RDMA und RoCEv2: kein Standardweg
Immer wieder kommt die Frage auf, ob sich das interne Ceph-Netz über RDMA beziehungsweise RoCEv2 beschleunigen lässt. Die Option existiert (ms_cluster_type = async+rdma), in der Praxis ist sie aber mit Vorsicht zu genießen.
Experimentell, nicht herstellergestützt
Der RDMA-Transport im Ceph-Messenger gilt in der Upstream-Doku als experimentell mit begrenzter Unterstützung. Red Hat unterstützt RDMA in keiner Ceph-Storage-Version, der Kubernetes-Operator Rook hat RoCE-Support als „wontfix" eingestuft, und der Code wird seit Jahren kaum gepflegt. Kernel-Mounts (RBD/CephFS) sprechen ohnehin weiter TCP. Für typische Cluster mit SAS/SATA-SSDs und 25-GbE-Netz bringt RDMA praktisch nichts, weil der Engpass eher bei BlueStore und CPU liegt. Lohnen kann es allenfalls in hochskalierten All-NVMe-Umgebungen mit 100-GbE-Fabric, und dann nur mit korrekt aufgebautem lossless Fabric (PFC, ECN, DSCP). Wir setzen es nicht als Standard ein.
11. Kapazität und Performance
Rohkapazität ist bei Ceph nicht gleich nutzbare Kapazität. Bei dreifacher Replikation steht grob ein Drittel der Rohkapazität für Nutzdaten zur Verfügung, noch vor Reserven. Erasure Coding verschiebt dieses Verhältnis zugunsten der Kapazität, kostet aber Latenz.
Ein Cluster sollte nicht randvoll laufen. Oberhalb von etwa 80 Prozent Füllstand wird es eng, weil nach einem Ausfall genug Platz für die Wiederherstellung bleiben muss. Wer erst bei 90 Prozent über Erweiterung nachdenkt, plant zu spät.
Performance hängt nicht an einer einzelnen Kennzahl, sondern am Zusammenspiel aus Workload, Medien, Netz, CPU und Pool-Design. Viele kleine zufällige Schreibvorgänge wie bei VM-Disks brauchen niedrige Latenz und schnelle Medien; große Objekte wie Archive über RGW brauchen Durchsatz. Ein Benchmark muss den echten Workload abbilden, nicht eine schöne Maximalzahl.
12. Backup und Disaster Recovery
Snapshots helfen, sind aber kein vollständiges Backup-Konzept. Ein Backup braucht getrennte Berechtigungen, getrennte Aufbewahrung, getestete Wiederherstellung und idealerweise einen zweiten Standort oder unveränderliche Speicherziele.
- RBD Mirroring asynchrone Replikation von Block-Images zwischen zwei Clustern, etwa für ein zweites Rechenzentrum.
- RGW Multisite Replikation des Objektspeichers über mehrere Zonen oder Standorte.
- Externe Backups VM-, Datei- und Applikationsdaten in ein getrenntes Backup-System, möglichst mit Object Lock gegen Ransomware.
Redundanz ist kein Backup. Ceph schützt vor dem Ausfall von Datenträgern und Knoten, nicht vor versehentlichem Löschen, Ransomware mit gültigen Zugangsdaten oder Logikfehlern.
13. Was Ceph im Betrieb verlangt
Ceph ist robust, aber kein System, das man einmal aufsetzt und dann vergisst. Der laufende Betrieb gehört von Anfang an mitgeplant.
- Monitoring Zustand, Auslastung und Wiederherstellungen gehören überwacht. Dashboard und Prometheus-Metriken liefern die Basis, siehe Monitoring.
- Lifecycle mit cephadm Moderne Cluster werden containerisiert über cephadm ausgerollt und verwaltet. Das vereinfacht den Betrieb, ersetzt aber kein eingeübtes Betriebsmodell für OSD-Austausch, Wartung und Updates.
- Updates Ceph erscheint in benannten Hauptversionen, zuletzt Reef, Squid und Tentacle, und wird im laufenden Betrieb rollierend aktualisiert. Eine gepflegte Version ist auch eine Sicherheitsfrage.
- Zugriffsschutz Mit cephx authentifizieren sich Clients und Dienste über Schlüssel. Rechte gehören minimal vergeben, Management-, Public- und Cluster-Netz sauber getrennt.
14. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Horizontale Skalierung über viele Knoten, ein Pool für Block, Datei und Objekt | Lohnt erst ab mehreren Knoten; für einen einzelnen Server überdimensioniert |
| Ausfallsicherheit über Replikation/Erasure Coding mit Selbstheilung | Hoher Betriebsaufwand: braucht Team, Monitoring und Patch-Disziplin |
| Gemeinsamer Storage für Virtualisierung (Proxmox, KVM, OpenStack), nativ über RBD | Leistung steht und fällt mit dem Netz (25/100 GbE, getrennte Netze) |
| S3-/Swift-kompatibler Objektspeicher (RGW) inkl. Object Lock | Höhere Latenz als lokaler Storage; nicht für latenzkritische Einzel-Workloads optimiert |
| Herstellerunabhängig, läuft auf Standard-Hardware (Open Source) | Bei sehr kleinen Umgebungen ist lokaler Storage wirtschaftlicher |
Die ehrliche Frage ist nicht, ob man Ceph installieren kann, sondern ob man es im Fehlerfall ruhig, dokumentiert und nachvollziehbar betreiben kann.
Häufige Fragen zu Ceph
Drei Knoten sind das praktikable Minimum, damit Quorum und dreifache Replikation funktionieren. Für gleichmäßige Auslastung und tragfähige Fehlerdomänen sind fünf oder mehr Knoten empfehlenswert.
librbd überall dort, wo der Hypervisor Ceph nativ spricht (Proxmox VE, KVM, OpenStack): am schnellsten, ohne Gateway. Das iSCSI-Gateway ist seit November 2022 im Maintenance-Modus und für Neuprojekte nicht erste Wahl. Für Hosts ohne librbd, etwa Windows oder ältere VMware-Stacks, ist das NVMe-oF-Gateway (NVMe/TCP) der modernere Weg.
Über den oVirt-Upstream ja, per „Managed Block Storage" (cinderlib). Dieser Weg hat Tech-Preview-Charakter und ist in der offiziellen Oracle-OLVM-Dokumentation nicht als Storage aufgeführt. Technisch möglich, aber außerhalb des offiziell gestützten Pfads und mit Tests zu planen.
Nein. Sauberes TCP über 25 oder 100 GbE reicht für die meisten Cluster. Der RDMA-Transport im Messenger gilt als experimentell und wird von kommerziellen Anbietern nicht unterstützt; für typische Umgebungen bringt er keinen Mehrwert.
Einen nativen Fibre-Channel-Target hat Ceph nicht, das ist kein dokumentierter Pfad. Praxisnäher ist, bestehende FC-LUNs auf RBD oder NVMe/TCP zu migrieren und die FC-Fabric abzulösen.
Nein. Ceph schützt über Redundanz vor Hardware-Ausfall, ersetzt aber kein Backup. Gegen versehentliches Löschen, Ransomware oder Logikfehler braucht es eine getrennte, idealerweise unveränderliche Sicherung.
Replikation (dreifach) ist einfacher und schneller, Erasure Coding spart Kapazität, kostet aber CPU und Latenz. Faustregel: heiße VM-Disks replizieren, kalte Archive per Erasure Coding.
Ja. Über das RADOS Gateway (RGW) stellt Ceph einen S3- und Swift-kompatiblen Objektspeicher bereit, inklusive Versionierung und Object Lock für unveränderliche Ablage.
Für produktive Cluster mindestens 10 GbE, realistisch 25 GbE oder mehr. Bei NVMe-Datenträgern und dichten Knoten sind 100 GbE sinnvoll. Getrennte Public- und Cluster-Netze entlasten den Normalbetrieb während der Wiederherstellung.
Nur bedingt. Für sehr kleine Umgebungen oder einen einzelnen Server ist der Betriebsaufwand meist zu hoch. Dort ist lokaler Speicher mit ZFS in der Regel die wirtschaftlichere Wahl.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Ceph im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.