Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Blob Storage unterstützt jetzt das NFS 3.0-Protokoll (Network File System). Diese Unterstützung bietet Linux-Dateisystemkompatibilität bei Objektspeicherskalierung und -preisen und ermöglicht es Linux-Clients, einen Container aus einem virtuellen Azure-Computer (VM) oder einem lokalen Computer in Blob Storage einzubinden.
Es war immer eine Herausforderung, umfangreiche Legacy-Workloads wie High Performance Computing (HPC) in der Cloud auszuführen. Ein Grund dafür ist, dass Anwendungen häufig herkömmliche Dateiprotokolle wie network file system (NFS) verwenden, um auf Daten zuzugreifen. Außerdem haben sich native Cloudspeicherdienste auf Objektspeicher mit einem flachen Namespace und umfangreichen Metadaten statt auf Dateisysteme konzentriert, die einen hierarchischen Namespace und effiziente Metadatenvorgänge bereitstellen.
Blob Storage unterstützt jetzt einen hierarchischen Namespace, und in Kombination mit der Unterstützung des NFS 3.0-Protokolls erleichtert Azure das Ausführen von Legacy-Anwendungen zusätzlich zum großen Cloudobjektspeicher.
Anwendungen und Workloads für die Verwendung von NFS 3.0 mit Blob Storage
Das NFS 3.0-Protokollfeature ist für hochskalierte, umfangreiche, leselastige Workloads mit sequenzieller E/A optimiert. Es ist ideal für Szenarien mit mehreren Lesern und zahlreichen Threads, bei denen der Durchsatz wichtiger ist als niedrige Latenz. Häufige Beispiele sind:
High-Performance Computing (HPC) – HPC-Aufträge umfassen häufig Tausende von Kernen, die dieselben großen Datasets gleichzeitig lesen. Das NFS 3.0-Protokollfeature verwendet den Objektspeicherdurchsatz, um herkömmliche Dateiserverengpässe zu beseitigen. Beispiele
Genomsequenzierung: Verarbeiten massiver DNA-Datasets.
Modellierung finanzieller Risiken: Monte Carlo Simulationen zu historischen Daten.
Seismische Analyse: Geologische Daten zur Öl- und Gasforschung.
Wettervorhersage: Modellieren von atmosphärischen Daten für Klima- und Sturmvorhersage.
Big Data & Analytics (Data Lakes) – Viele Analysetools erfordern hierarchische Verzeichnisse. BlobNFS (über Azure Data Lake Storage Gen2) liefert diese Struktur und unterstützt standardmäßige Dateiprotokolle. Beispiele
Maschinelles Lernen: Fütterung von Schulungsdaten in GPU-Cluster mithilfe von Standarddatei-E/A.
Protokollanalyse: Aggregieren von Protokollen aus Tausenden von Quellen.
Advanced Driver Assistance Systems (ADAS) – ADAS-Workflows erzeugen Petabytes sequenzieller Sensordaten wie LiDAR-Punktwolken und hochauflösende Kamerafeeds, die effizient aufgenommen und analysiert werden müssen, um Simulationen und Modellschulungen durchzuführen. Beispiel:
- Speichern von Roh-LiDAR-Scans und Multikamera-Videostreams von autonomen Testfahrzeugen mithilfe von NFS 3.0, und führen Sie dann umfangreiche Replaysimulationen über Tausende von Computeknoten hinweg aus, um Wahrnehmungsalgorithmen zu validieren.
Media & Entertainment – Renderingfarmen benötigen effizienten Zugriff auf große Objektbibliotheken. NFS 3.0 über BLOB stellt eine Dateischnittstelle für ältere Renderingtools bereit, die Dateipfade erwarten. Beispiele
Video-Rendering: Verteilte Knoten, die Quellressourcen lesen.
Transcodierung: Konvertieren großer roher Videodateien in Streamingformate.
Datenbanksicherung – Dieses Feature bietet ein kostengünstiges, hochdurchsatzreiches NFS 3.0-Ziel ohne komplexe Connectors oder teure Momentaufnahmen. Beispiele
- Oracle RMAN kann große Backup-Teile direkt für die langfristige Archivierung schreiben und die direkte Wiederherstellung von jeder NFS-bereitgestellten Linux-VM ermöglichen.
Wann nicht NFS 3.0 mit Blob Storage verwendet werden soll
Vermeiden Sie aufgrund von Objektspeichermerkmalen allgemeine Dateifreigaben oder Transaktionsworkloads:
| Workloadtyp | Grund | Bessere Alternative |
|---|---|---|
| Transaktionsdatenbanken | Erfordert eine präzise Sperrung, Unter millisekundenlatenz und häufige zufällige Schreibvorgänge. | Verwaltete Datenträger oder Azure NetApp-Dateien oder Azure-Dateien |
| Direkte Dateibearbeitung | Das Bearbeiten von Dateien erzwingt komplette Blob-Umschreibungen und macht Abläufe ineffizient. | Azure Files |
NFS 3.0 und der hierarchische Namespace
Die NFS 3.0-Protokollunterstützung erfordert, dass Blobs in einem hierarchischen Namespace organisiert werden. Sie können beim Erstellen eines Speicherkontos einen hierarchischen Namespace aktivieren. Die Möglichkeit zur Verwendung eines hierarchischen Namespace wurde in Azure Data Lake Storage eingeführt. Er organisiert Objekte (Dateien) genauso in eine Hierarchie von Verzeichnissen und Unterverzeichnissen, wie das Dateisystem auf Ihrem Computer organisiert ist. Der hierarchische Namespace wird linear skaliert und beeinträchtigt weder die Datenkapazität noch die Leistung. Verschiedene Protokolle werden aus dem hierarchischen Namespace erweitert. Das NFS 3.0-Protokoll ist eines der verfügbaren Protokolle.
Als Blockblobs gespeicherte Daten
Wenn Ihre Anwendung eine Anforderung mithilfe des NFS 3.0-Protokolls sendet, wird diese Anforderung in eine Kombination aus Blockblobvorgängen übersetzt. Beispielsweise werden NFS 3.0-Anforderungen zum Lesen von Remoteprozeduraufrufen (Remote Procedure Calls, RPCs) in einen Get Blob-Vorgang (Blob abrufen) übersetzt. NFS 3.0-Anforderungen zum Schreiben von Remoteprozeduraufrufen werden in eine Kombination aus Get Block List (Blockierungsliste abrufen), Put Block (Block festlegen) und Put Block List (Blockierungsliste festlegen) übersetzt.
Blockblobs sind optimiert, damit große Mengen von Daten mit vielen Lesevorgängen effizient verarbeitet werden. Blockblobs werden aus Blöcken zusammengesetzt. Jeder Block wird durch eine Block-ID identifiziert. Ein Blockblob kann bis zu 50.000 Blöcke enthalten. Jeder Block in einem Blockblob kann eine andere Größe haben – bis zur maximalen Größe, die für die von Ihrem Konto verwendete Dienstversion zulässig ist.
Allgemeiner Workflow: Einbinden eines Speicherkontocontainers
Ihre Linux-Clients können einen Container aus einem virtuellen Azure-Computer (VM) oder einem lokalen Computer in Blob Storage einbinden. Um einen Speichercontainer einzubinden, müssen Sie Folgendes tun.
Erstellen eines virtuellen Azure-Netzwerks (VNet).
Konfigurieren der Netzwerksicherheit.
Erstellen und Konfigurieren des Speicherkontos, das nur Datenverkehr aus dem VNet akzeptiert.
Erstellen eines Containers im Speicherkonto.
Einbinden des Containers.
Eine Schrittanleitung finden Sie unter Einbinden von Blob-Speicher unter Linux mithilfe des NFS 3.0-Protokolls (Network File System).
Netzwerksicherheit
Der Datenverkehr muss aus einem VNet stammen. Ein VNet ermöglicht Clients eine sichere Verbindung mit Ihrem Speicherkonto. Die einzige Möglichkeit zum Sichern der Daten in Ihrem Konto besteht darin, ein VNet und andere Netzwerksicherheitseinstellungen zu verwenden. Andere Tools zum Schützen von Daten – einschließlich Kontoschlüsselautorisierung, Microsoft Entra-Sicherheit und Zugriffssteuerungslisten (Access Control Lists, ACLs) – können nicht zum Autorisieren einer NFS 3.0-Anforderung verwendet werden.
Weitere Informationen finden Sie unter Netzwerksicherheitsempfehlungen für Blob-Speicher.
Unterstützte Netzwerkverbindungen
Ein Client kann über einen öffentlichen oder einen privaten Endpunkt sowie von jeder der folgenden Netzwerkadressen aus eine Verbindung herstellen:
Das VNet, das Sie für Ihr Speicherkonto konfigurieren.
In diesem Artikel bezeichnen wir dieses VNet als das primäre VNet. Weitere Informationen finden Sie unter Gewähren des Zugriffs aus einem virtuellen Netzwerk.
Ein Peer-VNet, das sich in derselben Region wie das primäre VNet befindet.
Sie müssen Ihr Speicherkonto so konfigurieren, dass es den Zugriff auf dieses Peer-VNet zulässt. Weitere Informationen finden Sie unter Gewähren des Zugriffs aus einem virtuellen Netzwerk.
Ein lokales Netzwerk, das mit Ihrem primären VNet über ein VPN Gateway oder ein ExpressRoute-Gateway verbunden ist.
Weitere Informationen finden Sie unter Konfigurieren des Zugriffs aus lokalen Netzwerken.
Ein lokales Netzwerk, das mit einem Peer-Netzwerk verbunden ist.
Dies kann mithilfe eines VPN Gateways oder eines ExpressRoute-Gateways zusammen mit Gatewaytransit erfolgen.
Wichtig
Das NFS 3.0-Protokoll verwendet die Ports 111 und 2048. Wenn Sie eine Verbindung aus einem lokalen Netzwerk heraus herstellen, stellen Sie sicher, dass Ihr Client die ausgehende Kommunikation über diese Ports zulässt. Wenn Sie den Zugriff auf bestimmte VNets gewährt haben, stellen Sie sicher, dass Netzwerksicherheitsgruppen, die diesen VNets zugeordnet sind, keine Sicherheitsregeln enthalten, die eingehende Kommunikation über diese Ports blockieren.
Einschränkungen und bekannte Probleme
Im Artikel Bekannte Probleme finden Sie eine vollständige Liste der Probleme und Einschränkungen im aktuellen Release der NFS 3.0-Unterstützung.
Preise
Auf der Seite Azure Blob Storage-Preise finden Sie die Kosten für Datenspeicher und Transaktionen.