Ceph Grundlagen – verteiltes, softwarebasiertes Storage-System

Ceph ist ein verteiltes, softwarebasiertes Speichersystem, das aus Standard‑Servern einen hochskalierbaren, fehlertoleranten Storage‑Cluster für Objekt‑, Block‑ und Dateizugriff aufbaut. Es gehört zur Klasse der Software Defined Storage (SDS)‑Lösungen und ersetzt klassische SAN-/NAS‑Systeme durch einen verteilten Objektspeicher, auf dem unterschiedliche Dienste aufsetzen.

Was ist Ceph und wofür wird es eingesetzt?

Ceph ist ein Open‑Source‑Storage‑System, das Speicherkapazität über viele Knoten verteilt und als ein einheitlicher Speicherpool bereitstellt. Statt wenige große Storage‑Arrays zu betreiben, können Admins viele Standard‑Server (Nodes) hinzufügen und so Kapazität und Performance nahezu linear skalieren.

Ceph basiert auf einem verteilten Objektspeicher namens RADOS, auf dem drei Haupt‑Dienste aufbauen:

• Block‑Storage über RBD (RADOS Block Device)
• Objektspeicher über RGW (RADOS Gateway, S3-/Swift‑ähnlich)
• POSIX‑Dateisystem über CephFS

Typische Einsatzszenarien:

• Speicher‑Backend für OpenStack, Kubernetes oder Virtualisierungsplattformen (RBD‑Volumes für VMs)
• Objektspeicher für Backups, Archivierung und Cloud‑native Anwendungen
• Hochverfügbares Shared‑Filesystem (CephFS) für Container‑Orchestrierung, HPC oder Big‑Data‑Workloads

RADOS – das Herz von Ceph

Im Kern von Ceph steht RADOS (Reliable Autonomic Distributed Object Store). RADOS speichert Daten als Objekte, verteilt sie automatisch, repliziert sie, balanciert Lasten und heilt sich nach Ausfällen selbst.

Wichtige Eigenschaften von RADOS

• Objektbasiert: Daten werden als Objekte in einem flachen Namespace abgelegt (kein klassischer Verzeichnisbaum).
• Pools: Objekte werden logisch in Pools organisiert, die Replikations‑ oder Erasure‑Coding‑Regeln, Platzierungsrichtlinien und Performance‑Profile definieren.
• Self‑Healing: Fällt ein Datenträger oder OSD aus, erkennt RADOS fehlende Replikate und baut diese automatisch auf anderen OSDs wieder auf.

Auf RADOS bauen alle Ceph‑Dienste auf – es ist die eigentliche Daten‑Engine des Ceph‑Clusters.

Zentrale Ceph‑Komponenten: MON, OSD, MGR, MDS

Ein Ceph‑Cluster besteht aus mehreren Daemon‑Typen mit klar getrennten Aufgaben.

Ceph Monitors (MON)

Monitors verwalten den globalen Cluster‑Zustand („Cluster Map“):

• Welche OSDs sind aktiv oder down
• Welche Pools, CRUSH‑Regeln und Konfigurationen existieren
• Quorum‑Status der Monitore

Eigenschaften:

• Typischerweise 3 oder 5 MON‑Instanzen zur Quorum‑Bildung
• Clients holen sich Cluster‑Karten bei den MONs und greifen dann direkt auf OSDs zu
• MONs sind kritisch für Konsistenz, speichern aber keine Nutzdaten

Ceph OSD Daemons (OSDs)

OSDs (Object Storage Daemons) sind die Arbeitspferde von Ceph.

Aufgaben der OSDs:

• Speichern von Objektdaten und Metadaten
• Replikation, Recovery, Backfilling und Rebalancing
• Health‑Status an Monitors melden
• Direkt mit Clients bei Lese‑/Schreibzugriffen kommunizieren

Standard‑Backend ist heute BlueStore, das Objekte direkt auf Block‑Geräten speichert und Dateisystem‑Overhead reduziert – wichtig für Performance und Latenz.

Ceph Manager (MGR)

Der Ceph‑Manager (MGR) ergänzt die Monitors um Management‑Funktionen:

• Sammeln von Statistiken und Telemetrie
• Bereitstellung des Web‑Dashboards
• Plugin‑System für Orchestrierung und Integrationen (z. B. Prometheus, Alerting)

MGR‑Daemons laufen häufig auf denselben Knoten wie MONs, können aber auch getrennt betrieben werden.

Ceph Metadata Server (MDS)

MDS‑Daemons werden für CephFS benötigt:

• Verwalten Metadaten für das Dateisystem: Verzeichnisse, POSIX‑Attribute, Locks
• Bearbeiten Operationen wie mkdir, rename, ls, während Datenblöcke als RADOS‑Objekte liegen
• Können skaliert und geshardet werden, um Hotspots in großen Dateibäumen zu vermeiden

Für reine Object‑ oder Block‑Use‑Cases sind MDS‑Daemons nicht notwendig.

Datenverteilung mit dem CRUSH‑Algorithmus

Ceph nutzt CRUSH (Controlled Replication Under Scalable Hashing), um zu bestimmen, auf welchen OSDs ein Objekt gespeichert wird.

Kernideen von CRUSH:

• Deterministische Platzierung: Client bzw. OSD berechnet aus Objekt‑ID, Pool und CRUSH‑Regel direkt die Ziel‑OSDs – ohne zentrale Lookup‑Datenbank.
• CRUSH‑Map: Beschreibt Cluster‑Topologie (z. B. Datacenter → Rack → Host → OSD) und Platzierungsregeln („repliziere über Racks hinweg“).
• Skalierbarkeit: Kein zentraler Metadaten‑Flaschenhals, Arbeit skaliert mit der Clustergröße.

