Storage Zugriffsmodelle

Auswahl zwischen Block-, Datei- und Objektspeicher

Dieselben physischen Medien können sehr unterschiedliche Arten des Datenzugriffs unterstützen. Das richtige Modell hängt davon ab, welche Daten die Anwendung erwartet, wem das Dateisystem gehört und wie Daten geteilt, geschützt und skaliert werden müssen
Entscheidungspfad verwenden Vergleich öffnen
Was muss die Anwendung berücksichtigen?
Anwendung oder Benutzer
Block
Datei
Objekt
Logisches Gerät
Pfad und Dateiname
Bucket- und Objektschlüssel
Zugriffsmodell ≠ MediumDerselbe SSD- oder HDD-Pool kann von verschiedenen Zugriffsdiensten verwaltet werden
Protokoll ≠ VerfügbarkeitFailover, Multipathing und Datenschutz bleiben separate Designebenen
Mehrere Protokolle erfordern besondere SorgfaltUnterschiedliche Schnittstellen gewährleisten nicht automatisch die sichere Austauschbarkeit eines Datensatzes
Beginnen Sie mit der WorkloadDer Anwendungsvertrag ist wichtiger als eine modische Speicherbezeichnung
Drei verschiedene Verträge

Der Unterschied liegt darin, was der Nutzer sieht und kontrolliert

Block-, Datei- und Objektspeicher können dasselbe Netzwerk und sogar dieselbe zugrunde liegende Kapazität nutzen. Sie bieten dem Nutzer jedoch grundlegend unterschiedliche Schnittstellen
Blockspeicher

Der Host erhält ein logisches Gerät

Das Speichersystem stellt Blöcke bereit. Der nutzende Host erstellt und verwaltet normalerweise das Dateisystem, den Volume-Manager oder das Datenbanklayout
DateisystembesitzerDer Host, Hypervisor, Cluster-Dateisystem oder die Anwendung
  • Typischer Zugriff: iSCSI, Fibre Channel und NVMe-oF
  • Besonders geeignet für: VM-Datenspeicher, Datenbanken und Boot-Volumes
  • Erfordert disziplinierte Pfadverwaltung und Multipathing
Dateispeicher

Der Client empfängt Pfade, Dateien und Verzeichnisse

Der Speicherserver verwaltet das Dateisystem und stellt Clients Namensgebung, Berechtigungen, Sperrung und Semantik für den gemeinsamen Zugriff bereit
DateisysteminhaberDer Speicherserver; Clients nutzen eine Netzwerkfreigabe oder einen Export
  • Typischer Zugriff: SMB und NFS
  • Stark geeignet für: Zusammenarbeit, Home-Verzeichnisse und gemeinsam genutzte Inhalte
  • Das Verhalten von Client hängt von Berechtigungen, Sperrmechanismen und Protokollfunktionen ab
Objektspeicher

Die Anwendung adressiert ein Objekt über den Schlüssel

Daten und Metadaten werden als Objekte in Buckets gespeichert. Anwendungen verwenden eine API, anstatt eine herkömmliche Festplatte oder ein gemeinsam genutztes Dateisystem einzubinden
Namespace-InhaberDer Objektdienst; die Anwendung verwendet Buckets, Schlüssel und API-Berechtigungen
  • Typischer Zugriff: S3-kompatible API, CLI, SDK oder Dateimanager
  • Besonders geeignet für: Backups, Archive, Anwendungsdaten und große Datensätze
  • Kein direkt einsetzbares POSIX-Dateisystem; überschreibt in der Regel ganze Objekte
Besitzverhältnisse sind wichtig

Der Speicherort des Dateisystems beeinflusst das Betriebsmodell

BlockStorage stellt ein logisches Gerät bereit. Der Host fügt ein Dateisystem, eine Datenbankstruktur oder eine Clusterschicht hinzu
→
DateiDas Speichersystem besitzt das Dateisystem. Clients fordern benannte Dateien über SMB oder NFS an
→
ObjektDer Dienst verwaltet Buckets und Objektschlüssel. Anwendungen führen API-Operationen an vollständigen Objekten durch
Diese sollten nicht als Leistungsstufen betrachtet werden Ein Dateidienst kann schneller sein als ein schlecht konzipierter Blockpfad, und ein Objektdienst kann die richtige Lösung für hohe Skalierungsanforderungen sein, selbst wenn er nicht für ein eingebundenes Datenbankvolume geeignet ist
Direkter Vergleich

