Ceph Storage: Überblick, Architektur und Integration mit Proxmox

Ceph ermöglicht eine nahezu unbegrenzte Skalierung, indem einfach neue Speicherknoten hinzugefügt werden. Bestehende Knoten müssen dabei nicht aufgerüstet werden. Ein Ceph-Cluster kann problemlos Hunderte oder sogar Tausende von Knoten umfassen und so mehrere Petabyte an Daten effizient verteilen. Dadurch bleibt das System flexibel, leistungsfähig und wächst dynamisch mit den Anforderungen.

In einem Ceph-Cluster lassen sich Objektspeicher, Blockspeicher und Dateisysteme nahtlos in einer einheitlichen Plattform kombinieren. Dieses Unified-Storage-Konzept eliminiert die Notwendigkeit separater Systeme für unterschiedliche Speicheranforderungen:

• Virtuelle Maschinen (VMs) können direkt Blockgeräte aus Ceph nutzen, ähnlich wie bei klassischen SAN-Systemen.
• Gleichzeitig steht ein S3-kompatibler Objektspeicher zur Verfügung, ideal für Cloud-native Anwendungen und skalierbare Datenarchitekturen.
• Zusätzlich bietet Ceph ein verteiltes POSIX-konformes Dateisystem, das sich wie ein klassisches NAS verwenden lässt.

All das läuft auf derselben Infrastruktur, ohne spezielle Speicherhardware oder dedizierte Controller, und vereinfacht das Speichermanagement erheblich.

Ceph sorgt für maximale Datensicherheit durch eine verteilte, redundante Speicherung: Standardmäßig werden alle Daten dreifach repliziert und auf mehreren Knoten im Cluster verteilt. Fällt eine Festplatte oder ein kompletter Server aus, bleiben die Daten weiterhin zugänglich. Das System erkennt den Ausfall automatisch und stellt die fehlende Redundanz selbstständig wieder her – ein Prozess, der als Selbstheilung bezeichnet wird. Dank des verteilten Designs gibt es keinen Single Point of Failure.

Um Daten effizient und ohne zentrales Verzeichnis im Cluster zu verteilen, nutzt Ceph den CRUSH-Algorithmus (Controlled Replication Under Scalable Hashing). Anstatt auf eine zentrale Metadatenbank zuzugreifen, berechnet jeder Client selbstständig, wo seine Daten gespeichert werden. Daraus ergeben sich mehrere Vorteile:

• Kein Single Point of Failure – keine zentrale Stelle, die den Datenfluss regelt oder zum Flaschenhals wird.
• Automatische Lastverteilung – die Daten werden gleichmäßig über alle verfügbaren Knoten verteilt.
• Selbstoptimierung bei Änderungen – beim Hinzufügen oder Entfernen von Nodes passt sich der Cluster automatisch an und verteilt die Daten neu.

Ceph ist unter der LGPL-Lizenz frei verfügbar und kann ohne Lizenzgebühren eingesetzt werden. Dadurch entfällt die Abhängigkeit von proprietären Speicherlösungen, die oft mit hohen Kosten und Einschränkungen verbunden sind. Ein wesentliches Problem solcher Lösungen ist der Vendor-Lock-in – die Bindung an einen bestimmten Hersteller. Ceph vermeidet dieses Risiko, da es auf handelsüblicher Hardware läuft und offene Standards nutzt.

Anstatt auf spezielle Speicher-Arrays oder dedizierte SAN-Fabrics angewiesen zu sein, läuft Ceph auf handelsüblicher Hardware. Jeder Storage-Node ist ein Linux-Server mit direkt angeschlossenen Festplatten. Redundanz und Datenverteilung übernimmt Ceph eigenständig, sodass keine klassischen Hardware-RAID-Controller erforderlich sind. Dadurch lassen sich Standardkomponenten nutzen, was eine flexible und kosteneffiziente Speicherlösung ermöglicht.

Jeder OSD-Dienst übernimmt eine zentrale Rolle bei der Speicherung und Verwaltung von Daten und sorgt dafür, dass jede einzelne physische Festplatte oder SSD optimal genutzt wird. Konkret speichern die OSD-Dienste die eigentlichen Datenobjekte und führen Aufgaben wie Datenreplikation, Wiederherstellung (Recovery), Neuverteilung (Rebalancing) und regelmäßige Prüfungen (Scrubbing) durch. Gleichzeitig melden sie kontinuierlich ihren Status an die Cluster-Monitore. In einem typischen Ceph-Server läuft pro Festplatte ein separater OSD-Prozess – das wird empfohlen, um die beste Performance ohne zusätzlichen RAID-Einsatz zu erzielen.

