Ceph vs. ZFS: wann was im Mittelstand

In nahezu jedem Proxmox-Projekt im Mittelstand stellt sich früher oder später dieselbe Grundsatzfrage: Ceph oder ZFS? Beide Lösungen sind ausgereift, beide sind Open Source, beide laufen nativ auf Proxmox VE 8.x. Trotzdem unterscheiden sich die Konzepte fundamental — und damit auch die Anforderungen an Hardware, Netzwerk und Betrieb. Wer hier eine Fehlentscheidung trifft, zahlt am Ende doppelt: einmal in Hardware, einmal in Betriebsaufwand.

Dieser Artikel liefert eine Entscheidungsmatrix für den typischen SMB-Anwendungsfall — drei bis fünf Hypervisor, 10 bis 50 VMs, ein oder zwei Standorte. Wir vergleichen die Architekturen, zeigen, wann welcher Ansatz technisch und wirtschaftlich sinnvoll ist, und beleuchten die Stolperfallen, die im Datenblatt nicht stehen.

Zwei grundverschiedene Konzepte

ZFS und Ceph beantworten zwei unterschiedliche Fragen. ZFS ist ein Dateisystem mit integriertem Volume-Manager, das auf einem einzelnen Host läuft. Es kombiniert Block-Layer, RAID, Snapshots, Komprimierung und Verschlüsselung in einem hochintegrierten Stack. Ceph hingegen ist ein verteilter Object Store, der mehrere Nodes zu einem einzigen Storage-Pool zusammenfasst — mit Redundanz über Hosts hinweg statt nur über Platten.

Eigenschaft	ZFS	Ceph
Architektur	Single-Host, lokal	Scale-out, verteilt
Redundanz	Über Platten (Mirror, RAIDZ)	Über Hosts (Replikation, EC)
Mindest-Nodes	1	3 (besser 4—5)
Shared Storage	Nein (nur per NFS/iSCSI-Export)	Ja (nativ)
Live-Migration in Proxmox	Mit Replikation alle 1—15 Min	Sofort, ohne Verzögerung
HA-Ausfallszenario	Sekunden bis Minuten Datenverlust	Kein Datenverlust
Performance Single-Thread	Sehr hoch	Mittel
Performance verteilt	Limitiert auf einen Host	Skaliert linear mit Nodes
Netzwerk-Anforderung	1—10 GbE	25—100 GbE empfohlen
Mindest-RAM pro Host	8—16 GB für Storage	32—64 GB für Storage
Komplexität Betrieb	Niedrig	Hoch

Diese Tabelle wirkt zunächst eindeutig pro Ceph — bis man auf die Hardware-Anforderungen und die Komplexität im Betrieb schaut.

Wann ZFS die richtige Wahl ist

Für die überwiegende Mehrheit der KMU-Setups ist ZFS die wirtschaftlich und technisch passende Lösung. Konkret immer dann, wenn:

• Sie ein bis drei Hypervisor betreiben und kein massives Wachstum geplant ist
• Ihre Workloads Single-Thread-Performance brauchen — Datenbanken, ERP, Exchange
• Sie knappe Budgets für Storage-Netzwerk haben (10 GbE reicht völlig)
• Ihr Team Linux-affin, aber kein Storage-Spezialist ist
• Ausfallzeiten von wenigen Minuten im Disaster-Fall akzeptabel sind

ZFS in Proxmox ist in einer Stunde produktiv konfiguriert. Ein typischer Pool für einen Hypervisor sieht so aus:

# Mirror aus zwei NVMe für VMs (hoher IOPS-Bedarf)
zpool create -o ashift=12 -O compression=zstd -O atime=off \
  vmpool mirror /dev/nvme0n1 /dev/nvme1n1

# RAIDZ2 aus sechs HDDs für Bulk-Daten und Backups
zpool create -o ashift=12 -O compression=zstd -O atime=off \
  datapool raidz2 sda sdb sdc sdd sde sdf

# Special-VDEV (Metadaten + kleine Blöcke) auf NVMe
zpool add datapool special mirror /dev/nvme2n1 /dev/nvme3n1

Für HA in einem 2-Node-Setup nutzt Proxmox ZFS-Replikation: alle 1 bis 15 Minuten wird ein inkrementeller zfs send auf den zweiten Host übertragen. Im Failover-Fall startet die VM dort mit dem letzten Snapshot — der Datenverlust entspricht dem Replikationsintervall. Für die meisten SMB-Workloads ist das akzeptabel, insbesondere wenn die Applikation selbst (Datenbank-WAL, Filer-Locking) keinen perfekten RPO=0 verlangt.

