WISSEN > OBJECT STORAGE -> ARCHITEKTURANSÄTZE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Object Storage
Architekturansätze zwischen eigenem Rechenzentrum und Cloud
Das sollten Sie mitnehmen:
- S3 ist eine Schnittstelle, keine Architektur.
Dahinter können On-Premises-, Cloud-, replizierte oder gestretched betriebene Storage-Systeme stehen.
- Die Failure Domain entscheidet über die tatsächliche Redundanz.
Die Anzahl der Kopien oder EC-Fragmente allein sagt noch nicht, welche Ausfälle überstanden werden.
- Redundanz ist gleichzeitig eine Kapazitätsentscheidung.
Replikation und Erasure Coding führen zu unterschiedlichen Raw-to-Usable-Verhältnissen.
- Stretched Storage und Replikation lösen unterschiedliche Probleme.
Stretched Designs koppeln Standorte enger zusammen und stellen entsprechend höhere Anforderungen an das Netzwerk.
- Cloud verschiebt Infrastrukturverantwortung, beseitigt Architekturfragen aber nicht.
Kostenmodell, Datenbewegung, Governance, Souveränität und Exit müssen berücksichtigt werden.
Object Storage
Inhaltsverzeichnis
- Object Storage verändert das Speichermodell
- On-Premises verlagert nicht den Speicherort, sondern die Betriebsverantwortung
- Replikation ist einfach – und teuer in der Kapazität
- Erasure Coding senkt den Kapazitätsbedarf und erhöht den Aufwand
- Die Failure Domain entscheidet, nicht die Anzahl der Kopien
- Zwei Rechenzentren lassen zwei grundverschiedene Architekturen zu
- Warum wir eine gespiegelte Umgebung gestreckt haben
- Stretched Storage passt nicht in jede Umgebung
- Cloud verschiebt die Verantwortungsgrenze
- S3 ist eine Schnittstelle, kein Architekturversprechen
- Warum in einem anderen Projekt die Cloud überzeugt hat
- Wenn Souveränitätsfragen die Architektur bestimmen
- Hybride Modelle kombinieren Eigenschaften und Fehlerquellen
- Fünf Architekturmodelle im Vergleich
- Die Fragen, die vor der Herstellerauswahl stehen
- Fazit
- Quellen
Object Storage wird häufig auf die Frage reduziert, ob Daten im eigenen Rechenzentrum oder in der Cloud liegen sollen. Für eine Architekturentscheidung reicht diese Betrachtung nicht aus. Entscheidend ist, wie Daten verteilt und geschützt werden, welche Failure Domains die Architektur abdeckt, wo die Betriebsverantwortung liegt und welche Kosten mit wachsender Datenmenge entstehen. Zwei Lösungen können beide eine S3-Schnittstelle anbieten und sich in Skalierung, Ausfallsicherheit, Datenhoheit und Betriebsmodell trotzdem grundlegend unterscheiden. Bei Datenbeständen von mehreren hundert Terabyte bis in den Petabyte-Bereich werden diese Unterschiede zum bestimmenden Faktor.
Object Storage verändert das Speichermodell
Ein klassisches Filesystem organisiert Daten über Dateien und Verzeichnisse. Object Storage verwendet dagegen einzeln adressierbare Objekte. Die Storage Networking Industry Association beschreibt Object Storage als Verfahren, Datenmengen als Sammlungen einzeln und eindeutig identifizierbarer, unteilbarer Objekte zu speichern und wieder abzurufen; Metadaten können dabei mitgeführt werden. Eine Verzeichnishierarchie, wie sie ein Filesystem kennt, ist für das Objektmodell selbst nicht erforderlich.
Der Zugriff erfolgt typischerweise über eine API, in der Praxis fast immer über die S3 API. Der Datenpfad führt von der Anwendung über diese API zu den Storage Services, von dort über eine Placement- und Metadatenschicht zu den Storage Nodes und schließlich auf die Datenträger. Die API beschreibt dabei ausschließlich, wie eine Anwendung mit dem Storage kommuniziert. Über den Aufbau des Systems darunter sagt sie zunächst wenig aus.
Ein S3-kompatibles System kann auf wenigen lokalen Nodes laufen, über zwei Rechenzentren verteilt sein oder als vollständig gemanagter Cloud-Service bereitgestellt werden. S3-Kompatibilität ist deshalb keine Storage-Architektur, sondern eine Aussage über die Zugriffsebene.
On-Premises verlagert nicht den Speicherort, sondern die Betriebsverantwortung
Beim klassischen On-Premises-Modell werden die Storage-Nodes im eigenen Rechenzentrum betrieben. Software und Hardware können als integrierte Lösung beschafft oder separat zusammengestellt werden. Die Organisation kontrolliert damit wesentliche Teile der Infrastruktur selbst: Hardware und Storage-Medien, Netzwerk, physische Standorte, Failure Domains, den Software- und Firmware-Lifecycle, die Kapazitätsplanung sowie die administrativen Zugänge.
Diese Kontrolle wird relevant, wenn regulatorische, organisatorische oder interne Vorgaben den Betrieb außerhalb eigener Rechenzentren einschränken. Sie hat allerdings eine unmittelbare Konsequenz: Der Betreiber übernimmt damit auch die Verantwortung für die physische Storage-Infrastruktur. Kapazität muss geplant, beschafft und installiert werden. Defekte Komponenten müssen ersetzt, Softwarestände gepflegt und Erweiterungen in die vorhandene Architektur integriert werden.
Das unterscheidet On-Premises fundamental von einem Cloud-Service. Nicht der Speicherort allein macht den Unterschied, sondern die Verteilung der Betriebsverantwortung.
Scale-out ersetzt die klassische Controller-Architektur
Viele Object-Storage-Systeme basieren auf einer Scale-out-Architektur, bei der Kapazität und häufig auch Verarbeitungsleistung durch zusätzliche Nodes erweitert werden. Wie Daten innerhalb dieses Clusters verteilt werden, ist implementationsabhängig.
Ceph zeigt einen konsequent dezentralen Ansatz. Clients und OSDs verwenden CRUSH, kurz für Controlled Replication Under Scalable Hashing, um die Position von Daten aus Cluster-Topologie und Placement-Regeln zu berechnen. Dadurch vermeiden sie den Engpass einer zentralen Lookup-Tabelle. Die CRUSH Map kann dabei Failure Domains wie Host, Rack oder andere Hierarchieebenen berücksichtigen.
Daraus folgt ein Grundsatz, der für den gesamten weiteren Verlauf trägt: Die Anzahl der Storage-Nodes allein definiert noch keine Ausfallsicherheit. Drei Kopien auf drei Laufwerken desselben Servers schützen gegen andere Fehler als drei Kopien auf unterschiedlichen Hosts oder in unterschiedlichen Rechenzentren.
Replikation ist einfach – und teuer in der Kapazität
Die grundlegende Möglichkeit zur Datenabsicherung ist Replikation. Bei drei vollständigen Kopien eines Objekts benötigt ein Terabyte Nutzdaten drei Terabyte Rohkapazität, der Storage-Overhead beträgt also 200 Prozent gegenüber den Nutzdaten.
Der Vorteil liegt im einfachen Grundprinzip. Eine vollständige Kopie kann unmittelbar gelesen werden, solange sie verfügbar ist; es sind keine Rekonstruktionsschritte erforderlich. Mit zunehmender Datenmenge wird jedoch der Kapazitätsbedarf zum bestimmenden Faktor. Bei einem Petabyte Nutzdaten würden drei vollständige Kopien bereits drei Petabyte Rohkapazität binden, bevor Reserven und System-Overheads überhaupt berücksichtigt sind. Große Object-Storage-Systeme setzen deshalb häufig zusätzlich oder alternativ auf Erasure Coding.
Erasure Coding senkt den Kapazitätsbedarf und erhöht den Aufwand
Bei Erasure Coding wird ein Objekt in Daten- und Coding-Fragmente aufgeteilt, üblicherweise beschrieben als k Datenfragmente plus m Coding-Fragmente. Ceph dokumentiert entsprechende Erasure-Coded Pools, bei denen jedes Objekt in K+MChunks zerlegt wird: K enthalten Daten, M zusätzliche Coding-Informationen.
Bei einem hypothetischen 8+3-Schema entstehen aus acht Datenfragmenten drei zusätzliche Coding-Fragmente. Der theoretische Kapazitätsfaktor liegt damit bei (8 + 3) / 8 = 1,375. Für ein Petabyte Nutzdaten wären rechnerisch rund 1,375 Petabyte erforderlich – erheblich weniger als bei drei vollständigen Kopien.
Diese Effizienz ist jedoch nicht kostenlos, und zwar in zweifacher Hinsicht.
Der erste Preis ist Rechenaufwand. Beim Schreiben müssen Coding-Fragmente berechnet und verteilt werden. Fällt eine Komponente aus, müssen fehlende Daten aus den verbliebenen Fragmenten rekonstruiert werden. Daraus entstehen zusätzliche Rechen-, I/O- und gegebenenfalls Netzwerkoperationen.
Der zweite Preis ist struktureller Natur und wird in Ausschreibungen regelmäßig übersehen. Ceph weist darauf hin, dass die meisten Erasure-Coded-Deployments mindestens k+m Failure Domains benötigen – in der Praxis also Hosts oder Racks – und dass mindestens k+m+1 Failure Domains operative Vorteile bieten. Für das genannte 8+3-Schema wären das elf, besser zwölf voneinander unabhängige Fehlerbereiche. Werte von k über acht werden in der Ceph-Dokumentation für die meisten Fälle ausdrücklich nicht empfohlen. Ein effizientes Schema setzt also eine entsprechend breite Topologie voraus; wer beides unabhängig voneinander plant, erhält am Ende ein Schema, das die Hardware nicht tragen kann.
Die entscheidende Architekturfrage lautet deshalb nicht, ob Replikation oder Erasure Coding besser sei. Sie lautet, welches Schutzschema die geforderte Failure-Toleranz mit vertretbarem Kapazitäts-, Performance- und Recovery-Aufwand erreicht.
Die Failure Domain entscheidet, nicht die Anzahl der Kopien
Redundanz schützt nur dann gegen einen Fehler, wenn die redundante Information außerhalb der betroffenen Failure Domain liegt. Ein Erasure-Coding-Verfahren kann mathematisch mehrere verlorene Fragmente tolerieren. Liegen diese Fragmente jedoch ungünstig innerhalb derselben Failure Domain, fehlt die gewünschte Rechenzentrums-Redundanz trotzdem.
Moderne verteilte Systeme berücksichtigen deshalb die Topologie bei der Datenplatzierung. Ceph kann über crush-failure-domain sicherstellen, dass keine zwei Chunks innerhalb derselben definierten Failure Domain abgelegt werden – ist die Failure Domain auf rack gesetzt, landen keine zwei Chunks im selben Rack.
Für IT-Verantwortliche folgt daraus eine Frage, die in jede Storage-Ausschreibung gehört: Gegen welchen konkreten Ausfall schützt das konfigurierte Datenlayout? Begriffe wie „Erasure Coding", „dreifache Redundanz" oder „Multi-Site" reichen als Antwort nicht aus. Sie beschreiben ein Verfahren, aber nicht die Topologie, über die es angewendet wird.
Zwei Rechenzentren lassen zwei grundverschiedene Architekturen zu
Besonders interessant wird Object Storage, wenn zwei Rechenzentren zur Verfügung stehen. Die naheliegende Architektur besteht darin, an beiden Standorten jeweils eine eigenständige Storage-Umgebung zu betreiben und die Daten zwischen ihnen zu replizieren.
Der Vorteil liegt in der klaren Trennung beider Systeme. Insbesondere asynchrone Replikation erlaubt größere geografische Entfernungen, weil ein Schreibvorgang nicht auf die Persistierung am entfernten Standort warten muss. Daraus folgt allerdings zwangsläufig ein RPO: Zum Zeitpunkt eines Standortausfalls können noch nicht replizierte Änderungen existieren. Hinzu kommt, dass Daten je nach Auslegung sowohl innerhalb jedes Standorts als auch zwischen den Standorten redundant vorgehalten werden müssen.
Stretched Object Storage
Die alternative Architektur spannt einen logischen Storage-Cluster über mehrere Standorte. Die Rechenzentren bilden dann Failure Domains innerhalb eines gemeinsamen Systems statt zweier getrennter Systeme.
Das verändert die Kapazitätsausnutzung grundlegend. Statt an beiden Standorten jeweils einen lokal geschützten Datenbestand vorzuhalten und anschließend einen weiteren vollständigen Bestand dorthin zu replizieren, verteilt ein Erasure-Coding-Schema seine Daten- und Coding-Fragmente direkt über die Standorte.
Scality dokumentiert sowohl replizierte Zwei-Site- als auch über zwei beziehungsweise drei Standorte gestreckte RING-Konfigurationen, wobei in den Stretched-Konfigurationen Erasure Coding standortübergreifend eingesetzt wird. Der Hersteller nennt dafür zugleich eine Voraussetzung: Stretched-Betrieb setzt eine leistungsfähige und latenzarme Verbindung zwischen den Rechenzentren voraus, wobei die konkreten Anforderungen von Workload und Performance-Erwartung abhängen.
Damit wird der zentrale Trade-off sichtbar. Stretched Storage kann die Speichereffizienz erhöhen und synchrone standortübergreifende Absicherung ermöglichen, koppelt dafür aber die Storage-Architektur unmittelbar an Qualität, Latenz und Verfügbarkeit der Verbindung zwischen den Rechenzentren.
Warum wir eine gespiegelte Umgebung gestreckt haben
Diese Unterschiede sind nicht nur theoretischer Natur. Wir haben eine On-Premises-Object-Storage-Umgebung in einer Größenordnung von rund 300 TB begleitet, in der Scality zum Einsatz kam. Die Umgebung arbeitete zunächst mit einem gespiegelten Speicheransatz über die vorhandenen Rechenzentrumsressourcen. Im weiteren Verlauf haben wir die Architektur verändert und den Storage über zwei Rechenzentren gespannt.
Ausschlaggebend war dabei nicht eine höhere nominelle Speicherkapazität der Hardware, sondern die bessere Nutzung der bereits vorhandenen Storage-Ressourcen. Die Projekterfahrung verdeutlicht einen Punkt, der in der Planung regelmäßig getrennt behandelt wird, obwohl er zusammengehört: Redundanz und Kapazität lassen sich bei Object Storage nicht unabhängig voneinander planen. Die Frage lautet nicht nur, wie viel Rohkapazität beschafft wird, sondern welcher Anteil davon nach Anwendung des gewünschten Protection Schemes tatsächlich nutzbar bleibt.
Die technische Plausibilität dieser Beobachtung lässt sich anhand der dokumentierten Scality-Architektur nachvollziehen. Der Hersteller beziffert den Overhead für einen über drei Standorte gestreckten RING mit typischerweise rund 75 Prozent. Für dieselben Daten in zwei replizierten RINGs entstünden dagegen 100 Prozent Overhead für die zusätzliche Kopie und zusätzlich rund 33 Prozent pro Standort für den lokalen Schutz. Es handelt sich um Herstellerangaben, nicht um unabhängig gemessene Werte; die Größenordnung erklärt jedoch, warum eine Architekturänderung die nutzbare Kapazität verändern kann, ohne dass zusätzliche Hardware beschafft wird.
Die konkrete Entscheidung und ihre Bewertung bleiben eine Projektbeobachtung. Sie ist keine allgemeine Aussage, dass Stretched Storage einer replizierten Architektur grundsätzlich überlegen wäre.
Stretched Storage passt nicht in jede Umgebung
Die höhere Storage-Effizienz darf nicht isoliert betrachtet werden. Bei synchron über Rechenzentren verteilten Schreibvorgängen wird die Verbindung zwischen den Standorten Bestandteil des I/O-Pfades. Damit werden Round-Trip-Latenz, verfügbare Bandbreite und Paketverluste ebenso zu Storage-Parametern wie das Verhalten bei Netzwerkpartitionen, die Quorum- und Witness-Architektur, das Verhalten beim Verlust eines Standorts und der Rebuild-Traffic nach dessen Wiederkehr.
Eine geografisch weiter entfernte DR-Site kann deshalb eine andere Architektur erfordern als zwei Rechenzentren innerhalb einer Metro-Region. Asynchrone Replikation akzeptiert einen zeitlichen Abstand zwischen primärem und sekundärem Datenbestand, entkoppelt dafür aber den normalen Schreibpfad deutlich stärker von der WAN-Latenz.
Stretched und repliziert lösen daher nicht dasselbe Architekturproblem. Sie unterscheiden sich nicht im Grad der Absicherung, sondern in der Art der Kopplung.
Cloud verschiebt die Verantwortungsgrenze
Beim Cloud-Modell verschiebt sich die Grenze der Verantwortung. Der Kunde verwaltet Buckets, Objekte, Zugriffsrechte, Lifecycle Policies und die Applikationsintegration. Die darunterliegende physische Storage-Infrastruktur betreibt dagegen der Cloud-Anbieter. Der Kunde entscheidet damit nicht mehr unmittelbar über einzelne Storage-Nodes, Laufwerke oder interne Rebuild-Prozesse.
Das kann einen erheblichen betrieblichen Vorteil darstellen, weil Kapazitätswachstum keine eigene Hardwarebeschaffung mehr erfordert. Gleichzeitig entstehen neue Abhängigkeiten: Netzwerkzugriff, Provider, Vertragsmodell, Identitätsarchitektur, Datenstandort und gegebenenfalls Exit-Strategie werden Bestandteil des Storage-Designs.
Cloud Object Storage eliminiert Infrastrukturentscheidungen daher nicht. Es verschiebt sie auf eine andere Ebene.
S3 ist eine Schnittstelle, kein Architekturversprechen
Für die Architekturentscheidung ist die Trennung zwischen API und Service wesentlich. S3 entstand als API von Amazon S3, wird heute aber von zahlreichen Object-Storage-Plattformen implementiert. Eine Anwendung kann deshalb über eine weitgehend vergleichbare Schnittstelle mit einem On-Premises-System oder mit einem Cloud-Service kommunizieren, ohne dass sich am Applikationscode Wesentliches ändert.
S3-Kompatibilität bedeutet allerdings nicht identisches Verhalten aller Implementierungen. Unterstützte API-Funktionen, Konsistenzverhalten, Object Lock, Identity-Funktionen und weitere Eigenschaften müssen für die konkrete Plattform geprüft werden.
Amazon dokumentiert für S3 heute Strong Read-after-Write Consistency für PUT- und DELETE-Requests in allen Regionen, sowohl für neue Objekte als auch für überschreibende PUTs; Updates auf einen einzelnen Key sind atomar. Diese Eigenschaft darf nicht allein aufgrund der Bezeichnung „S3-kompatibel" auf einen anderen Object Store übertragen werden.
Warum in einem anderen Projekt die Cloud überzeugt hat
Wir haben ebenfalls Object-Storage-Umgebungen in der Cloud mit einer Größenordnung von bis zu etwa 1,5 PB begleitet. Dort fielen Entscheidungen zugunsten von Wasabi Cloud Object Storage, die sich aus Sicht der begleiteten Projekte positiv entwickelt haben. Ein wesentlicher Faktor waren die Kosten für große Mengen inaktiver Daten.
Das ist ein typisches Einsatzprofil, bei dem eine reine Betrachtung des Anschaffungspreises von Storage-Hardware zu kurz greift. Bei langfristig gespeicherten Daten stehen Hardware-Lifecycle, Kapazitätsreserven, Rechenzentrumsressourcen und Betriebsaufwand auf der einen Seite den Storage-, Transfer- und gegebenenfalls API-Kosten des Cloud-Modells auf der anderen gegenüber.
Wasabi verwendet aktuell ein Storage-basiertes Preismodell. Für das Pay-as-you-Go-Modell dokumentiert der Anbieter keine separaten Gebühren für API Requests und Ingress. Egress ist ebenfalls ohne separate Gebühr, solange die monatlich heruntergeladene Datenmenge das aktive Speichervolumen nicht übersteigt; andernfalls behält sich der Anbieter Einschränkungen vor. Gleichzeitig gelten zwei Mindestgrößen: eine monatliche Mindestabrechnung in Höhe von einem Terabyte aktivem Speicher sowie eine Mindest-Speicherdauer von 90 Tagen. Werden Objekte vorher gelöscht, wird die verbleibende Mindestdauer als „Timed Deleted Storage" berechnet. Beim vorausbezahlten Reserved-Capacity-Modell beträgt diese Mindestdauer 30 Tage – das Vertragsmodell verändert also unmittelbar die Kostenwirkung von Löschvorgängen.
Damit wird zugleich deutlich, warum sich unsere Erfahrung nicht zu der Aussage verkürzen lässt, Cloud Storage sei günstiger. Das wäre technisch und wirtschaftlich nicht haltbar. Für Daten mit hoher Änderungsrate und kurzer Lebensdauer entsteht ein anderes Kostenprofil als für über Jahre weitgehend unveränderte Bestände.
Die relevante Größe ist deshalb nicht der Preis pro Terabyte und Monat, sondern die Summe aus Kapazität, Datenbewegung, Operationen, Mindestmengen, Mindesthaltedauer, Infrastruktur, Betrieb, Wachstum und Exit. Welche dieser Terme tatsächlich anfallen, hängt vom jeweiligen Provider und Vertragsmodell ab.
Wenn Souveränitätsfragen die Architektur bestimmen
In einem weiteren von uns begleiteten Entscheidungsprozess fiel die Wahl auf eine On-Premises-Architektur, weil Bedenken gegenüber der Nutzung von Cloud Storage bestanden. Auch diese Erfahrung ist für die Architekturentscheidung relevant, denn die Wahl zwischen Cloud und eigenem Rechenzentrum wird nicht ausschließlich durch Storage-Technologie bestimmt.
Zu prüfen sind Anforderungen an Datenresidenz, regulatorische Vorgaben, die Kontrolle administrativer Identitäten, das Schlüsselmanagement, die Abhängigkeit vom Provider, die Netzwerkanbindung, Exit- und Migrationsmöglichkeiten sowie interne Governance-Vorgaben.
Dabei sollten zwei Begriffe unterschieden werden, die häufig synonym verwendet werden. Datenresidenz beantwortet primär die Frage, wo Daten gespeichert beziehungsweise verarbeitet werden. Datenhoheit beziehungsweise digitale Souveränität ist weiter gefasst und schließt Identitäten, Schlüssel, Managementsysteme, rechtliche Rahmenbedingungen und die Möglichkeit eines Providerwechsels ein. Eine Cloud-Region in Deutschland beantwortet deshalb nicht automatisch sämtliche Souveränitätsfragen. Umgekehrt ist On-Premises nicht automatisch souverän, denn auch eine lokale Plattform kann von externen Managementdiensten, Herstellerzugängen, externen Identitätsdiensten oder proprietären Technologien abhängen.
Was beim Wechsel erhalten bleibt
Ein Teilaspekt der Exit-Frage wird regelmäßig zu spät gestellt: Welche Metadaten und Policies bleiben bei einem Wechsel zwischen Systemen überhaupt erhalten? Objektdaten lassen sich über die S3 API in aller Regel übertragen. Lifecycle-Regeln, Retention-Einstellungen, Zugriffsrichtlinien und benutzerdefinierte Metadaten folgen dieser Übertragung nicht zwangsläufig.
Auf Standardebene existiert für diesen Bereich mit CDMI ein Ansatz der Storage Networking Industry Association, standardisiert als ISO/IEC 17826:2022 in der Version 2.0.0. CDMI ist dabei kein konkurrierendes Zugriffsprotokoll zu S3, sondern ein Management- und Portabilitätsstandard: Er beschreibt Namespace-Discovery, Provisionierung, Data-Lifecycle-Management, Zugriffsverwaltung und Datenportabilität – also genau die Ebene, die beim Systemwechsel verlorengehen kann. In der Praxis ist die Verbreitung allerdings deutlich geringer als die der S3 API, weshalb Portabilität in konkreten Projekten meist über die jeweilige Plattform und nicht über einen Standard geklärt werden muss.
Hybride Modelle kombinieren Eigenschaften und Fehlerquellen
Zwischen reinem On-Premises-Betrieb und vollständiger Cloud-Nutzung existieren zahlreiche Mischformen, etwa ein On-Premises-Object-Storage, der Daten abhängig von Schutzbedarf, Alter oder Nutzung in einen Cloud Object Storage überführt.
Damit lassen sich theoretisch unterschiedliche Eigenschaften kombinieren. Gleichzeitig steigt die Architekturkomplexität, denn zusätzliche Fragen treten hinzu: Welches System besitzt den maßgeblichen Datenbestand? Wann und in welcher Form werden Daten übertragen, synchron oder asynchron? Wie wird Konsistenz behandelt? Was geschieht bei einem WAN-Ausfall, wie erfolgt das Failover, wie die Rückführung? Und welche Egress-Kosten entstehen dabei?
Ein zweiter Object Store ist deshalb nicht automatisch ein zweites Rechenzentrum derselben Storage-Architektur. Er ist ein zweiter Datenpfad mit eigenen Fehlerszenarien.
Fünf Architekturmodelle im Vergleich
Architektur
Kontrolle
Skalierung
Standortschutz
Kapazitätseffizienz
Betriebsverantwortung
On-Prem Single Site
hoch
eigene Erweiterung
zusätzlicher Schutz erforderlich
abhängig vom ProtectionScheme
überwiegend Betreiber
Zwei replizierte Systeme
hoch
pro Standort
durch Replikation
zusätzlicher Kapazitätsbedarf durch Kopien
Betreiber
StretchedObjectStorage
hoch
gemeinsamer Cluster
im Datenlayout integrierbar
mit EC potenziell effizienter als vollständige Standortkopien
Betreiber
Cloud ObjectStorage
geringer auf Infrastruktur-Ebene
servicebasiert
Provider-Architektur
für Kunden nicht primär als Raw/Usable-Verhältnis sichtbar
zwischen Kunde und Provider geteilt
Hybrid
abhängig vom Design
kombiniert
flexibel gestaltbar
abhängig von Datenplatzierung
geteilt und komplexer
Die Tabelle macht sichtbar, was eine Herstellerauswahl nicht beantwortet: Die Spalten stehen zueinander im Widerspruch. Höhere Kapazitätseffizienz über Standorte hinweg erkauft sich engere Kopplung. Stärkere Entkopplung der Standorte erkauft sich zusätzlichen Kapazitätsbedarf. Abgegebene Betriebsverantwortung erkauft sich neue Abhängigkeiten. Keine Zeile dominiert die anderen in allen Spalten.
Welche Zeile für eine konkrete Umgebung passt, entscheidet sich deshalb selten an der Storage-Technologie selbst. Sie entscheidet sich an Rahmenbedingungen, die vor jeder Produktauswahl feststehen müssen.
Die Fragen, die vor der Herstellerauswahl stehen
Wie groß ist der Datenbestand, wie schnell wächst er – und wie viel Rohkapazität folgt daraus?
300 TB mit geringem Wachstum stellen andere Anforderungen an Kapazitätsplanung und Hardware-Lifecycle als mehrere Petabyte mit kontinuierlichem Wachstum. Entscheidend ist dabei nicht die installierte Rohkapazität, sondern der Anteil, der nach Anwendung des gewünschten Protection Schemes tatsächlich nutzbar bleibt. Das Schutzschema gehört deshalb in die Kapazitätsplanung und nicht in einen nachgelagerten Konfigurationsschritt.
Wie aktiv sind die Daten – und wie lange leben sie?
Häufig gelesene oder permanent veränderte Daten besitzen ein anderes I/O- und Kostenprofil als langfristig unveränderte Archive oder Backup-Daten. Cloud-Preismodelle können zusätzlich Mindestmengen, Mindesthaltedauern oder unterschiedliche Storage Classes vorsehen. Häufiges Löschen und Neuschreiben erzeugt dann ein völlig anderes Kostenprofil als ein über Jahre weitgehend unveränderter Bestand.
Welche Ausfälle muss die Architektur überstehen?
Disk-Ausfall, Node-Ausfall und vollständiger Rechenzentrumsausfall sind unterschiedliche Failure Domains. Ein Schutzschema, das gegen den einen Fall wirkt, sagt über den anderen nichts aus.
Welches RPO ist erforderlich?
Eine asynchrone Kopie kann beim Ausfall hinter dem Primärsystem liegen. Eine synchrone Architektur vermeidet diesen Abstand nur unter den Bedingungen ihrer konkreten Implementierung und bindet dafür die entfernte Failure Domain enger in den Schreibpfad ein.
Wie wichtig ist Infrastrukturkontrolle?
Die Antwort beeinflusst, ob On-Premises, Cloud oder ein hybrider Ansatz organisatorisch überhaupt infrage kommt – und sie fällt, wie oben dargestellt, nicht allein anhand technischer Kriterien.
Fazit
Nicht „Cloud oder On-Premises?" ist die erste Frage
Die wichtigste Object-Storage-Entscheidung lautet nicht zwangsläufig, ob Daten in der Cloud oder im eigenen Rechenzentrum liegen. Zunächst muss geklärt werden, wie Daten geschützt, verteilt, betrieben und langfristig finanziert werden sollen. Erst daraus ergibt sich die passende Architektur.
Die von uns begleiteten Umgebungen zeigen dabei sehr unterschiedliche Entwicklungspfade: eine Architekturänderung zugunsten besserer Kapazitätsausnutzung, eine Cloud-Entscheidung aufgrund der Kosten inaktiver Daten, eine On-Premises-Entscheidung aufgrund grundsätzlicher Vorbehalte. Aus diesen Einzelbeobachtungen lässt sich keine allgemeine Überlegenheit einer Architektur ableiten. Sie zeigen etwas anderes: Je größer der Datenbestand wird, desto stärker bestimmen Datenverteilung, Redundanzmodell, Lebensdauer und Betriebsmodell die Gesamtarchitektur – und nicht allein die nominelle Speicherkapazität.
Die S3-Schnittstelle macht Object-Storage-Systeme austauschbarer auf der Zugriffsebene. Auf der Architekturebene macht sie sie nicht gleich.
Quellen
Storage Networking Industry Association (SNIA): What is Object Storage? – Objektdefinition. Abgerufen 25.08.2026.
Storage Networking Industry Association (SNIA): Cloud Data Management Interface (CDMI) – CDMI als Management- und Portabilitätsstandard. Abgerufen 25.08.2026.
ISO/IEC 17826:2022, Edition 3, 2022-05 – Cloud Data Management Interface (CDMI) Version 2.0.0.
Ceph Documentation: Architecture – CRUSH, Vermeidung zentraler Lookup-Tabellen. Abgerufen 25.08.2026.
Ceph Documentation: Erasure code – K+M-Chunks, crush-failure-domain, Anzahl erforderlicher Failure Domains, Empfehlung zu k. Abgerufen 25.08.2026.
Scality: How to fine-tune your network before deploying a stretched multi-site Scality RING architecture – Overhead-Vergleich Drei-Standort-Stretched gegenüber zwei replizierten RINGs; Netzwerkanforderungen. Herstellerangabe. Abgerufen 25.08.2026.
Amazon Web Services: Amazon Simple Storage Service User Guide – Strong Read-after-Write Consistency für PUT und DELETE in allen Regionen. Abgerufen 25.08.2026.
Wasabi Technologies: Pricing FAQ – Mindestabrechnung 1 TB, Mindest-Speicherdauer 90 Tage (Pay-as-you-Go), Timed Deleted Storage. Abgerufen 25.08.2026.
Wasabi Technologies: Hot Cloud Storage Console Documentation – Reasonable-Use-Egress-Regelung. Abgerufen 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
