ZFS-Pool planen: Anleitung mit Rechner und drei Beispiel-Konfigurationen

Ein ZFS-Pool ist keine Kiste voller Platten, sondern eine Architektur-Entscheidung. Wer den Pool erst zusammenklickt und dann feststellt, dass die Latenz für die Datenbank nicht reicht oder die nutzbare Kapazität um 30 Prozent hinter der Erwartung liegt, hat den Fehler bereits vor dem ersten zpool create gemacht. Dieser Artikel zeigt, wie Sie einen ZFS-Pool sauber planen: welche vdev-Layouts es gibt, wie sich RAID-Z Kapazität berechnen lässt, wann Slog, L2ARC oder ein Special vdev wirklich helfen und wie drei typische Setups für File-Server, VM-Storage und Cold-Archive konkret aussehen.

ZFS Pool Planung: die drei Stellschrauben vor der Hardware-Auswahl

Bevor Sie über Plattenmodelle oder Gehäuse nachdenken, müssen drei Fragen beantwortet sein:

1. Wieviel nutzbare Kapazität brauchen Sie heute — und in drei Jahren?
2. Welches Workload-Profil liegt an: sequentielles Lesen, viele kleine Writes, gemischte VM-Last, reines Archiv?
3. Wie hoch ist die Ausfalltoleranz pro vdev — eine Platte, zwei, drei?

Aus diesen drei Antworten ergibt sich das vdev-Layout, und erst daraus die konkrete Anzahl und Größe der Datenträger. Wer die Reihenfolge umdreht und mit der Hardware startet, muss am Ende meistens nachschieben — entweder Cache-Devices oder Platten.

Ein ZFS-Pool besteht immer aus einem oder mehreren vdevs, die zu einem gemeinsamen Speicher zusammengefasst werden. Innerhalb eines vdev entsteht die Redundanz, zwischen den vdevs entsteht die Skalierung. Verliert ein vdev seine Redundanz, ist der komplette Pool verloren — nicht nur das vdev. Diese Regel ist die wichtigste Leitplanke jeder ZFS-Pool-Planung.

vdev-Layouts für RAID-Z Kapazität berechnen und Performance abschätzen

ZFS kennt vier Redundanz-Layouts für Daten-vdevs: Mirror, RAID-Z1, RAID-Z2 und RAID-Z3. Der Unterschied liegt in der Anzahl der Paritäts- bzw. Kopie-Platten pro vdev — und damit in Kapazität, IOPS und Rebuild-Zeit.

Mirror-vdevs

Ein Mirror-vdev besteht aus zwei oder drei identischen Kopien jedes Blocks. Nutzbare Kapazität: 50 Prozent (2-Way) bzw. 33 Prozent (3-Way). Vorteil: höchste IOPS pro TB und schnellster Resilver, weil nur die Datenmenge einer Platte kopiert werden muss. Nachteil: teurer pro nutzbarem Terabyte. Für VM-Storage, Datenbanken und alles mit vielen kleinen Writes ist Mirror in fast allen Fällen die richtige Wahl.

RAID-Z1, Z2 und Z3

RAID-Z-vdevs verteilen Daten und Parität über mehrere Platten. Grobe Faustformel für die nutzbare Kapazität:

• RAID-Z1: (n - 1) * Plattengroesse, eine Platte darf ausfallen
• RAID-Z2: (n - 2) * Plattengroesse, zwei Platten dürfen ausfallen
• RAID-Z3: (n - 3) * Plattengroesse, drei Platten dürfen ausfallen

Die Faustformel ist eine Obergrenze. In der Praxis liegt die real nutzbare Kapazität etwa 5 bis 15 Prozent darunter — durch Padding, Metadaten und den ZFS-eigenen refreservation-Anteil. Wer 100 TB nutzbar auf dem Datenblatt liest, sollte 110 bis 115 TB brutto einplanen, wenn er 100 TB tatsächlich verkaufen oder ausliefern muss.

Wichtiger als die exakte Prozentzahl ist die Anzahl der Platten pro vdev. RAID-Z2 mit 6 bis 10 Platten ist der Sweet Spot für klassische Storage-Workloads. RAID-Z2 mit 16 oder mehr Platten ist zwar rechnerisch attraktiv, aber die Rebuild-Zeit steigt bei 20-TB-HDDs auf mehrere Tage — in denen jede weitere Platte im gleichen vdev nicht ausfallen darf. RAID-Z3 ist die Antwort, wenn die Rebuild-Zeit ein zweites oder drittes Redundanz-Level erzwingt.

IOPS-Regel: Ein RAID-Z-vdev liefert grob die IOPS einer einzelnen Platte — unabhängig von der Plattenzahl. Ein Pool aus vier RAID-Z2-vdevs liefert also die vierfache IOPS-Leistung eines einzelnen vdev. Wer Performance will, baut mehr vdevs — nicht breitere.

Der ZFS Rechner: von der Rohkapazität zum nutzbaren Pool

Ein pragmatischer Rechenweg in vier Schritten — die Basis für jeden ZFS-Rechner:

