Wo mein 3-Node-Ceph-Cluster auf 25GbE an seine Grenze stößt

Ich habe mir etwas hochgezogen, das auf dem Papier wie ein Monster wirkte: ein Drei-Node-Proxmox-Cluster, vier NVMe-OSDs pro Node, alle Enterprise-Grade. Separate 25Gb-NICs und Switches für öffentlichen und privaten Ceph-Traffic. Sauber, überdimensioniert und schnell, so jedenfalls der Plan.

Dann kamen die Benchmark-Zahlen zurück: 2756 MB/sec Bandbreite, 689 IOPS, 23ms durchschnittliche Latenz. Und plötzlich fühlte sich das glänzende 25Gb-Netzwerk gar nicht mehr so glänzend an.

Das war kein Produktivsystem, nur ein Lernlabor und eine Spielwiese. Aber wenn man echtes Geld für NVMe-Laufwerke und 25Gb-Networking ausgibt, erwartet man Feuerwerk. Stattdessen bekam ich eine Obergrenze. Und die Kommentare rollten an.

Das Setup, das hätte schreien müssen

Die Hardware im Cluster:

• 3x MS-02 Ultra 285HX Nodes
• 64GB DDR5 5600 pro Node
• 4x Micron 7450 Pro NVMe-Laufwerke pro Node
• PCIe Gen4
• Dual 25Gb-Networking (getrennte Public- und Cluster-Netzwerke)

Auf dem Papier sollte das Ding fliegen. Der Schreibtest wurde ausgeführt mit:

Coderados bench -p ultra-pool 20 write -t 16 --object_size=4MB --no-cleanup

Und das Ergebnis war konsistent, etwa 2,7 bis 2,8 GB/sec. Nicht sprunghaft, nicht instabil, einfach gedeckelt.

Eine Antwort brachte es unverblümt auf den Punkt: Sie stoßen an das Netzwerklimit. Ein anderer Nutzer rechnete es laut vor, fast 3 GBytes/sec sind etwa 24 Gbit, und das ist praktisch ausgereiztes 25GbE. Es tut weh, wenn es jemand anderes sagt, denn tief im Inneren weiß man es bereits.

„Ceph glänzt in großem Maßstab“, und genau da liegt der Haken

Eine der ersten Antworten schnitt durch das Rauschen:

Schwer zu sagen. Aber ich würde sagen, es liegt an der geringen Größe des Clusters. Ceph glänzt in großem Maßstab. 3 Nodes sind das absolute Minimum.

Das ist der Teil, den Leute nicht immer hören wollen. Drei Nodes sind kein „Cluster“, sie sind der minimal lebensfähige Cluster, der Punkt, an dem Ceph gerade erst anfängt, Ceph zu sein.

Verteilter Storage spielt seine Muskeln erst aus, wenn man ihm Raum zum Atmen gibt, also mehr OSDs, mehr Nodes und eine breiter verteilte Last. Dann beginnt echte Parallelität sichtbar zu werden. Mit nur drei Nodes ist man eingesperrt: Replikations-Traffic pendelt zwischen denselben Maschinen, Netzwerksättigung zeigt sich schnell, und die Daten haben nirgends Platz, sich zu verstecken. Das ist nicht Ceph, das langsam ist, das ist Ceph, das ehrlich ist.

Die IOPS-Angst

Einen Kommentator erschreckten am meisten die IOPS, 689 im Durchschnitt, und nicht die Bandbreite.

Jemand meldete sich zu Wort und sagte, aus seinen SAS-SSDs bekomme er ungefähr 127 IOPS heraus, im Vergleich sieht das hier also besser aus. Aber das sind Micron 7450 Pro NVMe-Laufwerke, lokal können sie absurde Zahlen liefern. Warum sieht verteilter Storage also so gewöhnlich aus?

Weil das kein lokaler Storage ist. Es ist keine einzelne NVMe, die über PCIe mit einer CPU spricht. Es ist:

• Client-Schreibvorgang
• Netzwerk-Hop
• Primärer OSD-Schreibvorgang
• Replika-OSD-Schreibvorgang(-vorgänge)
• Bestätigungskette
• Journaling
• Commit

Jedes 4MB-Objekt durchläuft eine Zeremonie aus Konsens und Absicherung. Man bekommt keine NVMe-Marketingzahlen in einem replizierten Cluster, man bekommt Haltbarkeit, Fehlertoleranz und Überleben. Und dafür gibt es einen Preis.

Ist 25GbE der Bösewicht?

Reden wir über das Netzwerk. 25GbE klingt schnell, und das ist es auch, bis man anfängt, mehrere 4MB-Objekte über Replikations-Streams zu schieben. Bei ~2,8 GB/sec sättigt man praktisch einen 25Gb-Link, wenn man den Overhead einrechnet. Man ist dann nicht nah dran, man ist da.

Ein Kommentator machte einen praktischen Vorschlag, nämlich LAG oder ECMP:

Einzelne Streams überschreiten nicht 25Gb. Aber man kann problemlos 50Gb pro Sekunde fahren.

Das ist die Feinheit. Ein einzelner TCP-Stream überschreitet nicht auf magische Weise 25Gb, aber mehrere Flows über mehrere Ports ändern das Bild. ECMP kann Traffic über mehrere Links verteilen, LAG kann auch funktionieren, wird bei manchen Geräten jenseits von zwei Ports aber seltsam. Plötzlich benchmarkt man nicht mehr nur Storage und steckt tief in der Netzwerkarchitektur. So passiert es: Man beginnt mit einem Cluster und landet beim Neudesign der Switching-Fabric.

Das 4K-Blockgrößen-Kaninchenloch

Dann wurde es interessanter. Jemand fragte, ob Switch oder Full-Mesh-Netzwerk, und dann kam der Vorschlag, die NVMe auf 4K-Blockgröße neu zu formatieren. Das ist der Moment, in dem man weiß, dass man offiziell im Unkraut steckt.

Die Micron-7450-Laufwerke laufen möglicherweise mit 512e statt nativem 4Kn. Diese Diskrepanz kann Performance kosten, besonders in verteilten Storage-Systemen, denen Alignment sehr wichtig ist.

NVMe-Laufwerke neu zu formatieren ist aber keine Kleinigkeit, man klickt nicht einfach einen Button. Man:

• Entfernt ein OSD
• Wartet auf das Rebalancing
• Formatiert das Laufwerk neu
• Fügt es als neues OSD wieder hinzu
• Wartet auf das Rebalancing
• Wiederholt das Ganze

Langsam und sorgfältig, eine Platte nach der anderen. Das ist nicht nur Tuning, das ist Chirurgie. Und hier ist die emotionale Realität: Wenn man neu bei Ceph ist, fühlt sich schon die Frage, ob man den gesamten Cluster neu aufsetzen muss, überwältigend an. Man will nicht das Lab in die Luft jagen, das man gerade erst gebaut hat. Aber so lernt man.

Benchmarks gegen Realität

Eine weitere vernünftige Stimme meldete sich zu Wort:

Der beste Benchmark ist wahrscheinlich Ihre tatsächliche Workload oder ein fio-Benchmark, der Ihrer Workload ähnelt.

Das ist die unbequeme Wahrheit über Storage-Benchmarks. rados bench ist synthetisch, sauber und kontrolliert, und er sieht weder aus wie VM-Traffic noch wie Datenbanken oder Backups.

Man kann Benchmark-Zahlen ewig hinterherjagen, oder man kann fragen: Bewältigt das, was ich tatsächlich betreiben will? Wenn Ihre Workload 25Gb nicht sättigt, sind Sie im echten Leben vielleicht gar nicht limitiert, und dieses „Limit“ existiert nur in Lab-Stresstests. Diese Perspektive zählt.

Warum verteilter Storage teuer ist

Es gab einen Moment in der Diskussion, in dem jemand im Grunde fragte, ob verteilter Storage wirklich so schlecht sei. Schlecht ist er nicht, er ist teuer, und zwar nicht nur finanziell, auch architektonisch.

