Proxmox-Storage: welcher Typ wofür

Proxmox kann viele Storage-Typen. Die Auswahlliste im Dialog verrät nicht, welcher davon Snapshots kann, welcher bei vollem Pool die Gäste anhält und welcher nur mit mehreren Hosts sinnvoll ist. Diese Übersicht ordnet die Typen nach dem, was im Betrieb zählt.

Die Übersicht#

Typ	Snapshots	Thin	Mehrere Hosts	Wofür
LVM-Thin	ja	ja	nein	Standard für einen einzelnen Host
ZFS (lokal)	ja	ja	nein (aber Replikation)	ein Host mit mehreren Platten
Verzeichnis	nur mit qcow2	mit qcow2	nein	ISOs, Vorlagen, Dumps
NFS	mit qcow2	mit qcow2	ja	kleine Cluster, einfach zu betreiben
Ceph RBD	ja	ja	ja	ab drei Knoten, eigenes Netz
iSCSI + LVM	nein	nein	ja	vorhandene SAN-Hardware

Zwei Zeilen daraus sind die praktisch relevanten: LVM-Thin und ZFS. Alles andere ist Sonderfall oder braucht deutlich mehr Hardware.

LVM-Thin#

Der Standard nach einer Installation ohne ZFS. Ein Thin-Pool vergibt Blöcke erst, wenn tatsächlich geschrieben wird.

lvs -a                          # was existiert
lvs -o+seg_monitor              # überwacht der Daemon den Pool?

Stärken: schnell, wenig Overhead, gut verstanden, Snapshots funktionieren.

Die Falle: Ein Thin-Pool kann überbucht werden. Du kannst zehn Gästen je 100 GB zusagen, obwohl nur 500 GB da sind. Solange nicht alle gleichzeitig schreiben, geht das gut. Läuft der Pool voll, gehen die Dateisysteme der Gäste in den Nur-Lese-Zustand und ein solcher Ausfall ist nicht sofort verständlich, weil im Gast noch Platz angezeigt wird.

# Belegung des Pools regelmäßig prüfen — die Spalte Data%
lvs vg0/data -o lv_name,lv_size,data_percent,metadata_percent

Metadaten laufen zuerst voll

Nicht nur der Datenbereich hat ein Limit, sondern auch der Metadatenbereich und der ist standardmäßig knapp bemessen. Ein volles Metadaten-LV hat dieselbe Wirkung wie ein voller Pool. Beide Werte gehören ins Monitoring, mit Warnung ab 80 %.

ZFS#

Wenn mehrere Platten vorhanden sind, ist ZFS die interessantere Wahl: Prüfsummen gegen stille Datenfehler, Snapshots ohne Zusatzaufwand, Kompression, und inkrementelle Replikation zu einem anderen Host.

zpool create -o ashift=12 tank mirror /dev/sda /dev/sdb
zfs set compression=lz4 tank
zfs set atime=off tank
pvesm add zfspool local-zfs --pool tank --sparse 1

Drei Einstellungen, die man beim Anlegen richtig setzt, weil sie später schwer zu ändern sind:

ashift=12, 4K-Sektoren. Bei fast jeder aktuellen SSD und Festplatte korrekt. Falsch gesetzt kostet es dauerhaft Leistung, und ändern geht nur über einen neuen Pool.
compression=lz4, praktisch immer sinnvoll. Die CPU-Kosten sind minimal, der Gewinn bei Textdaten und Datenbanken erheblich.
volblocksize für Zvols, der Standard passt für die meisten Fälle; bei Datenbanken lohnt es, ihn auf die Blockgröße der Datenbank abzustimmen.

Snapshots sind hier fast kostenlos und der Grund, warum ein Update im Gast entspannter abläuft:

zfs snapshot tank/vm-100-disk-0@vor-update
zfs list -t snapshot
zfs rollback tank/vm-100-disk-0@vor-update    # Gast muss aus sein

Replikation zu einem zweiten Host ist in Proxmox eingebaut und braucht keinen Cluster-Storage:

