ZFS unter Proxmox: Datasets, Snapshots und ARC-Tuning im Produktivbetrieb

Wenn Sie Daten auf einem simplen ext4-Filesystem ohne RAID-Controller speichern, spielen Sie nicht nur russisch Roulette mit Ihrer Infrastruktur – Sie werfen auch noch die Augen selbst. In meiner über zehnjährigen Laufbahn als Sysadmin habe ich genug schrottige Festplatten und verstummte SSDs gesehen, um zu wissen: Software-Defined Storage ist keine Nische mehr, sondern das absolute Fundament jeder modernen Virtualisierung. Kein Wunder also, dass Proxmox VE (VE = Virtual Environment) standardmäßig auf OpenZFS setzt. Doch genau hier beginnt bei vielen Admins der Stress. ZFS klingt in der Theorie wunderbar – Copy-on-Write, integrierte Checksummen, endlose Kapazitäten –, doch in der Praxis frisst das Dateisystem RAM wie ein schwarzes Loch und bestraft falsche Entscheidungen mit brutaler Performance-Drosselung.

In diesem Artikel zeige ich Ihnen weg vom Marketing-Geschnickere hin zum echten Produktivbetrieb. Wir schauen uns an, wie Sie ZFS-Datasets richtig strukturieren, Snapshots so konfigurieren, dass Sie ruhig schlafen können, und最重要的是 lernen, den gefürchteten ARC (Adaptive Replacement Cache) einzuzäunen, bevor er Ihre VMs und Container in den Ruhezustand zwingt.

Die Anatomie von ZFS: Storage Pools und Datasets richtig planen

Bevor wir überhaupt einen Block schreiben, müssen wir verstehen, wie ZFS physikalischen Speicher logisch abbildet. Unter ZFS gibt es kein separates Volume-Management wie LVM. Alles dreht sich um den Storage Pool (oder kurz VDev - Virtual Device) und die darüber liegenden Datasets. Wenn Sie in der Proxmox-Oberfläche einen neuen ZFS-Pool anlegen, entscheiden Sie hier über den Rest der Lebensdauer Ihres Speichers: Welche Festplatten kommen rein? Wie redundant soll der Pool sein? Ein klassischer Fehler ist das Mischen unterschiedlicher Plattentypen oder das Hinzufügen einzelner Festplatten zu einem bestehenden Mirror später. Ein ZFS-Pool ist eine Familie, da kommt niemand mehr dazu oder raus, ohne alles neu aufzusetzen.

Einmal erstellt, organisieren Sie Ihre Daten in Datasets. Denken Sie an Datasets als virtuelle Partitionen, die dynamisch aus dem Pool.capacity schöpfen. Das Killer-Feature: Jedes Dataset kann eigene Mountpunkte und Eigenschaften haben, teilt sich aber den zugrunde liegenden Pool. Für Proxmox-Admins ist eine klare Trennung essenziell. Ich sehe oft Leute, die alles auf rpool/ stapeln. Das ist Unsinn. Legen Sie explizite Datasets für VM-Festplatten (vm-images), Container-Speicher (lxc-storages) und Backups an.

Konkretes Beispiel:
Stellen wir uns einen Pool namens tank zusammen aus vier identischen NVMe-SSDs im RAID-Z1-Verbund (équivalent zu RAID 5). Die Befehle in der Proxmox-Shell könnten so aussehen:

# 1. Pool erstellen (wenn noch nicht via GUI getan)
zfcpool create tank raidz1 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1

# 2. Datasets für verschiedene Zwecke anlegen
zfssnapshot create tank/vm-images
zfssnapshot create tank/lxc-storages
zfssnapshot create tank/backups

# 3. Mountpunkte definieren (optional, wenn von Standard abweichen)
zfs set mountpoint=/proxmox/zfs/vms tank/vm-images

Indem Sie separate Datasets nutzen, behalten Sie die Kontrolle. Möchten Sie später alle VM-Daten komprimieren oder eine spezielle Quota setzen, greifen Sie gezielt ins Dataset tank/vm-images ein, ohne Ihre Backups zu gefährden.

Persönliche Einschätzung: Viele Administratoren unterschätzen die Planungsphase. Sobald Daten auf einem ZFS-Pool liegen, wird jede strukturelle Änderung teuer. Nehmen Sie sich beim ersten Setup unbedingt die Zeit für die richtige VDev-Konfiguration. Ein einmal falsch konfigurierter Pool ist wie ein Haus mit verkabelten Rohren: Man lebt damit, bis es kracht.

Snapshots: Ihr temporärer Rückwärtsknopf und Cloning-Mechanismus