Vergleichen Sie die Schnittstelle, bevor Sie Produkte vergleichen

Modell Verbraucheradressen Namensraum Dateisystembesitz Typischer Zugriff Guter Ausgangspunkt für Vorsicht geboten
Block Logische Blöcke auf einer Festplatte oder in einem Namensraum Vom Host erstellt Host, Hypervisor oder Clusteranwendung iSCSI, FCP, NVMe/TCP, NVMe/RDMA, NVMe/FC VM-Datenspeicher, Datenbanken, Boot- und Anwendungsvolumes Multipathing, Fencing, gleichzeitige Schreibvorgänge, Hostkompatibilität und Failover-Verhalten
Datei Pfad, Verzeichnis und Dateiname Vom Speicherserver bereitgestellt Storage-Server SMB und NFS Gemeinsame Teamdaten, Profile, Medien, Repositories und allgemeine NAS-Workloads Identitätszuordnung, Berechtigungen, Sperren, Metadatenladen und protokollspezifische Funktionen
Objekt Bucket, Objektschlüssel und API-Operation Flacher oder präfixbasierter Objekt-Namensraum Kein herkömmliches Client-Dateisystem S3-kompatible REST-API, CLI und SDKs Backup, Archive, Cloud-native Anwendungen und große unstrukturierte Datensätze Anwendungskompatibilität, Verhalten beim Überschreiben von Objekten, Konsistenzerwartungen, Aufbewahrungs- und Zugriffsrichtlinien

Die Tabelle beschreibt die Zugriffssemantik. Leistung, Verfügbarkeit und Datenschutz hängen von der vollständigen Implementierung und Architektur ab

Entscheidungspfad

Beginnen Sie mit dem, was die Workload benötigt

Welche Schnittstelle benötigt die Anwendung oder der Benutzer?
01 · GERÄT

Wird ein Datenträger, eine LUN oder ein NVMe-Namespace erwartet?

Der Host muss das Dateisystem erstellen oder das Volume direkt verwalten
Beginnen Sie mit Blockspeicher
02 · GEMEINSAME PFADE

Benötigen Benutzer oder Anwendungen Verzeichnisse und Dateisperren?

Clients sollten benannte Dateien durchsuchen und freigeben können, ohne das zugrunde liegende Dateisystem zu besitzen
Beginnen Sie mit Dateispeicher
03 · API

Nutzt die Anwendung Buckets, Schlüssel, Metadaten oder S3-Aufrufe?

Die Workload ist auf API-Zugriff, Skalierbarkeit oder Objektaufbewahrung ausgelegt
Beginnen Sie mit Objektspeicher
Mehrere Antworten sind normal Unternehmensumgebungen benötigen häufig alle drei Modelle. Entwerfen Sie separate Dienste und Schutzrichtlinien, anstatt anzunehmen, dass jeder Datensatz über jede Schnittstelle zugänglich gemacht werden sollte
Workload-Leitfaden

Gemeinsame Ausgangspunkte – keine universellen Regeln

Block

VMware- und Hyper-V-Datenspeicher

Verwenden Sie unterstützte Blockprotokolle, wenn der Hypervisor ein gemeinsam genutztes Gerät erwartet. NFS und SMB können ebenfalls gültig sein, sofern Hypervisor und Design dies unterstützen
Block

Datenbanken

Blockspeicher ermöglicht dem Host oder der Datenbank die direkte Kontrolle über das Volume-Layout. Dateispeicher bleibt für unterstützte Datenbank- und Backup-Workflows gültig
Datei

Benutzer- und Abteilungsdaten

SMB oder NFS bieten gemeinsame Pfade, Berechtigungen und Sperren, ohne dass jeder Client eine Festplatte verwalten muss
Datei

Medien und gemeinsam genutzte Inhalte

Dateiprotokolle eignen sich für Anwendungen, die Verzeichnisse, Dateinamen, zufällige Aktualisierungen und gleichzeitige Zusammenarbeit erwarten
Objekt

Backup und unveränderliche Aufbewahrung

S3 ist ein starkes Ziel, wenn Backup-Software Objekt-Repositories, Versionierung oder Aufbewahrungs-Workflows unterstützt
Objekt

