ZFS-Administration unter Solaris 11.4: Pools, Datasets, Snapshots und Scrubs

Worum es geht

ZFS ist das Standard-Dateisystem von Oracle Solaris 11.4 und das einzige unterstützte Root-Dateisystem (UFS bleibt für Daten unterstützt, Boot-Umgebungen setzen jedoch ZFS voraus). Zwei Befehle decken nahezu die gesamte Administration ab: zpool verwaltet die Speicherpools (die physischen Geräte und die Redundanz), zfs die Datasets – Dateisysteme, Volumes, Snapshots –, die innerhalb eines Pools liegen.

Warum es wichtig ist

Anders als bei einem Linux-Stack aus LVM und Dateisystem werden ZFS-Pools und -Datasets als ein einziges System verwaltet, mit eingebauten Prüfsummen, Snapshots und, über send/receive, nativer Replikation. Da Boot-Umgebungen (siehe den beadm-Artikel in dieser Reihe) selbst ZFS-Datasets sind, ist das Verständnis von zfs/zpool eine Voraussetzung für sicheres Patching und nicht nur für die Speicheradministration.

So wird es angewendet

• Zuerst den Zustand der Pools prüfen: zpool status zeigt für jeden Pool die Geräte, ihren Zustand (ONLINE, DEGRADED, FAULTED) und gegebenenfalls erforderliche Reparaturmassnahmen; zpool status -x meldet nur Pools mit Problemen; zpool list liefert pro Pool eine einzeilige Zusammenfassung zu Grösse, Belegung und Zustand.
• Datasets auflisten und untersuchen: zfs list zeigt eingehängte Dateisysteme, Volumes und deren Speicherverbrauch; zfs list -t snapshot beschränkt die Ansicht auf Snapshots.
• Ein Dataset samt Eigenschaft beim Erstellen anlegen: zfs create -o compression=on tank/data; eine Eigenschaft eines bestehenden Datasets später ändern mit zfs set compression=on tank/data.
• Eine Kopie zu einem bestimmten Zeitpunkt erstellen: zfs snapshot tank/data@before-change. Snapshots sind schreibgeschützt und belegen nur Speicher für Blöcke, die sich später ändern.
• Eine Änderung rückgängig machen, indem auf einen Snapshot zurückgegangen wird: zfs rollback tank/data@before-change. Alle seit diesem Snapshot geschriebenen Daten werden verworfen; standardmässig setzt der Befehl nur auf den jüngsten Snapshot zurück und verweigert die Ausführung, wenn neuere Snapshots existieren.
• Ein Dataset replizieren oder sichern: zfs send tank/data@snap | zfs receive backuppool/data sendet den Datenstrom eines Snapshots als vollständigen Send; der Unterbefehl send unterstützt auch inkrementelle Datenströme zwischen zwei Snapshots.
• Die Datenintegrität proaktiv prüfen: zpool scrub <pool> liest jeden Block und verifiziert ihn anhand seiner Prüfsumme; repariert wird, soweit die Redundanz es erlaubt. zpool status zeigt den Fortschritt des Scrubs und den Zeitpunkt des letzten abgeschlossenen Scrubs an.
• Die I/O-Last auf Pool-Ebene beobachten: zpool iostat -v <pool> <interval> (siehe auch den Performance-Artikel in dieser Reihe) zeigt Lese-/Schreiboperationen und Bandbreite pro Gerät, wiederholt im angegebenen Intervall.

Stolpersteine

• Erzwungenes Rollback über neuere Snapshots hinaus: -r zerstört jeden jüngeren Snapshot, -R zusätzlich dessen Clones. Daher vorher mit zfs list -t snapshot prüfen, was vorhanden ist. Für die Boot-Umgebungs-Datasets des Root-Pools beadm verwenden statt zfs rollback/destroy direkt.
• zpool scrub als Backup betrachten: Ein Scrub verifiziert und repariert über die Redundanz, schützt aber weder vor dem Löschen eines Datasets noch vor einem Pool, für den gar keine Redundanz konfiguriert ist.
• Übersehen, dass das Zerstören eines Snapshots mit abhängigen Clones eine explizite Kaskadenoption erfordert – vor jedem Zerstören immer zuerst die abhängigen Objekte auflisten.