WISSEN > OBJECT STORAGE -> SCALE-OUT OBJECT STORAGE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Scale-out Object Storage
Kapazität horizontal skalieren
Scale-Out Object Storage
Inhaltsverzeichnis
- Der Unterschied liegt nicht in der Hardware, sondern im Placement Layer
- Ein zusätzlicher Node bedeutet nicht nur zusätzliche Kapazität
- Rohkapazität ist nicht nutzbare Kapazität
- Failure Domains sind Teil der Kapazitätsarchitektur
- Über zwei Rechenzentren wird das Netzwerk Teil des Datenpfades
- ASSISTRA-Praxis: Mehr nutzbare Kapazität ohne zusätzliche Hardware
- Skalierbarkeit endet nicht bei der Kapazität
- Fazit
- Quellen
Object Storage wird häufig mit nahezu unbegrenzter Skalierbarkeit verbunden. Technisch ist diese Aussage zu einfach. Auch ein Scale-out Object Storage besitzt Grenzen, sie liegen nur an anderen Stellen als bei klassischen Scale-up-Systemen.
Während bei einer traditionellen Storage-Architektur meist die Kapazität und Leistungsfähigkeit eines Controller-Systems den Ausbau begrenzen, verteilt eine Scale-out-Architektur Daten und Redundanz über viele Storage-Nodes. Zusätzliche Kapazität lässt sich dadurch grundsätzlich durch weitere Nodes oder Storage Devices in den vorhandenen Cluster integrieren. Entscheidend ist jedoch nicht allein, wie viel Rohkapazität ein Cluster besitzt, sondern wie Daten verteilt werden, welches Redundanzverfahren zum Einsatz kommt, welche Failure Domains berücksichtigt sind und was bei Erweiterungen oder Ausfällen mit bereits gespeicherten Daten geschieht.
Der Unterschied liegt nicht in der Hardware, sondern im Placement Layer
Bei einer klassischen Scale-up-Architektur wird ein bestehendes Storage-System innerhalb der Grenzen seiner Architektur erweitert: zusätzliche Laufwerke, Shelves oder andere vom System unterstützte Kapazität werden an eine bestehende Controller-Infrastruktur angebunden.
Scale-out verfolgt einen anderen Ansatz. Die Storage-Ressourcen verteilen sich auf mehrere Systeme beziehungsweise Nodes, und die Datenplatzierung muss deshalb nicht nur ein einzelnes Storage-System, sondern den gesamten Clusterberücksichtigen. Die grundsätzliche Gegenüberstellung beider Modelle sowie ihre Abgrenzung zu Software-defined und disaggregierten Architekturen haben wir in einem eigenen Beitrag dieser Reihe behandelt; hier interessiert ausschließlich, was Scale-out für die nutzbare Kapazität bedeutet.
Vereinfacht durchläuft ein Zugriff die Kette aus Client, Object API, Storage Cluster, Placement, Storage Nodes und schließlich physischem Medium. Der wesentliche Unterschied zwischen beiden Modellen liegt im Placement Layer, denn das System muss für jedes Objekt bestimmen, auf welchen Ressourcen dessen Daten und Redundanzinformationen liegen.
Wie unterschiedlich sich das implementieren lässt, zeigen Ceph und OpenStack Swift. Ceph ordnet Objekte zunächst Placement Groups zu und berechnet anschließend über CRUSH deren Zuordnung zu OSDs. Swift verwendet dagegen Rings, über die Partitionen den Storage Devices zugeordnet werden. Beide Beispiele zeigen dasselbe Prinzip verteilter Object-Storage-Systeme: Die Zuordnung von Daten zu physischen Ressourcen wird von der einzelnen Storage-Hardware abstrahiert. Genau diese Abstraktion ermöglicht horizontale Skalierung.
Ein zusätzlicher Node bedeutet nicht nur zusätzliche Kapazität
Das Hinzufügen von Storage-Ressourcen verändert die Verteilungsmöglichkeiten innerhalb des Clusters. Damit die neue Kapazität tatsächlich genutzt wird, muss ein Teil der vorhandenen Daten, Partitionen oder Fragmente auf die neuen Ressourcen gelangen. Das konkrete Verhalten hängt von der Implementierung ab. Ceph kann bei einer Änderung der Cluster-Topologie die Zuordnung von Placement Groups zu OSDs verändern und überträgt Daten daraufhin auf andere OSDs. Swift verwendet einen Rebalance-Mechanismus, um Partitionen entsprechend der vorhandenen Kapazität auf die Devices zu verteilen.
Damit entsteht ein wichtiger Unterschied zu einer rein physikalischen Betrachtung der Skalierung: Neue Kapazität muss nicht nur installiert, sondern logisch in die Datenverteilung des Clusters integriert werden.
Diese Bewegung vorhandener Daten beansprucht Ressourcen. Die Ceph-Dokumentation beschreibt ausdrücklich, dass die Migration von Placement Groups und der darin enthaltenen Objekte die operative Performance des Clusters erheblich beeinträchtigen kann; Ceph priorisiert Backfill-Operationen deshalb niedriger als Lese- und Schreibanfragen der Clients. Swift begrenzt die Umverteilung auf anderem Weg, indem über min_part_hours festgelegt wird, wie oft eine Partition innerhalb eines konfigurierbaren Zeitraums überhaupt verschoben werden darf. Beide Implementierungen behandeln die Neuverteilung damit als etwas, das gebremst werden muss, und nicht als Nebeneffekt, der sich von selbst erledigt.
Scale-out bedeutet deshalb gerade nicht, dass ein zusätzlicher Node unmittelbar proportional mehr nutzbare Kapazität und Performance liefert. Technisch korrekter ist eine Abfolge: Der Node kommt hinzu, das Placement ändert sich, Daten werden gegebenenfalls neu verteilt, und der Cluster nähert sich einer neuen Verteilung von Daten und Kapazität an. Wie hoch die daraus resultierende Belastung ausfällt, hängt von Implementierung, Datenmenge, Auslastung, Netzwerkinfrastruktur und Konfiguration ab.
Rohkapazität ist nicht nutzbare Kapazität
Die wichtigste Größe beim Design eines Object-Storage-Clusters ist deshalb nicht die Summe der eingebauten Laufwerke, sondern die nutzbare Kapazität nach Redundanz. Bei dreifacher vollständiger Replikation benötigt ein Datenbestand die dreifache physische Kapazität; ein Petabyte Nutzdaten belegt unter dieser vereinfachten Betrachtung drei Petabyte Rohkapazität.
Erasure Coding verfolgt einen anderen Ansatz. Daten werden in k Datenfragmente zerlegt und um m Coding-Fragmente ergänzt. Daraus ergeben sich zwei Größen, die in der Praxis regelmäßig verwechselt werden. Der Kapazitätsfaktor beschreibt, wie viel Rohkapazität eine Einheit Nutzdaten belegt, und beträgt (k+m)/k. Der Rohkapazitäts-Overhead beschreibt dagegen nur den Zuschlag über die Nutzdaten hinaus und beträgt m/k. Ein 8+2-Schema hat damit einen Kapazitätsfaktor von 1,25 und einen Overhead von 25 Prozent, dreifache Replikation in derselben Systematik einen Faktor von 3,0 und einen Overhead von 200 Prozent.
Ceph verwendet die zweite Größe. Die Dokumentation beschreibt für k=10, m=4, dass ein Objekt in zehn Daten-Chunks zerlegt, um vier Coding-Chunks ergänzt und auf vierzehn OSDs verteilt wird; der Rohkapazitäts-Overhead beträgt dabei 40 Prozent, der Kapazitätsfaktor entsprechend 1,4.
Die höhere Kapazitätseffizienz ist jedoch nicht kostenlos. Für die Codierung müssen Coding-Fragmente berechnet werden, und bei einer Rekonstruktion müssen ausreichend vorhandene Fragmente gelesen und daraus die fehlenden Daten wiederhergestellt werden. Je nach Verfahren entsteht dadurch erheblicher I/O- und Netzwerkverkehr. Ceph dokumentiert für das isa-Plugin, dass der Verlust eines OSD das Lesen von k weiteren erfordert, bei k=8, m=4 also von acht; für jerasurebeschreiben ältere Dokumentationsstände sogar das Lesen aller übrigen Fragmente.
Was das mengenmäßig bedeutet, macht die Ceph-Dokumentation zum CLAY-Plugin an einem Zahlenbeispiel deutlich: Bei k=8, m=4 unter jerasure erfordert die Wiederherstellung von einem GiB das Übertragen von acht GiB. Der Recovery-Traffic ist damit ein Vielfaches der tatsächlich verlorenen Datenmenge. Replication und Erasure Coding sind deshalb nicht einfach zwei Methoden, Speicherplatz zu sparen. Sie verändern den Datenpfad, die Failure-Toleranz und das Recovery-Verhalten des Clusters.
Failure Domains sind Teil der Kapazitätsarchitektur
Ein verteiltes System muss außerdem wissen, welche Komponenten gemeinsam ausfallen können. Ein einzelnes Laufwerk ist eine andere Failure Domain als ein Storage-Node, ein Rack kann mehrere Nodes gleichzeitig betreffen, und in einer Architektur über mehrere Rechenzentren wird schließlich der Standort selbst zur Failure Domain. Ein Redundanzverfahren ist daher nur dann sinnvoll, wenn das Placement dazu passt.
Werden mehrere redundante Fragmente eines Objekts innerhalb derselben Failure Domain gespeichert, können sie durch dasselbe Ereignis gleichzeitig verloren gehen. Systeme wie Ceph erlauben deshalb, Failure Domains für die Platzierung zu definieren; bei einer Failure Domain host verteilt Ceph die EC-Chunks eines Objekts auf unterschiedliche Hosts.
Das Architekturprinzip dahinter lautet: Redundanz beantwortet die Frage, wie viele Ausfälle toleriert werden können, Placement beantwortet zusätzlich die Frage, welche Ausfälle diese Redundanz tatsächlich abdeckt. Beides muss gemeinsam geplant werden.
Über zwei Rechenzentren wird das Netzwerk Teil des Datenpfades
Besonders deutlich wird das bei Object Storage über mehrere Standorte. Eine einfache Möglichkeit besteht darin, Datenbestände zwischen zwei Rechenzentren vollständig zu spiegeln. Das erzeugt eine klare Trennung der Standorte, benötigt für die standortübergreifende Kopie aber entsprechend zusätzliche Kapazität.
Alternativ können bestimmte Architekturen Erasure Coding über Failure Domains beziehungsweise Standorte hinweg einsetzen. Daten- und Coding-Fragmente verteilen sich dann über die Infrastruktur beider Standorte. Das verbessert die Kapazitätsausnutzung gegenüber der vollständigen Spiegelung, führt jedoch zu einer neuen Abhängigkeit: Das Netzwerk zwischen den Standorten wird Bestandteil des Storage-Datenpfades und des Recovery-Pfades.
Wie konkret dieser Trade-off ist, zeigt die Ceph-Entwicklungsdokumentation für EC Stretch Cluster. Sie benennt für ein naiv über zwei Zonen gelegtes Standard-EC-Profil drei Effekte. Jeder Schreibvorgang verteilt alle k+m Chunks über beide Zonen, wobei die Coding-Fragmente unnötig über die Standortverbindung dupliziert werden. Jeder Lesevorgang benötigt mindestens k Fragmente, die in der Regel über beide Zonen verteilt liegen, und trägt damit die Latenz dieser Verbindung. Und nach einem Zonenausfall lastet die gesamte Recovery-Last auf genau dem Netzwerkpfad, der die geringste Bandbreite besitzt.
Aufschlussreich ist, welche Konsequenz das Ceph-Projekt daraus zieht. Der dort vorgeschlagene Entwurf verteilt die Fragmente gerade nicht über die Standorte. Stattdessen hält jede Zone einen vollständigen, unabhängigen EC-Stripe, sodass die Pool-Größe zones × (k+m) beträgt. Lesevorgänge und Wiederherstellung bleiben dadurch zonenlokal, und über die Standortverbindung läuft nur noch die Schreibreplikation. Kapazitätsseitig liegt dieser Entwurf damit näher an der Spiegelung als an einem gestreckten k+m-Schema.
Beide Wege sind tragfähig, sie optimieren nur unterschiedliche Größen. Ein über beide Standorte verteiltes Schema optimiert die Kapazitätsausnutzung und bezahlt dafür mit Inter-Site-Traffic, der zonenlokale Stripe optimiert Latenz und Recovery-Verhalten und bezahlt dafür mit Kapazität. Es ist derselbe Trade-off, nur aus entgegengesetzter Richtung aufgelöst, und genau deshalb lässt sich die Frage nach Erasure Coding über zwei Rechenzentren nicht ohne die Eigenschaften der Standortverbindung beantworten.
Zur Einordnung gehört der Reifegrad. Das zitierte Dokument beschreibt einen Entwicklungsstand, setzt ausdrücklich Fast EC voraus, unterstützt keine Legacy-EC-Implementierungen und ist in aufeinanderfolgende Auslieferungsstufen gegliedert. Als Beleg für die Architekturlogik ist es belastbar, als Beschreibung eines verfügbaren Produktzustands nicht.
Eine Stretched-Architektur muss deshalb nicht nur hinsichtlich der Kapazität bewertet werden. Auch Bandbreite, Latenz, Failure Handling und Recovery-Traffic zwischen den Rechenzentren gehören zur Architekturentscheidung.
ASSISTRA-Praxis: Mehr nutzbare Kapazität ohne zusätzliche Hardware
Wie stark das Redundanzmodell die tatsächlich nutzbare Kapazität beeinflusst, zeigte sich in einer von uns begleiteten Object-Storage-Umgebung in einer Größenordnung von rund 300 TB. Die bestehende Infrastruktur war ursprünglich über getrennte Speicherbereiche gespiegelt. Später wurde die Architektur verändert: Statt der bisherigen Spiegelung betrieben wir die vorhandene Hardware als Stretched-Architektur über zwei Rechenzentren und setzten Erasure Coding über beide Standorte ein. Zusätzliche Nodes wurden dabei nicht installiert; ausschlaggebend war eine bessere Kapazitätsausnutzung der bereits vorhandenen Hardware.
Damit liegt das Projekt bewusst auf der ersten der beiden im vorigen Abschnitt beschriebenen Seiten. Wir haben die Fragmente über beide Standorte verteilt, um die vorhandene Kapazität besser auszunutzen, und nicht, um Lese- und Recovery-Pfade zonenlokal zu halten. Die Standortverbindung wurde damit sehenden Auges Teil des Datenpfades. Diese Entscheidung ist nur tragfähig, wenn Bandbreite und Latenz zwischen den Rechenzentren entsprechend ausgelegt sind, und sie lässt sich nicht auf Umgebungen übertragen, in denen die Standortverbindung der Engpass ist.
Die Unterscheidung hat eine Konsequenz, die in Kapazitätsdiskussionen regelmäßig unerwähnt bleibt. Kapazität, die durch ein verändertes Redundanzmodell nutzbar wird, entsteht ohne zusätzliche Leistungsaufnahme, ohne zusätzliche Kühllast und ohne zusätzlichen Rack-Platz. Ein zusätzlicher Storage-Node bringt dagegen beides mit: nutzbare Terabyte und einen dauerhaften Beitrag zur Anschlussleistung des Rechenzentrums, der über die gesamte Lebensdauer des Systems bestehen bleibt.
In der PUE-Betrachtung wird dieser Unterschied nicht sichtbar. PUE setzt die gesamte Rechenzentrumsleistung ins Verhältnis zur IT-Last und bleibt unverändert, ob dieselbe Nutzdatenmenge auf vorhandener oder auf zusätzlich installierter Hardware liegt. Sichtbar wird der Unterschied ausschließlich in der absoluten Anschlussleistung, also genau in der Größe, die für Standortplanung, Kühlkonzept und regulatorische Berichtspflichten relevant ist.
Die Erfahrung zeigt damit einen Punkt, der bei Scale-out-Projekten leicht übersehen wird: Mehr nutzbare Kapazität entsteht nicht zwangsläufig durch mehr Hardware. Auch Placement, Failure Domains und Redundanzmodell bestimmen, welcher Anteil der vorhandenen Rohkapazität für Nutzdaten zur Verfügung steht. Eine allgemeine Aussage über den Kapazitätsgewinn von Erasure Coding lässt sich aus dem Projekt dagegen bewusst nicht ableiten; dafür müssten unter anderem das konkrete k+m-Schema und weitere Implementierungsdetails berücksichtigt werden.
Skalierbarkeit endet nicht bei der Kapazität
Ein Scale-out-Cluster kann physisch wachsen. Daraus folgt jedoch nicht, dass jede andere Systemeigenschaft im gleichen Verhältnis skaliert. Mindestens fünf Dimensionen müssen getrennt betrachtet werden.
Die Kapazität beantwortet, wie viel zusätzliche nutzbare Kapazität nach Berücksichtigung von Replication oder Erasure Coding tatsächlich entsteht. Die Datenverteilung beschreibt, wie bestehende und neue Objekte nach einer Erweiterung über die Ressourcen verteilt werden. Das Netzwerk trägt den East-West-Traffic aus Writes, Rebalancing, Replication, Erasure Coding und Recovery. Das Failure Handling bestimmt, wie viele Laufwerke, Nodes, Racks oder Standorte ausfallen können, ohne dass Daten verloren gehen oder unverfügbar werden. Und das Recovery entscheidet, wie viele Daten nach einem Ausfall gelesen, übertragen, rekonstruiert und neu geschrieben werden müssen.
Gerade bei großen Clustern wird der letzte Punkt wichtig. Die Wiederherstellung eines ausgefallenen Storage-Devices betrifft in einem verteilten System nicht zwangsläufig nur zwei Laufwerke wie bei einer einfachen lokalen Spiegelung, sondern kann über zahlreiche Clusterkomponenten hinweg ablaufen. Ceph zeigt das daran, wie die von einem ausgefallenen OSD betroffenen Placement Groups über die verbleibenden OSDs wiederhergestellt werden.
Die Stärke einer Scale-out-Architektur besteht somit nicht darin, grenzenlos zu sein. Sie besteht darin, Kapazität und Datenplatzierung über eine verteilte Menge von Ressourcen organisieren zu können, sodass die Erweiterung nicht zwingend an die Ausbaugrenze eines einzelnen Storage-Controllers gekoppelt ist.
Damit verschieben sich allerdings die Grenzen. Statt Controller-Slots und maximal unterstützter Shelves werden andere Faktoren relevant: die unterstützten Cluster- und Node-Größen der konkreten Implementierung, Netzwerkbandbreite und Netzwerktopologie, Placement und Failure Domains, Rebalancing und Recovery, die Redundanz- beziehungsweise Erasure-Coding-Policy, das Verhältnis von Roh- zu nutzbarer Kapazität sowie das Verhalten bei partiellen Ausfällen. Die maximale Rohkapazität eines Systems allein sagt deshalb wenig darüber aus, wie gut eine Object-Storage-Architektur für einen bestimmten Workload skaliert.
Fazit
Scale-out Object Storage löst Kapazität von der Ausbaugrenze eines einzelnen Storage-Systems und verteilt Daten über einen Cluster aus Storage-Ressourcen. Das schafft die technische Grundlage, Speicherinfrastrukturen horizontal bis in sehr große Kapazitätsbereiche auszubauen. Der entscheidende Architekturparameter ist dabei jedoch nicht die Zahl der Nodes.
Placement, Redundanz, Failure Domains und Recovery bestimmen gemeinsam, wie viel Kapazität tatsächlich nutzbar ist und wie sich das System bei Wachstum und Ausfällen verhält. Der oben beschriebene Umbau von gespiegelter Datenhaltung auf eine Stretched-Architektur mit standortübergreifendem Erasure Coding ist genau dafür ein Beispiel: Die nutzbare Kapazität stieg, die installierte Hardware blieb unverändert.
Die entscheidende Frage bei der Planung lautet deshalb nicht nur, wie viele Petabyte ein System verwalten kann, sondern wie die Architektur diese Daten verteilt, schützt und rekonstruiert, wenn der Cluster wächst oder Teile davon ausfallen.
Quellen
Ceph Project: Ceph Architecture – Mapping PGs to OSDs / CRUSH, aktuelle Online-Dokumentation, abgerufen am 25.08.2026.
Ceph Project: Placement Groups, aktuelle Online-Dokumentation, abgerufen am 25.08.2026.
Ceph Project: Erasure Code Profiles, aktuelle Online-Dokumentation, abgerufen am 25.08.2026.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
