Wenn Speicher wächst

von Dr. Holger Reibold

OpenZFS vereint Dateisystem und Volume-Manager in einer durchgängigen Architektur. Richtig eingesetzt entstehen Storage-Pools, die Datenverluste erkennen, Snapshots ohne Zusatztools bereitstellen und sich effizient replizieren lassen. Diese Mechanismen bilden auch die Grundlage für Migrationen von Datenbeständen und kompletten Storage- Systemen. Entscheidend ist eine saubere Planung zentraler Designregeln.

Speichersysteme gehören zu den kritischsten Komponenten moderner IT-Infrastrukturen – bei gleichzeitig wachsenden Datenmengen. Klassische Storage- Architekturen stoßen dabei zunehmend an Grenzen. Hardware-RAID-Controller kapseln die physische Speicherschicht und stellen dem Betriebssystem lediglich ein logisches Volume zur Verfügung. Dateisystemen wie ext4 oder XFS fehlt dabei vielfach eine durchgehende Ende-zu-Ende- Integritätsprüfung. Bitfehler oder sogenannte "silent data corruption" bleiben daher häufig unentdeckt. Hinzu kommt, dass konsistente Backups laufender Systeme oft zusätzliche Software, Skripte oder Snapshotfunktionen der Storage-Hardware erfordern. Genau hier setzt Open‑ZFS [1] an: Das System kombiniert Dateisystem und Volume-Manager in einer einheitlichen Architektur und integriert zentrale Funktionen direkt in die Speicherschicht.

Pool und vdevs richtig planen

Um die Funktionsweise von OpenZFS praxisnah zu erklären, betrachten wir einen typischen Storage-Server, wie er in zahlreichen kleinen Rechenzentren, Lab-Umgebungen oder auch Virtualisierungsclustern zum Einsatz kommt. Das System soll gleichzeitig performanten VM-Storage bereitstellen, Backups ermöglichen und eine hohe Datensicherheit gewährleisten.

Die wichtigste Designentscheidung bei der Arbeit mit OpenZFS fällen Sie bereits beim Aufbau des Storage-Pools. Anders als klassische RAID-Systeme arbeitet ZFS nicht direkt mit einzelnen Festplatten. Stattdessen fasst es mehrere Disks zu sogenannten Virtual Devices (vdevs) zusammen. Ein oder mehrere vdevs bilden anschließend gemeinsam den Storage-Pool (zpool). Ein einfaches Beispiel für einen Pool mit RAIDZ2, dem Redundanzkonzept von OpenZFS, könnte so aussehen:

Der Pool trägt die Bezeichnung "itabeispiel". Die sechs Festplatten werden zu einem RAIDZ2-vdev zusammengefasst. Dieses vdev bildet die grundlegende Speichereinheit, über die ZFS seine Daten organisiert. Der entscheidende Punkt ist: ZFS verteilt Daten über die vdevs – nicht über einzelne Festplatten.

Dieses Konzept hat direkte Auswirkungen auf Performance, Redundanz und Erweiterbarkeit. Beim Erzeugen eines Pools sollten Sie stets "ashift=12" setzen, um moderne Festplatten mit 4K-Sektoren korrekt anzusprechen. Ein falsch gewählter Wert lässt sich nachträglich nicht korrigieren.

Auch bei der Skalierung unterscheidet sich ZFS von klassischen RAID-Systemen. Ein bestehendes RAIDZ-vdev – also auch ein RAIDZ2-Verbund wie im Beispiel – lässt sich traditionell nicht einfach um zusätzliche Festplatten erweitern. Diese Einschränkung hat viele Adminis- tratoren in der Vergangenheit überrascht. Die typische Vorgehensweise: Sie fügen dem Pool ein neues vdev hinzu. Der Pool wächst damit horizontal. Beispielsweise kann ein zweites Mirror- oder RAIDZ-Set ergänzt werden, über das ZFS anschließend ebenfalls Daten verteilt.

Gut zu wissen: Neuere Versionen von OpenZFS unterstützen die RAIDZ-Expansion. Damit lassen sich bestehende RAIDZ-vdevs nachträglich um Festplatten erweitern, wobei die Daten über alle Disks neu verteilt werden. Für ZFS sollten Sie ausschließlich CMR-Festplatten einsetzen. SMR-Laufwerke können bei Resilver-Vorgängen extrem hohe Latenzen verursachen und Pools destabilisieren. Besonders bei großen RAIDZ-vdevs kann sich der Resilver-Vorgang deutlich verlängern.

