VM benötigt zusätzlichen Speicher? Füge einen Datenträger hinzu

Die CloudTrips-Linux-VM benötigt zusätzlichen dauerhaften Speicher für Anwendungsdaten. Eine größere VM-Größe kann mehr CPU und Arbeitsspeicher bereitstellen, erhöht aber nicht die Kapazität des verwalteten Betriebssystemdatenträgers. Füge stattdessen einen separaten verwalteten Azure-Datenträger hinzu.

Azure verwaltet die Datenträgerressource und verbindet sie mit der VM. Linux muss das neue Blockgerät trotzdem identifizieren, Partition und Dateisystem erstellen, es einbinden und diese Einbindung über Neustarts hinweg speichern.

Dieser Trip fügt der vorhandenen Ubuntu-VM eine leere 32-GiB-Standard-SSD hinzu. Der Datenträger wird als ext4 formatiert und per Dateisystem-UUID unter /datadrive eingebunden. Der Trip endet mit einem optionalen sicheren Entfernungsvorgang.

Unterscheide die Speichertypen

Eine Azure-VM kann mehrere Speicherarten verwenden:

Speicher	Dauerhaft?	Verwendungszweck
Betriebssystemdatenträger	Ja	Linux, installierte Pakete und Systemkonfiguration
Verwalteter Datenträger	Ja	Anwendungsdateien und Daten, die VM-Neustarts oder -Verschiebungen überstehen müssen
Temporärer Datenträger	Nein	Ausschließlich kurzlebige Cache- oder Arbeitsdaten

Speichere keine wichtigen Daten auf dem temporären Datenträger. Sie können bei Größenänderung, Deallokierung, Hostwartung oder Hostausfall gelöscht werden.

Bestätige die vorausgesetzte VM

Dieser Trip erwartet:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-compute-test-weu
Virtual machine: vm-cloudtrips-linux01-test-weu
Operating system: Ubuntu Server
VM state: Running

Falls die VM nicht existiert, schließe zuerst Linux-Server wird schnell benötigt? Erstelle eine Linux-VM ab. Der Trip zur Größenänderung ist nützlich, aber nicht erforderlich.

Verbinde dich über SSH:

ssh \
  -i ~/.ssh/sshkey-cloudtrips-linux-test-weu.pem \
  azureuser@<VM-PUBLIC-IP>

Notiere die vorhandenen Blockgeräte, bevor du etwas hinzufügst:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Notiere Betriebssystemdatenträger und mögliche temporäre Datenträger. Diese Ausgangslage verhindert, dass du später das falsche Gerät formatierst. Beende die Sitzung:

exit

Plane den verwalteten Datenträger

Verwende:

Disk name: disk-cloudtrips-linux01-data-test-weu
Source type: None (empty disk)
Storage type: Standard SSD LRS
Size: 32 GiB
LUN: 0
Host caching: None

Die Logical Unit Number, kurz LUN, identifiziert den angeschlossenen Datenträger gegenüber der VM. LUN 0 ist die erste Datenträgerposition und steht nicht in Beziehung zum Linux-Gerätenamen. Linux kann den Datenträger je nach VM-Serie und Speichercontroller als SCSI-Gerät wie /dev/sdc oder als NVMe-Gerät darstellen.

Was sind SCSI und NVMe?

SCSI und NVMe sind zwei Schnittstellen, über die eine VM mit einem Datenträger kommunizieren kann. SCSI ist die traditionelle und breit unterstützte Schnittstelle. NVMe ist eine neuere Schnittstelle für leistungsfähigen Speicher. Beide beschreiben weder den Inhalt des Datenträgers noch sein Dateisystem. Sie bestimmen, wie Linux das Gerät erkennt.

Datenträgerschnittstelle	Beispiel für Linux-Gerätename	Beispiel für Partitionsname
SCSI	/dev/sdc	/dev/sdc1
NVMe	/dev/nvme0n2	/dev/nvme0n2p1

Linux vergibt den Namen, und er kann von diesen Beispielen abweichen. Verwende lsblk, um den neu verbundenen leeren Datenträger zu identifizieren, statt seinen Namen vorauszusetzen.

Standard SSD hält diese Übung vergleichsweise günstig. Datenträgerkosten laufen weiter, solange der verwaltete Datenträger existiert, selbst wenn die VM gestoppt ist.