Wir setzen ZFS auch als Backend für TrueNAS ein — als reine NAS-Appliance, die Proxmox per NFS oder iSCSI versorgt. Das gibt eine saubere Trennung zwischen Compute und Storage, ohne die Komplexität eines verteilten Systems.

Wann Ceph die richtige Wahl ist

Ceph spielt seine Stärken aus, sobald Sie echtes Shared Storage über mehrere Hosts brauchen. Die typischen Indikatoren:

• Vier oder mehr Hypervisor sind im Cluster geplant, weiteres Wachstum absehbar
• Workloads sollen ohne Verzögerung live migrierbar sein (Patch-Windows ohne VM-Stop)
• Sie betreiben Container-Plattformen (Kubernetes, OpenShift) mit dynamischen PVCs
• RPO=0 ist eine harte Anforderung — jeder Schreibvorgang muss redundant sein
• Sie können in 25 GbE oder 100 GbE Cluster-Netzwerk investieren
• Das Betriebs-Team ist bereit, in Ceph-Know-how zu investieren oder kauft externe Expertise dauerhaft ein

Ein Mindest-sinnvolles Ceph-Setup im Proxmox-Cluster sieht so aus:

3 x Proxmox-Node, je:
  - 2x NVMe (OS, ZFS-Mirror)
  - 4-8x NVMe als Ceph-OSDs (je 1.92-3.84 TB Enterprise SSD)
  - 64-128 GB RAM
  - 2x 25 GbE für Ceph-Public/Cluster-Netz, getrennt
  - 2x 10 GbE für VM-Traffic und Management

Die Faustregel für Ceph-RAM: 1 GB pro TB OSD-Kapazität, plus mindestens 4 GB pro OSD-Daemon. Ein Node mit 8 OSDs zu je 3.84 TB braucht also rund 60 GB nur für Storage — VMs kommen oben drauf.

Die Replikation in Ceph erfolgt typischerweise mit size=3, min_size=2. Das bedeutet: drei Kopien jedes Blocks auf drei verschiedenen Nodes, Schreibvorgänge brauchen mindestens zwei bestätigte Repliken. Die nutzbare Kapazität beträgt damit ein Drittel der Brutto-Kapazität. Erasure Coding kann diesen Overhead reduzieren, ist für VM-Workloads in Proxmox aber selten die richtige Wahl.

Die Hardware-Falle

Der häufigste Fehler im Mittelstand ist, Ceph auf Hardware aufzusetzen, die für ZFS geplant war. Symptome zeigen sich erst unter Last:

• Latenzen über 20 ms bei Datenbanken
• “Slow ops” Warnungen im Cluster-Status
• Hohe CPU-Last auf den Nodes durch RocksDB-Kompaktion
• Inkonsistente Performance je nach VM-Verteilung

Konkret problematisch sind: Consumer-SSDs ohne Power-Loss-Protection (führen unter Sync-Writes zu massiver Performance-Degradation), gemeinsame 10 GbE für VM- und Ceph-Traffic, zu wenige OSDs pro Node (mindestens vier sind sinnvoll), und HDDs als Ceph-OSDs ohne separates DB-Device auf NVMe.

Für ZFS dagegen genügt deutlich genügsamere Hardware. Ein Hypervisor mit 64 GB RAM, vier Enterprise-NVMe im RAIDZ2 und 10 GbE ist für 20—30 typische SMB-VMs vollkommen ausreichend.

Performance im Vergleich

Die folgenden Werte stammen aus einem aktuellen DATAZONE-Benchmark mit identischer Server-Hardware (AMD EPYC 9354P, 256 GB RAM, 8x Kioxia CD8-V 3.84 TB NVMe pro Node, 25 GbE Mellanox):

Workload	ZFS Mirror (1 Host)	Ceph 3-Node (size=3)
4K Random Read, 1 Thread	195.000 IOPS	28.000 IOPS
4K Random Read, 64 Threads	410.000 IOPS	1.350.000 IOPS
4K Random Write, 1 Thread	88.000 IOPS	11.000 IOPS
4K Random Write, 64 Threads	195.000 IOPS	720.000 IOPS
Sequential Read, 1 MB	12 GB/s	18 GB/s (aggregiert)
Average Write-Latenz	0,4 ms	1,8 ms

