Ceph-Skalierung bei 40 GB/s: Von fünf auf sechs Nodes

Storage-Engineers begeistern sich für Details, die außerhalb des Serverraums kaum jemand bemerkt: sinkende Latenzen oder ein Dashboard, auf dem alle Nodes grün leuchten. Man verbringt Wochen mit Planung, Feinabstimmung und Lastanpassungen, beobachtet Diagramme auf dem Weg zu Leistungswerten, die knapp außer Reichweite schienen, und eines Tages fallen die Messwerte plötzlich höher aus als erwartet.

Ein Speichercluster aus fünf Nodes lieferte bereits beeindruckende Durchsatzraten: rund 40 GB/s durchschnittliche Leserate, Schreibspitzen von bis zu 11 GB/s und mehr als 2 Millionen IOPS, während über 30 Clients gleichzeitig direkte Last erzeugten. Das Setup basierte auf AMD EPYC-Systemen mit 200 Gb Netzwerk und Ceph über RBD, getestet mit Direct-I/O. Das waren reale Messwerte von echter Hardware unter Maximallast, keine geschönten Zahlen aus einer Herstellerpräsentation.

Die naheliegende nächste Frage lautete: Was passiert, wenn man weitere Nodes hinzufügt? Es gab keine Störungen und der Speicherplatz ging nicht zur Neige. Wer solche Systeme aufbaut, möchte schlicht wissen, wo das Limit liegt.

Das Ausloten von Grenzen gehört zum Handwerk

Hardware wurde über die Jahre kontinuierlich schneller, Netzwerke machten riesige Sprünge und NVMe verschob die Erwartungen so drastisch, dass traditionelle Storage-Architekturen plötzlich alt aussahen. Reine Durchsatzgeschwindigkeit allein entscheidet heute jedoch kaum noch etwas. Moderne Speichersysteme werden daran gemessen, wie gut sie skalieren. Ein Cluster, der mit fünf Nodes hervorragend läuft, verliert seinen Wert, wenn ein sechster Node Rebalancing-Stürme, Ausfallzeiten, Latenzspitzen oder unerwartete Engpässe auslöst. Wer jemals eine problematische Storage-Erweiterung miterlebt hat, vergisst das nicht so schnell.

Diese Vorgeschichte sorgt für gesunde Skepsis. Eine Gruppe begegnet jeder Skalierungsbehauptung mit Misstrauen, bis sie sich unter realer Belastung bewährt hat, denn Hersteller werben gerne mit glatten Diagrammen, während die Praxis manchmal Nachtschichten und Notreparaturen bereithält. Eine andere Gruppe betrachtet Skalierung bei sauberer Architektur als gelöstes Problem, schließlich wurde verteilter Speicher genau dafür konzipiert: Ressourcen ergänzen, Daten neu verteilen und den Betrieb ohne Unterbrechung fortführen.

Wer bereits viele Cluster aufgebaut hat, positioniert sich dazwischen. Erfahrene Engineers wissen, dass der Erfolg weniger an der Grundsatztechnologie hängt als an Implementierungsdetails, über die erst gesprochen wird, wenn etwas schiefgeht: Netzwerkkonfiguration, Failure Domains, Zugriffsmuster, Placement Groups, Rebalancing-Strategien und homogene Hardware. Diese Stellschrauben entscheiden darüber, ob eine Erweiterung reibungslos verläuft oder im Chaos endet. Genau das machte diesen Test bemerkenswert: Der Cluster wurde erweitert und anschließend maximal gefordert.

Ein System unter Vollast bestehen zu sehen

Infrastruktur gezielt an ihre Leistungsgrenze zu treiben, hat seinen ganz eigenen Reiz. Man schaltet Clients auf, treibt den Durchsatz nach oben, erzeugt intensive Schreiblast und beobachtet die Latenzkurven auf erste Warnsignale.

Dieser Cluster war bereits vor dem Ausbau außerordentlich leistungsfähig. Durchschnittlich vierzig Gigabyte pro Sekunde beim Lesen übersteigen typische Unternehmensumgebungen bei Weitem, und zwei Millionen IOPS verschieben die Maßstäbe grundlegend. Auf diesem Leistungsniveau treten Schwachstellen sofort zutage, ganz gleich, ob es sich um unpassende Hardwarekomponenten, suboptimale Verteilungsregeln oder Kompromisse beim Systemdesign handelt.