Das vielleicht mächtigste Feature von ZFS sind die Snapshots. Anders als bei traditionellen Dateisystemen, wo ein Snapshot oft nur eine momentane Kopie der Metadaten ist, ist ein ZFS-Snapshot ein voll funktionsfähiger Zustand des Dateisystems zum Zeitpunkt seiner Erstellung. Weil ZFS Copy-on-Write nutzt, verbraucht ein Snapshot initial keinen einzigen zusätzlichen Byte an Speicherplatz. Erst wenn sich die Originalseiten ändern, werden die alten Blöcke für den Snapshot separat gespeichert.

Unter Proxmox integrieren sich diese Snapshots nahtlos in den Lifecycle Ihrer virtuellen Maschinen. Sie sind perfekt geeignet, bevor Sie ein risikoreiches Update durchführen oder eine neue Softwarekomponente testen. Aber Achtung: Ein Snapshot ist kein Backup! Solange der Snapshot existiert, blockieren die referenzierten Blöcke die Garbage Collection und können Ihre Schreibperformance drastisch mindern, weil alte Blöcke nicht überschrieben werden dürfen. Löschen Sie alte Snapshots zügig.

Ein weiteres Kraftpaket ist das Klonen (Cloning). Aus einem Snapshot lässt sich innerhalb von Sekunden ein vollständiges Dataset klonen. Im Virtualisierungskontext bedeutet das: Sie erstellen einen Master-Snapshot einer Linux-VM, aktualisieren diesen regelmäßig und bauen daraus in Sekundenschnelle identische Testumgebungen auf. Ohne ZFS würden Sie hier riesige qcow2-Images kopieren; mit ZFS teilen sich der Klon und der Snapshot physisch dieselben Datenblöcke.

Konkretes Beispiel:
Angenommen, Sie führen Wartungen an einer Datenbank-VM durch. Sie wollen einen Sicherungspunkt direkt vor dem Start der Updates:

#Snapshot der spezifischen VM-Disk erstellen (Name der VM: 101)
zfs snapshot tank/vm-images/vm-101-disk-0@pre-maintenance

#Aus diesem Snapshot eine Momentaufnahme-Kopie (Klon) für Tests erstellen
zfs clone tank/vm-images/vm-101-disk-0@pre-maintenance tank/test-clones/vm-101-testrun

#Später Cleanup, wenn Tests abgeschlossen sind:
zfs destroy tank/test-clones/vm-101-testrun
zfs destroy tank/vm-images/vm-101-disk-0@pre-maintenance

Achten Sie darauf, dass in Proxmox nach der manuellen Erstellung eines Snapshots über die Shell die WebUI diesen zunächst nicht anzeigen kann, solange der Storage nicht neu eingelesen wird. Nutzen Sie für regelmäßige Schnappschüsse besser die eingebauten Retention-Policies der Proxmox-Bakcup-Jobs oder CronJobs, die via API sauberer aufräumen.

Persönliche Einschätzung: Ich nutze Snapshots fast ausschließlich als chirurgisches Werkzeug kurz vor Änderungen. Wer versucht, seine tägliche Backup-Strategie primär auf stundenweisen Snapshots aufzubauen, wird früher oder später unter der „Snapshot Bloat“ leiden. Der Vorteil der Geschwindigkeit darf nie die Disziplin beim Aufräumen verdrängen.

ARC-Tuning: Dem RAM-Fresser Grenzen setzen

Hier kommt der Teil, der jeden Proxmox-Admin mal aus der Reserve gelockt hat: Der Adaptive Replacement Cache (ARC). Damit ZFS schnell bleibt, zwischenspeichert es gelesene Datenblöcke im Arbeitsspeicher. Der ARC versucht intelligent, das Verhältnis zwischen reinen Metadaten (MRU/MFU Lists) und reinen Datenblöcken (dbuf cache) zu optimieren. Das Problem: ZFS kennt kein Sättigungsgefühl. Geben Sie ihm 64 GB RAM zur Verfügung, füllt es den ARC irgendwann komplett – selbst wenn gleichzeitig eine virtuelle Maschine läuft, die dringend 8 GB ihres eigenen Speichers braucht. Das Ergebnis? Massives Swapping, hängende VMs und ein Host, der reagiert wie ein erschöpfter Rentner an einem Montagmor-gen.

Glücklicherweise lässt sich das Verhalten über Parameter im Linux-Modul spl steuern. Die einfachste und effektivste Maßnahme ist das Setzen eines absoluten Maximums (modules_dep spl max.arc_c=...). Eine etwas intelligenter angehende Methode ist es, ZFS nur eine prozentuale Share des Gesamtspeichers zu erlauben. Auf einem dedizierten Storage-Server mag das egal sein, auf einem All-in-One-Proxmox-Host mit vielen RAM-hungrigen VMs ist ARC-Tuning überlebenswichtig.

Konkretes Beispiel:
Wir nehmen an, Sie betreiben einen Proxmox-Node mit 128 GB RAM. Sie möchten sicherstellen, dass ZFS maximal 32 GB (also 25% des Speichers) für seinen Cache verwendet, damit Ihre virtuellen Maschinen garantiert 96 GB plus einen Puffer haben. Führen Sie folgendes durch:

1. Berechnung des Limits in Bytes (32 GB = 34359738368 Bytes):
   $ echo $((32 * 1024 * 1024 * 1024))

2. Anpassen der Kernel-Parameter dauerhaft über /etc/modprobe.d/zfs.conf:
   

   echo "options spl max_arc=34359738368" > /etc/modprobe.d/zfs.conf

1. Neu laden des Moduls (oder Neustart des Servers nötig):

   rmmod spl #Vorsicht: Nur tun, wenn keine aktiven ZFS-Operationen laufen!
   modprobe spl

Alternativ gibt es noch ashift. Wenn Sie moderne SSDs mit einer nativen Sektorgröße von 4k nutzen, sollten Sie beim Erstellen des Pools ashift=12 erzwingen. Obwohl moderne ZFS-Versionen das oft automatisch erkennen, schützt die manuelle Vorgabe davor, dass zufällige USB-Sticks oder seltsame Controller-Emulationen das auf 9 (512 Byte) zurückwerfen und Ihre SSDs durch unnötige Teilblöck-Schreibvorgänge verschleißen.

Persönliche Einschätzung: ARC-Tuning ist keine Option, sondern Pflicht, sobald ZFS nicht isoliert auf einem reinen NAS, sondern direkt auf dem Compute-Knoten mit Ihren Workloads konkurriert. Ich rate jedem dazu, max_arc konsequent auf etwa 25–30% des Gesamtspeichers zu limitieren, außer Sie betreiben spezialisierte Database-Appliances, bei denen der gesamte RAM sowieso für Caches gedacht ist. Ignorieren Sie dies, und Sie basteln an Ihrem Performancetuning am falschen Ende der Pfeife.

Häufige Fehler im ZFS-Einsatz

Auch mit der besten Theorie stolpert man in der Praxis immer wieder über dieselben Steine. Hier sind drei Fallen, die ich in Foren und Support-Cases permanent sehe:

• Der „Striping“-Irrtum: Viele versuchen, mehrere Festplatten einfach nur zu stripen (stripe), ohne Redundanz, um maximale Geschwindigkeit zu erreichen. Wenn dabei eine einzige Platte stirbt, fliegt der gesamte Pool – und damit alle Daten – den Bach runter. Nutzen Sie niemals Striping ohne Spiegelung oder Parität für produktive Daten. Ein mirror oder raidz1 ist zwar langsamer beim Schreiben, aber deutlich wertvoller beim Überleben.
• Überfüllte Pools (Der 80%-Mythos): Bei traditionellem RAID ist es schlimm, über 80% ausgelastet zu sein. Bei ZFS ist dies der absolute Totpunkt. Durch die interne Defragmentierung (oder besser: die Vermeidung davon) und die Notwendigkeit, freie Blöcke für Write-Intents zu finden (SLOG) bzw. alten Müll zu verschieben, bricht die Schreibperformance ab 80%, vor allem aber ab 85% Auslastung, dramatisch ein. Planen Sie immer mindestens 20% Pufferkapazität ein.
• Verschlüsselung nachträglich hinzufügen: ZFS-Verschlüsselung funktioniert auf Dataset-Ebene. Sie können einen bereits erstellten, unverschlüsselten Pool nicht einfach „nachverschlüsseln“. Sie müssen die Daten auf ein neues, verschlüsseltes Dataset kopieren. Wenn Datenschutz von Anfang an wichtig ist (DSGVO etc.), aktivieren Sie die Verschlüsselung (encrypt=on) zwingend schon beim Anlegen des Datasets.

Fazit und Ihr konkreter nächster Schritt

ZFS unter Proxmox bietet Ihnen Enterprise-Features auf Hardware, die Sie sich leisten können. Es ist robust, fehlertolerant und unglaublich leistungsfähig – vorausgesetzt, Sie behandeln es mit Respekt. Die Kombination aus durchdachte Dataset-Architektur, diszipliniertem Snapshot-Management und einer strikten Begrenzung des ARC macht den Unterschied zwischen einem stabil laufenden Rechenzentrum und einem ständigen Kampf gegen Latenzen aus.

Was sollten Sie jetzt tun? Loggen Sie sich heute noch per SSH in Ihren Proxmox-Host ein. Prüfen Sie mit cat /proc/spl/kstat/zfs/arcstats | grep c_max oder einfacher mit dem Tool arc_summary, wie viel RAM Ihr ZFS aktuell fressen darf. Wenn dort ein Wert steht, der nahe an Ihrer gesamten Systemausstattung liegt, passen Sie sofort die /etc/modprobe.d/zfs.conf an und setzen ein max_arc. Danach listen Sie Ihre现有 Pools mit zpool list auf und prüfen Sie, ob Sie nicht versehentlich Striping ohne Redundanz im Einsatz haben. Ein gesunder Schlaf beginnt oft mit einem gut konfigurierten Storage-Layer.