Eine App benötigt ein gemeinsames Dateisystem? Azure Files erstellen, einbinden und als Snapshot sichern

Veröffentlicht am:
#azure-storage#azure-files#smb#linux#share-snapshot

CloudTrips benötigt ein klassisches gemeinsames Dateisystem, das mehrere Anwendungsinstanzen einbinden können. Azure Files stellt verwaltete SMB- und NFS-Freigaben ohne File-Server-VM bereit. Dieser Trip bindet eine SMB-Freigabe unter Linux ein und schützt sie mit einem zeitpunktbezogenen Share Snapshot.

SMB (Server Message Block) und NFS (Network File System) sind Protokolle, durch die entfernter Speicher wie ein normales Verzeichnis erscheint. Der dahinterliegende Speicherdienst bleibt dennoch wichtig:

Azure Files SMB Azure Files NFS Vorheriger Trip: Blob NFS
Verwendet SMB und funktioniert mit Windows, Linux und macOS Verwendet NFS und richtet sich hauptsächlich an Linux-/Unix-Anwendungen Verwendet NFS 3.0, um Linux einen Blobcontainer bereitzustellen
Verwendet den File-Endpunkt: account.file.core.windows.net Verwendet einen Azure-Files-Endpunkt Verwendet den Blob-Endpunkt: account.blob.core.windows.net
Speichert Daten in einer verwalteten Azure-Files-Freigabe Speichert Daten in einer verwalteten Azure-Files-Freigabe Speichert jede Datei als Block Blob
Unterstützt SMB-Authentifizierung und SMB-3.x-Funktionen Verwendet Unix-artige Identitäten und Berechtigungen Autorisiert NFS-Zugriff über das erlaubte Netzwerk und hat mehr Dateisystemeinschränkungen
Ideal für allgemeine gemeinsame Ordner und breite Betriebssystemkompatibilität Ideal, wenn eine Linux-Anwendung eine klassische NFS-Freigabe erwartet Ideal, wenn Daten über Blob-APIs erreichbar bleiben müssen und zum Blob-NFS-Verhalten passen

Dieser Trip verwendet Azure Files über SMB. Linux zeigt einen SMB-Mount als cifs an und seine Quelle enthält .file.core.windows.net. Im vorherigen Trip meldete Linux nfs und die Quelle enthielt .blob.core.windows.net.

Das Lab verwendet für einen einfachen Mount einen Storage-Account-Key. Dieser Key gewährt weitreichenden Zugriff und ist praktisch ein Administrator-Credential; Produktionsworkloads sollten unterstützte identitätsbasierte Authentifizierung und private Netzwerke bevorzugen.

Storage Account erstellen

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

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-files-test-itn
Storage account name: stctfilesdmytrotestitn
Region: Italy North
Primary service: Azure Files
Media tier: HDD
File share billing: Pay-as-you-go
Redundancy: Locally-redundant storage (LRS)

HDD ist der kostengünstigere Standard-Medientier und reicht für diesen kleinen allgemeinen File-Share-Test. SSD bietet geringere Latenz und höhere Leistung, kostet jedoch mehr. Pay-as-you-go berechnet die tatsächlich genutzten Daten und Vorgänge, statt bereitgestellte File-Share-Kapazität zu reservieren.

Lasse den hierarchischen Namespace deaktiviert; er wird für eine SMB-Freigabe von Azure Files nicht benötigt. Belasse unter Security die Einstellung Enable storage account key access: Enabled, da das generierte Mountskript des Labs einen Account-Key verwendet. Erstelle den Account.

Storage-Account-Übersicht für das eigenständige Azure-Files-Lab

SMB-Dateifreigabe erstellen

Öffne den Storage Account und wähle Data storage > Classic file shares > + File share. Falls das Wort Classic im Portal nicht angezeigt wird, wähle File shares. Konfiguriere:

Name: app-share
Access tier: Transaction optimized
Backup: Disabled, if offered

Erstelle die Freigabe. Transaction optimized eignet sich für ein allgemeines Lab mit häufigen Dateivorgängen. Der manuelle Snapshot dieses Trips ist nicht dasselbe wie eine geplante Azure-Backup-Konfiguration.

Azure-Files-Seite mit der privaten SMB-Dateifreigabe app-share

Linux-Client erstellen

Erstelle eine Ubuntu-VM in derselben Ressourcengruppe:

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

Erstelle die VM, bewahre ihren privaten Key sicher auf und kopiere ihre öffentliche IP-Adresse. Verbinde dich aus dem lokalen Terminal mit dem heruntergeladenen Key:

