Ceph ist grandios. Nur selten wirtschaftlich

In der IT wird oft blind der Enterprise-Standard gekauft, weil die Entscheidung auf dem Papier sicher wirkt. Niemand wurde je dafür kritisiert, Ceph vorgeschlagen zu haben. Aber Budgets schützt man nicht mit Buzzwords, sondern mit Ressourcenplanung, die zum tatsächlichen Zuschnitt passt.

Ceph ist ein hervorragendes System. Es skaliert über Racks und Standorte, es heilt sich selbst, es kennt keine Forklift-Upgrades, und mit Erasure Coding senkt es die Speicherkosten gegenüber klassischer Replikation deutlich. Es lässt sich hyperkonvergent auf vorhandenen GPU-Nodes mitfahren, und das Netzwerk profitiert davon, dass Clients Anfragen direkt an den zuständigen Node stellen statt über einen zentralen Kopf zu laufen.

Genau diese Mechanismen haben aber eine Eintrittsschwelle. Sie sind nicht optional dazuschaltbar, sie sind die Architektur. Wer ein Projekt darauf zwingt, das die Skalierung nie braucht, kauft die vollständige Mechanik und ruft davon nichts ab. Die Kosten für Hardware, Strom und vor allem für die fortlaufende Administration laufen trotzdem weiter.

Ceph verteilt Daten nicht über Platten, sondern über Fehlerdomänen. Im Standard-CRUSH-Ruleset ist diese Domäne der Host. Das ist die entscheidende Zahl, denn daraus folgt direkt, wie viele komplette Server du kaufen musst, bevor das System überhaupt seinen Zweck erfüllt.

Dazu kommt das Monitor-Quorum: MONs entscheiden per Mehrheit über den Cluster-Zustand. Zwei MONs sind schlechter als einer, weil der Ausfall eines einzelnen das Quorum bereits zerstört. Produktiv sind es deshalb immer mindestens drei.

Die Rechnung für Erasure Coding ist unerbittlich: Ein Profil mit k Daten- und m Paritäts-Chunks verlangt mindestens k+m Fehlerdomänen, damit jeder Chunk auf einem eigenen Host liegt. Für einen sinnvollen Betrieb willst du mindestens eine Domäne mehr, sonst kann der Cluster nach einem Host-Ausfall nicht rekonstruieren, sondern nur noch ausliefern.

Damit ist der oft gehörte Satz „mit Erasure Coding wird Ceph günstig" für kleine Umgebungen entwertet. Die guten Effizienzwerte beginnen bei sechs Hosts. Wer bei drei Nodes bleibt, hat entweder 33 % Nutzkapazität durch dreifache Replikation oder ein k=2,m=1-Profil, das exakt einen Host-Ausfall verträgt und beim Rebuild den halben Cluster durchs Netz zieht.

# Profil anlegen. Ohne genug Hosts bleiben die PGs dauerhaft in incomplete.
ceph osd erasure-code-profile set ec42 k=4 m=2 crush-failure-domain=host

# Gegenprobe vor dem Kauf: reichen die Fehlerdomänen ueberhaupt?
ceph osd tree
ceph osd erasure-code-profile get ec42

Die Node-Anzahl ist der sichtbare Teil. Teuer wird Ceph an drei Stellen, die in der ersten Kalkulation selten auftauchen.

Netzwerk

Ceph repliziert im Hintergrund. Jeder Write mit size=3 erzeugt zwei zusätzliche Übertragungen, jeder Host-Ausfall löst ein Recovery aus, das so schnell läuft, wie das Netz es zulässt. Empfohlen sind getrennte Public- und Cluster-Netze, praktisch bedeutet das 25 GbE aufwärts und redundante Switches. Bei drei Nodes finanzierst du damit eine Switch-Infrastruktur, deren einziger Zweck es ist, Kopien zwischen drei Gehäusen zu schieben, die im selben Rack stehen.

RAM

BlueStore reserviert per Default rund 4 GiB pro OSD (osd_memory_target). Ein Node mit zwölf Platten bindet also allein für die OSDs etwa 48 GiB, bevor MON, MGR und im CephFS-Fall die MDS dazukommen. Auf einem dedizierten Storage-Node ist das eingeplant. Auf einem hyperkonvergenten GPU-Node konkurriert es mit genau dem RAM, für den du die Maschine gekauft hast.

Administration

Das ist der Posten, der die Rechnung entscheidet, und der einzige, der nach der Beschaffung immer weiterläuft. Ceph braucht Kompetenz im Haus: PG-Autoscaling verstehen, CRUSH-Maps lesen, Upgrades in der richtigen Reihenfolge fahren, Near-Full-Zustände abfangen, Recovery-Throttling gegen Client-Latenz abwägen. Nichts davon ist exotisch, aber alles davon ist Aufwand, der bei einem einzelnen ZFS-Pool schlicht nicht existiert.

Nehmen wir einen realistischen Fall aus dem Mittelstand: 150 TB nutzbar, als Backup-Ziel und Scratch-Layer für einen lokalen GPU-Cluster. Kein Multi-Rack-Ausbau geplant, kein S3-Angebot an Dritte, keine mandantenfähige Plattform.