Stattdessen verlief der Ausbau nach Berichten beinahe verdächtig reibungslos. Ein sechster NVMe-Node wurde integriert, Ceph verteilte die Daten im Hintergrund neu und glich sie ab, während das Gesamtsystem ohne Ausfallzeit und ohne größere Zwischenfälle weiterlief. Wer darauf konditioniert ist, dass wachsende Infrastruktur unweigerlich Schmerzen verursacht, empfindet einen solchen Verlauf fast als ungewohnt.

Ein Beobachter kommentierte die Situation humorvoll mit der Bemerkung, traditionelle rotierende Festplatten würden beim Versuch, bei solchen Zahlen mitzuhalten, wohl in Tränen ausbrechen. Dieser Vergleich trifft den Kern, weil sich die Messlatte grundlegend verschoben hat. Leistungsziele, die vor wenigen Jahren noch undenkbar schienen, sind in modernen Umgebungen zur Normalität geworden, und die Hardwareentwicklung verlief schneller als vielfach angenommen.

Warum Storage-Erweiterungen oft mehr schmerzen als zugegeben

Über beeindruckende Performancewerte wird gerne gesprochen, über operative Belastungen hingegen deutlich seltener. Die Skalierung von Speichersystemen ist im Alltag oft mühsam. Cluster müssen Daten neu verteilen, der interne Netzwerkverkehr steigt sprunghaft an, Rebuild-Vorgänge konkurrieren mit der Produktivlast, Latenzen schwanken vorübergehend und Administratoren behalten ihre Dashboards deutlich engmaschiger im Auge als sonst. Mitunter zeigen sich Probleme erst Wochen nach dem eigentlichen Eingriff.

Aus genau diesem Grund sind reibungslose Erweiterungen so wertvoll. Wenn Skalierung ohne Reibungsverluste gelingt, planen Teams mutiger, Architekturen entwickeln sich agiler und Erweiterungen verlieren ihren Ruf als riskante Großereignisse, die tagelange Vorbereitungen erfordern.

Skepsis bleibt dennoch berechtigt. Manche Engineers betonen, dass Benchmarks nur dann Aussagekraft besitzen, wenn das Lastprofil der Realität entspricht, da synthetische Testumgebungen Schwachstellen kaschieren können und transaktionale Produktivdatenbanken ganz anders reagieren als lineare Direct-I/O-Tests. Andere halten dagegen, dass gezielte Stresstests Schwachstellen aufdecken, bevor sie im Produktivbetrieb Schaden anrichten. Beide Sichtweisen haben ihre Berechtigung: Starke Infrastruktur-Teams betrachten Messergebnisse und operative Erfahrungswerte stets im Zusammenhang, bevor sie einem System vertrauen.

Cephs größtes Versprechen war nie reine Geschwindigkeit

Hohe Leistungsdaten sorgen für Schlagzeilen, aber echte Skalierbarkeit sichert das langfristige Überleben verteilter Speichersysteme. Der entscheidende Punkt bei diesem Test lag weniger im maximalen Durchsatz als im Ablauf der Erweiterung: wenige Aktionen im Dashboard, ein automatisches Rebalancing und ein fortlaufender Betrieb ohne jede Unterbrechung.

Diese Schlichtheit ist entscheidend, weil Komplexität mit der Zeit exponentiell anwächst. Cluster werden größer, die Zahl der angebundenen Clients nimmt zu, der Speicherbedarf multipliziert sich und Unternehmen verkleinern ihre Infrastruktur so gut wie nie. Technologien, die sich im kleinen Rahmen mühelos betreiben lassen, geraten im großen Maßstab mitunter operativ ins Wanken. Verteilte Architekturen versprechen einen Ausweg aus dieser Falle, selbst wenn sie keine universelle Perfektion garantieren: Sie können wachsen, ohne alles von Grund auf neu zu errichten, ohne aufwendige Forklift-Migrationen, ohne monatelange Neuentwürfe aufgrund überholter Annahmen und ohne Wartungsfenster mit Downtime.

Wenn eine Skalierung sauber funktioniert, bleibt sie im Alltag nahezu unsichtbar. Anwender außerhalb des Betriebs bemerken kaum etwas davon, während das Infrastruktur-Team den Erfolg zu schätzen weiß.

Das Wettrüsten bei der Infrastruktur hält an

