PBProduktive Kapazität
3 → ∞Knoten · linear skalierbar
3APIs · Block, File, Object
0Vendor-Lock-in
Drei Schnittstellen, ein Cluster
Was Ceph konkret liefert
Block-Storage für Hypervisor
RADOS Block Device als Disk-Backend für Proxmox VE und KVM. Live-Migration ohne Storage-Move, Thin-Provisioning, Snapshots auf Cluster-Ebene. Standard-Setup für unsere HCI-Cluster.
CephFS — POSIX-Filesystem
Verteiltes POSIX-Dateisystem mit Mount-Punkt auf jedem Client. Ersetzt klassische NAS-Lösungen für File-Server, Home-Verzeichnisse, Media-Asset-Storage. Ideal wenn mehrere Hosts gleichzeitig auf gleiche Files zugreifen müssen.
RADOS Gateway — S3- & Swift-API
S3-kompatibles Objekt-Storage für Backup-Software (Veeam, PBS), eigene Anwendungen, Cloud-Native-Workloads. Inkl. Multi-Tenancy, Versionierung, Object-Lock für ransomware-resistente Sicherungen.
Self-Healing & Replikation
CRUSH-Algorithmus verteilt Daten deterministisch — kein zentraler Metadata-Knoten. Bei Knoten-/Disk-Ausfall recovert der Cluster automatisch in die verbliebenen Knoten. 3 Replicas oder Erasure Coding je nach Workload.
Architektur
Komponenten eines produktiven Ceph-Clusters
MON
Monitor-Daemons (mind. 3, ungerade Anzahl)
Halten den Cluster-Map (welche OSDs leben, wo liegen Daten). Quorum-basiert — Cluster bleibt online, solange Mehrheit der MONs steht. Klein dimensioniert: 4 – 8 Cores, 32 – 64 GB RAM, NVMe für die LevelDB.
OSD
Object Storage Daemons (1 pro Disk)
Die eigentlichen Daten-Träger. Modern Next baut OSDs ausschließlich mit BlueStore — direkter Disk-Access ohne XFS-Overhead. NVMe-OSDs typisch 30 – 40k IOPS, SAS-SSD-OSDs typisch 8 – 15k IOPS. RAM-Faustregel: 4 – 6 GB pro OSD.
MGR
Manager-Daemon (mind. 2, Active/Standby)
Stellt das Web-Dashboard bereit, führt Background-Tasks (Re-Balancing, Scrubbing-Coordination) aus. Plus Prometheus-Exporter für Monitoring. Auf den MON-Nodes kollokierbar.
MDS
Metadata Server (nur für CephFS)
Liefert die POSIX-Filesystem-Semantik. Aktiv-Aktiv-fähig mit Pinning für hohe Lasten. Nur erforderlich, wenn CephFS genutzt wird; reine RBD/RGW-Cluster brauchen keinen MDS.
RGW
RADOS Gateway (für S3/Swift)
HTTP(S)-Frontend für Objekt-Storage. Stateless, beliebig viele Instanzen hinter Loadbalancer. Multi-Site-fähig für DR-Setups (asynchrone Replikation zwischen Rechenzentren).
Leistungsspektrum
Was wir konkret anbieten
Cluster-Design & Sizing
Workload-Analyse, Kapazitäts- und Performance-Plan, Hardware-Stückliste mit konkreten Modellen, Netzwerk-Plan (Front-/Back-Mesh), Failure-Domain-Strategie. Output: vollständige Bauanleitung, die du auch selbst umsetzen könntest.
Aufbau & Inbetriebnahme
Hardware-Beschaffung (oder Vor-Ort-Aufbau auf eurer), OSD-Bootstrapping, Tuning der wichtigsten Parameter (BlueStore, RBD-Cache, min_alloc_size), Monitoring-Anbindung, Backup-Strategie für die Cluster-Konfig.
Migration aus vSAN / NetApp / EMC
Paralleler Aufbau, gestaffelter Cutover je VM-Klasse, Storage-vMotion-basiert oder via Backup/Restore. Typisch für 3-Knoten-vSphere mit 60 VMs: 15 – 25 Engineering-Tage. Rollback-Plan pro Schritt.
Performance-Tuning
Bestehende Cluster auf Out-of-the-box-Settings können oft 2 – 3× schneller laufen. Wir analysieren mit ceph-perf, fio-Profilen und Wireshark, optimieren BlueStore-Cache, Bluestore-DB-Sharding, RBD-Read-Ahead, NUMA-Pinning.
OSD-Lifecycle & Hardware-Wechsel
Disk-Tausch im laufenden Betrieb, Knoten-Refresh ohne Downtime, Erweiterungen mit korrektem Re-Balancing-Throttling. Routine-Vorgang, der bei selbst-gebauten Clustern oft Bauchschmerzen macht.
24/7-Betrieb & Recovery-Drills
Im Rahmen unseres Full IT Service: dokumentierte Runbooks pro Vorfall-Klasse, monatliche Verifikations-Tests, jährliche Notfall-Übung mit eurer Geschäftsleitung. SLA-Reaktionszeiten vertraglich definiert.
Schulung interner Teams
2- bis 5-Tage-Workshops in eurer Test-Umgebung mit echten Operations: OSD-Tausch, Pool-Konfiguration, CRUSH-Map editieren, Recovery-Simulation. Output: euer Team kann den Cluster selbstständig betreiben — wir bleiben Eskalations-Backup.
Health-Check für bestehende Cluster
Eurer Cluster läuft, aber niemand weiß ob er gut läuft? Wir kommen 1 – 2 Tage rein, analysieren PG-Verteilung, Latenzen, Recovery-Verhalten, Hardware-Headroom. Output: priorisierter Maßnahmenkatalog plus Sofort-Quick-Wins.
Wann Ceph wirtschaftlich passt: ab ca. 50 TB Nutzdaten oder ab 3 produktiven Hypervisor-Knoten mit gemeinsamem Block-Storage-Bedarf. Darunter ist ZFS auf Einzelknoten oder ein klassisches NAS oft schlanker. Darüber skaliert Ceph linear bis in den Petabyte-Bereich. Konkrete Größenklasse klären wir in 30 Minuten Erstgespräch — kein Magnet für Angebote, die nicht passen.
Praxis-Zahlen
Was Modern-Next-Cluster konkret leisten
| Cluster-Profil | Konfiguration | Performance (gemessen) |
|---|---|---|
| 3-Knoten KMU-HCI | 3 × 6 NVMe-OSDs, 25 GbE-Mesh, 256 GB RAM/Knoten | Random-Read 4k: 280k IOPS · Sequential-Write: 8 GB/s |
| 5-Knoten Behörden-HCI | 5 × 12 NVMe-OSDs, 100 GbE-Mesh, 512 GB RAM/Knoten | Random-Read 4k: 1.2M IOPS · Latenz P99: 1.4 ms |
| Backup-Cluster (S3 via RGW) | 4 × 24 SAS-SSD-OSDs, 25 GbE, Erasure 8+3 | Sustained Write: 4.2 GB/s · Object-Locked Aufbewahrung: 5 Jahre |
| Healthcare-DICOM-Pool | 3 × 4 NVMe-Hot + 8 SAS-Warm, dual-Pool | DICOM-Latenz Median: 45 ms (vorher SAN: 230 ms) |
Vergleich
Wann Ceph — wann was anderes?
| Storage-Anforderung | Empfehlung | Warum |
|---|---|---|
| Single-Server, < 20 TB | ZFS | Kein Cluster-Overhead, einfacheres Operations-Modell |
| 2-Knoten-Cluster, < 50 TB | ZFS-Replication oder DRBD | Ceph braucht 3 Knoten Mindest für Quorum |
| 3+ Knoten, mixed Workload | Ceph (RBD) | Linear skalierbar, kein zentraler Hotspot |
| Petabyte-Object-Store | Ceph (RGW) | S3-API, Multi-Site-Replikation, Object-Lock |
| Gemeinsamer File-Server | CephFS oder klassisches NAS | NAS einfacher bei kleinen Setups, CephFS bei verteilten |
| Strict-Latenz unter 0.5 ms | Lokales NVMe + Application-Sharding | Verteilte Storages haben Netzwerk-Latenz im Pfad |
FAQ
Häufige Fragen zu Ceph
Wirtschaftlich ab ca. 50 TB Nutzdaten oder ab 3 produktiven Hypervisor-Knoten mit gemeinsamem Block-Storage-Bedarf. Unterhalb dieser Größe ist ZFS auf einzelnen Knoten oder ein klassisches NAS oft die schlankere Lösung. Oberhalb skaliert Ceph linear bis in den Petabyte-Bereich.
Drei bis sieben Knoten mit Dual-Socket-Xeon oder EPYC, 128 – 512 GB RAM, 6 – 12 NVMe-OSDs pro Knoten. Cluster-Mesh auf 25 GbE oder 100 GbE für die Storage-VLAN, getrennt vom Frontend-Traffic. Mindestens drei Monitor-Nodes (oft auf den OSD-Nodes mit kollokiert). Konkrete Sizing-Tabelle nach Workload-Klärung.
In sauber abgestimmten Setups vergleichbar bis besser. Out-of-the-box mit Default-Settings ist Ceph oft langsamer als vSAN — der Unterschied liegt im Tuning. BlueStore-DB auf separater NVMe, RBD-Cache, min_alloc_size auf 4k, korrekte CPU-Pinning bringen Ceph in unseren Setups auf ca. 30 – 40k IOPS pro NVMe-OSD. Zahlen aus konkreten Modern-Next-Clustern.
Ceph erkennt den Ausfall innerhalb weniger Sekunden und beginnt automatisch das Re-Replikat fehlender PGs auf die verbliebenen Knoten — der Cluster bleibt online und schreibbar. Bei drei Replicas und N=3-Knoten überlebt der Cluster den Ausfall eines kompletten Knotens ohne Datenverlust. Wichtig: Hardware-Reserve (mind. 33 % Headroom) muss von Anfang an eingeplant sein, sonst läuft der Recovery in eine volle Disk.
Ja. Im Rahmen unseres Full IT Service betreuen wir Ceph-Cluster mit 24/7-Monitoring, dokumentierten Recovery-Runbooks, monatlichen Verifikations-Tests und proaktivem Capacity-Planning. SLAs werden vertraglich festgelegt — typische Reaktionszeit für High-Severity-Issues ist 1 Stunde bei Premium-Kunden.
Ja, das ist eine unserer häufigsten Migrationen seit Broadcom 2024. Ablauf: paralleler Aufbau, Schatten-Replikation der VM-Disks per Storage-vMotion auf einen Ceph-Übergangs-Pool, gestaffelter Cutover je VM-Klasse. Typischer Aufwand für 3-Knoten-vSphere-Cluster mit 60 VMs: 15 – 25 Engineering-Tage. Hardware kommt obendrauf, je nachdem ob ihr Bestandshardware übernehmt oder neu beschafft.
Ceph soll funktionieren, nicht experimentell sein.
30 Minuten Erstgespräch zur Größeneinordnung — Workload, Knotenzahl, Performance-Anforderung, Budget. Danach wisst ihr, ob Ceph passt, was es kostet und wie ein realistischer Zeitplan aussieht. Auch wenn die Antwort heißt: für eure Größe ist es Overkill.