Die Monitore verwalten die Cluster Map – eine umfassende Übersicht aller wesentlichen Zustandsinformationen. Dazu gehören die OSD Map (Status der Speicherknoten), die Monitor Map, die Placement Group Map (logische Datengruppen für effiziente Replikation) und die CRUSH Map (Datenverteilung im Cluster). Die Monitore überwachen kontinuierlich, welche OSDs aktiv oder inaktiv sind, und liefern den Clients die aktuelle Cluster Map. Für einen ausfallsicheren Betrieb sollten mindestens drei Monitore eingesetzt werden. So wird im Quorum – einem Mechanismus, bei dem die Mehrheit der Monitore zustimmen muss – verhindert, dass ein einzelner Ausfall das gesamte System gefährdet.

Der Metadata-Server (MDS) ist eine zentrale Komponente von CephFS – dem verteilten Dateisystem von Ceph. Er speichert und verwaltet Verzeichnisstrukturen sowie Dateimetadaten (z. B. Dateinamen, Ordnerstrukturen und Zugriffsberechtigungen), um einen schnellen und effizienten Dateizugriff zu gewährleisten. Für den Betrieb von CephFS wird mindestens ein MDS benötigt; bei steigendem Traffic können mehrere MDS parallel eingesetzt werden, um die Last zu verteilen.

Manager-Daemons ergänzen den Cluster-Betrieb durch zentrale Verwaltungsfunktionen. Sie sammeln wichtige Cluster-Metriken und stellen ein interaktives Dashboard zur einfachen Überwachung und Steuerung bereit. Außerdem unterstützen sie die orchestrierte Verwaltung, sodass wiederkehrende Aufgaben automatisiert werden können. Für den reinen Speicherbetrieb sind sie nicht zwingend erforderlich, für Funktionen wie die Web-Dashboard-Überwachung jedoch unverzichtbar. In der Regel wird auf jedem Monitor-Knoten auch ein Manager-Dienst betrieben.

RADOS (Reliable Autonomic Distributed Object Store) ist der grundlegende Objektspeicher-Layer von Ceph und bildet die Basis, auf der alle weiteren Ceph-Dienste aufbauen. RADOS integriert alle Object Storage Daemons (OSDs) sowie Ceph-Monitore (MONs). Objekte – einzelne Datenblöcke – werden sicher gespeichert, automatisch repliziert und effizient über den Cluster verteilt. Entwickler können über die librados-Bibliothek direkt darauf zugreifen. Diese modulare, dezentrale Architektur gewährleistet hohe Skalierbarkeit, Ausfallsicherheit und Performance.

Der Ceph Object Gateway (auch RADOS Gateway oder RGW) ist ein optionaler Dienst, der eine REST-API für Objektspeicher bereitstellt. Dank Kompatibilität mit den Amazon-S3- und OpenStack-Swift-APIs ermöglicht er den Cloud-Style-Einsatz von Ceph, wobei sämtliche Objektdaten letztlich im RADOS gespeichert werden. Der Dienst verwaltet eigenständig Benutzer und Zugriffsrechte und unterstützt den Betrieb mehrerer Instanzen für Lastverteilung und Hochverfügbarkeit.

Das RADOS Block Device (RBD) stellt virtuelle Blockgeräte auf Basis des RADOS-Objektspeichers bereit. Diese Blockgeräte lassen sich wie klassische Festplatten einbinden und eignen sich besonders als Speicher für virtuelle Maschinen und Container. RBD unterstützt Funktionen wie Thin Provisioning, Snapshots und Clones und verteilt die zugrunde liegenden Daten automatisch redundant über den Cluster.

Das Ceph File System (CephFS) ist ein verteiltes, POSIX-kompatibles Dateisystem auf Basis eines Ceph-Clusters. Es lässt sich ähnlich wie ein traditionelles Network File System (NFS) einsetzen – entweder durch direkte Einbindung über Kernel-Treiber oder mittels FUSE (Filesystem in Userspace). Im Kern speichert CephFS Dateiinhalte als Objekte im RADOS, während ein oder mehrere Metadata-Server (MDS) die Verwaltung der Dateisystem-Metadaten übernehmen. So können zahlreiche Clients simultan auf das geteilte Dateisystem zugreifen, ohne dass Datenintegrität oder Performance leiden.