Datasets gezielt konfigurieren

Während Pools und vdevs die physische Struktur definieren, liegt die eigentliche Flexibilität von OpenZFS bei den Datasets. Ein Dataset ist ein eigenständiges Dateisystem im Pool mit individuell konfigurierbaren Eigenschaften. Datasets lassen sich sehr einfach erzeugen, beispielsweise für unterschiedliche Workloads:

Jedes Dataset kann eigene Parameter besitzen. Dadurch lassen sich Virtualisierungs-, Backup- oder Archivdaten innerhalb desselben Pools gezielt optimieren. Neben Dateisystem-Datasets existieren sogenannte zvols. Diese blockbasierten Volumes werden zum Beispiel für VM-Disks, iSCSI-Targets oder virtio-Storage genutzt.

Eine wichtige Eigenschaft ist die integrierte Kompression. Viele Installationen setzen standardmäßig auf LZ4:

Die Kompression reduziert die Menge an geschriebenen Daten und damit auch die Anzahl der IO-Operationen. Gleichzeitig ist der CPU-Aufwand gering, sodass die Gesamtperformance häufig sogar steigt. Die ZFS-Deduplizierung wird selten empfohlen, da die DDT-Tabelle sehr viel RAM benötigt. Ohne ausreichend Speicher kann Dedup die Performance stark verschlechtern.

Ein weiterer wichtiger Parameter ist "recordsize". Damit bestimmen Sie die maximale Blockgröße eines Datasets. Standardmäßig verwendet ZFS 128 KByte. Für bestimmte Workloads kann eine Anpassung jedoch sinnvoll sein.

Datenbanken arbeiten häufig effizienter mit kleineren Blöcken, etwa 16 KByte, während Fileserver mit großen Dateien von größeren Werten wie 1 MByte profitieren können. Eine ungeeignete "recordsize" kann unnötige IO verursachen und damit die Leistung deutlich reduzieren.

Zusätzlich unterstützt ZFS native Verschlüsselung auf Dataset-Ebene. Dabei werden Daten direkt im Dateisystem verschlüsselt, ohne eine zusätzliche Schicht wie LUKS zu benötigen:

Der Vorteil dieser Methode liegt darin, dass Funktionen wie Snapshots und Replikation weiterhin effizient funktionieren. Administratoren können so einzelne Bereiche eines Pools gezielt verschlüsseln, ohne die Flexibilität des Systems einzuschränken. Datasets unterstützen außerdem Speicherlimits und Reservierungen:

Quotas begrenzen den maximalen Speicherverbrauch eines Datasets, während Reservations garantierten Speicher vorhalten. Das ist besonders nützlich für Multi-User-Systeme, Backupserver oder VM-Storage.

Snapshots: schnelle Rollbacks ohne Zusatztools

Eine der praktischsten Funktionen von OpenZFS sind Snapshots. Sie ermöglichen es Ihnen, den Zustand eines Dateisystems zu einem bestimmten Zeitpunkt festzuhalten – und das nahezu ohne Zeitverzögerung. Ein Snapshot lässt sich mit einem einzigen Befehl generieren:

Der Snapshot enthält eine konsistente Momentaufnahme des gesamten Datasets. Sollte später ein Fehler auftreten, etwa durch eine Fehlkonfiguration oder ein fehlerhaftes Update, können Sie den Zustand schnell wiederherstellen:

Mit dem Befehl zfs list zeigen Sie Datasets, Snapshots und deren Speicherverbrauch an. Der Befehl gehört zu den wichtigsten Werkzeugen im täglichen ZFS-Betrieb. Snapshots basieren auf dem Copy-on-Write-Prinzip: Bestehende Blöcke werden nicht überschrieben; erst bei Änderungen schreibt ZFS neue Blöcke.

Ein weiterer praktischer Anwendungsfall sind Clones. Aus einem Snapshot kann ein neues Dataset erzeugt werden:

Der Clone nutzt zunächst dieselben Datenblöcke wie der Snapshot und verbraucht daher nur minimalen zusätzlichen Speicher. Dieses Verfahren eignet sich hervorragend für Softwaretests, Entwicklungsumgebungen oder temporäre VM-Kopien. Aber beachten Sie: Ein Snapshot ersetzt kein Backup, da er sich im selben Storage-Pool wie die Originaldaten befindet. Fällt der Pool aus oder wird er gelöscht, verschwinden auch alle Snapshots. Für echte Datensicherung sollte daher weiterhin die 3-2-1-Regel gelten: drei Kopien der Daten, auf zwei unterschiedlichen Medien, davon mindestens eine außerhalb des Systems.

Replikation mit Bordmitteln

Ein großer Vorteil von OpenZFS ist die integrierte Replikationsfunktion. Anders als bei vielen klassischen Dateisystemen kann ZFS Snapshots direkt auf ein anderes System übertragen. Grundlage dafür sind die Befehle zfs send und zfs receive. Ein einfacher Transfer eines Snapshots auf einen Backupserver könnte beispielsweise so aussehen:

Dabei erzeugt zfs send einen Datenstrom des Snapshots, der über SSH an ein anderes System übertragen wird. Dort schreibt zfs receive die Daten wieder in ein entsprechendes Dataset. Das Verfahren arbeitet effizient und ermöglicht inkrementelle Übertragungen, bei denen nur geänderte Datenblöcke übertragen werden. Für den produktiven Betrieb empfiehlt sich der Einsatz spezialisierter Werkzeuge, die Snapshot-Erstellung, Aufbewahrung und Replikation automatisieren. Ein Beispiel ist "zrepl", das zeitgesteuerte Snapshots erstellt und diese zwischen Systemen repliziert.

Eine weitere verbreitete Kombination besteht aus "sanoid" und "syncoid". Während sanoid die Snapshot-Policy verwaltet – beispielsweise stündliche oder tägliche Snapshots – übernimmt syncoid den eigentlichen Datentransfer zwischen zwei Servern. Solche Werkzeuge sind heute in vielen Admin-Umgebungen Standard, da sie den Betrieb großer ZFS-Infrastrukturen deutlich vereinfachen und gleichzeitig zuverlässige Backup- und Replikationsprozesse ermöglichen.

zfs send und zfs receive in der Praxis

Neben klassischen Backup- und Disaster-Recovery-Szenarien nutzen Administratoren zfs send und zfs receive vor allem für Migrationen von Datenbeständen und kompletten Storage-Systemen. In der Praxis kommen sie etwa beim Umzug auf neue Hardware, beim Verschieben von VM-Storage zwischen Hosts oder beim schrittweisen Ersatz bestehender NAS-Systeme zum Einsatz. Dazu erstellen Sie zunächst einen vollständigen Snapshot des Quellsystems und übertragen ihn auf das Ziel. Dieser initiale Transfer kann Zeit in Anspruch nehmen, erfolgt jedoch ohne Unterbrechung des laufenden Betriebs:

Nach diesem ersten Abgleich laufen Quelle und Ziel zunächst auseinander, da sich die Daten im produktiven System weiter verändern. Anschließend übertragen inkrementelle Snapshots nur die seit dem letzten Stand geänderten Daten, wodurch sich beide Systeme schrittweise synchronisieren:

In der Praxis wiederholen Sie diesen oft mehrfach, bis sich Quelle und Ziel nur noch minimal unterscheiden. Die eigentliche Umschaltung – der sogenannte Cutover – erfolgt dann in einem kurzen Wartungsfenster. Dabei werden die relevanten Dienste gestoppt, ein letzter Snapshot erstellt und übertragen und anschließend das Zielsystem aktiviert. Da zu diesem Zeitpunkt nur noch wenige Änderungen anfallen, lässt sich die Downtime in vielen Fällen auf wenige Minuten begrenzen.