pvesr create-local-job 100-0 node2 --schedule "*/15"

Details zum Zusammenspiel im Cluster: Proxmox-Cluster über getrennte Standorte.

Was ZFS kostet#

RAM. ZFS nutzt freien Arbeitsspeicher als Lesecache (ARC) und gibt ihn bei Bedarf zurück, trotzdem konkurriert er auf einem gut ausgelasteten Host mit den Gästen. Eine Obergrenze ist deshalb sinnvoll:

echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf   # 8 GB
update-initramfs -u && reboot

Und: Kein ZFS auf einem Hardware-RAID-Controller. ZFS will die Platten direkt sehen; ein RAID-Controller dazwischen verbirgt genau die Fehler, die ZFS erkennen und reparieren könnte. Wenn der Controller einen HBA- oder IT-Modus hat, ist das der richtige.

Die Einstellungen pro virtueller Platte#

Beim Anlegen einer VM-Platte gibt es drei Optionen, die im Alltag mehr ausmachen als die Wahl des Storage-Typs.

Discard / TRIM#

Ohne discard erfährt der Storage nie, dass der Gast Dateien gelöscht hat, Thin-Provisioning wächst dann nur, nie zurück.

qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,ssd=1

Im Gast dazu passend den regelmäßigen TRIM aktivieren:

systemctl enable --now fstrim.timer

Cache-Modus#

Modus	Verhalten	Wann
`none`	Host-Cache aus, Gast-Cache an	Standard, sicher, gute Wahl
`writeback`	Host puffert Schreibvorgänge	schneller, aber Datenverlust bei Stromausfall möglich
`writethrough`	jede Schreiboperation sofort durch	langsam, selten sinnvoll

none ist der richtige Startwert. writeback nur, wenn die Daten reproduzierbar sind oder eine USV im Spiel ist und mit dem Wissen, dass ein Hostausfall dann Schreibvorgänge kostet, die der Gast schon als erledigt gemeldet hat.

IO-Thread und Controller#

virtio-scsi-single mit iothread=1 gibt jeder Platte einen eigenen Thread und entlastet die Haupt-CPU-Schleife der VM. Bei Gästen mit spürbarer Plattenlast ist das der Unterschied, den man ohne Messung merkt.

Was wohin gehört#

Eine bewährte Aufteilung für einen einzelnen Host:

Inhalt	Storage
VM- und Container-Platten	`local-lvm` oder `local-zfs`
ISOs und Container-Vorlagen	`local` (Verzeichnis)
Backups	nicht lokal, PBS oder externes Ziel
Snapshots	dieselbe Ebene wie die Platte, kein eigener Storage

Der dritte Punkt ist der wichtige. Ein vzdump auf dieselbe Platte, auf der die Gäste liegen, sichert gegen genau einen Fehler: das versehentliche Löschen eines Gastes. Gegen Plattenausfall, Hostverlust oder Verschlüsselung hilft es nicht, siehe 3-2-1.

Erweitern, wenn es eng wird#

# Bestehende VM-Platte vergrößern (nur vergrößern, nie verkleinern)
qm resize 100 scsi0 +50G

Danach im Gast das Dateisystem nachziehen:

# im Gast
growpart /dev/sda 1
resize2fs /dev/sda1          # ext4
# oder: xfs_growfs /

Reihenfolge merken

Drei Ebenen, drei Schritte: Storage vergrößern → Partition vergrößern → Dateisystem vergrößern. Wer nach dem ersten Schritt aufhört, sieht im Gast unverändert die alte Größe und sucht den Fehler an der falschen Stelle.

Kurz gesagt#

Eine Platte, wenig RAM: LVM-Thin, und den Füllstand überwachen.
Zwei oder mehr Platten: ZFS im Spiegel, ashift=12, compression=lz4, ARC begrenzen.
Backups gehören nie auf dieselbe Ebene wie die Daten.
discard=on und fstrim.timer sind zwei Zeilen, die verhindern, dass der Speicher langsam vollläuft.