Die Erwartungen an Speicherleistungen haben sich tiefgreifend verändert. Vor fünf Jahren maßen viele Rechenzentren den Erfolg ihrer Speichersysteme an völlig anderen Kriterien. Heute fordern KI-Systeme gewaltige Durchsatzraten, die Dichte virtualisierter Umgebungen steigt kontinuierlich, Analyse-Pipelines bewegen enorme Datenmengen und moderne Software-Stacks setzen schlicht voraus, dass der Speicher keinen Flaschenhals darstellt.

Diese Erwartungshaltung erzeugt spürbaren Druck auf die Verantwortlichen für die Infrastruktur. Von ihnen wird verlangt, Bandbreite, IOPS, Konsistenz, Ausfalltoleranz, Wiederherstellungstempo und Raum für zukünftiges Wachstum gleichzeitig bereitzustellen, und eine Ziellinie existiert nicht. Erreicht man 40 GB/s durchschnittliche Leserate, fragt jemand nach 50. Schafft man 2 Millionen IOPS, wird sofort nach dem nächsten Meilenstein gefragt.

Dieser Anspruch treibt Innovationen voran, verlangt Teams aber auch viel ab. Infrastruktur-Teams sollen mehr Leistung bei unverminderter Stabilität liefern, größere Umgebungen überschaubar halten und Anpassungen schneller vornehmen, ohne Ausfälle zu riskieren. Berichte wie dieser finden deshalb großen Anklang, weil sie belegen, dass sich sorgfältige Planung auszahlt. Eine durchdachte Architektur fängt Wachstum elastisch ab, während eine unpassende Konstruktion sich dagegen sperrt.

Performance ist wertlos ohne Vertrauen

Verlässlichkeit und Vertrauen lassen sich schwer in Kennzahlen fassen. Dashboards bilden sie nicht ab und Benchmarks erfassen sie nur bruchstückhaft. Man erkennt dieses Vertrauen daran, dass Teams die Angst vor Erweiterungen verlieren, dass Skalierung ihren Ausnahmecharakter einbüßt und dass Systeme sich unter Last berechenbar verhalten.

Die Speicherbranche kennt unzählige Geschichten über schmerzhafte Wachstumsprozesse: Erweiterungen mit schwerwiegenden Zwischenfällen, unerwartete Hardware-Inkompatibilitäten, unvorhergesehene Engpässe, mühsame Migrationsprojekte, endlose Rebalancing-Phasen und schlaflose Nächte. Solche Negativbeispiele verbreiten sich schnell, weil fast jeder erfahrene Administrator schon einmal damit konfrontiert war. Umso deutlicher heben sich reibungslose Abläufe ab. Ein erfolgreicher Ausbau verändert den Blick auf künftige Entscheidungen: Wachstum verliert seinen Schrecken, neue Tests fallen leichter und der Handlungsspielraum wächst spürbar, was weit mehr zählt als jeder Screenshot eines Benchmark-Tools.

Gute Infrastruktur tritt leise in den Hintergrund und gerät erst dann wieder ins Bewusstsein, wenn etwas versagt. Das größte Kompliment für ein Speichersystem klingt oft erstaunlich nüchtern: „Es lief einfach unterbrechungsfrei weiter.“

Der eigentliche Härtetest steht noch bevor

Das Hinzufügen des sechsten Nodes hat eine zentrale Frage beantwortet und sogleich die nächste aufgeworfen: Wie viel Leistungsreserve steckt noch in diesem Verbund? Nach einer erfolgreichen Erweiterung geben sich erfahrene Ingenieure selten zufrieden. Es folgen neue Benchmarks, gezielte Feinabstimmungen und weitere Messungen unter Maximallast, denn das Erreichen einer Grenze macht meist die nächste sichtbar.

Nachdem der Cluster diesen Ausbauschritt gemeistert hat, bleibt abzuwarten, ob der Durchsatz spürbar weiter ansteigt, wie sich die Schreibmuster unter Dauerlast entwickeln, ob die Skalierungseffizienz erhalten bleibt, auf welchem Niveau sich die Latenzen einpendeln und ob die Client-Zahlen noch weiter gesteigert werden können. Es gibt immer ein weiteres Diagramm zu analysieren und ein neues Limit auszuloten. Systeme entwickeln sich weiter, Anforderungen wachsen und moderne Hardware eröffnet ständig neue Möglichkeiten.

Irgendwo vor einer Reihe von Monitoren beobachtet in diesem Moment jemand, wie die Messkurven die Werte des Vortags übertreffen, und lächelt zufrieden. Zu erleben, wie ein ohnehin schnelles System noch mehr leisten kann, gehört zu den lohnendsten Momenten in diesem Beruf.