chmod 600 ~/Downloads/vm-cloudtrips-files01-test-itn_key.pem

ssh -i ~/Downloads/vm-cloudtrips-files01-test-itn_key.pem \
  azureuser@<VM_PUBLIC_IP>

Verwende den bei der Erstellung gewählten Administratornamen, falls er nicht azureuser lautet.

Freigabe einbinden

Installiere auf der VM den Linux-SMB-Client:

sudo apt-get update
sudo apt-get install --yes cifs-utils

Öffne app-share im Portal und wähle Connect. Wähle:

Operating system: Linux
Authentication method: Storage account key

Kopiere das generierte Linux-Skript und führe es innerhalb der SSH-Sitzung aus. Das Skript erstellt ein Mountverzeichnis, speichert den Account-Key in einer nur für root lesbaren Credential-Datei unter /etc/smbcredentials und bindet die Freigabe über den File-Endpunkt auf TCP-Port 445 ein. Das generierte Skript und der Account-Key dürfen nicht in einem Screenshot erscheinen.

Falls das Skript einen Authentifizierungsdialog für org.freedesktop.systemd1.reload-daemon anzeigt, brich ihn mit Ctrl+C ab und führe aus:

sudo systemctl daemon-reload
sudo mount -a

Dies passiert, wenn systemctl daemon-reload ohne sudo aufgerufen wird. Die SSH-Key-Authentifizierung stellt für diesen Dialog kein Linux-Kennwort bereit.

Prüfe den Mount:

findmnt --types cifs

Die Quelle sollte ungefähr so aussehen:

//stctfilesdmytrotestitn.file.core.windows.net/app-share

Für diesen Trip lautet der generierte Mountpfad:

/media/app-share

Version 1 schreiben und Snapshot erstellen

Erstelle die ursprüngliche gemeinsame Datei:

printf 'CloudTrips shared file - version 1\n' | \
  sudo tee /media/app-share/shared.txt

cat /media/app-share/shared.txt

Öffne app-share im Portal, wähle Snapshots > + Add snapshot, füge den optionalen Kommentar Before version 2 hinzu und wähle OK.

Ein Share Snapshot ist eine schreibgeschützte Zeitpunktansicht der gesamten Freigabe. Er ist inkrementell: Azure berechnet geänderte Daten, statt sofort die komplette Freigabe zu duplizieren. Er ersetzt nicht automatisch einen Backupzeitplan und schützt nicht vor dem Löschen des Storage Accounts.

Snapshots-Seite mit dem nach Version 1 erstellten Zeitpunkt-Snapshot

Live-Datei überschreiben

Schreibe über dieselbe eingebundene Freigabe eine zweite Version:

printf 'CloudTrips shared file - version 2\n' | \
  sudo tee /media/app-share/shared.txt

cat /media/app-share/shared.txt

Die Live-Freigabe enthält jetzt Version 2, während der Snapshot Version 1 bewahrt.

Linux-Terminal mit CIFS-Mount und auf Version 2 geänderter shared.txt

Version 1 wiederherstellen

Wähle in der Freigabe Snapshots und öffne den Snapshot. Suche shared.txt, klicke sie mit der rechten Maustaste an und wähle Restore. Wähle Overwrite original file und danach OK. Dadurch wird die Snapshotdatei zurück in die Live-Freigabe kopiert; der Snapshot selbst bleibt schreibgeschützt und unverändert.

Snapshotbrowser mit zur Wiederherstellung über die Originaldatei ausgewählter shared.txt

Kehre zur SSH-Sitzung zurück und bestätige den wiederhergestellten Inhalt:

cat /media/app-share/shared.txt

Erwartetes Ergebnis:

CloudTrips shared file - version 1

Linux-Terminal mit aus dem Azure-Files-Snapshot wiederhergestellter Version 1

Falls der Mount fehlschlägt, prüfe, ob die VM stctfilesdmytrotestitn.file.core.windows.net über TCP 445 erreicht und der Zugriff per Storage-Account-Key aktiviert bleibt. Manche externen Netzwerke blockieren Port 445, eine Azure-VM erreicht den Azure-Files-Endpunkt jedoch normalerweise direkt.

Bereinigen

Trenne die Freigabe vor dem Löschen des Labs. Verwende den tatsächlich generierten Mountpfad:

sudo umount /media/app-share

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

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

Bestätige, dass sie nicht mehr existiert:

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

Erwartetes Ergebnis: false.