Admins können Ausfall‑Domänen modellieren (Host, Rack, Datacenter), sodass Replikate oder Erasure‑Coding‑Chunks bewusst verteilt werden – wichtig für Hochverfügbarkeit und Disaster Recovery.

Replikation und Erasure Coding

Ceph bietet zwei grundsätzliche Strategien zur Datensicherung: Replikation und Erasure Coding.

Replizierte Pools

In replizierten Pools wird jedes Objekt in n Kopien gespeichert (typisch size = 3):

• Sehr einfache Konfiguration und bewährtes Verhalten
• Schnelle Write‑Performance, da keine Kodierung nötig ist
• Hoher Kapazitätsbedarf (z. B. 3× Rohkapazität)

Erasure‑Coding‑Pools

Erasure Coding (EC) teilt Objekte in Daten‑ und Paritäts‑Chunks (z. B. 8+3):

• Deutlich besseres Kapazitätsverhältnis als reine Replikation
• Cluster bleibt lesbar, solange nicht mehr als m Chunks verloren gehen
• Höherer Rechenaufwand beim Schreiben und bei Recovery

Praxis: - Performance‑kritische Workloads (Datenbanken, VMs) häufig in replizierten Pools - Archive, Backups, „kalte“ Daten in Erasure‑Coding‑Pools

Ceph‑Speicherdienste: RBD, RGW, CephFS

Auf RADOS bauen drei zentrale Frontends auf:

RBD – RADOS Block Device

• Stellt virtuelle Block‑Devices bereit, vergleichbar mit LUNs im SAN
• Ideal für virtuelle Maschinen oder Datenbanken
• Unterstützt Thin Provisioning, Snapshots, Klone
• Häufiges Backend für KVM, OpenStack und Kubernetes (über CSI‑Treiber)

RGW – RADOS Gateway (S3/Swift)

• Stellt S3‑ und Swift‑kompatible APIs bereit
• Anwendungen arbeiten wie mit einem Public‑Cloud‑Objektspeicher, Daten bleiben jedoch on‑premises
• Unterstützt Buckets, Policies, Versionierung und Multi‑Tenancy

CephFS – POSIX‑Dateisystem

• Bietet ein vollwertiges POSIX‑Dateisystem auf Basis von RADOS
• MDS‑Daemons verwalten Metadaten, Daten liegen als Objekte in Pools
• Unterstützt Snapshots, Quotas und parallele Zugriffe in großen Umgebungen

Mit einem Ceph‑Cluster lassen sich so Block‑Storage, Objektspeicher und Shared‑Filesystem aus einer Plattform bereitstellen – ein starkes SEO‑Argument für Begriffe wie „Ceph All‑in‑One Storage“.

Skalierung und Hochverfügbarkeit

Ceph ist von Grund auf für horizontale Skalierung und hohe Verfügbarkeit ausgelegt.

Horizontale Skalierung

• Kapazität: Durch Hinzufügen weiterer OSD‑Nodes wächst der Speicherpool; CRUSH verteilt Daten neu.
• Performance: Mehr OSDs bedeuten mehr parallele I/O‑Kapazität, da Clients direkt mit vielen OSDs sprechen.
• Beim Hinzufügen/Entfernen von OSDs werden nur Teile der Daten verschoben (effizientes Rebalancing).

Hochverfügbarkeit & Self‑Healing

• Redundanz durch Replikation oder Erasure Coding schützt vor Disk‑ und Node‑Ausfällen.
• Fällt ein OSD aus, markiert der Cluster ihn als „down“ und baut fehlende Kopien automatisch neu auf.
• Multi‑Site‑Replikation/Mirroring erlaubt DR‑Szenarien über Standorte hinweg.

Hardware‑Grundlagen für Ceph‑Cluster

Für stabilen Betrieb sind passende Hardware‑Designs entscheidend:

• Rollen trennen: OSD‑Daten getrennt von MON/MGR/MDS‑Daten, um I/O‑Konflikte zu vermeiden.
• Netzwerk: Dedizierte 10/25/40‑GbE‑Netzwerke für Public‑ und Cluster‑Traffic sind Standard.
• Speichermedien: SSDs/NVMe für BlueStore DB/WAL und Metadaten, HDDs für Kapazitäts‑OSDs bei kapazitätsorientierten Clustern.
• Workload‑abhängig entweder IOPS‑optimierte (mehr, schnelle OSDs) oder kapazitätsoptimierte (dichte HDD‑Shelfs) Designs wählen.

Administration und Monitoring

Für Betrieb und Fehleranalyse stellt Ceph mehrere Werkzeuge bereit:

• ceph CLI: Statusabfragen (ceph status), OSD‑Listen, Pool‑Konfiguration, Health‑Checks.
• Dashboard: Web‑GUI mit Health‑Übersicht, Metriken, Konfiguration.
• Metrik‑Integration: Export zu Prometheus/Grafana, Logging in zentrale Systeme.

Wichtig für den Betrieb:

• Schwellenwerte für Kapazität und Health‑Zustände definieren
• Backfill‑ und Recovery‑Limits so setzen, dass Cluster auch unter Ausfallbedingungen performant bleibt
• Regelmäßige Tests von Ausfallszenarien (z. B. OSD/Node‑Ausfall) und Dokumentation