WISSEN > CLOUD INFRASTRUKTUR -> FILE, BLOCK UND OBJECT STORAGE ERKLÄRT
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Cloud Storage: File, Block und Object Storage erklärt
Warum das Zugriffsmodell die Architektur bestimmt und nicht der Speicherort
Das sollten Sie mitnehmen: FALSCH FALSCH
- WAN-Latenz lässt sich nicht wegkaufen, nur umgehen.
Edge File Services sorgen dafür, dass möglichst wenige Zugriffe den WAN-Pfad durchlaufen.
- Global verfügbar heißt nicht lokal gespeichert.
Für die Cache-Größe zählt der lokale Working Set, nicht die Gesamtkapazität.
- Caching und Locking lösen zwei verschiedene Probleme.
Das eine optimiert den Weg zu den Daten, das andere koordiniert konkurrierende Schreibzugriffe. Wer nur das erste plant, bekommt das zweite als Überraschung.
- Nicht jedes Produkt kann standortübergreifend sperren.
DFS Replication und Azure File Sync bieten kein globales Locking – das entscheidet die Auswahl früher als jede Performance-Kennzahl.
- Sizing braucht Nutzungsdaten, keine Kapazitätszahlen.
Aussagekräftig sind Dateianzahl, Änderungsverhalten und Zugriffsverhalten am Standort.
Warum das Zugriffsmodell die Architektur bestimmt und nicht der Speicherort
Inhaltsverzeichnis
- Cloud beschreibt die Bereitstellung, nicht das Zugriffsmodell
- Block Storage liefert Blöcke, die Dateistruktur entsteht erst auf dem Host
- File Storage bringt den Namensraum mit, den Block Storage dem Host überlässt
- Object Storage ersetzt die Verzeichnishierarchie durch Identifier und Metadaten
- Die Modelle unterscheiden sich im Zugriffsweg, nicht in einer Rangfolge der Geschwindigkeit
- Object Storage ist nicht langsam, sondern anders zu parallelisieren
- Bestehende File-Anwendungen scheitern an der Semantik, nicht am Durchsatz
- Eine File-Service-Schicht entkoppelt Anwendungsschnittstelle und Storage-Ebene
- In ASSISTRA-Projekten trat Object Storage als Ebene auf, nicht als Ersatz
- Die Anwendung bestimmt das Zugriffsmodell, nicht der Speicherort
- Fazit
- Quellen
Cloud Storage ist keine eigene Speicherklasse. Der Begriff beschreibt zunächst nur, dass Storage-Ressourcen über eine Cloud-Infrastruktur bereitgestellt werden. Wie Anwendungen auf die gespeicherten Daten zugreifen, ist damit noch nicht entschieden.
Auch in der Cloud existieren deshalb unterschiedliche Storage-Modelle. Die drei grundlegenden Formen sind Block Storage, File Storage und Object Storage. Sie unterscheiden sich vor allem darin, welche Einheit gegenüber dem Client bereitgestellt wird: Blöcke, Dateien oder Objekte. Die Storage Networking Industry Association hat diesen Punkt in ihrer Gegenüberstellung der drei Modelle ausdrücklich festgehalten: Cloud Storage kann block-, file- oder objektbasiert sein, und Object Storage ist in Cloud-Umgebungen zwar verbreiteter als außerhalb, aber nicht mit Cloud Storage gleichzusetzen.
Diese Unterscheidung ist für die Architektur wesentlich. Eine virtuelle Maschine benötigt andere Storage-Funktionen als ein gemeinsam genutztes Dateisystem. Eine Backup-Anwendung stellt wiederum andere Anforderungen als eine Datenplattform, die große Datenbestände über eine Object-API verarbeitet. Cloud-Anbieter führen ihre Dienste deshalb entlang dieser Zugriffsmuster: IONOS etwa stellt Block Storage für virtuelle Maschinen, Network File Storage über NFS für gemeinsam genutzte Verzeichnisse und S3-kompatiblen Object Storage für unstrukturierte Daten als getrennte Produkte bereit.
Offenlegung: ASSISTRA implementiert und betreibt CTERA-Umgebungen und setzt Wasabi Cloud Object Storage in Kundenprojekten ein. Beide Hersteller sind Bestandteil unseres Portfolios; die im Kapitel zu den Projekterfahrungen genannten Beobachtungen sind vor diesem Hintergrund zu lesen.
Cloud beschreibt die Bereitstellung, nicht das Zugriffsmodell
Bei lokalem Storage wird bereits anhand der Architektur zwischen SAN, NAS und Object Storage unterschieden. In einer Cloud verschwindet diese Unterscheidung nicht, sie wird lediglich hinter verwalteten Diensten weniger sichtbar.
Das NIST beschreibt Cloud Computing in SP 800-145 als Modell für den bedarfsgerechten Netzzugriff auf einen gemeinsam genutzten Pool konfigurierbarer Ressourcen und definiert dazu wesentliche Merkmale, Servicemodelle und Bereitstellungsmodelle. Die Definition sagt nichts darüber aus, über welche Schnittstelle ein System auf gespeicherte Daten zugreift. Genau diese Frage entscheidet aber darüber, ob eine Anwendung in einer Zielarchitektur überhaupt lauffähig ist.
Wir trennen deshalb in Architekturgesprächen konsequent zwei Fragen. Die erste betrifft den Ort: Wird Storage im eigenen Rechenzentrum, in einer Public Cloud oder in einer hybriden Infrastruktur bereitgestellt? Die zweite betrifft den Zugriff: Sprechen Systeme über Block-, File- oder Object-Schnittstellen mit den Daten? Ein tragfähiges Cloud-Storage-Konzept muss beide Ebenen beantworten, und es beantwortet sie unabhängig voneinander. Der Speicherort schränkt das Zugriffsmodell nicht ein, und das Zugriffsmodell legt den Speicherort nicht fest.
[BILD 1] Schematische Gegenüberstellung der drei Datenpfade. Drei parallele horizontale Bahnen: Anwendung → Dateisystem → Block Device → Storage; Anwendung → File Client → SMB/NFS → File Service → Storage; Anwendung → Object API → Object Storage. Gleiche Startbox „Anwendung" links, unterschiedliche Zwischenstufen, gemeinsame Storage-Ebene rechts. ASSISTRA-Blauskala, Zugriffseinheit (Block, Datei, Objekt) als Beschriftung an der jeweils entscheidenden Kante.
Block Storage liefert Blöcke, die Dateistruktur entsteht erst auf dem Host
Block Storage stellt einem Client Speicher in Form adressierbarer Blöcke zur Verfügung. Die SNIA definiert Block Storage als Verfahren zur Speicherung von Daten in Blöcken und hält im selben Eintrag fest, dass die Anordnung dieser Blöcke zu Dateien durch ein Dateisystem auf dem Host erfolgt. Diese zweite Hälfte der Definition ist der eigentlich architekturrelevante Teil.
Das Betriebssystem sieht zunächst ein Block Device beziehungsweise ein Volume. Darauf können Partitionen und Dateisysteme angelegt werden. Die Datei- und Verzeichnisstruktur, die ein Benutzer später sieht, ist damit keine Eigenschaft des Storage-Systems, sondern eine Leistung der darüberliegenden Schicht. Wer Block Storage bereitstellt, stellt keinen Namensraum bereit.
Für den Blockzugriff nennt die SNIA unter anderem SCSI, SATA, Fibre Channel, iSCSI und RDMA. In einer Cloud wird diese Protokollebene meist durch einen verwalteten Dienst abstrahiert. IONOS etwa stellt Block Storage als Grundlage für Dedicated-Core-Server, vCPU-Server und Cloud Cubes bereit und ergänzt ihn um Images und Snapshots. Der Kunde provisioniert ein Volume; welches Transportprotokoll darunter arbeitet, ist für die Anwendungsarchitektur in der Regel nicht mehr sichtbar.
Eingesetzt wird Block Storage überall dort, wo ein System ein Volume erwartet: für Betriebssystem-Volumes virtueller Maschinen, für Dateisysteme innerhalb dieser Maschinen, für Datenbanken mit blockorientiertem Zugriff und für Anwendungen, die die Organisation der Daten auf dem Volume selbst übernehmen. Die konkrete Eignung hängt allerdings vom jeweiligen Dienst, seinem Leistungsprofil und vom Workload ab. Aus dem Zugriffsmodell allein lässt sich keine IOPS-, Latenz- oder Durchsatzleistung ableiten.
File Storage bringt den Namensraum mit, den Block Storage dem Host überlässt
File Storage stellt Daten als Dateien zur Verfügung. Die SNIA definiert den Begriff knapp als Verfahren zur Speicherung von Daten als Dateien und verweist ausdrücklich auf die Abgrenzung zu Block Storage.
Eine Datei besitzt einen Namen und liegt typischerweise in einer hierarchischen Struktur aus Verzeichnissen und Unterverzeichnissen. Der entscheidende Unterschied zum Block Storage besteht darin, dass die File-Service-Schicht genau die Funktionen mitbringt, die beim Block Storage erst durch ein Dateisystem auf dem Host entstehen. Der Client arbeitet unmittelbar mit Dateien und Verzeichnissen, ohne selbst ein Dateisystem betreiben zu müssen.
Die SNIA beschreibt die Zugriffsmethode für Dateien als Kombination aus Ordner, Datei und Offset. Daraus folgen zwei Eigenschaften, die im Vergleich mit Object Storage wichtig werden: File Storage erlaubt den Zugriff auf bestimmte Bereiche innerhalb einer Datei, und er erlaubt in vielen Fällen gemeinsame Schreibzugriffe mehrerer Clients auf dieselbe Datei.
Für Cloud File Storage werden die etablierten File-Protokolle weiterverwendet. IONOS stellt Network File Storage als verwalteten Dienst bereit, der mehreren virtuellen Maschinen eines virtuellen Rechenzentrums gemeinsamen Speicherplatz über NFS zur Verfügung stellt, und positioniert ihn ausdrücklich als bevorzugte Lösung für gemeinsam genutzten Speicher innerhalb eines Rechenzentrums.
Relevant ist dieses Modell überall dort, wo Anwendungen oder Benutzer eine bestehende File-System-Schnittstelle voraussetzen: bei gemeinsam genutzten Verzeichnissen, bei Anwendungen mit SMB- oder NFS-Abhängigkeit, bei Benutzerverzeichnissen und bei Workloads, die Dateien über bestehende File-System-Funktionen bearbeiten. Gerade bei Migrationen ist diese Schnittstelle der kritische Punkt. Eine Anwendung, die ein gemountetes Dateisystem und dessen Semantik erwartet, lässt sich nicht dadurch auf Object Storage umstellen, dass ihre Dateien in einen Object Store kopiert werden.
[QUERVERWEIS: Enterprise File Architectures für Multi-Site-Umgebungen]
Object Storage ersetzt die Verzeichnishierarchie durch Identifier und Metadaten
Object Storage verwendet ein anderes Datenmodell. Die SNIA beschreibt Objekte als atomare Einheiten, die im System jeweils durch einen eindeutigen Identifier adressiert werden. Eine Struktur, die einer Verzeichnishierarchie entspricht, existiert nicht; die Adressierung erfolgt über Key-Value statt über einen Pfad.
IONOS beschreibt sein Object-Storage-Angebot entsprechend als flache Struktur ohne tief verschachtelte Ordnerhierarchien und grenzt sie ausdrücklich von hierarchischen Systemen wie Block-Storage-Volumes und Disk-Dateisystemen ab. Als Schnittstelle dient dabei die S3-API, die sich als De-facto-Standard etabliert hat: Wasabi, IONOS und zahlreiche weitere Anbieter setzen sie ein, sodass bestehende S3-Clients ohne Anpassung gegen unterschiedliche Systeme arbeiten können.
Daneben existiert mit der Cloud Data Management Interface ein formaler Standard. CDMI wurde von der SNIA entwickelt und als ISO/IEC 17826 international standardisiert; die aktuelle Fassung ISO/IEC 17826:2022 entspricht CDMI 2.0.0. CDMI ist allerdings kein Gegenstück zu S3 auf der Ebene des Datenzugriffs, sondern ein herstellerneutraler Managementstandard: Er dient der protokollunabhängigen Erkennung von Namensräumen, der Verwaltung von Datenmanagement-Eigenschaften und der portablen Datenbewegung zwischen Systemen. Wer eine Object-Schnittstelle für den Zugriff sucht, findet in der Praxis S3; wer Datenmanagement über Protokollgrenzen hinweg standardisieren will, findet CDMI.
Metadaten gehören beim Objektmodell zum Objekt
Ein wesentlicher Unterschied zum reinen Blockzugriff besteht darin, dass Object Storage neben den eigentlichen Daten zusätzliche Metadaten zum Objekt verwaltet. Die SNIA beschreibt diese Metadaten als Bestandteil des Objekts, der über Objekt-ID und Nutzdaten hinausgeht.
Dadurch kann die Storage-Schicht beschreibende Informationen gemeinsam mit einem Objekt führen, ohne dafür eine Verzeichnisstruktur zu benötigen. Objekte lassen sich über ihre Metadaten suchen und in Gruppen bearbeiten, ohne dass die einzelnen Objekt-IDs bekannt sein müssen. Für Datenplattformen ist das eine der praktisch wichtigsten Eigenschaften des Modells.
[QUERVERWEIS: Object Storage wird zur Datenplattform]
Änderungen an Objekten folgen anderen Regeln als File-I/O
Auch die Änderung von Daten unterscheidet sich deutlich von einem Dateisystem. Die SNIA formuliert das ohne Einschränkung: Bei Object Storage besteht häufig keine Möglichkeit, ein Objekt oder Teile davon zu aktualisieren; in der Regel muss das gesamte Objekt neu geschrieben werden. Viele Systeme erlauben entweder nur das Anhängen am Ende eines Objekts oder gar keine Änderung nach der Erstellung. Gemeinsame Lesezugriffe sind üblich, gemeinsame Schreibzugriffe auf dasselbe Objekt sind es nicht.
Die konkrete Änderungssemantik hängt vom jeweiligen System und Objekttyp ab. Die Richtung ist jedoch eindeutig genug, um eine Fehlannahme auszuschließen: Object Storage ist nicht File Storage mit einer anderen API.
Die Modelle unterscheiden sich im Zugriffsweg, nicht in einer Rangfolge der Geschwindigkeit
Stellt man die drei Modelle nebeneinander, ergibt sich ein klares Bild entlang weniger Merkmale.
Merkmal
Block Storage
File Storage
Object Storage
Zugriffseinheit
Block
Datei
Objekt
Sicht für den Client
Volume beziehungsweise Block Device
Dateien und Verzeichnisse
Objekte über Keys
Organisation der Daten
Dateisystem des Hosts
File System beziehungsweise File Service
keine klassische Hierarchie erforderlich
Adressierung
logische Blockadresse
Ordner, Datei, Offset
Key-Value
Typische Schnittstellen
SCSI, SATA, FibreChannel, iSCSI, RDMA
SMB, NFS
HTTP-basierte Object-APIs, in der Praxis S3
Metadaten
Eigenschaft darüberliegender Schichten
File-System-Metadaten
Bestandteil des Objekts
Teiländerung innerhalb der Einheit
vorgesehen
vorgesehen
häufig nicht vorgesehen
Gemeinsame Schreibzugriffe
abhängig von der darüberliegenden Schicht
in vielen Fällen möglich
typischerweise nicht vorgesehen
Typische Nutzung
VM-Volumes, Datenbanken, Dateisysteme
gemeinsame Verzeichnisse, file-basierte Anwendungen
Backups, Archive, cloud-native Anwendungen, große Datenbestände
Diese Gegenüberstellung beschreibt Zugriffsmodelle, nicht Leistungsklassen. Aus ihr die Reihenfolge „Block schnell, File mittel, Object langsam" abzuleiten, wäre falsch. Die SNIA führt selbst das Gegenbeispiel an: In einer Tiering-Architektur kann Block Storage für kalte und File Storage für heiße Daten eingesetzt werden, und ebenso sind drei Tiers innerhalb desselben Modells möglich. Die tatsächliche Leistung hängt vom Dienst, seiner Architektur, dem Netzwerk, der Konfiguration und vor allem vom Workload ab.
Die beiden Zeilen zu Teiländerung und gemeinsamen Schreibzugriffen sind dabei die architektonisch folgenreichsten. Sie beschreiben keine Leistungsunterschiede, sondern unterschiedliche Zusicherungen — und genau daran scheitern Migrationen, die allein über Kapazität und Kosten geplant wurden.
Object Storage ist nicht langsam, sondern anders zu parallelisieren
Object Storage wird häufig pauschal mit geringer Performance gleichgesetzt. Diese Vereinfachung führt in Architekturentscheidungen regelmäßig in die Irre.
Object-Storage-Systeme sind verteilte Systeme, und ihre Leistung erschließt sich über Parallelität statt über Einzeloperationen. Wasabi dokumentiert für seinen Dienst die Multipart-Upload-Funktion der S3-API, bei der eine große Datei in separate Teile zerlegt, unabhängig übertragen und nach Abschluss wieder als eine Datei zusammengesetzt wird. Der Vorteil liegt nicht nur in der Effizienz der Übertragung, sondern auch in der Fehlerbehandlung: Bricht eine Übertragung ab, kann die Anwendung mit dem fehlgeschlagenen Teil fortsetzen, statt von vorne zu beginnen. Dasselbe Prinzip gilt in der Gegenrichtung, wenn Anwendungen mehrere Objekte oder Teilbereiche gleichzeitig abrufen.
Damit verschiebt sich die Frage. Leistung hängt beim Object Storage nicht in erster Linie vom Medium ab, sondern davon, ob eine Anwendung für das Zugriffsmodell des Storage-Systems ausgelegt ist. Ein Workload mit vielen voneinander unabhängigen Object Requests kann Object Storage vollständig ausreizen. Eine klassische Anwendung, die zahlreiche kleinteilige File-System-Operationen absetzt und dabei auf niedrige Einzellatenzen angewiesen ist, kann es nicht — unabhängig davon, wie hoch der aggregierte Durchsatz des Systems ist.
Die architektonisch tragfähige Frage lautet deshalb nicht, welcher Storage schneller ist, sondern welches Zugriffsmodell dem I/O-Verhalten der Anwendung entspricht.
[QUERVERWEIS: High-Performance Data Access]
Bestehende File-Anwendungen scheitern an der Semantik, nicht am Durchsatz
File und Object Storage unterscheiden sich nicht nur in der technischen Schnittstelle, sondern in den Zusicherungen, die sie einer Anwendung geben.
Eine bestehende File-Anwendung kann hierarchische Verzeichnisse voraussetzen, einen File-System-Namensraum, SMB oder NFS, bestimmte File-System-Operationen, Änderungen innerhalb bestehender Dateien, bestimmte Locking- oder Konsistenzmechanismen und niedrige Latenzen für einzelne Operationen. Eine Object-API bietet nichts davon automatisch, und bei den Punkten Teiländerung und gemeinsamer Schreibzugriff bietet sie es nach der SNIA-Beschreibung des Modells typischerweise gar nicht.
Hohe aggregierte Object-Storage-Durchsätze lösen dieses Problem nicht, weil es kein Durchsatzproblem ist. Die Anwendung muss das Object-Zugriffsmodell nutzen können, und ihr I/O-Muster muss zur Architektur des jeweiligen Object Stores passen. Wo beides nicht gegeben ist, führt eine direkte Umstellung zu Funktionsfehlern, nicht zu langsamerem Betrieb.
Eine File-Service-Schicht entkoppelt Anwendungsschnittstelle und Storage-Ebene
Aus diesem Befund folgt kein Entweder-oder. File Storage und Object Storage müssen keine konkurrierenden Alternativen sein.
Ein System kann gegenüber Clients eine File-Schnittstelle bereitstellen und intern Object Storage als persistente Storage-Ebene verwenden. Die File-Service-Schicht stellt dabei Namensraum, File-Zugriff und File-Protokolle bereit; die Object-Storage-Schicht übernimmt die persistente Speicherung der Datenobjekte. Welche zusätzlichen Funktionen dazwischen erforderlich sind — Caching, Metadatenverwaltung, Synchronisation, Konsistenzmechanismen —, hängt von der Implementierung ab und ist der eigentliche Gegenstand der Produktauswahl auf dieser Ebene.
Die SNIA stützt diese Trennung ausdrücklich: Manche Object-Storage-Systeme legen die zugrundeliegenden Daten als Dateien ab, manche File-Storage-Systeme legen sie als Objekte ab. Für Kunden und Anwendungen zählen die Zugriffsmethode, die Leistung und die Verfügbarkeit, nicht das darunterliegende Speicherverfahren. Die gegenüber einer Anwendung bereitgestellte Schnittstelle und die physische Speicherung sind getrennte Architekturentscheidungen.
Wir behandeln diese Schicht deshalb nicht als Notlösung für Migrationsfälle, sondern als eigenständiges Architekturelement. Sie erlaubt es, die Anforderungen der Anwendungsseite und die Eigenschaften der Storage-Seite unabhängig voneinander zu optimieren, statt eine Seite der anderen zu opfern.
[BILD 2] Schichtmodell File Service über Object Storage. Von oben nach unten: Clients (SMB/NFS), File-Service-Schicht mit den Funktionsblöcken Namespace, Protokolle, Caching, Metadaten, darunter Object-Storage-Ebene als persistente Speicherung. Rechts eine gestrichelte vertikale Linie mit der Beschriftung „getrennte Architekturentscheidungen", die die Schnittstellenebene von der Speicherebene abgrenzt.
[QUERVERWEIS: S3 als gemeinsame Zugriffsschicht]
In ASSISTRA-Projekten trat Object Storage als Ebene auf, nicht als Ersatz
In den von uns begleiteten Projekten hat sich diese Trennung zwischen File- und Object-Ebene konkret gezeigt.
Object Storage wurde dabei unter anderem als Storage-Ebene von File Services eingesetzt. In einer Architektur wurde ein CTERA Global File System innerhalb einer AWS-Cloud-Umgebung betrieben. In einer anderen Konstellation lief das Global File System im eigenen Rechenzentrum, während Azure Blob Storage als Storage-Ebene diente. Für Benutzer und Anwendungen blieb in beiden Fällen eine File-Service-Schicht erhalten; Object Storage war Bestandteil der darunterliegenden Dateninfrastruktur, nicht der Anwendungsschnittstelle.
Eine zweite beobachtete Nutzung von Cloud Object Storage war der Einsatz als Backup Target. In entsprechenden Kundenkonstellationen wurden für diese Aufgabe zuvor auch blockbasierte Storage-Ziele verwendet. Diese Beobachtung beschreibt die konkreten Projekte und ist nicht als allgemeine Aussage über die Entwicklung des Backup-Marktes zu verstehen.
Bei bestehenden File-Workloads zeigte sich außerdem, dass eine direkte Umstellung auf Object Storage nur selten praktikabel war. Die Ursache lag dabei nicht in einer grundsätzlich niedrigeren Performance des Object Storage. Entscheidend waren die Unterschiede zwischen File- und Object-Zugriffsmodell sowie das Verhalten des jeweiligen Workloads. Eine zusätzliche File-Service-Schicht konnte diese Modelle voneinander entkoppeln.
Eine Grenze dieser Projekterfahrung ist dabei zu benennen: Die Kunden kamen in den bisherigen Fällen typischerweise bereits mit einer grundsätzlichen Storage-Entscheidung oder -Präferenz zu uns. Ein vollständig technologieoffener Auswahlprozess zwischen Block, File und Object war nicht Bestandteil dieser Projekte. Die Beobachtungen sagen deshalb etwas über die Umsetzbarkeit bestimmter Zielarchitekturen aus, nicht über die relative Häufigkeit der drei Modelle im Markt.
[QUERVERWEIS: Global File System — wann ist es sinnvoll?]
Die Anwendung bestimmt das Zugriffsmodell, nicht der Speicherort
Die Entscheidung sollte deshalb bei der Anwendung beginnen und nicht beim Anbieter. Benötigt sie ein Block Device, ist Block Storage der Ausgangspunkt. Benötigt sie Dateien, Verzeichnisse und ein File-Protokoll, wird eine File-Service-Schicht benötigt — unabhängig davon, was darunter liegt. Kann sie Daten unmittelbar als Objekte über eine API verarbeiten, lässt sich Object Storage direkt in die Anwendungsarchitektur integrieren.
Erst danach werden die quantitativen Anforderungen relevant. Dazu gehören das I/O-Muster, Latenz, IOPS und Durchsatz, der mögliche Grad der Parallelisierung, Größe und Anzahl der Dateien beziehungsweise Objekte, gemeinsame Zugriffe und Konsistenzanforderungen, der Datenlebenszyklus, Backup und Recovery, die Skalierungsanforderungen sowie Netzwerk, Datenlokalität und das Kostenmodell des jeweiligen Dienstes. Erst aus der Kombination dieser Anforderungen lässt sich eine konkrete Storage-Architektur ableiten.
Die verbreitete umgekehrte Reihenfolge — zuerst den Cloud-Anbieter wählen, dann den günstigsten Storage-Dienst, dann die Anwendung anpassen — erzeugt genau die Migrationsprobleme, die sich mit einer Betrachtung des Zugriffsmodells vorab vermeiden lassen.
[QUERVERWEIS: Storage-Entscheidungen beginnen nicht beim Storage]
Fazit
Cloud Storage bezeichnet keinen einzelnen Storage-Typ. Block, File und Object Storage stellen unterschiedliche Daten- und Zugriffsmodelle bereit: Block Storage liefert adressierbare Blöcke und überlässt die Dateiorganisation dem Host, File Storage abstrahiert Daten als Dateien in einem Namensraum, Object Storage verwaltet sie als individuell adressierbare Objekte mit eigenen Metadaten.
Welche Variante geeignet ist, hängt nicht davon ab, ob Daten in einer Cloud liegen, sondern davon, wie Anwendungen auf diese Daten zugreifen müssen. Die Unterschiede sind dabei nicht graduell, sondern semantisch: Wo ein Modell gemeinsame Schreibzugriffe oder Teiländerungen nicht vorsieht, hilft kein höherer Durchsatz.
Gleichzeitig müssen die Modelle nicht isoliert eingesetzt werden. Die Kombination einer File-Service-Schicht mit Object Storage zeigt, dass die gegenüber einer Anwendung bereitgestellte Schnittstelle und die darunterliegende Storage-Ebene getrennte Architekturentscheidungen sind. Unsere Projekterfahrung bestätigt diese Trennung: Object Storage trat sowohl als Backup-Ziel als auch als Storage-Ebene für File Services auf. Bei bestehenden File-Anwendungen war dagegen regelmäßig eine Vermittlungsschicht erforderlich, wenn Object Storage Bestandteil der Zielarchitektur werden sollte.
Quellen
National Institute of Standards and Technology (NIST): Mell, P.; Grance, T.: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, September 2011. DOI 10.6028/NIST.SP.800-145. https://doi.org/10.6028/NIST.SP.800-145
National Institute of Standards and Technology (NIST): Liu, F.; Tong, J.; Mao, J.; Bohn, R.; Messina, J.; Badger, L.; Leaf, D.: NIST Cloud Computing Reference Architecture. NIST Special Publication 500-292, September 2011. DOI 10.6028/NIST.SP.500-292. https://doi.org/10.6028/NIST.SP.500-292
ISO/IEC: ISO/IEC 22123-1:2023 – Information technology — Cloud computing — Part 1: Vocabulary. Edition 2, Februar 2023. ISO/IEC JTC 1/SC 38. Ersetzt ISO/IEC 17788:2014 und ISO/IEC 22123-1:2021. https://www.iso.org/standard/82758.html
ISO/IEC: ISO/IEC 22123-2:2023 – Information technology — Cloud computing — Part 2: Concepts. Edition 1, 2023. ISO/IEC JTC 1/SC 38. https://www.iso.org/standard/80351.html
Europäische Union: Verordnung (EU) 2023/2854 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung (Data Act). Amtsblatt der Europäischen Union, 22. Dezember 2023. Hier insbesondere Artikel 29 (schrittweiser Wegfall der Wechselentgelte) und Artikel 34 Absatz 2 (Datenausleitungskosten bei parallelem Betrieb).
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