Die Aussage ist eindeutig: Für einzelne, latenzkritische Workloads ist ZFS überlegen. Sobald viele parallele Worker oder verteilte Anwendungen ins Spiel kommen, gewinnt Ceph durch die aggregierte Bandbreite mehrerer Nodes.

Betriebsaufwand und Eskalationspfade

Im Betrieb unterscheiden sich beide Lösungen drastisch. ZFS-Wartung beschränkt sich in der Regel auf monatliche zpool scrub, gelegentliche Disk-Tausche und das Monitoring von SMART-Werten. Ein gut aufgesetzter ZFS-Pool läuft jahrelang ohne Eingriff.

Ceph dagegen ist ein lebendes System, das aktive Pflege braucht: Upgrade-Pfade müssen geplant werden (Monitor vor OSD vor MDS), Rebalancing-Storms nach Node-Ausfällen wollen gesteuert sein, PG-Counts müssen zur Cluster-Größe passen, und im Fehlerfall ist die Diagnose ungleich komplexer. Ein vergessenes ceph osd set noout vor einem Reboot kann eine Stunde Rebalancing auslösen — mit entsprechender VM-Performance-Einbuße.

Realistisch sollten Sie für einen Ceph-Cluster mit mindestens 4 Stunden pro Monat aktiver Wartung rechnen, plus regelmäßiges Patch-Management und Capacity-Planning. Bei ZFS sind es eher 30 Minuten pro Monat. Diese Differenz multipliziert mit dem Stundensatz Ihres Admins ist Teil der Gesamtkosten.

Für Kunden, die Ceph nicht selbst betreiben wollen, übernehmen wir den Betrieb im Rahmen unserer Virtualisierungs-Services inklusive Monitoring, Patch-Management und Eskalation an Proxmox-Enterprise-Support.

Entscheidungsmatrix: kurz und konkret

Ihre Situation	Empfehlung
1—2 Hypervisor, klassisches KMU	ZFS lokal
2 Hypervisor mit HA-Wunsch, RPO 5—15 Min ok	ZFS + Proxmox-Replikation
Zentrales NAS, mehrere PVE-Hosts	TrueNAS mit ZFS, NFS/iSCSI
3+ Hypervisor, RPO=0, Container-Plattform	Ceph (3 Nodes minimum, besser 4—5)
Hochfrequente OLTP-DB, ein Hauptserver	ZFS auf NVMe, dedizierter DB-Host
Wachstum auf 100+ VMs absehbar	Ceph mit klarem Scale-out-Plan
Knappes Budget, kein 25-GbE-Netz	ZFS, Ceph macht hier keinen Sinn

Hybride Setups sind ebenfalls verbreitet: Ceph als Shared Storage für die meisten VMs, ZFS lokal für eine latenzkritische Datenbank-VM, die explizit gepinnt wird. Auch das Backup-Layout profitiert von ZFS auf dem PBS-Host, selbst wenn die Produktion auf Ceph läuft.

Fazit

Es gibt keine pauschale Antwort auf “Ceph oder ZFS” — aber es gibt klare Indikatoren. ZFS ist die richtige Wahl für 80 Prozent der typischen KMU-Setups: einfach im Betrieb, vorhersehbare Performance, geringe Hardware-Anforderungen. Ceph entfaltet seinen Wert erst, wenn echte Skalierung, Container-Workloads oder RPO=0 gefordert sind — und wenn die Organisation bereit ist, in entsprechende Hardware und Know-how zu investieren.

Die teuerste Variante ist immer die, die zur falschen Anforderung gebaut wurde: Ceph für ein 2-Node-Setup ohne 25 GbE bringt nur Probleme, ZFS für ein 6-Node-Container-Cluster blockiert sinnvolle Workflows. Die richtige Wahl spart in Summe deutlich mehr als die reine Hardware-Differenz.

DATAZONE unterstützt Sie bei der Storage-Architektur Ihrer Proxmox-Umgebung — von der ehrlichen Anforderungs-Analyse über die Auswahl der passenden Hardware bis zum Betrieb von Ceph-Clustern oder ZFS-basierten TrueNAS-Systemen. Wir bauen seit Jahren beide Welten im Mittelstand und kennen die Stolperfallen, die im Hochglanz-Datenblatt fehlen. Sprechen Sie uns an: /kontakt/.