Ceph · Block, Objekt, Datei
Ceph Storage und hochverfügbare Speicherinfrastruktur
Ein Ceph-Cluster ist nur so ausfallsicher wie seine Auslegung. SKAFFON plant, baut und betreibt ihn so, dass der Verlust eines Hosts Ihre Anwendungen nicht anhält.
- RBD für Proxmox und Kubernetes
- S3-kompatibler Objektspeicher
- Betrieb auf Wunsch rund um die Uhr
01Ausgangslage
Warum Ceph-Projekte an der Dimensionierung scheitern
SKAFFON plant, baut und betreibt Ceph-Cluster als Software-defined Storage für Block-, Objekt- und Dateispeicher: für Proxmox- und Kubernetes-Plattformen, als S3-kompatiblen Objektspeicher oder als gemeinsamen Speicher für virtuelle Maschinen.
Ceph skaliert und ist robust, aber nur bei richtiger Auslegung. Ein falsch dimensionierter Cluster ist eine typische Ursache für Probleme. Diese Seite richtet sich an IT-Leitung und Infrastrukturverantwortliche, die entscheiden müssen, ob Ceph zu ihrer Größe und ihrem Betrieb passt und wie ein Cluster ausgelegt sein muss, damit er den Ausfall von Komponenten tatsächlich übersteht.
02Schnittstellen
Drei Zugriffswege auf einen verteilten Speicher
Ceph speichert Daten als Objekte in einem verteilten Speicher namens RADOS, auf dem alle weiteren Schnittstellen aufsetzen (Ceph: Architecture).
-
RBD: Block für VMs und Volumes
Dünn provisionierte, skalierbare Blockgeräte, die über RADOS verteilt, repliziert und mit Snapshots versehen sind; Hypervisoren wie KVM/QEMU nutzen sie direkt (Ceph: Block Device).
-
Object Gateway: S3
Ein RESTful-Gateway mit S3-kompatibler Schnittstelle (für eine große Teilmenge der Amazon-S3-API) und Swift-kompatibler Schnittstelle (Ceph: Object Gateway). „S3-kompatibel“ heißt nicht „identisch“: Wir prüfen die von Ihren Anwendungen genutzten Funktionen gegen die Dokumentation.
-
CephFS: Datei
Ein POSIX-kompatibles verteiltes Dateisystem (Ceph: File System).
03Eignung
Ab welcher Clustergröße Ceph sich lohnt
Ceph lohnt sich bei ausreichender Knotenzahl, schnellem Netz und dem Bedarf an gemeinsamem, hochverfügbarem Speicher mit der Möglichkeit, später zu wachsen. Das entscheiden wir mit Ihnen anhand von Knotenzahl, Wachstum und Betriebsfähigkeit, nicht anhand von Vorlieben.
Ceph passt, wenn
- genügend Knoten und ein schnelles Netz vorhanden sind
- gemeinsamer, hochverfügbarer Speicher gebraucht wird
- der Speicher später wachsen soll
Besser etwas anderes, wenn
- der Cluster sehr klein ist: Die Ceph-Dokumentation rät zu vielen kleineren statt wenigen dichten Knoten, weil beim Ausfall eines Hosts mit großem Kapazitätsanteil die Wiederherstellung die Datenträger über die Füllgrenze treiben kann und Ceph dann den Betrieb anhält, um Datenverlust zu vermeiden (Ceph: Hardware Recommendations)
- Sie bei drei Knoten ohne Wachstum einen einfachen Speicher suchen: ZFS mit Replikation oder ein externer Speicher kann besser sein
04Replikation
Drei Kopien, drei Hosts: was size und min_size festlegen
Ein replizierter Pool speichert üblicherweise drei Kopien jedes Objekts (size = 3). Die Zahl der OSDs, die ohne Datenverlust gleichzeitig ausfallen dürfen, ist laut Dokumentation um eins kleiner als die Zahl der Replikate. Mit min_size legt man fest, wie viele aktive Replikate für Ein- und Ausgabe nötig sind; size 3 mit min_size 2 ist das Standardbeispiel.
Ausdrücklich warnt die Dokumentation: size 2 oder min_size 1 im Produktivbetrieb riskiert Datenverlust und gehört höchstens vorübergehend in Notfälle (Ceph: Pools).
- Erasure Coding spart bei großen Beständen Platz, hat aber andere Eigenschaften (Ceph: Erasure Code)
- Es verlangt zusätzliche Planung für Failure Domains, Leistung und Wiederherstellung
- Für VM-Disks prüfen wir es besonders kritisch
05
So verteilt Ceph ein Objekt auf drei Hosts
06Failure Domains
Was ausfallen darf: die Failure Domain entscheidet
Eine Failure Domain ist alles, dessen Ausfall mehrere Daemons oder Datenträger gleichzeitig betrifft: ein Host, ein Rack, ein Switch, eine Stromschiene, ein Brandabschnitt. Beim Erstellen einer CRUSH-Regel für einen replizierten Pool wählt man sie: Bei host liegt jedes Replikat auf einem eigenen Host, bei rack in einem eigenen Rack (Ceph: CRUSH-Map). Die Wahl bestimmt, wie viele solcher Einheiten es mindestens geben muss.
| Failure Domain | Schützt vor | Mindestens nötig | Wann sinnvoll | Gegenseite |
|---|---|---|---|---|
| Datenträger (OSD) | Ausfall einzelner Platten | Als alleinige Domain nicht empfohlen: Ein Hostausfall träfe mehrere Replikate | Praktisch nie als Produktionsstandard | Kein Schutz bei Hostausfall |
| Host | Ausfall eines Servers | Drei Hosts; für Wiederherstellung nach Ausfall besser mehr | Standard für kleine bis mittlere Cluster | Kein Schutz bei Rack- oder Switch-Ausfall |
| Rack | Ausfall von Rack, Stromverteilung oder Top-of-Rack-Switch | Drei Racks | Größere Cluster in mehreren Racks | Mehr Infrastruktur nötig |
| Standort (Stretch) | Ausfall eines Rechenzentrums | Zwei Standorte mit Daten plus ein dritter Ort für einen Tiebreaker-Monitor | Zwei Rechenzentren mit gleichmäßig verteiltem Datenbestand | Höhere Netzanforderungen, asynchrone Alternativen prüfen |
Monitore benötigen für das Quorum eine ungerade Zahl (Ceph: Monitor-Konfiguration); üblich sind drei.
07Zwei Rechenzentren
Stretch-Modus oder RBD-Mirroring: zwei Wege über zwei Standorte
Der Stretch-Modus beschreibt zwei Rechenzentren, die je eine Kopie halten, und eine dritte Zone mit einem Tiebreaker-Monitor, der bei Netztrennung entscheidet (Ceph: Stretch Clusters).
Wer Daten zwischen zwei getrennten Clustern replizieren will, kann RBD-Mirroring nutzen, das Images asynchron spiegelt, wahlweise journal-basiert (Latenzen verdoppeln sich laut Dokumentation nahezu) oder snapshot-basiert (Ceph: RBD Mirroring). Welches Muster passt, hängt von Ihren Wiederherstellungszielen ab; mehr dazu bei Backup und Disaster Recovery.
08Kapazität
Wie viel Speicher bleibt nutzbar: Rechenbeispiel mit Ausfallreserve
Nutzbare Kapazität ist nicht „Rohkapazität geteilt durch Replikate“, denn nach einem Ausfall muss die Wiederherstellung innerhalb des verbleibenden Clusters Platz finden. Eine Näherung, die wir für die Erstauslegung nutzen:
nutzbar ≈ Rohkapazität × (N − 1) / N × maximale Zielfüllung / size
Dabei ist N die Zahl der Failure Domains (hier Hosts), die maximale Zielfüllung der Wert, bei dem Sie noch mit Reserve unterhalb der Füllgrenzen (nearfull, backfillfull, full) bleiben wollen.
Rechenbeispiel mit angenommenen Werten, keine Messung und keine Empfehlung: fünf Hosts mit je vier Datenträgern à 3,84 TB: Rohkapazität 5 × 4 × 3,84 = 76,8 TB. Angenommene Zielfüllung 0,8, size 3: 76,8 × 4/5 × 0,8 / 3 ≈ 16,4 TB nutzbar. Das sind rund ein Fünftel der Rohkapazität, deutlich weniger als die 25,6 TB, die eine naive Division durch drei ergäbe.
09Hardware und Netz
Hardware und Netzwerk: was die Ceph-Dokumentation vorgibt
Die Ceph-Dokumentation nennt unter anderem die folgenden Prinzipien (Ceph: Hardware Recommendations). Ein getrenntes Cluster-Netz ist optional; ohne es läuft aller Verkehr über das öffentliche Netz (Ceph: Netzwerk-Konfiguration). Läuft Ceph in Proxmox, kommen die Vorgaben aus Proxmox Support hinzu.
- Daemons über viele Hosts verteilen
- Betriebssystem und jeden OSD auf eigene Datenträger legen
- Bei HDD-OSDs WAL und DB auf SSD verlagern
- Monitor-Datenbanken und Metadaten auf Enterprise-SSDs
- Im Produktivbetrieb Datenträger mit Schutz gegen Stromausfall
- Bandbreite für Client-Verkehr plus Replikation und Wiederherstellung
- Links über zwei Switches bündeln
- Management- und BMC-Verkehr in ein eigenes Netz
10Projektablauf
Vom Lastprofil zum getesteten Cluster
- 01
Anforderungen
Workloads, Kapazität, Wachstum, Leistung (IOPS, Latenz, Durchsatz), Verfügbarkeitsziele.
- 02
Auslegung
Knoten, Medien, Netz, Failure Domains, Replikation, Kapazitätsrechnung wie oben.
- 03
Aufbau und Härtung
Zugriff über benannte Ceph-Benutzer mit minimalen Rechten, Management-Netz getrennt; Verschlüsselung von Daten im Ruhezustand und auf dem Transportweg wird je Anforderung entschieden.
- 04
Validierung
Ausfalltest (Datenträger, Host, Netz), Wiederherstellung unter Last, Leistungsmessung mit Ihrem Lastprofil. Die Dokumentation rät selbst, vor dem Kauf zu benchmarken.
- 05
Inbetriebnahme und Betrieb
Integration mit Proxmox, Kubernetes (über CSI) und S3-Clients klären wir im Projekt.
11Betrieb
Was im laufenden Cephbetrieb anfällt
-
Monitoring
Das Manager-Modul
prometheusstellt Ceph-Zähler für Prometheus bereit (Ceph: Prometheus-Modul); wir alarmieren auf Gesundheitszustand, Füllstand, Wiederherstellungsfortschritt, Scrub-Probleme und Latenzen. -
Erweiterung und Austausch
OSDs und Hosts hinzufügen und entfernen, Rebalancing steuern; Updates mit Cephadm, das laut Dokumentation Ceph von einem Point-Release zum nächsten sicher aktualisieren kann (Ceph: Cephadm).
-
Störungsbearbeitung
Health-Warnungen (Ceph: Health Checks) einordnen, Ursache finden, Wiederherstellung begleiten.
-
Zugriffsverwaltung
Ceph-Benutzer und Berechtigungen je Anwendung.
Replikation ist kein Backup
Löschen oder Beschädigung durch Anwendungsfehler werden von Ceph mitrepliziert. Sicherungen konzipieren wir getrennt, siehe Backup und Disaster Recovery.
12Ihr Beitrag
Das brauchen wir von Ihnen
- Hardware und Rechenzentrumsumgebung, Netzwerkanbindung
- Lastprofile und Wachstumsplanung
- Entscheidung über Verfügbarkeitsziele und Standorte
13Abgrenzung
Was SKAFFON bei Ceph übernimmt und was nicht
Das leisten wir
- Planung, Aufbau und Validierung des Clusters
- Betrieb auf Wunsch, rund um die Uhr (24/7)
Das gehört nicht dazu
- Hardware und Rechenzentrumsfläche: die stellen Sie oder Ihr Hosting-Anbieter
- Herstellersupport für Ceph selbst: den leistet SKAFFON nicht; er wäre über einen Anbieter einer kommerziellen Ceph-Distribution zu beziehen
- Ein fertiges, verwaltetes Objektspeicher-Produkt eines Anbieters
Welchen Ceph-Cluster brauchen Sie?
Beschreiben Sie Ihre Anforderungen (Kapazität, Leistung, Standorte) in einer Projektanfrage. Die Reaktionszeiten je Prioritätsstufe ergeben sich aus dem Servicelevel-Modell unter Managed Services und werden je Vertrag vereinbart.