Wichtig ist die Struktur, nicht die Nachkommastelle. Selbst wenn man die Hardware-Seite großzügig zugunsten von Ceph rechnet, bleibt der Administrationsblock. Er ist der Grund, warum sich ein Scale-out-System auf einem Zuschnitt, der nie skaliert, nicht amortisiert.

Für stark fokussierte Umgebungen bauen wir extrem dichte Architekturen auf einzelnen Servern. Die Datenmasse tragen hochkapazitäre HDDs im RAIDZ2, die Zugriffsmuster fängt eine NVMe-Schicht ab. Der entscheidende Baustein ist das Special vdev: Es nimmt Metadaten und alle Blöcke unterhalb einer definierten Schwelle auf.

# 2 x raidz2 aus 20-TB-HDDs, dazu ein gespiegeltes Special vdev auf NVMe
zpool create tank \
  raidz2 /dev/disk/by-id/ata-HDD_{01..06} \
  raidz2 /dev/disk/by-id/ata-HDD_{07..12} \
  special mirror /dev/disk/by-id/nvme-NVME_01 /dev/disk/by-id/nvme-NVME_02

# Metadaten plus alles unter 32K landen auf Flash
zfs set special_small_blocks=32K tank/backup

Damit verschiebt sich das Lastprofil grundlegend. Verzeichnis-Traversierungen, rsync-Scans und die vielen kleinen Zugriffe interner Datenbanken treffen nicht mehr die Platten, sondern NVMe. Aus den 120 bis 200 IOPS, die ein RAIDZ-vdev physikalisch liefert, werden zehntausende IOPS bei Flash-Latenz, ohne dass die Kapazität teurer wird.

Dazu kommt der Schreibpfad. ZFS sammelt Writes im RAM zu Transaction Groups und schreibt sie gebündelt als große, sequenzielle Blöcke auf die vdevs. Viele kleine, verstreute Schreibzugriffe werden so zu wenigen großen. In Kombination mit dem Special vdev, das die Metadaten-Updates komplett abfängt, sinkt die mechanische Belastung der HDDs deutlich, und das verlängert ihre Lebensdauer spürbar.

Der wirtschaftliche Effekt: Ein einzelnes Gehäuse liefert die Kapazität, die im Ceph-Entwurf drei Gehäuse gebraucht hätten, plus eine IOPS-Charakteristik, die für Backup-Ziele und GPU-Scratch mehr als ausreicht. Das Geld, das nicht in Redundanzmechanik fließt, steht für Rechenleistung zur Verfügung.

Ja. Ein einzelner Server ist eine einzelne Fehlerdomäne, und wer das verschweigt, verkauft genauso unsauber wie derjenige, der pauschal Ceph anbietet. Die Frage ist nicht, ob ein SPOF existiert, sondern ob die geforderte Wiederanlaufzeit ihn erlaubt.

Für ein Backup-Ziel ist eine RTO von Stunden fast immer akzeptabel, denn das System ist per Definition die zweite Kopie. Für GPU-Scratch ebenfalls, weil die Daten reproduzierbar sind. Genau in diesen Fällen kauft man mit Ceph eine Verfügbarkeitsklasse, die niemand angefordert hat, und bezahlt sie fünf Jahre lang.

Umgekehrt gilt: Wenn die Anforderung tatsächlich unterbrechungsfreier Betrieb über mehrere Fehlerdomänen ist, dann ist ein einzelner ZFS-Server die falsche Antwort. Dann ist die Diskussion beendet, und die Node-Anzahl aus Abschnitt 02 ist schlicht der Eintrittspreis.

Die Entscheidung lässt sich auf wenige Fragen reduzieren. Sobald zwei davon klar auf Ceph zeigen, ist Ceph richtig, und zwar ohne Wenn und Aber.

Die letzte Zeile ist die, die am häufigsten unterschätzt wird. Ceph erlaubt es, einzelne OSDs und Nodes im laufenden Betrieb hinzuzufügen, ohne den Pool anzufassen. ZFS verlangt, dass man beim vdev-Layout vorher nachdenkt. Wer echtes, unvorhersehbares Wachstum hat, kauft mit Ceph nicht Redundanz, sondern Planungsfreiheit, und die ist ihr Geld wert.

Konkret, damit die Diskussion nicht abstrakt bleibt. Das ist die Konfiguration, die wir für Backup-Ziel plus GPU-Scratch in dieser Größenordnung bauen.

# Belegung des Special vdev im Blick behalten. Laeuft es voll,
# spillen neue Metadaten zurueck auf die HDDs und der Effekt ist weg.
zpool list -v tank

# Inkrementelle Replikation auf das zweite System
zfs snapshot tank/backup@$(date +%Y%m%dT%H%M)
zfs send -I @vorher @jetzt tank/backup | ssh replikat zfs recv -F tank/backup

Die Reihenfolge der Investition ist dabei fast immer dieselbe: erst die Kapazität sauber auslegen, dann das Special vdev, dann RAM, und ein SLOG nur, wenn eine echte Sync-Last nachgewiesen ist. Wer stattdessen mit der Frage „Ceph oder nicht" beginnt, hat die Reihenfolge bereits umgedreht.