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.
Azure Blob Storage unterstützt jetzt das Network File System (NFS) 3.0-Protokoll. Diese Unterstützung bietet Linux-Dateisystem-Kompatibilität im Maßstab und zu den Preisen von Objektspeichern und ermöglicht Linux-Clients, einen Container in Blob Storage aus einem virtuellen Azure-Computer (VM) oder einem lokalen Computer einzubinden.
Es ist eine Herausforderung, große Legacy-Workloads auszuführen, z. B. High-Performance Computing (HPC), in der Cloud. Ein Grund dafür ist, dass Anwendungen häufig herkömmliche Dateiprotokolle wie NFS verwenden, um auf Daten zuzugreifen. Darüber hinaus verfügen systemeigene Cloudspeicherdienste, die sich auf objektspeichern konzentrieren, über einen flachen Namespace und umfangreiche Metadaten anstelle von Dateisystemen, die einen hierarchischen Namespace und effiziente Metadatenvorgänge bereitstellen.
Blob Storage unterstützt jetzt einen hierarchischen Namespace. In Kombination mit der NFS 3.0-Protokollunterstützung erleichtert Azure das Ausführen 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, die mehrere Leser und zahlreiche Threads umfassen, bei denen der Durchsatz wichtiger als die niedrige Latenz ist. Häufige Beispiele sind:
Hochleistungscomputing: 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. Nachfolgend finden Sie einige Beispiele:
- Genomsequenzierung: Verarbeiten massiver DNA-Datasets.
- Modellierung finanzieller Risiken: Verwenden von Monte Carlo-Simulationen zu historischen Daten.
- Seismische Analyse: Analyse geologischer Daten für die Öl- und Gasforschung.
- Wettervorhersage: Modellieren von atmosphärischen Daten für Klima- und Sturmvorhersage.
Big Data and Analytics (Data Lakes): Viele Analysetools erfordern hierarchische Verzeichnisse. BlobNFS (über Azure Data Lake Storage Gen2) liefert diese Struktur und unterstützt standardmäßige Dateiprotokolle. Nachfolgend finden Sie einige 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 Petabyte sequenzielle Sensordaten, z. B. LiDAR-Punktwolken und hochauflösende Kamerafeeds. Die Daten müssen effizient erfasst und im Maßstab für Simulation und Modellschulung analysiert werden. Ein Beispiel hierfür ist das Speichern von Roh-LiDAR-Scans und Multikamera-Videostreams von autonomen Testfahrzeugen mithilfe von NFS 3.0 und anschließend die Durchführung von Simulationen in großem Maßstab über Tausende von Computeknoten hinweg, um Wahrnehmungsalgorithmen zu validieren.
Medien und Unterhaltung: 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. Nachfolgend finden Sie einige Beispiele:
- Videorendering: Lesen von Quellressourcen mit verteilten Knoten.
- Transcodierung: Konvertieren großer roher Videodateien in Streamingformate.
Datenbanksicherung: Ein kostengünstiges, hochdurchsatzreiches NFS 3.0-Ziel ohne komplexe Connectors oder teure Momentaufnahmen. 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 die Verwendung für allgemeine Dateifreigaben oder Transaktionsworkloads aufgrund von Objektspeichermerkmalen:
| Workload-Typ | Grund | Bessere Alternative |
|---|---|---|
| Transaktionsdatenbanken | Erfordert präzise Sperrung, Submillisekundenlatenz und häufige zufällige Schreibvorgänge. | Verwaltete Datenträger oder Azure NetApp-Dateien oder Azure Files |
| Lokale Dateibearbeitung | Das Bearbeiten von Dateien erzwingt vollständige Neuschreibungen von Blobs, was zu ineffizienten Vorgängen führt. | 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.
Azure Data Lake Storage hat die Möglichkeit eingeführt, einen hierarchischen Namespace zu verwenden. 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 mithilfe des NFS 3.0-Protokolls eine Anforderung sendet, wird diese Anforderung in eine Kombination aus Block-BLOB-Vorgängen übersetzt. Beispielsweise werden NFS 3.0-Anforderungen zum Lesen von Remoteprozeduraufrufen (Remote Procedure Calls, RPCs) in Get Blob-Vorgänge ü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. Eine Block-ID identifiziert jeden Block. 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.
| NFSv3 RPC | REST-API-Vorgang |
|---|---|
| Metadaten und Attribute | |
Nfs3GetAttr |
Get Blob Properties |
Nfs3SetAttr |
Set Blob Properties (Wenn die Dateigröße festgelegt ist, wird Nfs3Write aufgerufen.) |
Nfs3Lookup |
Get Blob Properties |
Nfs3Access |
Get Blob Properties |
Nfs3Readlink |
Get Blob Properties |
Nfs3FsStat |
Get Blob Properties |
Nfs3Fsinfo |
Get Blob Properties |
Nfs3Pathconf |
Get Blob Properties |
| Verzeichnisaufzählung | |
Nfs3ReadDir |
List Blobs |
Nfs3ReadDirPlus |
List Blobs |
| Lesevorgänge | |
Nfs3Read |
Get Blob |
Nfs3ReadLink |
Get Blob Properties
+
Get Blob der zugrunde liegenden Datei. |
| Schreibvorgänge | |
NFs3Write |
Get Block List (1) + Put Block (x) + Put Block List (1) |
Nfs3Commit |
Keine Operation. |
| Dateilebenszyklus | |
Nfs3Create |
Put Blob + Get Blob Properties |
Nfs3Remove |
Delete Blob |
Nfs3Rename |
Nicht unterstützt (keine Eins-zu-Eins-Zuordnung). |
Nfs3Link |
Nicht unterstützt. |
| Verzeichnisverwaltung | |
Nfs3MkDir |
Put Blob + Get Blob Properties |
Nfs3RmDir |
Put Blob |
| Andere | |
Nfs3SymLink |
Put Blob + Get Blob Properties |
Nfs3MkNod |
Nicht unterstützt. |
Nfs3Null |
Keine Operation. |
Treffer- oder Fehlerergebnisse im Cache lösen möglicherweise andere Get Blob Properties Anforderungen zum Abrufen von Attributen vor dem Vorgang und nach dem Vorgang aus. Mehrere Variablen beeinflussen die Anzahl der Blob Storage-Transaktionen für End-to-End-Operationen (z. B. Dateilesevorgänge und -schreibvorgänge) und können sich über verschiedene Iterationen hinweg unterscheiden. Verwenden Sie zum Schätzen der Transaktionsanzahl für repräsentative Workloads die Blob Storage Protokolle für Beispielszenarien.
Allgemeiner Workflow: Bereitstellen eines Speicherkontocontainers
Ihre Linux-Clients können einen Container in Blob Storage von einer Azure-VM oder einem lokalen Computer bereitstellen. Um einen Speicher-Account-Container einzubinden, führen Sie die folgenden Aufgaben aus:
- Erstellen Sie ein virtuelles Azure-Netzwerk.
- Konfigurieren der Netzwerksicherheit.
- Erstellen und konfigurieren Sie ein Speicherkonto, das nur Datenverkehr aus dem virtuellen Netzwerk akzeptiert.
- Erstellen eines Containers im Speicherkonto.
- Einbinden des Containers.
Eine schrittweise Anleitung finden Sie unter Mount Blob Storage mithilfe des Network File System (NFS) 3.0-Protokolls.
Netzwerksicherheit
Der Datenverkehr muss aus einem virtuellen Netzwerk stammen. Mit einem virtuellen Netzwerk können Clients eine sichere Verbindung mit Ihrem Speicherkonto herstellen. Die einzige Möglichkeit zum Sichern der Daten in Ihrem Konto besteht darin, ein virtuelles Netzwerk und andere Netzwerksicherheitseinstellungen zu verwenden. Jedes andere Tool zum Sichern von Daten, 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 Storage.
Hinweis
Öffentliche IP-Filterung für den Zugriff auf Ihr Speicherkonto wird nicht unterstützt.
Unterstützte Netzwerkverbindungen
Clients können eine Verbindung über einen öffentlichen oder privaten Endpunkt herstellen, wenn die Verbindung von einem der folgenden Netzwerkstandorte stammt:
Das virtuelle Netzwerk, das Sie für Ihr Speicherkonto konfigurieren.
In diesem Artikel beziehen wir uns auf dieses virtuelle Netzwerk als primäres virtuelles Netzwerk. Weitere Informationen finden Sie unter Gewähren des Zugriffs aus einem virtuellen Netzwerk.
Ein virtuelles Peeringnetzwerk, das sich in derselben Region wie das primäre virtuelle Netzwerk befindet.
Sie müssen Ihr Speicherkonto konfigurieren, um den Zugriff auf dieses virtuelle Peer-Netzwerk zu ermöglichen. Weitere Informationen finden Sie unter Gewähren des Zugriffs aus einem virtuellen Netzwerk.
Ein lokales Netzwerk, das mithilfe des Azure VPN-Gateways oder eines Azure ExpressRoute-Gateways mit Ihrem primären virtuellen Netzwerk verbunden ist.
Weitere Informationen finden Sie unter Konfigurieren des Zugriffs über lokale Netzwerke.
Ein lokales Netzwerk, das mit einem peered-Netzwerk verbunden ist.
Sie können ein VPN-Gateway oder ein ExpressRoute-Gateway zusammen mit der Gatewaytransit verwenden.
Wichtig
Das NFS 3.0-Protokoll verwendet die Ports 111 und 2048. Wenn Sie eine Verbindung über ein lokales Netzwerk herstellen, stellen Sie sicher, dass Ihr Client ausgehende Kommunikation über diese Ports zulässt. Wenn Sie Zugriff auf bestimmte virtuelle Netzwerke gewährt haben, stellen Sie sicher, dass alle netzwerksicherheitsgruppen, die diesen virtuellen Netzwerken zugeordnet sind, keine Sicherheitsregeln enthalten, die eingehende Kommunikation über diese Ports blockieren.
Einschränkungen und bekannte Probleme
Eine vollständige Liste der Probleme und Einschränkungen mit der aktuellen Version der NFS 3.0-Unterstützung finden Sie unter Bekannte Probleme.
Preise
Informationen zu Datenspeicherungs- und Transaktionskosten finden Sie auf der Azure Blob Storage-Preisseite .
Verwandte Inhalte
- Mounten von Blob Storage unter Verwendung des Network File System (NFS) 3.0 Protokolls
- 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.