1. Ziel-Kapazität nutzbar festlegen, z. B. 100 TB.
2. Reserve für Snapshots und ZFS-Overhead aufschlagen: mindestens 20 Prozent, besser 25 bis 30 Prozent. Ein Pool sollte nie über 80 bis 85 Prozent Auslastung laufen — ab da bricht die Schreib-Performance ein.
3. vdev-Layout und Redundanz wählen. Beispiel: RAID-Z2 mit 8 Platten -> Faktor 6/8 = 75 Prozent nutzbar pro vdev, minus rund 10 Prozent ZFS-Overhead.
4. Anzahl der vdevs aus IOPS-Bedarf ableiten und Plattengröße ausrechnen.

Konkret für 100 TB nutzbar mit Reserve auf 125 TB und RAID-Z2 8-wide: 125 TB / 0,75 / 0,9 = ca. 185 TB brutto. Verteilt auf zwei RAID-Z2-vdevs mit je 8 Platten sind das 16 Platten mit rund 12 TB — praktisch also 16 x 14 TB für Reserve und einheitliche Bestellung.

Wer die Rechnung nicht selbst durchgehen möchte, kann sie in unserem TrueNAS-Konfigurator direkt am Modell durchspielen — Plattenanzahl und vdev-Layout werden dort auf die verfügbaren Chassis-Größen abgebildet, ohne dass Sie das Datenblatt jeder Serie kennen müssen.

Beispiel 1: File-Server mit 100 TB nutzbar

Workload: klassischer SMB-Fileserver, gemischte Office-Dateien, tageweise Snapshots, monatliche Replikation offsite.

• Layout: 2 x RAID-Z2 mit je 8 x 14 TB HDDs (Enterprise SAS oder SATA, CMR)
• Rohkapazität: 224 TB, nutzbar rund 110 TB nach ZFS-Overhead
• Redundanz: 2 Platten pro vdev
• Cache: kein Slog nötig — SMB ist überwiegend asynchron. Ein Special vdev als 3-Way-Mirror aus kleinen NVMe-SSDs (z. B. 1 TB) beschleunigt Metadaten und macht ls auf großen Verzeichnissen spürbar flüssiger.
• ARC: 128 GB RAM sind bei diesem Volumen ein solider Startwert.

Hintergrund zur Wirkung von Special vdev und ARC-Tuning haben wir in unserem Artikel zu SLOG und Special VDEV ausführlich zerlegt.

Beispiel 2: VM-Storage mit 50 TB für Proxmox

Workload: 30 bis 60 VMs auf einem Proxmox-Cluster, gemischt aus Windows-Server, Linux und Datenbanken. iSCSI oder NFS an die Hypervisor.

• Layout: 6 x Mirror-vdev mit je 2 x 15 TB Enterprise NVMe — oder als günstigere Variante 6 x Mirror mit je 2 x 8 TB SATA-SSD
• Rohkapazität: 90 TB, nutzbar rund 45 TB (50 Prozent) minus ZFS-Overhead
• Redundanz: eine Platte pro Mirror-vdev
• IOPS: durch 6 vdevs bewusst hoch — Mirror-Pools skalieren pro vdev
• Slog: eigenes Slog auf zwei kleinen Enterprise-NVMe (z. B. 200 GB, Power-Loss-Protection) als Mirror — Pflicht für NFS-VM-Storage mit sync=always.
• ARC: 256 GB RAM, kein L2ARC nötig, solange die Working-Set ins RAM passt.

Warum Mirror und nicht RAID-Z für VMs? Weil VM-Workloads viele kleine, verstreute Writes erzeugen. RAID-Z zwingt für jeden Block eine Full-Stripe-Rechnung durch — Mirror-vdevs bedienen den gleichen IOPS-Bedarf mit deutlich niedrigerer Latenz. Wer sich unsicher ist, ob VM-Storage über ZFS oder Ceph laufen sollte, findet die Entscheidungsmatrix in Ceph vs. ZFS.

Beispiel 3: Cold-Archive mit 300 TB Rohkapazität

Workload: WORM-artiges Langzeit-Archiv, wenige große Reads, überwiegend sequentielle Writes bei Ingest, Replikationsziel für ein zweites TrueNAS-System.

• Layout: 2 x RAID-Z3 mit je 12 x 20 TB HDDs (Helium, CMR, Enterprise-Grade)
• Rohkapazität: 480 TB, nutzbar rund 300 TB nach RAID-Z3-Overhead und ZFS-Reserve
• Redundanz: drei Platten pro vdev — notwendig, weil die Rebuild-Zeit einer 20-TB-Platte in einem 12er-vdev je nach Auslastung 3 bis 5 Tage betragen kann
• Cache: kein Slog, kein L2ARC — lohnt sich für reines Archiv nicht
• Kompression: zstd-3 als Default — der Overhead ist minimal, der Nutzen bei gemischten Dokumenten deutlich
• ARC: 64 GB RAM reichen für diese Workload aus

Wer ein Cold-Archive konservativ dimensionieren will, findet in unserem Artikel zur 3-2-1-Backup-Regel den passenden Kontext zur Frage, wieviel Redundanz zwischen Primärstorage, Nearline-Archiv und Offsite-Kopie sinnvoll ist.

