Ihr 25GbE-Traum knallt gegen eine Wand: Die brutale Wahrheit über meinen 3-Node-Ceph-Cluster
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. Schnell.
Do You Really Need a 10Gb Network for Proxmox Ceph?
Zumindest sollte es so sein.
Dann kamen die Benchmark-Zahlen zurück.
Bandbreite: 2756 MB/sec.
IOPS: 689.
Durchschnittliche Latenz: 23ms.
Und plötzlich fühlte sich das glänzende 25Gb-Netzwerk gar nicht mehr so glänzend an.
Das war kein Produktivsystem. Es war ein Lernlabor. 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: Es hätte schreien müssen
Hier ist die Hardware:
- 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? Das Ding sollte 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. 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 das ist 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“. Es ist 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. Mehr OSDs hinzufügen. Mehr Nodes hinzufügen. Die Last breiter verteilen. 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. Die Daten haben nirgends Platz, sich zu verstecken.
Das ist nicht Ceph, das langsam ist.
Das ist Ceph, das ehrlich ist.
Die IOPS-Angst
Was einen Kommentator wirklich erschreckte, war nicht die Bandbreite. Es waren die IOPS.
689 IOPS im Durchschnitt.
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 seien wir ehrlich: 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. Durch Konsens. Durch Absicherung.
Man bekommt keine NVMe-Marketingzahlen in einem replizierten Cluster. Man bekommt Haltbarkeit. Man bekommt Fehlertoleranz. Man bekommt Überleben.
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 nicht „nah dran“. Man ist da.
Ein Kommentator machte einen praktischen Vorschlag: 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? Jetzt wird es interessant.
ECMP kann Traffic über mehrere Links verteilen. LAG kann auch funktionieren, aber es wird bei manchen Geräten jenseits von zwei Ports seltsam. Plötzlich benchmarkt man nicht mehr nur Storage — man 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: Switch oder Full-Mesh-Netzwerk?
Dann kam der Vorschlag: NVMe auf 4K-Blockgröße neu 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.
Aber NVMe-Laufwerke neu zu formatieren ist 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. 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 vs. 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. Er ist sauber. Er ist kontrolliert. Er sieht nicht aus wie VM-Traffic. Er sieht nicht aus wie Datenbanken. Er sieht nicht aus wie 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. Vielleicht existiert dieses „Limit“ nur in Lab-Stresstests.
Diese Perspektive zählt.
Verteilter Storage ist nicht „schlecht“. Er ist teuer.
Es gab einen Moment in der Diskussion, in dem jemand im Grunde fragte:
Ist verteilter Storage wirklich so schlecht?
Er ist nicht schlecht.
Er ist teuer.
Nicht nur finanziell. 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.
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 diese Phase — in der man alles hinterfragt — ist die, in der sich tiefes Verständnis bildet.
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 hinzufügen? Die Performance steigt, weil sich die Replikation breiter verteilt und die aggregierte Bandbreite wächst.
Mehr Links hinzufügen? Man durchbricht die Single-Link-Obergrenze.
Blockgröße und Alignment tunen? Man kann eventuell zusätzliche Effizienz herauskitzeln.
Aber nichts hier schreit „kaputt“.
Es schreit „Physik“.
Die harte Wahrheit über „Overkill“-Labs
Es hat etwas Demütigendes, zu erkennen, dass Ihr „überdimensioniertes“ Lab bereits ausgereizt ist.
Sie dachten, 25Gb wäre riesig. Es ist nicht unendlich.
Sie dachten, Enterprise-NVMe bedeutet absurde Cluster-Zahlen. Es hebelt die Replikationsmathematik nicht aus.
Sie dachten, drei Nodes wären ernsthafte Skalierung. Es ist die Startlinie.
Das ist kein Scheitern.
Das ist ein verteiltes System, das den Vorhang zurückzieht.
Der eigentliche Gewinn
Hier ist der Teil, der zählt:
Der Cluster ist stabil.
Die Bandbreite ist konsistent.
Die Latenz ist nicht chaotisch.
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. 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? Genau das macht es süchtig.