Eine Linux-App benötigt NFS-Speicher? NFS für Blob Storage konfigurieren

Veröffentlicht am:
#azure-storage#blob-storage#nfs#linux#virtual-network

CloudTrips hat eine Linux-Anwendung, die ein gemeinsames Verzeichnis statt einer Object-Storage-API erwartet. Azure Blob Storage unterstützt NFS 3.0. Dadurch kann Linux einen Blobcontainer als Verzeichnis einbinden, während Azure dessen Dateien als Block Blobs speichert.

Dies ist NFS für Blob Storage, keine NFS-Freigabe von Azure Files. Beide erscheinen unter Linux als eingebundenes Verzeichnis, verwenden aber unterschiedliche Dienste und sind für unterschiedliche Workloads gedacht:

NFS für Blob Storage NFS-Freigabe von Azure Files
Speichert jede Datei als Block Blob in einem Blobcontainer Speichert Dateien in einer verwalteten Dateifreigabe
Verwendet NFS 3.0 und den Blob-Endpunkt: account.blob.core.windows.net Verwendet NFS 4.1 und den File-Endpunkt: account.file.core.windows.net
Für Object-Storage-Skalierung sowie große, sequenzielle und leselastige Workloads optimiert Für Anwendungen gedacht, die hauptsächlich ein klassisches gemeinsames Dateisystem benötigen
Daten bleiben über Blob-Storage-APIs und Object-Storage-Werkzeuge erreichbar Daten werden über Azure Files verwaltet
Hat mehr Dateisystemeinschränkungen, unter anderem keinen NLM-File-Locking-Dienst Bietet umfassendere Dateisystemsemantik und Protokollfunktionen

Wähle Blob NFS, wenn die Anwendung per NFS auf Daten zugreifen soll, die im Object Storage bleiben müssen, etwa Analyse-, Medienverarbeitungs- oder HPC-Datasets. Wähle Azure Files NFS, wenn ein klassisches gemeinsames Dateisystem die Hauptanforderung ist. Anwendungen mit vollständigem POSIX-Verhalten, häufigem Überschreiben an Ort und Stelle oder File Locking müssen vor dem Einsatz von Blob NFS sorgfältig geprüft werden.

Netzwerk erstellen

Erstelle eine eigenständige Ressourcengruppe:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-nfs-test-itn
Region: Italy North

Suche nach Virtual networks, wähle Create und verwende:

Virtual network: vnet-cloudtrips-nfs-test-itn
Address space: 10.70.0.0/16
Subnet name: snet-app
Subnet range: 10.70.1.0/24

Das Netzwerk ist die Sicherheitsgrenze für den NFS-Zugriff. Blob-NFS-Anfragen werden nicht mit Storage-Account-Keys, SAS-Tokens, Microsoft-Entra-Rollen oder ACLs autorisiert.

Linux-Client erstellen

Erstelle eine Ubuntu-VM in derselben Ressourcengruppe:

Virtual machine name: vm-cloudtrips-nfs01-test-itn
Region: Italy North
Image: Ubuntu Server 24.04 LTS
Size: Standard D2s v3
Authentication type: SSH public key
Virtual network: vnet-cloudtrips-nfs-test-itn
Subnet: snet-app
Public inbound ports: Allow selected ports
Select inbound ports: SSH (22)

Erstelle die VM und notiere ihre öffentliche IP-Adresse für die spätere SSH-Verbindung.

NFS-Storage-Account erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Resource group: rg-cloudtrips-nfs-test-itn
Storage account name: stctnfsdmytrotestitn
Region: Italy North
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Aktiviere unter Advanced beide Einstellungen:

Enable hierarchical namespace: Enabled
Enable network file system (NFS) v3: Enabled

Beides sind Entscheidungen bei der Erstellung und können später nicht deaktiviert werden. Der hierarchische Namespace liefert Verzeichnisse; NFS 3.0 liefert das Linux-Mountprotokoll.

Wähle unter Networking:

Network access: Enable public access from selected virtual networks and IP addresses
Virtual network: vnet-cloudtrips-nfs-test-itn
Subnet: snet-app

Füge keine öffentliche Client-IP hinzu. NFS-Verkehr muss aus einem erlaubten VNet, einem zugelassenen Peering-VNet derselben Region oder einem damit verbundenen lokalen Netzwerk stammen. Erstelle den Account.

Storage-Account-Übersicht mit aktiviertem hierarchischen Namespace und NFS v3

Networking-Seite des Storage Accounts mit Beschränkung auf vnet-cloudtrips-nfs-test-itn und snet-app

NFS-Container erstellen

Öffne den Storage Account und wähle Data storage > Containers > + Container:

Name: app-nfs
Anonymous access level: Private (no anonymous access)

Belasse die Root-Squash-Einstellung des Containers für dieses Lab beim generierten Standard. In Produktion muss eine geeignete Root-Squash-Richtlinie gewählt werden, damit ein entfernter Root-Benutzer nicht mehr Zugriff als beabsichtigt erhält.

Privater Container app-nfs im NFS-fähigen Storage Account

Container unter Linux einbinden

Verbinde dich per SSH mit der VM, installiere den Ubuntu-NFS-Client und Microsofts AZNFS Mount Helper und erstelle einen Mountpunkt:

sudo apt-get update
sudo apt-get install --yes nfs-common
wget \
  https://github.com/Azure/AZNFS-mount/releases/latest/download/aznfs_install.sh \
  --output-document=/tmp/aznfs_install.sh
sudo bash /tmp/aznfs_install.sh
sudo mkdir --parents /mnt/cloudtrips-nfs

Wenn der Installer Enable auto update for AZNFS mount helper fragt, lasse <Yes> ausgewählt und drücke Enter. Durch das Herunterladen vor der Ausführung bleibt die Terminaleingabe für diesen interaktiven Dialog verfügbar.

Prüfe, ob der Dienst zur Überwachung des Endpunkts aktiv ist:

systemctl is-active aznfswatchdog

Erwartetes Ergebnis: active.

Binde den Container ein. Der entfernte Pfad enthält sowohl den Storage-Account- als auch den Containernamen:

sudo mount \
  --types aznfs \
  --options sec=sys,vers=3,nolock,proto=tcp \
  stctnfsdmytrotestitn.blob.core.windows.net:/stctnfsdmytrotestitn/app-nfs \
  /mnt/cloudtrips-nfs

sudo chmod 0755 /mnt/cloudtrips-nfs

NFS 3.0 verwendet die Netzwerkidentität und Unix-UID/GID-Informationen statt eines Azure-Kennworts. Der AZNFS Helper hält den Mount verbunden, falls sich die IP-Adresse des Storage-Endpunkts ändert. nolock vermeidet eine Abhängigkeit vom Network Lock Manager (NLM). Auf einem klassischen NFS-Server ermöglicht NLM Anwendungen die Koordination von Advisory Locks, damit nicht zwei Prozesse dieselbe Datei gleichzeitig ändern. Blob NFS stellt diesen Locking-Dienst nicht bereit. Anwendungen müssen gleichzeitige Schreibvorgänge daher selbst koordinieren und dürfen sich für Datenkonsistenz nicht auf NFS-File-Locks verlassen.

Ein neuer Blob-NFS-Container hat normalerweise den Unix-Modus 0750. Da root sein Besitzer ist, kann azureuser das Verzeichnis nicht betreten und lesen, selbst wenn die Datei selbst lesbar ist. 0755 lässt Schreibzugriff für dieses Lab auf root beschränkt, erlaubt anderen Benutzern aber das Betreten und Lesen. In Produktion müssen die Berechtigungen passend zur tatsächlichen UID und GID der Anwendung gewählt werden.

Eingebundenen Speicher testen

Schreibe über das eingebundene Verzeichnis und prüfe das Ergebnis:

printf 'CloudTrips Blob NFS test\nHost: %s\n' "$(hostname)" | \
  sudo tee /mnt/cloudtrips-nfs/linux-app.txt

cat /mnt/cloudtrips-nfs/linux-app.txt
findmnt /mnt/cloudtrips-nfs

findmnt sollte einen NFS-v3-Mount melden und der Dateiinhalt sollte ausgegeben werden.

Linux-Terminal mit eingebundenem Blob-NFS-Container und erfolgreichem Schreibtest

Der Containerbrowser des Portals stellt eine Datenanfrage von der aktuellen öffentlichen IP-Adresse des Administrators und nicht aus snet-app. Da nur das VM-Subnetz erlaubt ist, kann das Öffnen von app-nfs deshalb 403 liefern, obwohl der NFS-Mount funktioniert.

Öffne zur Portalprüfung die Seite Networking des Storage Accounts. Belasse Enabled from selected virtual networks and IP addresses, füge die aktuelle Client IP address hinzu und speichere. Öffne danach app-nfs und prüfe, dass linux-app.txt als Block Blob erscheint. Dies zeigt die zwei Ansichten derselben Daten: als Datei über NFS und als Blob über Azure Storage.

Azure-Portal mit linux-app.txt im Container app-nfs nach dem Linux-Schreibvorgang

Kehre zu Networking zurück, entferne die temporäre Client-IP-Regel und speichere erneut. Schalte den Zugriff nicht auf alle Netzwerke um. Die IP-Regel erlaubt Portal- und HTTPS-Blobvorgänge von dieser Adresse; der NFS-Zugriff selbst benötigt weiterhin einen unterstützten VNet-Pfad.

Dieser manuelle Mount bleibt bis zum Unmount oder Neustart der VM bestehen. Eine Produktions-VM kann denselben AZNFS-Mount für automatisches erneutes Einbinden in /etc/fstab eintragen; für dieses temporäre Lab wird keine Persistenz eingerichtet.

Falls das Einbinden mit access denied fehlschlägt, prüfe, ob die VM snet-app verwendet und die Storage Firewall dieses Subnetz erlaubt. Stelle außerdem sicher, dass eine Netzwerksicherheitsgruppe die ausgehenden TCP-Ports 111 und 2048 nicht blockiert.

Bereinigen

Trenne den Container, bevor du das Lab löschst:

sudo umount /mnt/cloudtrips-nfs

Lösche anschließend die eigenständige Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-nfs-test-itn \
  --yes

Bestätige, dass sie nicht mehr existiert:

az group exists --name rg-cloudtrips-nfs-test-itn

Erwartetes Ergebnis: false.