Erasure Coding ermöglicht eine speichereffiziente und ausfallsichere Speicherung großer Datenmengen, indem Datenobjekte in Fragmente und Paritätsblöcke geteilt werden.

Datenaufteilung und Paritätsberechnung: Ein Objekt wird in k Datenfragmente unterteilt. Zusätzlich werden m Paritätsblöcke (z. B. mittels Reed-Solomon-Codierung) berechnet, sodass insgesamt k + m Fragmente entstehen. Bei Ausfall von bis zu m Fragmenten kann das Objekt rekonstruiert werden.

Verteilte Speicherung: Alle k + m Fragmente werden auf verschiedene OSDs verteilt. Der CRUSH-Algorithmus bestimmt anhand der Cluster-Topologie die Platzierung und organisiert sie in Placement Groups (PGs).

Datenwiederherstellung: Bei einem Ausfall genügt die Verfügbarkeit von mindestens k Fragmenten zur vollständigen Rekonstruktion. Dieser Prozess läuft automatisch über die OSDs oder Client-Bibliotheken (librados). Erasure Coding spart signifikant Speicherplatz gegenüber der dreifachen Replikation, erfordert jedoch mehr Rechenleistung und kann zu leicht erhöhten Latenzen führen.

Einsatzbereiche: In Ceph wird Erasure Coding für den Objektspeicher (RGW) und CephFS genutzt, während RBD-Pools standardmäßig repliziert werden. Die Methode eignet sich besonders für Cold Storage und Archivierung.

Die Replikation folgt einem dezentral organisierten Ansatz:

Datenverteilung mit CRUSH: Jeder Client berechnet autonom, welche OSDs für ein bestimmtes Objekt zuständig sind – ganz ohne zentrale Lookup-Server. Die Informationen zur Clusterstruktur liegen in der CRUSH-Map, die von den Monitoren gepflegt und an die Clients verteilt wird.

Organisation in Pools und Placement Groups: Objekte werden in logischen Pools organisiert; jeder Pool wird weiter in Placement Groups (PGs) unterteilt. CRUSH ordnet jedem Objekt eine PG zu und platziert die PG auf bestimmten OSDs.

Standardmäßige 3-fache Replikation: Beim Schreibzugriff kontaktiert der Client den primären OSD der zugehörigen PG, der die Daten zuerst speichert. Anschließend werden zwei weitere Kopien auf anderen OSDs erstellt.

Automatische Wiederherstellung: Fällt ein OSD aus, erkennen die Monitore den Ausfall und markieren den Knoten als „down". Die verbleibenden OSDs stellen die fehlenden Kopien auf anderen intakten Knoten her – parallel auf PG-Ebene.

Im Vergleich reduziert Erasure Coding den Speicherbedarf (ein k=3-, m=2-Schema benötigt nur etwa den 1,67-fachen Speicherplatz statt des dreifachen). Während Replikation vor allem für aktive, latenzkritische Anwendungen geeignet ist, bietet Erasure Coding eine effiziente Lösung für große, seltener genutzte Datenmengen.

Vorteile von Ceph

• Horizontale Skalierung: Kapazität und Leistung wachsen durch Hinzufügen von Knoten – kein teures Aufrüsten zentraler Appliances.
• Einheitliche Plattform: Objektspeicher, Blockspeicher und POSIX-Dateisystem in einem System.
• Kosten- und Anbieterunabhängigkeit: Open Source ohne Lizenzkosten und Vendor-Lock-in.
• Automatische Lastverteilung: Intelligente Datenverteilung vermeidet Engpässe.

Nachteile von Ceph

• Komplexität: Erfordert mehr Fachwissen und sorgfältige Planung als „Plug-and-Play"-SAN-Lösungen.
• Aufwändige Implementierung: Der initiale Setup-Prozess ist zeitintensiver.

Vorteile von Ceph

• Plattformunabhängigkeit: Ceph läuft primär unter Linux und unterstützt diverse Clients (z. B. über iSCSI oder Samba), während S2D ausschließlich auf Windows-Servern einsetzbar ist.
• Kosten: Ceph ist Open Source und kostenfrei, während S2D eine Windows-Datacenter-Lizenz benötigt.
• Flexibilität: Ceph lässt sich in heterogenen Umgebungen wie Kubernetes oder OpenStack integrieren.

Nachteile von Ceph

