Netzwerkdateisystem (NFS) 3.0-Protokollunterstützung für Azure Blob Storage

Blob Storage unterstützt jetzt das NFS 3.0-Protokoll (Network File System). Diese Unterstützung bietet Linux-Dateisystemkompatibilität im Hinblick auf Maßstab und Preis des Objektspeichers und ermöglicht es Linux-Clients, einen Container im Blob-Speicher von einer Azure-VM oder einem lokalen Computer bereitzustellen.

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 nun einen hierarchischen Namespace, und in Kombination mit der NFS 3.0-Protokollunterstützung erleichtert Azure die Ausführung von Legacyanwendungen über den 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 sollte NFS 3.0 nicht mit Blob Storage verwendet werden?

Vermeiden Sie Dateifreigaben für allgemeine Zwecke oder transaktionale Workloads aufgrund der Eigenschaften von Object Storage:

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, einen hierarchischen Namespace zu verwenden, wurde durch 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.

Cachetreffer-/Cachefehler-Ergebnisse können zusätzliche Anforderungen für „Get Blob“-Eigenschaften auslösen, um Pre- und Post-Operation-Attribute abzurufen. Die Transaktionsanzahl für End-to-End-Vorgänge in Blob Storage (z. B. Lese- oder Schreibvorgänge) wird von mehreren Variablen beeinflusst und kann sich bei verschiedenen Iterationen unterscheiden. Verwenden Sie zum Schätzen der Transaktionsanzahl für repräsentative Workloads die Blob Storage Protokolle für Beispielszenarien.

Allgemeiner Workflow: Einbinden eines Speicherkontocontainers

Ihre Linux-Clients können einen Container im Blob-Speicher von einem Azure-virtuellen Computer (VM) oder einem lokalen Computer einbinden. Um einen Storage-Konto Container zu mounten, müssen Sie diese Dinge tun.

1. Erstellen eines Azure Virtual Network (VNet).

2. Konfigurieren der Netzwerksicherheit.

3. Erstellen und Konfigurieren des Speicherkontos, das nur Datenverkehr aus dem VNet akzeptiert.

4. Erstellen eines Containers im Speicherkonto.

5. 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. Jedes andere Tool, das zum Sichern von Daten verwendet wird, einschließlich Kontoschlüsselautorisierung, Microsoft Entra Sicherheit und Zugriffssteuerungslisten (Access Control Lists, ACLs) kann nicht verwendet werden, um eine NFS 3.0-Anforderung zu autorisieren.

Weitere Informationen finden Sie unter Netzwerksicherheitsempfehlungen für Blob-Speicher.

Unterstützte Netzwerkverbindungen

Clients können über einen öffentlichen oder privaten Endpunkt eine Verbindung herstellen, vorausgesetzt, die Verbindung stammt von einem der folgenden Netzwerkstandorte:

• 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 verbunden ist, indem VPN Gateway oder ein ExpressRoute-Gateway verwendet wird.

  Weitere Informationen finden Sie unter Konfigurieren des Zugriffs aus lokalen Netzwerken.

• Ein lokales Netzwerk, das mit einem Peer-Netzwerk verbunden ist.

  Dazu können Sie VPN Gateway oder ein ExpressRoute-Gateway zusammen mit Gateway-Transit verwenden.

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

Weitere Informationen finden Sie auf der Seite Azure Blob Storage pricing für Datenspeicherung und Transaktionskosten.

Weitere Informationen

• Blob-Speicher mithilfe des Network File System (NFS) 3.0-Protokolls mounten
• Network File System (NFS) 3.0 Leistungsüberlegungen in Azure Blob Storage
• Vergleichen Sie den Zugriff auf Azure Files, Blob Storage und Azure NetApp Files mit NFS.