Sie tauschen:

• Rohe lokale NVMe-Geschwindigkeit

gegen

• Redundanz
• Selbstheilung
• Datenverteilung
• Node-Ausfalltoleranz

Ceph ist nicht darauf ausgelegt, Einzellaufwerk-Benchmarks zu gewinnen. Es ist darauf ausgelegt, zu überleben, wenn um 2 Uhr nachts ein Node stirbt, ohne dass Sie es bemerken, und das ist die eigentliche Performance-Kennzahl.

Die Anfängerphase ist die beste Phase

Ein Kommentar blieb mir im Gedächtnis:

Neu bei alldem, aber es hat bisher Spaß gemacht zu lernen.

Das ist die Energie, die zählt, denn in dieser Phase, in der man alles hinterfragt, bildet sich tiefes Verständnis. Warum skaliert Ceph mit Nodes? Warum verstärkt Replikation die Netzwerklast? Warum ist Blockgrößen-Alignment wichtig? Warum verändert ECMP die Durchsatzcharakteristik? Man versteht verteilte Systeme erst wirklich, wenn sie einen enttäuschen. Dann fängt man an, an den Fäden zu ziehen.

Was passiert hier eigentlich?

Zoomen wir raus:

• ~2,7 GB/sec Schreibbandbreite
• ~24 Gbit/sec effektiver Durchsatz
• 25Gb-Netzwerk
• 3-Node-replizierter Cluster
• 4MB-Objekte
• 16 Threads

Das ist beinahe Lehrbuch-Netzwerksättigung. Die Laufwerke sind nicht der Engpass, PCIe Gen4 ist nicht der Engpass, die CPUs (285HX) ringen nicht nach Luft. Die Fabric ist es, und mit nur drei Nodes gibt es begrenzte horizontale Skalierung.

Mehr Nodes bringen mehr Performance, weil sich die Replikation breiter verteilt und die aggregierte Bandbreite wächst. Mehr Links durchbrechen die Single-Link-Obergrenze. Tuning von Blockgröße und Alignment kitzelt eventuell zusätzliche Effizienz heraus. Nichts davon schreit „kaputt“, es schreit „Physik“.

Wenn das überdimensionierte Lab schon ausgereizt ist

Es hat etwas Demütigendes, zu erkennen, dass Ihr überdimensioniertes Lab bereits ausgereizt ist. Sie dachten, 25Gb wäre riesig, aber unendlich ist es nicht. Sie dachten, Enterprise-NVMe bedeutet absurde Cluster-Zahlen, aber es hebelt die Replikationsmathematik nicht aus. Sie dachten, drei Nodes wären ernsthafte Skalierung, dabei sind sie die Startlinie. Gescheitert ist hier nichts, es ist ein verteiltes System, das den Vorhang zurückzieht.

Der eigentliche Gewinn

Der Teil, der zählt: Der Cluster ist stabil, die Bandbreite ist konsistent, die Latenz ist nicht chaotisch, und das System verhält sich vorhersehbar. Vorhersehbarkeit ist Gold im Storage. Sie haben keinen Fehler entdeckt, Sie haben ein Limit entdeckt, und Limits sind der Punkt, an dem echte Architekturentscheidungen beginnen.

Werden Sie:

• Nodes hinzufügen?
• Netzwerk-Links hinzufügen?
• Auf 100Gb umsteigen?
• OSD-Einstellungen tunen?
• Die Replikation ändern?
• Die Obergrenze akzeptieren?

Das ist keine Benchmark-Frage mehr, das ist Design.

Drei Nodes, zwölf NVMe-Laufwerke, 25GbE und fast 3 GB/sec Schreibgeschwindigkeit. Kein Scheitern, nur der Moment, in dem man erkennt, dass verteilter Storage sich nicht um Ihre Erwartungen kümmert, nur um Ihre Topologie. Und ehrlich gesagt macht genau das süchtig.