Erstelle und verbinde den Datenträger

Öffne vm-cloudtrips-linux01-test-weu im Azure-Portal und gehe zu:

Settings > Disks

Wähle unter Data disks die Option Create and attach a new disk.

Konfiguriere die neue Zeile:

Name: disk-cloudtrips-linux01-data-test-weu
Storage type: Standard SSD LRS
Size: 32 GiB
LUN: 0
Host caching: None

Wähle je nach Portalansicht Apply oder Save. Warte auf den Abschluss und bestätige, dass der Datenträger als verbunden erscheint.

Ein leerer verbundener Datenträger erzeugt nicht sofort ein verwendbares Linux-Verzeichnis. Die übrigen Schritte finden in Ubuntu statt.

Identifiziere das neue Gerät sicher

Verbinde dich erneut über SSH und führe aus:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Vergleiche die Ausgabe mit der Ausgangslage. Suche den neuen ungefähr 32 GiB großen Datenträger ohne Dateisystem und Einbindungspunkt. Auf dieser VM ist er häufig /dev/sdc, kann aber einen anderen SCSI- oder NVMe-Namen besitzen.

Prüfe das gefundene Gerät vor der Formatierung ausdrücklich. Ersetze /dev/sdc nur, wenn deine Ausgabe ein anderes neues Gerät zeigt:

sudo fdisk -l /dev/sdc
lsblk -f /dev/sdc

Stoppe, wenn das Gerät das Dateisystem /, ein vorhandenes Dateisystem oder unerwartete Daten enthält. Die folgenden Formatierungsbefehle zerstören vorhandene Daten auf dem ausgewählten Gerät.

Partitioniere und formatiere den leeren Datenträger

Der neue Azure-Datenträger ist zunächst nur ein leeres Blockspeichergerät. Linux erkennt /dev/sdc, kann darauf aber noch keine normalen Dateien speichern. Bereite ihn in drei Ebenen vor:

Azure-Datenträger  /dev/sdc
    ↓ partitionieren
Partition          /dev/sdc1
    ↓ Dateisystem erstellen
ext4-Dateisystem
    ↓ einbinden
Linux-Verzeichnis  /datadrive

Die Partition legt fest, welcher Bereich des Datenträgers verwendet wird. Ein Datenträger kann in mehrere Partitionen aufgeteilt werden. Diese VM benötigt jedoch nur einen Speicherbereich, weshalb /dev/sdc1 fast den gesamten 32-GiB-Datenträger umfasst. Auf manchen unpartitionierten Linux-Datenträgern könnte ein Dateisystem auch direkt erstellt werden. Eine GPT-Partitionstabelle mit einer Partition bietet jedoch ein übliches und für Datenträgerwerkzeuge klar verständliches Layout.

Das Dateisystem organisiert die Partition in Dateien und Verzeichnisse. Eine rohe Partition kennt noch keine Dateinamen, Ordner, Besitzer, Berechtigungen oder freien Speicherplatz. Dieser Trip verwendet ext4, ein verbreitetes Linux-Dateisystem.

Das Dateisystem muss anschließend eingebunden werden, um es mit dem Linux-Verzeichnisbaum zu verbinden. Linux weist Datenträgern normalerweise keine Laufwerksbuchstaben wie D: zu. Wenn /dev/sdc1 unter /datadrive eingebunden wird, liegt eine Datei wie /datadrive/cloudtrips.txt physisch auf diesem Azure-Datenträger.

Nachdem du /dev/sdc als neuen leeren Datenträger bestätigt hast, erstelle eine GPT-Partitionstabelle und eine Partition über den gesamten Datenträger:

sudo apt-get update
sudo apt-get install -y parted
sudo parted /dev/sdc --script mklabel gpt
sudo parted /dev/sdc --script mkpart primary ext4 0% 100%
sudo partprobe /dev/sdc

Bestätige, dass /dev/sdc1 jetzt existiert:

lsblk /dev/sdc

Erstelle ein ext4-Dateisystem:

sudo mkfs.ext4 -L cloudtrips-data /dev/sdc1

