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 fuer die Datenbank nicht reicht oder die nutzbare Kapazitaet 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 Kapazitaet berechnen laesst, wann Slog, L2ARC oder ein Special vdev wirklich helfen und wie drei typische Setups fuer File-Server, VM-Storage und Cold-Archive konkret aussehen.

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

Bevor Sie ueber Plattenmodelle oder Gehaeuse nachdenken, muessen drei Fragen beantwortet sein:

1. Wieviel nutzbare Kapazitaet 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 Groesse der Datentraeger. 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 fuer RAID-Z Kapazitaet berechnen und Performance abschaetzen

ZFS kennt vier Redundanz-Layouts fuer Daten-vdevs: Mirror, RAID-Z1, RAID-Z2 und RAID-Z3. Der Unterschied liegt in der Anzahl der Paritaets- bzw. Kopie-Platten pro vdev — und damit in Kapazitaet, IOPS und Rebuild-Zeit.

Mirror-vdevs

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

RAID-Z1, Z2 und Z3

RAID-Z-vdevs verteilen Daten und Paritaet ueber mehrere Platten. Grobe Faustformel fuer die nutzbare Kapazitaet:

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

Die Faustformel ist eine Obergrenze. In der Praxis liegt die real nutzbare Kapazitaet 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 tatsaechlich 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 fuer 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 — unabhaengig 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 Rohkapazitaet zum nutzbaren Pool

Ein pragmatischer Rechenweg in vier Schritten — die Basis fuer jeden ZFS-Rechner:

1. Ziel-Kapazitaet nutzbar festlegen, z. B. 100 TB.
2. Reserve fuer Snapshots und ZFS-Overhead aufschlagen: mindestens 20 Prozent, besser 25 bis 30 Prozent. Ein Pool sollte nie ueber 80 bis 85 Prozent Auslastung laufen — ab da bricht die Schreib-Performance ein.
3. vdev-Layout und Redundanz waehlen. 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 Plattengroesse ausrechnen.

Konkret fuer 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 fuer Reserve und einheitliche Bestellung.

Wer die Rechnung nicht selbst durchgehen moechte, kann sie in unserem TrueNAS-Konfigurator direkt am Modell durchspielen — Plattenanzahl und vdev-Layout werden dort auf die verfuegbaren Chassis-Groessen abgebildet, ohne dass Sie das Datenblatt jeder Serie kennen muessen.

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)
• Rohkapazitaet: 224 TB, nutzbar rund 110 TB nach ZFS-Overhead
• Redundanz: 2 Platten pro vdev
• Cache: kein Slog noetig — SMB ist ueberwiegend asynchron. Ein Special vdev als 3-Way-Mirror aus kleinen NVMe-SSDs (z. B. 1 TB) beschleunigt Metadaten und macht ls auf grossen Verzeichnissen spuerbar fluessiger.
• 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 ausfuehrlich zerlegt.

Beispiel 2: VM-Storage mit 50 TB fuer 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 guenstigere Variante 6 x Mirror mit je 2 x 8 TB SATA-SSD
• Rohkapazitaet: 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 fuer NFS-VM-Storage mit sync=always.
• ARC: 256 GB RAM, kein L2ARC noetig, solange die Working-Set ins RAM passt.

Warum Mirror und nicht RAID-Z fuer VMs? Weil VM-Workloads viele kleine, verstreute Writes erzeugen. RAID-Z zwingt fuer 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 ueber ZFS oder Ceph laufen sollte, findet die Entscheidungsmatrix in Ceph vs. ZFS.

Beispiel 3: Cold-Archive mit 300 TB Rohkapazitaet

Workload: WORM-artiges Langzeit-Archiv, wenige grosse Reads, ueberwiegend sequentielle Writes bei Ingest, Replikationsziel fuer ein zweites TrueNAS-System.

• Layout: 2 x RAID-Z3 mit je 12 x 20 TB HDDs (Helium, CMR, Enterprise-Grade)
• Rohkapazitaet: 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 fuer reines Archiv nicht
• Kompression: zstd-3 als Default — der Overhead ist minimal, der Nutzen bei gemischten Dokumenten deutlich
• ARC: 64 GB RAM reichen fuer 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 Primaerstorage, Nearline-Archiv und Offsite-Kopie sinnvoll ist.

Slog, L2ARC und Special vdev: wann sich welche Ergaenzung rechnet

Diese drei Zusatz-vdevs verwechseln viele — obwohl sie voellig unterschiedliche Probleme loesen.

• Slog (Separate Intent Log): beschleunigt synchrone Writes. Sinnvoll fuer 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 zerstoeren, die der Slog eigentlich absichern soll.
• L2ARC: erweitert den Read-Cache auf schnelle SSDs. Braucht selbst RAM fuer seine Index-Strukturen — ein zu grosser 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 grossen Verzeichnissen wird spuerbar schneller, Backup-Scans laufen kuerzer. Immer als Mirror — ein einzelnes Special vdev kann den Pool zerstoeren. Empfehlung: 3-Way-Mirror fuer produktive Systeme.

Details zur Wahl der richtigen NVMe fuer 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 gewaehlten Design. Fuer Standardfaelle bilden wir das direkt im TrueNAS-Konfigurator ab — fuer Sondergroessen, 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 fuer die groesseren Systeme geben wir bewusst als Rahmen oder auf Anfrage — der Hardwaremarkt schwankt zu stark, um pauschale Zahlen zu drucken.

Haeufige Fragen zur ZFS-Pool-Planung

Wieviel Kapazitaet verliere ich bei RAID-Z2 tatsaechlich?

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 Rohkapazitaet als nutzbarer Speicher uebrig. Diese Zahl sollten Sie in jeder Planung verwenden — nicht die reine Paritaets-Formel.

Wie gross soll ein SLOG sein?

Ein SLOG muss nur die synchronen Writes von etwa 10 Sekunden puffern koennen. Bei 10 GbE-Anbindung reichen 16 bis 32 GB — die uebrig gebliebene Kapazitaet der NVMe wird nicht genutzt. Wichtiger als die Groesse sind niedrige Latenz und Power-Loss-Protection.

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

Fuer RAID-Z1: 3 bis 5. Fuer RAID-Z2: 6 bis 10. Fuer RAID-Z3: 10 bis 15. Groessere vdevs sind rechnerisch attraktiv, aber die Rebuild-Zeit und das Risiko waehrend des Rebuilds steigen deutlich an.

Kann ich einen ZFS-Pool nachtraeglich erweitern?

Ja, aber mit Einschraenkungen. Sie koennen ein neues vdev hinzufuegen — der Pool wird groesser, alte Daten bleiben aber auf den alten vdevs. Seit OpenZFS 2.3 gibt es zudem RAID-Z Expansion: einem bestehenden RAID-Z-vdev laesst sich eine weitere Platte hinzufuegen. Der Rebuild ist aufwaendig und die alten Blocks behalten ihr altes Paritaets-Verhaeltnis — fuer echte Green-Field-Planung ist es besser, das Ziel-Layout gleich richtig zu waehlen.

Brauche ich zwingend ECC-RAM fuer ZFS?

Fuer 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 haeufigste 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.