Wichtig ist dabei, die Migration nicht nur technisch, sondern auch organisatorisch sauber vorzubereiten. So sollten Dataset-Strukturen und Namenskonventionen zwischen Quelle und Ziel konsistent bleiben, um spätere Replikationen oder Rollbacks zu erleichtern. Ebenso empfiehlt es sich, zentrale Eigenschaften wie Kompression, "recordsize" oder Verschlüsselung im Vorfeld zu prüfen, da diese zwar mit übertragen werden, aber zur Zielumgebung passen müssen. Ein weiterer praktischer Aspekt ist die verfügbare Bandbreite, da sie die Dauer der Synchronisation maßgeblich beeinflusst. Insgesamt sind zfs send und zfs receive weit mehr als reine Backupwerkzeuge. Richtig eingesetzt ermöglichen sie kontrollierte Migrationen mit minimaler Ausfallzeit.

ZFS erkennt Datenfehler und repariert sich selbst

Ein zentrales Designziel von OpenZFS ist die Sicherstellung der Datenintegrität. Im Gegensatz zu vielen klassischen Dateisystemen überprüft ZFS jeden gespeicherten Datenblock mithilfe von Checksummen. Diese Prüfsummen werden zusammen mit den Metadaten gespeichert und bei jedem Lesezugriff erneut berechnet und verglichen.

Wird dabei eine Abweichung festgestellt, erkennt ZFS sofort, dass der gelesene Block beschädigt ist. Solche Fehler können beispielsweise durch defekte Festplattensektoren, Übertragungsfehler oder die bereits erwähnte "silent data corruption" entstehen. Klassische Dateisysteme bemerken solche Probleme häufig nicht, da ihnen eine durchgehende Integritätsprüfung fehlt.

Befindet sich der betroffene Block in einem redundanten vdev – etwa in einem Mirror oder RAIDZ-Verbund – kann ZFS den beschädigten Block automatisch aus einer intakten Kopie rekonstruieren. Dieser Mechanismus nennt sich Self-Healing. Das System erkennt also nicht nur Fehler, sondern repariert sie im Idealfall selbstständig.

Zusätzlich können Sie regelmäßig eine vollständige Inte- gritätsprüfung des Pools durchführen. Dafür verwenden Sie folgenden Befehl:

Beim sogenannten Scrub liest ZFS sämtliche Datenblöcke im Pool und überprüft deren Checksummen. Werden Fehler gefunden, versucht das System sie mithilfe der vorhandenen Redundanz zu korrigieren. In vielen produktiven Umgebungen ist es Best Practice, einen Scrub einmal pro Monat automatisch auszuführen. So erkennen Sie schleichende Datenfehler frühzeitig und können diese beheben, bevor sie zu ernsthaften Problemen führen.

Performance und Cache optimieren

Beim Thema Performance kursiert rund um OpenZFS viel Halbwissen. Besonders häufig zu Missverständnissen kommt es bei den Cachemechanismen oder Loggeräten. Ein grundlegendes Verstehen der ZFS-Cachearchitektur hilft daher, Systeme sinnvoll zu dimensionieren.

Der wichtigste Cache in ZFS ist der ARC (Adaptive Replacement Cache). Er befindet sich vollständig im Arbeitsspeicher und speichert häufig oder kürzlich gelesene Datenblöcke. Anders als einfache Cachemechanismen kombiniert der ARC zwei Strategien: LRU (Least Recently Used) und LFU (Least Frequently Used). Dadurch hält er sowohl kurzfristig als auch häufig benötigte Daten effizient im Cache.

Da ZFS möglichst viel RAM als Cache verwendet, wirkt es oft so, als würde das System den gesamten Speicher verbrauchen. Tatsächlich ist dieses Verhalten gewollt. Der ARC fungiert als hochoptimierter Read-Cache und gibt Speicher bei Bedarf automatisch wieder frei.

Wenn der Arbeitsspeicher nicht ausreicht, kann ein zusätzlicher Cache auf schnellen SSDs eingerichtet werden: der L2ARC. Dieser erweitert den ARC um eine zweite Cacheebene. Allerdings bringt L2ARC nur Vorteile, wenn der Datensatz größer ist als der verfügbare RAM und häufig gelesen wird. In kleinen Systemen oder bei überwiegend sequenziellen Zugriffen ist der Effekt oft gering. Der Einsatz von L2ARC ist jedoch nicht immer sinnvoll: Jeder Eintrag benötigt Metadaten im ARC (rund 70 bis 100 Byte). Auf RAM-knappen Systemen kann L2ARC den ARC verkleinern und Performance verschlechtern.