Anwendungen, Archive und KI-Datensätze

Objekt-APIs eignen sich für große Datensätze, metadatengesteuerten Zugriff und Anwendungen, die für die Arbeit mit Buckets und Schlüsseln entwickelt wurden
Multi-Protokoll-Architekturen

Eine Plattform kann mehrere Dienste bereitstellen, ohne dass diese identisch sein müssen

Eine Speicherplattform kann Block-, Datei- und Objektzugriffe über eine gemeinsame Infrastruktur ermöglichen. Jeder Dienst benötigt dennoch ein eigenes Design für Kompatibilität, Verfügbarkeit, Sicherheit und Datenschutz
Vermeiden Sie unkontrollierten protokollübergreifenden Zugriff Die Bereitstellung derselben Daten über unabhängige Schnittstellen kann zu Sperr-, Besitz- oder Konsistenzproblemen führen, sofern die Plattform diese Semantik nicht explizit koordiniert
euroNAS als Implementierungsbeispiele

Unterschiedliche Plattformen decken unterschiedliche Betriebsmodelle ab

Die folgenden Produkte sind Beispiele für die Implementierung der drei Zugriffsmodelle. Die Produktauswahl sollte sich nach dem erforderlichen Service, dem Verfügbarkeitsmodell und der Skalierbarkeit richten – und nicht umgekehrt
Plattform Dateidienste Blockdienste Objektdienste Architekturrolle
euroNAS Premium SMB und NFS von einem eigenständigen Speicherserver FC-, iSCSI/iSER- und NVMe-oF-Ziele auf qualifizierter Hardware S3 für einfache Objekt-Service-Anforderungen Einzelserver-Speicherbetriebssystem, einschließlich Bereitstellung als Virtual Storage Appliance
euroNAS HA Cluster Hochverfügbare SMB- und NFS-Dienste Hochverfügbare FC-, iSCSI/iSER- und NVMe-oF-Ziele auf qualifizierter Hardware S3-Funktionalität zusammen mit den Speicherdiensten Automatisches Service-Failover auf zwei Knoten mittels synchronem Mirroring oder einem Shared-Storage-Modell; asynchrone Replikation ist eine separate DR-Option
eEKAS Scale-out SMB und NFS iSCSI/iSER- und NVMe-oF-Ziele; Kein FC-Ziel Scale-out S3 mit Quoten, Abrechnungsintegration und S3 File Manager Ceph-basierter Scale-Out-Speicher ohne feste Zwei-Knoten-Grenze
eEVOS Nutzt bei Bedarf kompatible externe Dateidienste Nutzt kompatiblen externen gemeinsam genutzten Blockspeicher über integrierte Initiatoren Anwendungen können Objektdienste nutzen; eEVOS wird hier nicht als Objektziel dargestellt Virtualisierungsplattform mit integriertem Backup & Disaster Recovery; in diesem Vergleich kein universelles Speicherziel
Standalone

euroNAS Premium

Datei-, Block- und S3-Dienste von einem Speicherserver oder einer virtuellen Appliance Premium-Details →
Zwei-Knoten-HA

HA Cluster

Automatisches Service-Failover für Datei- und Blockspeicherarchitekturen HA Cluster Details →
Scale-out

eEKAS

Verteilte Ceph-Plattform für Block-, Datei- und Objektdienste eEKAS Details →
Virtualisierungsplattform

eEVOS

Compute, die Speicher gemäß der gewählten Architektur nutzt und integriert eEVOS Details →
Technische Bewertung fortsetzen

Vom Zugriffsmodell zum Protokoll und zur Architektur wechseln

Primäre Referenzen

Standards und herstellerneutrale technische Leitlinien

Wählen Sie das Zugriffsmodell, bevor Sie die Appliance auswählen

Wir können die Workload-Erwartungen, die Anforderungen an die gemeinsame Nutzung, die Schutzziele und die Betriebsgrenzen jedes Dienstes überprüfen
Besprechen Sie Ihre Architektur
Diese Seite bietet Architekturhinweise für Geschäfts- und Unternehmensumgebungen. Kompatibilität, Verfügbarkeit und Leistung müssen für das gesamte Host-, Netzwerk- und Speicherdesign validiert werden
↑
Nach oben scrollen