• Leistung: S2D erzielt in Hyper-V-Umgebungen oft bessere I/O-Performance und niedrigere Latenzen, da es tief im Windows-Kernel integriert ist.
• Komplexität: Ceph erfordert zusätzliches Linux-Know-how und eine komplexere Einrichtung (z. B. durch die CRUSH-Logik).

Vorteile von Ceph

• Umfassende Speicherunterstützung: Native Unterstützung für Block-, Objekt- und Dateispeicher in einer einzigen Lösung.
• Erweiterte Features: Integrierte Selbstheilung, dynamische Lastverteilung und Block-Device-Unterstützung.
• Skalierbarkeit: Objektbasierte Architektur ermöglicht sehr große Cluster mit feiner Datenverteilung ohne zentralisierte Sperrprobleme.

Nachteile von Ceph

• Komplexität: Höhere Lernkurve durch Konzepte wie CRUSH, Pools und Placement Groups.
• Aufwändige Administration: Schwieriger zu installieren und zu betreiben, vor allem in kleineren Setups, wo GlusterFS oft ressourcenschonender ist.

Vorteile von Ceph

• Verteilte Architektur: Ermöglicht horizontale Skalierung und automatische Ausfallverteilung über viele Knoten hinweg.
• Flexible Einsatzbereiche: Bietet zusätzliche Funktionen wie Object-Storage-Interfaces und Multi-Client-Blockgeräte.
• Nahtlose Erweiterbarkeit: Kapazität und Leistung lassen sich durch einfaches Hinzufügen neuer Serverknoten erweitern.

Nachteile von Ceph

• Komplexität: Aufbau und Betrieb eines Ceph-Clusters erfordern mehr Fachwissen und kontinuierliche Wartung.
• Höherer Verwaltungsaufwand: Initiale Einrichtung und Pflege sind zeitintensiver als bei einem einzelnen ZFS-System.
• Leistung bei Einzelknoten: Für Anwendungen auf einem einzelnen Server (z. B. Datenbanken oder Video-Streaming) bietet ZFS oft bessere Performance und geringere Latenz.

Proxmox VE verfügt über integrierte Werkzeuge wie die Web-GUI und die pveceph-CLI. Diese ermöglichen es, einen Ceph-Cluster direkt über das Proxmox-Interface zu installieren und zu steuern. Administratoren können Monitore, OSDs und Speicher-Pools per Mausklick konfigurieren, was den Einstieg erheblich vereinfacht.

Virtuelle Festplatten auf Basis von Ceph RBD (RADOS Block Device) unterstützen Thin Provisioning, sodass Speicherplatz bedarfsgerecht zugewiesen wird, ohne sofort den gesamten physischen Speicher zu reservieren. Integrierte Snapshots ermöglichen schnelle, nahezu overheadfreie Sicherungen und Klon-Erstellungen.

Dank der automatischen Replikation in Ceph werden VM-Daten redundant gespeichert. Fällt ein Knoten aus, übernimmt ein anderer automatisch – ganz ohne separate HA-Speichersysteme. Diese fehlertolerante Architektur eliminiert klassische Single Points of Failure.

Eine Proxmox-+-Ceph-Umgebung lässt sich schrittweise erweitern: Bei steigendem Speicher- oder Leistungsbedarf wird einfach ein weiterer Node mit zusätzlichen Festplatten hinzugefügt. Ceph skaliert theoretisch bis in den Exabyte-Bereich – weit über die Kapazitäten traditioneller Hardware-SANs hinaus.

Innerhalb eines Ceph-Clusters können unterschiedliche Speicherarten integriert werden: Ceph RBD liefert Blockspeicher, ideal als VM-/Container-Datastore; CephFS bietet ein verteiltes Dateisystem als gemeinsamen Speicher für mehrere VMs; RGW stellt objektbasierten, cloud-kompatiblen Speicher bereit. Diese nahtlose Einbindung sorgt für eine einheitliche und flexible Infrastruktur.

Ceph nutzt vorhandene Server und lokale Laufwerke, wodurch teure externe Storage-Systeme und RAID-Controller entfallen. Jeder zusätzliche Proxmox-Knoten mit einigen Festplatten erweitert den Gesamtspeicher – was Kosten und Komplexität reduziert.

In einer hyperkonvergenten Proxmox-Ceph-Architektur sind separate Storage-Netzwerke wie Fibre-Channel-SANs oder NAS-Appliances nicht erforderlich. Ein separates VLAN für den Ceph-Datenverkehr empfiehlt sich zwar für optimale Performance, das Gesamtsystem bleibt jedoch deutlich einfacher und kosteneffizienter.