Slog, L2ARC und Special vdev: wann sich welche Ergänzung rechnet

Diese drei Zusatz-vdevs verwechseln viele — obwohl sie völlig unterschiedliche Probleme lösen.

• Slog (Separate Intent Log): beschleunigt synchrone Writes. Sinnvoll für NFS-VM-Storage, Datenbanken mit O_SYNC, iSCSI mit sync=always. Kein allgemeiner Write-Cache. Immer als Mirror aus zwei kleinen NVMe-SSDs mit Power-Loss-Protection. Ohne PLP kann ein Stromausfall genau die Transaktionen zerstören, die der Slog eigentlich absichern soll.
• L2ARC: erweitert den Read-Cache auf schnelle SSDs. Braucht selbst RAM für seine Index-Strukturen — ein zu großer L2ARC frisst ARC-RAM auf und macht den Pool langsamer. Erst sinnvoll ab mindestens 128 GB RAM und wenn die Working-Set nachweislich nicht ins ARC passt.
• Special vdev: speichert Metadaten und optional kleine Blocks auf einem eigenen Mirror-vdev. Wirkung: ls auf großen Verzeichnissen wird spürbar schneller, Backup-Scans laufen kürzer. Immer als Mirror — ein einzelnes Special vdev kann den Pool zerstören. Empfehlung: 3-Way-Mirror für produktive Systeme.

Details zur Wahl der richtigen NVMe für Slog und Special vdev, inklusive Sizing-Faustformeln, stehen in unserem Beitrag OpenZFS 2.4 Anwender-Update.

Von der Planung zur Konfiguration

Sobald das Layout steht, ist die Hardware-Frage der einfachere Teil. Chassis, Backplane, HBA, CPU-Kerne und Netzwerk skalieren linear mit dem gewählten Design. Für Standardfälle bilden wir das direkt im TrueNAS-Konfigurator ab — für Sondergrößen, HA-Systeme oder Sonderausstattungen wie 100 GbE oder mehrere Special vdevs ergibt eine kurze Sizing-Session mit unserem IT-Beratungs-Team meist mehr Wert als jedes weitere Datenblatt. Preise für die größeren Systeme geben wir bewusst als Rahmen oder auf Anfrage — der Hardwaremarkt schwankt zu stark, um pauschale Zahlen zu drucken.

Häufige Fragen zur ZFS-Pool-Planung

Wieviel Kapazität verliere ich bei RAID-Z2 tatsächlich?

Rechnerisch (n - 2) / n, also z. B. 75 Prozent bei einem 8-Platten-vdev. Real bleiben nach ZFS-Overhead und der empfohlenen Reserve auf 80 Prozent Auslastung rund 60 bis 65 Prozent der Rohkapazität als nutzbarer Speicher übrig. Diese Zahl sollten Sie in jeder Planung verwenden — nicht die reine Paritäts-Formel.

Wie groß soll ein SLOG sein?

Ein SLOG muss nur die synchronen Writes von etwa 10 Sekunden puffern können. Bei 10 GbE-Anbindung reichen 16 bis 32 GB — die übrig gebliebene Kapazität der NVMe wird nicht genutzt. Wichtiger als die Größe sind niedrige Latenz und Power-Loss-Protection.

Wie viele Platten pro RAID-Z-vdev sind sinnvoll?

Für RAID-Z1: 3 bis 5. Für RAID-Z2: 6 bis 10. Für RAID-Z3: 10 bis 15. Größere vdevs sind rechnerisch attraktiv, aber die Rebuild-Zeit und das Risiko während des Rebuilds steigen deutlich an.

Kann ich einen ZFS-Pool nachträglich erweitern?

Ja, aber mit Einschränkungen. Sie können ein neues vdev hinzufügen — der Pool wird größer, alte Daten bleiben aber auf den alten vdevs. Seit OpenZFS 2.3 gibt es zudem RAID-Z Expansion: einem bestehenden RAID-Z-vdev lässt sich eine weitere Platte hinzufügen. Der Rebuild ist aufwändig und die alten Blocks behalten ihr altes Paritäts-Verhältnis — für echte Green-Field-Planung ist es besser, das Ziel-Layout gleich richtig zu wählen.

Brauche ich zwingend ECC-RAM für ZFS?

Für produktive Systeme: ja. ZFS erkennt und repariert Bit-Rot auf Platten, aber nicht im RAM. Ein defektes RAM-Modul kann checksummen-korrekte, aber inhaltlich falsche Daten in den Pool schreiben — ein Problem, das jedes Dateisystem betrifft, aber bei ZFS besonders unangenehm ist, weil der Snapshot-Verlauf die falschen Daten mitschleppt.

Was ist der häufigste Planungsfehler?

Zu breite RAID-Z-vdevs oder zu wenige vdevs. Ein einzelnes 20er-RAID-Z2 sieht auf dem Papier attraktiv aus, liefert aber die IOPS einer einzigen Platte — und produziert Rebuild-Zeiten, die die Redundanz aushebeln. Zwei 10er-vdevs statt einem 20er-vdev sind fast immer die bessere Wahl.