WISSEN > CLOUD INFRASTRUKTUR > BLOCK, FILE & OBJECT
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Cloud Storage ist ein Bezugsweg, kein Speichermodell
Block, File und Object bleiben auch in der Cloud drei verschiedene Zugriffsmodelle
Das sollten Sie mitnehmen:
- Cloud beschreibt den Bezugsweg, nicht das Speichermodell.
File, Block und Object beschreiben unterschiedliche Formen der Speicherung und des Datenzugriffs.
- Block Storage stellt Blöcke bereit.
Ein Betriebssystem oder eine Anwendung baut darauf ein Dateisystem auf.
- File Storage stellt Dateien und Verzeichnisse bereit.
Clients greifen typischerweise über SMB oder NFS darauf zu.
- Object Storage adressiert über Identifier statt über Pfade.
Anwendungen sprechen Objekte über Keys an, üblicherweise über HTTP-basierte APIs.
- Die drei Modelle sind nicht beliebig austauschbar.
Anwendungen, Protokolle und I/O-Muster bestimmen, welches Zugriffsmodell gebraucht wird. Eine zusätzliche File-Service-Schicht kann Object Storage für Anwendungen nutzbar machen, die weiterhin eine File-Schnittstelle benötigen.
Cloud Storage ist ein Bezugsweg, kein Speichermodell
Inhaltsverzeichnis
- Zwei Fragen, die getrennt beantwortet werden müssen
- Block Storage liefert Blöcke, keine Dateien
- File Storage bringt den Namensraum mit
- Object Storage adressiert über Identifier statt über Pfade
- Metadaten und Änderungssemantik trennen Object von File
- Die Gegenüberstellung beschreibt Zugriff, nicht Tempo
- Warum Object Storage nicht grundsätzlich langsamer ist
- Warum File-Anwendungen den Umzug selten unbeschadet überstehen
- File Services und Object Storage schließen sich nicht aus
- Was wir in ASSISTRA-Projekten beobachtet haben
- Fazit
- Quellen
Cloud Storage ist keine eigene Speicherklasse. Der Begriff beschreibt zunächst nur, dass Storage-Ressourcen über eine Cloud-Infrastruktur bezogen werden. Wie Anwendungen auf die gespeicherten Daten zugreifen, ist damit noch nicht entschieden.
Diese Frage entscheidet sich an anderer Stelle. Auch in der Cloud existieren mit Block Storage, File Storage und Object Storage drei grundlegend verschiedene Modelle, die sich darin unterscheiden, welche Einheit gegenüber dem Client bereitgestellt wird: Blöcke, Dateien oder Objekte.
Zwei Fragen, die getrennt beantwortet werden müssen
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.
Die Anbieter selbst gliedern ihr Portfolio entlang genau dieser Linien. IONOS führt Block Storage, Network File Storage und Object Storage als getrennte Dienste, und die Trennung reicht bis in die Bereitstellungseinheit hinein: Ein Block-Volume wird einem Server zugeordnet, ein NFS-Cluster stellt Shares bereit, die mehrere virtuelle Maschinen einbinden, und ein Bucket ist über einen HTTPS-Endpunkt erreichbar. Zugleich zeigt der Markt, dass ein Anbieter nicht alle drei Modelle führen muss: Wasabi bietet mit Hot Cloud Storage einen einzigen Object-Storage-Dienst ohne Storage-Klassen an. Die Modellgrenzen sind also keine Erfindung der Fachliteratur, sondern strukturieren die Produktkataloge.
Wie unscharf der Sprachgebrauch selbst in Produktdokumentationen bleibt, zeigt ein Detail derselben Quelle: Die Übersichtsseite zum IONOS Block Storage beginnt mit der Aussage, Block Storage sei eine Architektur, in der Daten als Dateisystem gespeichert werden, um zwei Absätze später korrekt zu beschreiben, dass das virtuelle Storage-Gerät einem iSCSI-Blockgerät entspricht und im Betriebssystem des Servers konfiguriert wird. Genau deshalb lohnt es sich, die Begriffe in einem Architekturkonzept selbst zu definieren, statt sie aus Produktnamen zu übernehmen.
Daraus folgt eine Trennung, die jedes Cloud-Storage-Konzept leisten muss. Die erste Frage lautet, wo der Storage bereitgestellt wird — im eigenen Rechenzentrum, in einer Public Cloud oder in einer hybriden Infrastruktur. Die zweite Frage lautet, wie Systeme auf die Daten zugreifen. Hier kommen Block-, File- und Object-Schnittstellen ins Spiel. Wer nur die erste Frage beantwortet, hat noch keine Storage-Architektur beschrieben.
[QUERVERWEIS: Hybrid Cloud Storage — Architekturmuster zwischen Rechenzentrum und Cloud]
Block Storage liefert Blöcke, keine Dateien
Block Storage stellt einem Client Speicher in Form adressierbarer Blöcke zur Verfügung.
Die Storage Networking Industry Association definiert Block Storage als Methode, Daten in Blöcken zu speichern. Plattenlaufwerke arbeiten dabei typischerweise mit fester Blockgröße, etwa 512 oder 4.096 Byte, während Bandlaufwerke auch variable Blockgrößen bereitstellen können. Entscheidend für das Verständnis ist der nächste Satz der Definition: Die Anordnung dieser Blöcke zu Dateien erfolgt durch ein Dateisystem auf dem Host. Als Zugriffsprotokolle nennt die SNIA unter anderem SCSI, Fibre Channel, iSCSI und RDMA.
Das Betriebssystem sieht damit zunächst ein Block Device beziehungsweise Volume. Darauf lassen sich Partitionen und Dateisysteme anlegen. Die Datei- und Verzeichnisstruktur, die ein Benutzer später sieht, entsteht also nicht im Storage-System, sondern eine Ebene darüber.
[BILD: Drei Datenpfade im Vergleich — Block, File und Object. Jeweils von der Anwendung bis zur Storage-Ebene, mit Kennzeichnung, auf welcher Ebene die Datei- und Verzeichnisstruktur entsteht.]
In einer Cloud wird diese Komplexität durch verwaltete Dienste abstrahiert, ohne dass sich am Modell etwas ändert. IONOS beschreibt das bereitgestellte virtuelle Storage-Gerät ausdrücklich als Äquivalent eines iSCSI-Blockgeräts, das sich wie direkt angebundener Speicher verhält und innerhalb des Server-Betriebssystems konfiguriert und verwaltet wird. Die Volumes werden unabhängig von den Servern verwaltet, lassen sich mit einem Image belegen und in Kombination anhängen — bis zu 24 Stück pro Server, in beliebiger Mischung der Leistungsklassen. Was der Gast sieht, bleibt ein Block Device.
Eingesetzt wird Block Storage entsprechend überall dort, wo ein System ein eigenes Volume benötigt: 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.
Aus dem Zugriffsmodell allein lässt sich allerdings keine Leistung ableiten. Welche IOPS-, Latenz- oder Durchsatzwerte erreicht werden, hängt vom konkreten Dienst, dessen Leistungsprofil und vom Workload ab.
File Storage bringt den Namensraum mit
File Storage stellt Daten als Dateien zur Verfügung. Die SNIA fasst den Begriff entsprechend knapp als Methode, Daten als Dateien zu speichern.
In der praktischen Ausprägung kommt zu dieser Definition erheblich mehr hinzu. Eine Datei trägt einen Namen und liegt üblicherweise innerhalb eines hierarchischen Namensraums aus Verzeichnissen und Unterverzeichnissen. Wer eine Datei adressieren will, tut das über ihren Pfad in dieser Hierarchie. Zugriffsrechte, Zeitstempel und weitere Attribute verwaltet das Dateisystem beziehungsweise der File Service.
Damit übernimmt die File-Ebene Funktionen, die beim Block Storage erst durch ein darüberliegendes Dateisystem auf dem Host entstehen. Bei einem Netzwerk-Dateisystem liegt diese Ebene nicht mehr auf dem Client, sondern im bereitstellenden System. Der Client arbeitet unmittelbar mit Dateien und Verzeichnissen, ohne selbst ein Dateisystem auf einem Volume anzulegen.
Wie weitreichend diese Zusagen sind, zeigt die Protokollspezifikation. NFS in der Fassung 4.1 beschreibt einen Server als die Instanz, die den Zugriff mehrerer Clients auf eine Menge von Dateisystemen koordiniert, und regelt dabei unter anderem, unter welchen Bedingungen Lock-Zustände über mehrere Verbindungen hinweg geteilt werden können. Ein File Service verwaltet also nicht nur Daten, sondern auch Zustand — und genau dieser Zustand ist der Grund, warum sich File-Zugriff nicht beliebig auf andere Modelle abbilden lässt.
Für Cloud File Storage werden diese etablierten Protokolle weiterverwendet. Der Network-File-Storage-Dienst von IONOS stellt Shares über NFSv4.2 in einem privaten Netz bereit, wobei ein Share ein eigenes Dateisystem innerhalb eines Clusters ist, das virtuelle Maschinen einbinden. Die Dokumentation nennt dabei genau die Merkmale, die das File-Modell ausmachen: feingranulare POSIX-Berechtigungen auf Datei- und Verzeichnisebene, gleichzeitigen Zugriff mehrerer Compute-Instanzen auf dieselben Daten und eine Hochverfügbarkeit, die über eine gemeinsame IP-Adresse zweier Knoten realisiert wird.
Genau dieser Punkt macht die Schnittstelle zur Architekturentscheidung: Ein File Service ist über das Protokoll definiert, das er spricht. Ein Dienst, der NFS bereitstellt, bedient damit keine Anwendung, die SMB-Semantik und Windows-ACLs voraussetzt — unabhängig davon, ob er in einer Cloud oder im eigenen Rechenzentrum betrieben wird.
Relevant wird dieses Modell überall dort, wo Anwendungen oder Benutzer eine bestehende File-System-Schnittstelle erwarten: 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 entscheidet diese Schnittstelle über den Aufwand. 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 Services — Architekturen für verteilte Standorte]
Object Storage adressiert über Identifier statt über Pfade
Object Storage verwendet ein anderes Datenmodell.
Die SNIA beschreibt Object Storage als Verfahren, bei dem Daten als einzeln identifizierbare, unteilbare Objekte gespeichert und wieder abgerufen werden. Objekte gelten dabei als atomare Einheit. Eine Struktur, die der Verzeichnishierarchie eines Dateisystems entspräche, existiert nicht; jedes Objekt wird über einen eindeutigen Identifier angesprochen. Sammlungen von Objekten lassen sich über diese Identifier durchsuchen und filtern, ohne dass die einzelnen Identifier vorab bekannt sein müssen.
Anders als bei einem klassischen File System muss die Anwendung ein Objekt also nicht über einen Pfad innerhalb einer Hierarchie finden. Das Object-Storage-System verwaltet Objekte über Identifier beziehungsweise Keys. IONOS stellt diesen Unterschied in der eigenen Produktdokumentation genau so dar und grenzt die flache Struktur des Object Storage ausdrücklich gegen hierarchische Systeme wie Block-Volumes und Dateisysteme ab.
Bei den Zugriffsschnittstellen ist die Lage besonders zu betrachten, weil hier kein Normungsgremium den Ton angibt. Die verbreitetste Object-Schnittstelle ist die S3-API. Sie wurde von einem Anbieter für den eigenen Dienst entwickelt und ist keine Spezifikation einer Standardisierungsorganisation. Da zahlreiche Anbieter ihre Systeme an dieser Schnittstelle ausgerichtet haben, hat sie sich faktisch zum Quasi-Standard für den Object-Zugriff entwickelt — IONOS bezeichnet sie in der eigenen Dokumentation als den globalen Standard für ObjectStorage und attestiert dem eigenen Dienst einen der höchsten Unterstützungsgrade.
Die Bezeichnung „S3-kompatibel" beschreibt dabei allerdings keine zertifizierte Konformität. Wie groß die Spannweite ist, lässt sich an derselben Quelle ablesen: Die veröffentlichte Feature-Matrix führt Funktionen auf, die gar nicht unterstützt werden, darunter Security Token Service, Bucket Notifications, Bucket Metrics und Multi-Faktor-Authentifizierung. Andere Funktionen wie Bucket Tagging oder Block Public Access stehen ausschließlich über die API zur Verfügung, nicht über die Weboberfläche. Und der abgedeckte Funktionsumfang unterscheidet sich innerhalb eines einzigen Dienstes zwischen den beiden Bucket-Typen: Object Ownership, Bucket Inventory und Access Logging stehen nur für Buckets im Besitz eines Benutzers zur Verfügung, ObjectQuery dagegen nur für vertragsgebundene Buckets.
Andere Anbieter verfolgen dasselbe Datenmodell über eigene HTTP-basierte APIs. Die Gleichartigkeit betrifft dann das Modell, nicht die Schnittstelle: Eine Anwendung, die gegen eine bestimmte Object-API entwickelt wurde, spricht eine andere nicht ohne Übersetzungsschicht an. Für Architekturentscheidungen ist diese Unterscheidung wesentlicher als die Frage, welcher Anbieter den Speicher stellt.
[QUERVERWEIS: S3 als Zugriffsschicht auf Object Storage]
Metadaten und Änderungssemantik trennen Object von File
Ein wesentlicher Unterschied zum reinen Blockzugriff besteht darin, dass Object Storage neben den Daten selbst zusätzliche Metadaten zum Objekt verwalten kann. Die SNIA beschreibt diese typischerweise als Attribut-Wert-Paare, die Teil des Objekts sind und über den Identifier und die eigentlichen Daten hinausgehen. Die Storage-Schicht kann Informationen damit gemeinsam mit einem Objekt führen, ohne dafür die Verzeichnisstruktur eines File Systems zu benötigen.
Deutlicher noch fällt der Unterschied bei Änderungen aus. Häufig besteht laut SNIA keine Möglichkeit, ein Objekt oder Teile davon zu aktualisieren, sodass in der Regel das gesamte Objekt neu geschrieben werden muss. Lesend lässt sich dagegen sowohl das vollständige Objekt als auch ein Teil davon anfordern.
Dass große Objekte in Teilen übertragen werden, ändert daran nichts. Wasabi unterstützt den Multipart-Upload der S3-API, bei dem eine große Datei in Teile zwischen 5 MB und 5 GB zerlegt, parallel übertragen und nach einem Abbruch mit dem fehlgeschlagenen Teil fortgesetzt werden kann. Zusammengesetzt werden diese Teile jedoch erst beim Commit, und das Ergebnis ist ein Objekt. Die Teilung betrifft den Transport, nicht die Änderbarkeit des gespeicherten Objekts. Wie stark diese Semantik in die Anwendungsebene durchschlägt, zeigt die Dokumentation von s3fs, einem verbreiteten FUSE-Treiber für S3-kompatible Speicher: Wahlfreie Schreibzugriffe oder Anhängen an eine Datei erfordern dort das Neuschreiben des gesamten Objekts.
Wie streng das im Einzelfall ausfällt, hängt vom System ab. Wer eine Anwendung migriert, muss diese Semantik im konkreten Zielsystem prüfen, statt sie aus dem Begriff „Object Storage" abzuleiten.
Object Storage als „File Storage mit einer anderen API" zu verstehen, greift deshalb zu kurz.
Die Gegenüberstellung beschreibt Zugriff, nicht Tempo
Merkmal
Block Storage
File Storage
Object Storage
Zugriffseinheit
Block
Datei
Objekt
Sicht für Client
Volume/Block Device
Dateien und Verzeichnisse
Objekte/Keys
Organisation der Dateien
Dateisystem des Hosts
File System/File Service
keine File-System-Hierarchie erforderlich
Typische Schnittstellen
SCSI, Fibre Channel, iSCSI, RDMA
SMB, NFS
HTTP-/Object-APIs
Metadaten
abhängig von darüberliegenden Schichten
File-System-Metadaten
objektbezogene Metadaten
Typische Nutzung
VM-Volumes, Datenbanken, Dateisysteme
Shared Files, file-basierte Anwendungen
Backups, Archive, Cloud-native Anwendungen
Zugriff durch Anwendung
über Dateisystem oder direktes Block-I/O
über File-System-Schnittstelle
über Object API
Die Tabelle beschreibt Zugriffsmodelle, nicht deren absolute Leistung. Die Ableitung, Block Storage sei schnell, File Storage mittelmäßig und Object Storage langsam, lässt sich aus ihr nicht ziehen.
Wie weit die Werte innerhalb eines einzigen Zugriffsmodells auseinandergehen, zeigt der Blick in ein Preis- und Leistungsblatt. IONOS führt für Block Storage drei Leistungsklassen. In der günstigsten Klasse ist die Leistung statisch und unabhängig von der Volume-Größe; in den beiden SSD-basierten Klassen skaliert sie dagegen mit der Kapazität und wird in IOPS pro Gigabyte angegeben, bis zu einer Obergrenze pro Volume. Die höchsten dokumentierten Werte für wahlfreie Zugriffe setzen zusätzlich eine Mindestausstattung der virtuellen Maschine mit Kernen und Arbeitsspeicher voraus. Ein und dasselbe Zugriffsmodell liefert bei einem einzigen Anbieter also Leistungswerte, die um mehr als eine Größenordnung auseinanderliegen — abhängig von Klasse, Volume-Größe und Konfiguration der Recheninstanz.
Warum Object Storage nicht grundsätzlich langsamer ist
Object Storage wird trotzdem regelmäßig mit geringer Performance gleichgesetzt. Diese Vereinfachung hält technisch nicht stand.
Große Object-Dienste sind verteilte Systeme, deren Leistung sich erst über Parallelität erschließt. Der Multipart-Mechanismus der S3-API ist genau dafür gebaut: Ein großes Objekt wird in Teile zerlegt, die gleichzeitig übertragen werden können, wobei sich ein abgebrochener Transfer beim betroffenen Teil fortsetzen lässt. Wasabi dokumentiert darüber hinaus, dass parallel zum laufenden Upload lesende Zugriffe erfolgen können, um die verfügbare Bandbreite auszunutzen. Umgekehrt zeigt sich Latenz dort, wo ein Workload viele kleine, voneinander abhängige Operationen ausführt: Die s3fs-Dokumentation weist ausdrücklich darauf hin, dass Metadatenoperationen wie das Auflisten von Verzeichnissen schwache Leistung zeigen, weil jede dieser Operationen über das Netz läuft.
Beide Beobachtungen zeigen dasselbe: Ein Object Store hat kein festes Tempo, sondern ein Zugriffsprofil. Wer ihn sequenziell und einzelrequestweise anspricht, sieht Latenz. Wer ihn parallel anspricht, sieht Durchsatz.
Damit verschiebt sich der eigentliche Punkt. Performance hängt nicht allein vom Speichermedium ab, sondern davon, ob eine Anwendung für das Zugriffsmodell des Storage-Systems ausgelegt ist. Ein Workload mit vielen voneinander unabhängigen Object Requests nutzt Object Storage anders aus als eine klassische Anwendung, die zahlreiche File-System-Operationen erwartet. Die brauchbare Frage lautet deshalb nicht, welcher Storage schneller ist, sondern welches Zugriffsmodell dem I/O-Verhalten der Anwendung entspricht.
[QUERVERWEIS: Hochperformanter Datenzugriff — Architekturen für anspruchsvolle Workloads]
Warum File-Anwendungen den Umzug selten unbeschadet überstehen
File und Object Storage unterscheiden sich nicht nur in der technischen Schnittstelle, sondern in den Zusagen, die sie einer Anwendung machen.
Eine bestehende File-Anwendung kann hierarchische Verzeichnisse voraussetzen, File-System-Namensräume, SMB oder NFS, bestimmte File-System-Operationen, Änderungen innerhalb bestehender Dateien, definierte Locking- oder Konsistenzmechanismen und geringe Latenzen für einzelne File-Operationen. Eine Object-API bietet nicht automatisch dieselbe Semantik. Die s3fs-Dokumentation formuliert das für den Mount-Fall unmissverständlich: Ein S3-kompatibler Object Store kann Leistung und Semantik eines lokalen Dateisystems nicht in gleicher Weise bereitstellen. Sie nennt dabei auch einen Punkt, der bei S3-kompatiblen Diensten jenseits des ursprünglichen Anbieters ausdrücklich offenbleibt: Konsistenzgarantien können abweichen, sodass ein Lesezugriff vorübergehend veraltete Daten liefert.
Hohe aggregierte Durchsätze lösen dieses Problem nicht. Die Anwendung muss das Object-Zugriffsmodellnutzen können, und ihr I/O-Muster muss zur Architektur des jeweiligen Object Stores passen. Wo das nicht gegeben ist, bleibt eine Möglichkeit: eine File-Service-Schicht zwischen Anwendung und Object Storage einzufügen.
[BILD: File-Service-Schicht zwischen Client und Object Storage. Client über SMB/NFS zur File-Service-Schicht, von dort über Object-API zur Storage-Ebene. Kennzeichnung, dass die Anwendung weiterhin mit Dateien arbeitet.]
Die Anwendung arbeitet dann weiterhin mit Dateien, während eine zusätzliche Systemschicht die Abbildung auf Object Storage übernimmt. Das ist technisch etwas anderes als ein direkter Zugriff der Anwendung auf einen Object Store — und diese Unterscheidung sollte in einer Zielarchitektur benannt werden, statt in der Formulierung „wir gehen auf Object Storage" zu verschwinden.
File Services und Object Storage schließen sich nicht aus
Daraus ergibt sich ein Architekturgrundsatz, der in Auswahlgesprächen häufig übersehen wird: 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, während die Object-Storage-Schicht die persistente Speicherung der Datenobjekte übernimmt. Welche zusätzlichen Funktionen dazwischen nötig sind — Caching, Metadatenverwaltung, Synchronisation, Konsistenzmechanismen — hängt von der jeweiligen Implementierung ab.
Die SNIA weist in dieselbe Richtung: Wie Objekte gespeichert werden, ist für die Anwendung unerheblich, und viele Systeme nutzen intern file- oder blockbasierten Storage. Die gegenüber der Anwendung bereitgestellte Schnittstelle und die darunterliegende Speicherform sind getrennte Entscheidungen.
Das Muster ist nicht auf spezialisierte Produkte beschränkt, und die Anbieter selbst führen es vor. Wasabi dokumentiert für den eigenen Dienst mehrere Wege, einen Bucket als Dateisystem einzubinden, unter anderem über die FUSE-Treiber s3fs und GeeseFS. Und mit Wasabi Cloud NAS besteht ein Produkt, das die File-Seite ausdrücklich adressiert.
Genau dieses Produkt zeigt allerdings auch, wie viel Architektur eine solche Vermittlung erfordert. Nach der Herstellerdokumentation ist die Quelle ein NTFS- oder ReFS-Volume beziehungsweise eine per SMB oder NFS erreichbare Freigabe, die mit einem Bucket gepaart wird. Zwischen Quelle und Bucket liegt ein lokaler Ordner mit Stub-Dateien, die als Platzhalter auf ausgelagerte Inhalte verweisen; er fungiert als Gateway und soll mindestens 15 Prozent der Kapazität der Quelle umfassen. Damit Benutzer und Anwendungen ausgelagerte Dateien bei Bedarf abrufen können, muss dieser Ordner selbst wieder über SMB oder NFS exportiert werden, und eine lokale Datenbank verfolgt die verwalteten Dateien — bei einer Million Dateien in der Größenordnung von 100 MB. Die File-Schnittstelle bleibt hier also ein echtes Dateisystem, und Object Storage übernimmt die Rolle der dahinterliegenden Storage-Ebene.
Genau hier liegt der Punkt, der in Architekturentscheidungen zählt: Eine Vermittlungsschicht liefert nicht automatisch vollständige File-Semantik, und sie ist nicht kostenlos. Wer eine File-Anwendung auf eine solche Schicht setzt, prüft deshalb nicht, ob sie eine File-Schnittstelle bietet, sondern welche File-Funktionen sie tatsächlich abbildet und welche Voraussetzungen sie ihrerseits mitbringt.
[QUERVERWEIS: Object Storage als Datenplattform]
Was wir in ASSISTRA-Projekten beobachtet haben
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 haben wir ein CTERA Global File System innerhalb einer Public-Cloud-Umgebung betrieben. In einer anderen Konstellation lief das Global File System im eigenen Rechenzentrum, während der Object Storage eines Cloud-Anbieters als Storage-Ebene diente. Für Benutzer und Anwendungen blieb in beiden Fällen eine File-Service-Schicht erhalten, während Object Storage Bestandteil der darunterliegenden Dateninfrastruktur war.
Eine weitere beobachtete Nutzung war der Einsatz als Backup Target. In entsprechenden Kundenkonstellationen wurden für diese Aufgabe zuvor auch blockbasierte 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 war eine direkte Umstellung auf Object Storage dagegen nur selten praktikabel. Die Ursache lag dabei nach unserer Beobachtung nicht in einer grundsätzlich niedrigeren Performance von 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 benennen wir bewusst: Die Kunden kamen in den bisherigen Fällen typischerweise bereits mit einer grundsätzlichen Storage-Entscheidung beziehungsweise Präferenz zu uns. Ein vollständig technologieoffener Auswahlprozess zwischen Block, File und Object war deshalb nicht Bestandteil dieser Projekte.
[QUERVERWEIS: Von NAS zum Global File System — Migrationspfade]
Fazit
Die Entscheidung für ein Storage-Modell sollte bei der Anwendung beginnen, nicht bei der Infrastruktur.
Benötigt sie ein Block Device, ist Block Storage der Ausgangspunkt. Benötigt sie Dateien, Verzeichnisse und Protokolle wie SMB oder NFS, wird eine File-Service-Schicht gebraucht. Kann sie Daten unmittelbar als Objekte über eine API verarbeiten, lässt sich Object Storage direkt in die Anwendungsarchitektur integrieren.
Darüber hinaus sind weitere Anforderungen zu klären, bevor eine Architektur entsteht. Dazu gehören das I/O-Muster, Latenz-, IOPS- und Durchsatzanforderungen, die Parallelisierbarkeit der Zugriffe, Größe und Anzahl der Dateien beziehungsweise Objekte, gemeinsame Zugriffe und Konsistenzanforderungen, der Datenlebenszyklus, Backup und Recovery, Skalierungsanforderungen, Netzwerk und Datenlokalität sowie das Kostenmodell des jeweiligen Dienstes.
Dieses Kostenmodell gehört zum Bezugsweg, nicht zum Zugriffsmodell — und es kann den Datenlebenszyklus trotzdem unmittelbar einschränken. Wasabi etwa berechnet nach eigener Dokumentation eine Mindestspeicherdauer von 90 Tagen im Pay-as-you-go-Modell und 30 Tagen bei reservierter Kapazität; wird ein Objekt vorher gelöscht, fallen die Gebühren für die verbleibenden Tage weiterhin an. Für ein Langzeitarchiv ist das ohne Bedeutung, für eine Staging-Fläche mit kurzen Aufbewahrungszeiten dagegen ein Auswahlkriterium. Erst aus der Kombination technischer und kommerzieller Anforderungen lässt sich eine konkrete Storage-Architektur ableiten.
[QUERVERWEIS: Storage-TCO im Vergleich — Kostenmodelle jenseits des Kapazitätspreises]
Block, File und Object stellen unterschiedliche Daten- und Zugriffsmodelle bereit: adressierbare Blöcke, eine Abstraktion als Dateien und Verzeichnisse, individuell adressierbare Objekte. 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.
Isoliert eingesetzt werden müssen die Modelle dabei nicht. Gerade 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 sein können. Unsere Projekterfahrung bestätigt diese Trennung: Object Storage diente sowohl als Backup-Ziel als auch als Storage-Ebene für File Services, während bei bestehenden File-Anwendungen regelmäßig eine Vermittlungsschicht erforderlich war.
Quellen
Storage Networking Industry Association (SNIA): block storage. SNIA Dictionary. Definition, Blockgrößen bei Platten- und Bandlaufwerken, Anordnung der Blöcke durch ein Host-Dateisystem sowie Zugriffsprotokolle. https://www.snia.org/education/online-dictionary/term/block-storage
Storage Networking Industry Association (SNIA): file storage. SNIA Dictionary. Definition von File Storage als Methode, Daten als Dateien zu speichern. https://www.snia.org/education/online-dictionary/term/file-storage
Storage Networking Industry Association (SNIA): What is Object Storage? Objektmodell, Identifier, Metadaten als Attribut-Wert-Paare, Änderungs- und Lesesemantik sowie das Verhältnis zwischen interner Speicherform und Anwendungsschnittstelle. https://www.snia.org/education/what-is-object-storage
Internet Engineering Task Force (IETF): RFC 8881 — Network File System (NFS) Version 4 Minor Version 1 Protocol, August 2020. Rolle des Servers bei der Koordination des Zugriffs mehrerer Clients sowie Bedingungen für die gemeinsame Nutzung von Lock-Zuständen. Ersetzt RFC 5661. https://www.rfc-editor.org/rfc/rfc8881.html
IONOS Cloud: Block Storage — Overview. Virtuelles Storage-Gerät als Äquivalent eines iSCSI-Blockgeräts mit Verhalten wie direkt angebundener Speicher, Konfiguration im Betriebssystem des Servers, Verwaltung unabhängig vom Server, bis zu 24 Volumes pro Server. Enthält im Einstiegsabsatz auch die im Text erwähnte unscharfe Formulierung zum Dateisystem (Stand: 3. September 2026). https://docs.ionos.com/cloud/backup-and-storage/block-storage/overview
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