Falls dein Datenträger unter einem anderen Namen erschien, verwende in diesem Abschnitt dieses Gerät und die daraus entstandene Partition. Kopiere /dev/sdc nicht ungeprüft aus dem Beispiel.

Binde das Dateisystem ein

Erstelle den Einbindungspunkt und binde das neue Dateisystem ein:

sudo mkdir -p /datadrive
sudo mount /dev/sdc1 /datadrive

Überprüfe es:

findmnt /datadrive
df -h /datadrive

Erstelle eine kleine Testdatei:

echo "CloudTrips persistent data disk" | sudo tee /datadrive/cloudtrips.txt
sudo cat /datadrive/cloudtrips.txt

Diese manuelle Einbindung gilt nur bis zum nächsten Neustart, sofern sie nicht zusätzlich in /etc/fstab deklariert wird.

Speichere die Einbindung per UUID

Gerätenamen wie /dev/sdc1 können sich nach einem Neustart ändern. Verwende die Dateisystem-UUID, die das Dateisystem selbst identifiziert:

sudo blkid /dev/sdc1

Sichere /etc/fstab, bevor du die Datei bearbeitest:

sudo cp /etc/fstab /etc/fstab.cloudtrips-backup

Ermittle die UUID und füge die Einbindungsdefinition hinzu:

DISK_UUID=$(sudo blkid -s UUID -o value /dev/sdc1)
echo "UUID=${DISK_UUID} /datadrive ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab

nofail lässt Linux weiter starten, wenn der Datenträger vorübergehend nicht verfügbar ist. Ein falscher /etc/fstab-Eintrag kann trotzdem Start- oder Einbindungsprobleme verursachen. Überprüfe ihn daher vor dem Neustart:

sudo findmnt --verify --verbose
sudo umount /datadrive
sudo mount -a
findmnt /datadrive
sudo cat /datadrive/cloudtrips.txt

Starte nicht neu, bevor findmnt --verify ohne Fehler für /datadrive abschließt und mount -a den Datenträger erfolgreich erneut einbindet.

Überprüfe die Persistenz nach dem Neustart

Starte Ubuntu neu:

sudo reboot

Die SSH-Verbindung wird geschlossen. Warte, bis die VM wieder erreichbar ist, verbinde dich erneut und führe aus:

findmnt /datadrive
df -h /datadrive
sudo cat /datadrive/cloudtrips.txt
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

Bestätige, dass /datadrive vom neuen ext4-Dateisystem eingebunden ist und die Testdatei weiterhin CloudTrips persistent data disk enthält.

Öffne den verwalteten Datenträger im Azure-Portal und bestätige:

Name: disk-cloudtrips-linux01-data-test-weu
Disk state: Attached
Owner: vm-cloudtrips-linux01-test-weu
Size: 32 GiB
Storage type: Standard SSD LRS

Die VM besitzt jetzt dauerhaften Anwendungsspeicher unabhängig vom Betriebssystemdatenträger.

Behalte oder entferne den Datenträger

Behalte den Datenträger für weitere Speichertests. Er verursacht weiterhin Kosten für verwaltete Datenträger, solange er existiert.

Um ihn sicher zu entfernen, verbinde dich zuerst erneut mit Linux. Sichere benötigte Daten und entferne die /datadrive-Zeile aus /etc/fstab, bevor du den Datenträger trennst:

sudo cp /etc/fstab /etc/fstab.before-disk-removal
sudo sed -i '\| /datadrive ext4 |d' /etc/fstab
sudo findmnt --verify --verbose
sudo umount /datadrive

Bestätige, dass er nicht mehr eingebunden ist:

findmnt /datadrive || echo "/datadrive is not mounted"

Öffne anschließend VM > Settings > Disks, trenne disk-cloudtrips-linux01-data-test-weu und wähle Apply. Das Trennen entfernt den Datenträger von der VM, löscht aber weder den verwalteten Datenträger noch beendet es seine Kosten.

Nachdem du den Zustand Unattached und die fehlende weitere Verwendung der Daten bestätigt hast, öffne die Datenträgerressource und wähle Delete.

Behalte vm-cloudtrips-linux01-test-weu und die gemeinsam verwendete Ressourcengruppe rg-cloudtrips-compute-test-weu. Lösche die Gruppe nicht, da sie auch die Windows-VM und deren Ressourcen enthalten kann.