Unter Linux kann der ARC standardmäßig nahezu den gesamten freien Arbeitsspeicher nutzen. In Virtualisierungsumgebungen – etwa mit Prox-mox VE – kann dies zu Konkurrenz zwischen ARC und Anwendungen wie virtuellen Maschinen führen. In solchen Fällen empfiehlt es sich, ein ARC-Limit zu setzen. Dazu verwenden Sie den Parameter "zfs_arc_max":

Die Einstellung setzen Sie typischerweise in der Datei "/etc/modprobe.d/zfs.conf". Dadurch lässt sich der maximale ARC-Speicher begrenzen und verhindern, dass ZFS den verfügbaren RAM vollständig beansprucht. Besonders auf Hosts mit vielen VMs ist dies eine wichtige Praxismaßnahme zur Stabilisierung der Speicherverteilung.

Ein weiteres, recht häufig missverstandenes Feature ist der SLOG (Separate Log Device). Er beschleunigt ausschließlich synchrone Schreiboperationen, etwa bei Datenbanken oder NFS-Storage. Viele Administratoren erwarten, dass ein SLOG allgemeine Schreibvorgänge beschleunigt – etwa beim Kopieren großer Dateien über SMB. Das ist jedoch nicht der Fall.

In modernen ZFS-Architekturen kommen SSDs zunehmend als Special-vdevs zum Einsatz. Diese speichern Metadaten und kleine Dateien auf schnellen Flashgeräten, während große Daten weiterhin auf HDDs liegen. Besonders bei großen Pools kann dies die Geschwindigkeit von Operationen wie ls oder find deutlich verbessern, da Metadatenzugriffe erheblich schneller erfolgen.

Monitoring und Alerting nicht vergessen

Auch bei OpenZFS ist Monitoring essenziell. Der wichtigste Diagnosebefehl ist zpool status. Er zeigt Poolzustand, fehlerhafte Disks sowie laufende Resilver- oder Scrub-Prozesse. Eine zentrale Rolle übernimmt dabei der ZFS Event Daemon (ZED). Dieser Dienst überwacht kontinuierlich Ereignisse innerhalb des ZFS-Subsystems. Erkennt das System beispielsweise einen Festplattenfehler, einen degradierten Pool oder Probleme bei einem Scrub-Vorgang, wird ein entsprechendes Event erzeugt. ZED kann diese Ereignisse automatisch verarbeiten und Benachrichtigungen auslösen, etwa per E-Mail oder durch Skripte, die in bestehende Monitoringlösungen integriert werden. Dadurch erfahren Sie frühzeitig von Hardwareproblemen und können reagieren, bevor Daten gefährdet sind.

Neben solchen Ereignis-basierten Warnungen ist auch die kontinuierliche Beobachtung wichtiger Systemmetriken sinnvoll. In vielen modernen Infrastrukturen wird hierfür Prometheus eingesetzt. Über spezielle Exporter lassen sich ZFS-interne Kennzahlen auslesen und in das Monitoringsystem integrieren.

Fazit

OpenZFS ist weit mehr als ein klassisches Dateisystem. Durch die Kombination aus Dateisystem, Volume-Manager und integrierten Funktionen entsteht eine vollständige Storage-Plattform. Datenintegrität durch End-to-End-Checksummen, nahezu sofortige Snapshots und integrierte Replikation erleichtern Backups, Tests und Disaster Recovery. Durch Pools, vdevs und Datasets lassen sich unterschiedliche Workloads gezielt optimieren. Voraussetzung ist jedoch eine sorgfältige Planung der Poolstruktur und zentraler Parameter. Richtig konfiguriert bietet OpenZFS ein leistungsfähiges und langfristig skalierbares Speichersystem – besonders für Virtualisierungs-, Backup- und NAS-Umgebungen.

OpenZFS in der Praxis

Wenn Speicher wächst

Pool und vdevs richtig planen

Pool und vdevs richtig planen

Datasets gezielt konfigurieren

Snapshots: schnelle Rollbacks ohne Zusatztools

Replikation mit Bordmitteln

zfs send und zfs receive in der Praxis

ZFS erkennt Datenfehler und repariert sich selbst

Performance und Cache optimieren

Monitoring und Alerting nicht vergessen

Fazit