--- title: "Ceph Storage und hochverfügbarer Speicher | SKAFFON" description: "Ceph-Cluster planen und betreiben: Replikation, Failure Domains, Kapazität mit Ausfallreserve, RBD, S3, Monitoring. Mit Entscheidungstabelle und Rechenbeispiel." url: https://skaffon.de/infrastruktur/storage-ceph/ --- ![Server im Rack mit Festplatteneinschüben und leuchtenden Status-LEDs in blauem Licht](/_astro/server-rack-festplatteneinschueben-leuchtenden.DuJLNrgm_1nAkNc.jpg) 1. [Startseite](/) 2. [Infrastruktur](/infrastruktur/) 3. Ceph Storage und hochverfügbare Speicherinfrastruktur 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. [Projekt anfragen](/projekt-anfragen/) [Zur Kapazitätsrechnung](/infrastruktur/storage-ceph/#kapazitaet-ausfallreserve) - RBD für Proxmox und Kubernetes - S3-kompatibler Objektspeicher - Betrieb auf Wunsch rund um die Uhr Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## 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. Wo Ceph eingebettet ist Wo Ceph in einer Proxmox-Umgebung läuft, beschreibt [Proxmox Support, Cluster und Hochverfügbarkeit](/infrastruktur/proxmox/); den Gesamtaufbau einer Plattform [Private Cloud](/infrastruktur/private-cloud/). Schnittstellen ## 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](https://docs.ceph.com/en/latest/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](https://docs.ceph.com/en/latest/rbd/)). - ### 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](https://docs.ceph.com/en/latest/radosgw/)). „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](https://docs.ceph.com/en/latest/cephfs/)). Eignung ## 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](https://docs.ceph.com/en/latest/start/hardware-recommendations/)) - Sie bei drei Knoten ohne Wachstum einen einfachen Speicher suchen: ZFS mit Replikation oder ein externer Speicher kann besser sein Replikation ## 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](https://docs.ceph.com/en/latest/rados/operations/pools/)). - Erasure Coding spart bei großen Beständen Platz, hat aber andere Eigenschaften ([Ceph: Erasure Code](https://docs.ceph.com/en/latest/rados/operations/erasure-code/)) - Es verlangt zusätzliche Planung für Failure Domains, Leistung und Wiederherstellung - Für VM-Disks prüfen wir es besonders kritisch ![Geöffnete Festplatte mit sichtbarer Magnetscheibe und Schreib-Lese-Arm](/_astro/geoeffnete-festplatte-sichtbarer-magnetscheibe.B29YV__f_TY8Fz.jpg) ## So verteilt Ceph ein Objekt auf drei Hosts Replikation mit size 3 und Failure Domain Host. Replikation mit size 3 und Failure Domain Host. Failure 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](https://docs.ceph.com/en/latest/rados/operations/crush-map/)). Die Wahl bestimmt, wie viele solcher Einheiten es mindestens geben muss. __Entscheidungstabelle Failure Domain bei size = 3__ | 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](https://docs.ceph.com/en/latest/rados/configuration/mon-config-ref/)); üblich sind drei. Zwei 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](https://docs.ceph.com/en/latest/rados/operations/stretch-mode/)). 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](https://docs.ceph.com/en/latest/rbd/rbd-mirroring/)). Welches Muster passt, hängt von Ihren Wiederherstellungszielen ab; mehr dazu bei [Backup und Disaster Recovery](/managed-services/disaster-recovery/). Kapazitä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. Größenordnung, nicht Ergebnis Die Schwellen der Füllgrenzen und die tatsächliche Verteilung (Datenträger je Host, Gewichtung) stellen wir im Projekt ein; die Formel zeigt die Größenordnung, nicht Ihr Ergebnis. Hardware und Netz ## Hardware und Netzwerk: was die Ceph-Dokumentation vorgibt Die Ceph-Dokumentation nennt unter anderem die folgenden Prinzipien ([Ceph: Hardware Recommendations](https://docs.ceph.com/en/latest/start/hardware-recommendations/)). Ein getrenntes Cluster-Netz ist optional; ohne es läuft aller Verkehr über das öffentliche Netz ([Ceph: Netzwerk-Konfiguration](https://docs.ceph.com/en/latest/rados/configuration/network-config-ref/)). Läuft Ceph in Proxmox, kommen die Vorgaben aus [Proxmox Support](/infrastruktur/proxmox/) 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 ![Türkisfarbene Glasfaser-Patchkabel in den Anschlüssen eines Patchfelds](/_astro/tuerkisfarbene-glasfaser-patchkabel-anschluessen.eE7BIH-W_Z1cnUmw.jpg) Projektablauf ## Vom Lastprofil zum getesteten Cluster 1. 01 ### Anforderungen Workloads, Kapazität, Wachstum, Leistung (IOPS, Latenz, Durchsatz), Verfügbarkeitsziele. 2. 02 ### Auslegung Knoten, Medien, Netz, Failure Domains, Replikation, Kapazitätsrechnung wie oben. 3. 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. 4. 04 ### Validierung Ausfalltest (Datenträger, Host, Netz), Wiederherstellung unter Last, Leistungsmessung mit Ihrem Lastprofil. Die Dokumentation rät selbst, vor dem Kauf zu benchmarken. 5. 05 ### Inbetriebnahme und Betrieb Integration mit Proxmox, Kubernetes (über CSI) und S3-Clients klären wir im Projekt. Betrieb ## Was im laufenden Cephbetrieb anfällt - ### Monitoring Das Manager-Modul `prometheus` stellt Ceph-Zähler für Prometheus bereit ([Ceph: Prometheus-Modul](https://docs.ceph.com/en/latest/mgr/prometheus/)); 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](https://docs.ceph.com/en/latest/cephadm/)). - ### Störungsbearbeitung Health-Warnungen ([Ceph: Health Checks](https://docs.ceph.com/en/latest/rados/operations/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](/managed-services/disaster-recovery/). Ihr Beitrag ## Das brauchen wir von Ihnen - Hardware und Rechenzentrumsumgebung, Netzwerkanbindung - Lastprofile und Wachstumsplanung - Entscheidung über Verfügbarkeitsziele und Standorte Abgrenzung ## 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](/managed-services/) und werden je Vertrag vereinbart. [Projekt anfragen](/projekt-anfragen/) [Zurück zu Infrastruktur](/infrastruktur/)