ZFS, bitte übernehmen Sie …

Speicherplatz kann man nie genug haben. Besonders dann nicht, wenn man das Backup für mittlerweile ein Dutzend Webserver zu verantworten hat. Also die Lizenz zum Shoppen geholt und die billigste Konsumerware gekauft, die zu haben war … – diese dann aber in rauhen Mengen. Man baue also einen günstigen & dummen SAS-Controller und so viele Platten mit HotSwap-Bays wie möglich in einen Rechner, fertig ist die Speichertonne. ZFS sich dieses Rezept nennt, das womöglich letzte Dateisystem der Menschheit, denn es vereint so ziemlich alles, was das Dateisystem-Herz begehrt: Copy-on-write, alle RAID-Modi, Snapshots, Checksummenprüfung bei jedem Lesevorgang, 128 Bit Adressierung …

Also 14 Platten mit HotSwap-Bays in einen handelsüblichen Rechner gestopft, aus einem Windows-7-System heraus ein Ubuntu-Linux virtualisiert und dieser virtuellen Instanz die physische Hoheit über 12x2TB Festplatten übertragen. Da es sich hier nur um ein Backup-Medium handelt und eine übertriebene Ausfallsicherheit keine Rolle spielt, ich mich für 2xRAID5 entschieden habe. Entscheidend dabei ist aber, daß sich beide Verbunde zu einem Pool zusammenfügen lassen und die resultierende Speichermenge somit ganzheitlich genutzt werden kann. Welchen fantastischen Vorteil das hat wird jeder erkennen, der schon mal mit Snapshots oder Hardlink-Backups zu tun hatte. Mit ein paar Kommandos ist das Ganze dann startklar:

Einen Tank erstellen mit 2xRAID5 über jeweils 6 Platten á 2 Terabyte:
root@sully:~# zpool create tank raidz1 sda sdb sdc sdd sdf sdg raidz1 sdh sdi sdj sdk sdl sdm

Alle Tanks anzeigen lassen:
root@sully:~# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 21,8T 19,3G 21,7T 0% 1.00x ONLINE –

Zur Verfügung stehenden Speicherplatz ermitteln:
root@sully:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 110K 17,8T 34,9K /tank

Status des Pools anzeigen lassen:
root@sully:~# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
sdh ONLINE 0 0 0
sdi ONLINE 0 0 0
sdj ONLINE 0 0 0
sdk ONLINE 0 0 0
sdl ONLINE 0 0 0
sdm ONLINE 0 0 0

errors: No known data errors

Den Tank mal unter Last setzen, 100 MB/s in+out ist für meine Zwecke völlig ausreichend:
root@sully:~# dd if=/dev/zero count=1K bs=16M of=/tank/foobar
1024+0 Datensätze ein
1024+0 Datensätze aus
17179869184 Bytes (17 GB) kopiert, 146,593 s, 117 MB/s

root@sully:~# dd if=/tank/foobar count=1K bs=16M of=/dev/null
1024+0 Datensätze ein
1024+0 Datensätze aus
17179869184 Bytes (17 GB) kopiert, 175,299 s, 98,0 MB/s

Diesen Zustand sichern:
root@sully:~# zfs snapshot tank@start

Jetzt zerstören wir unser gerade erstelltes Foobar, um den Rollback zu prüfen:
root@sully:~# rm /tank/foobar

Rollback bitte:
root@sully:~# zfs rollback tank@start

Auferstanden aus Ruinen, ehrlich:
root@sully:~# ls -l /tank
insgesamt 16758739
-rw-r–r– 1 root root 17179869184 2011-10-19 23:28 foobar

Dann natürlich während des Schreibens von 100 GB eine Platte aus dem Rechner gezogen, um zu sehen, was im Fehlerfall passiert. Der Schreibvorgang ging völlig unbeeindruckt weiter, als ob rein gar nichts wäre. Im Status die Platte nun natürlich offline war, also Platte wieder reingeschoben und wieder aktiviert: aufgrund der durch ZFS auf dieser Platte hinterlassen Infos (letzter geschriebener Block usw.) muss nur das an Schreibarbeit nachgeholt werden, was seit dem Entfernen der Platte hinzu gekommen ist oder sich geändert hat, 20 Sekunden dies dauerte. Ein konventioneller RAID-Controller hätte gar keine andere Möglichkeit als die Platte KOMPLETT neu aufzubauen, weil der Controller rein gar nichts über die erfolgten Änderungen an dieser Platte wüßte. Das klingt jetzt erstmal banal, aber wer mal einen 10-Stunden-Rebuild einer 2-Terabyte-Festplatte in einem Produktionssystem beaufsichtigen durfte, die Bedeutung dieser großartigen Eigenheit begreift.

Das hat mir natürlich noch nicht gereicht, also das virtuelle Ubuntu heruntergefahren und den Windows-Wirt ebenso. Dann ein Live-Ubuntu auf einen USB-Stick gepackt und davon gebootet … – ich wollte wissen, wie robust das Ganze ist, wenn z.B. das Betriebssystem verreckt und man die Daten mit einem anderen System reaktivieren wollen würde.

Im Livesystem nach ZFS-Tanks suchen:
root@live:~# zpool import

Und siehe da, alles problemlos wieder startklar mit nur einem Befehl:
root@live:~# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 21,8T 19,3G 21,7T 0% 1.00x ONLINE –

So, jetzt ist aber Schluß mit nett, jetzt wollen wir das Ding wirklich zerstören:
root@live:~# zpool destroy tank

Wir scheinen den Tank besiegt zu haben …
root@live:~# zpool import
no pools available to import

Oder doch nicht? Der Parameter -D sucht nach eventuell noch lauffähigen Tanks:
root@live:~# zpool import -D
pool: tank
id: 11868722355900426724
state: ONLINE (DESTROYED)
action: The pool can be imported using its name or numeric identifier.
config: …

Anhand der ID ist es also möglich, den Tank wieder aus dem Sumpf zu ziehen:
root@live:~# zpool import -D 11868722355900426724

Back on track! Daten wieder da:
root@live:~# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 21,8T 19,3G 21,7T 0% 1.00x ONLINE –

Letzteres funktioniert natürlich nur, wenn inzwischen nicht zu viel der urprünglichen Daten zerstört oder überschrieben wurde. Solange aber noch die Mindestanforderungen entsprechend des gewählten RAID-Modus erfüllt sind, ist selbst ein „zpool DESTROY TANK“ nicht endgültig. :) Ich bin begeistert und werde weiterhin versuchen, den Panzer zu schrotten. Die Jungs von Sun, die Macher von ZFS, haben es laut eigener Aussage jedenfalls nicht geschafft … – und die haben immerhin staatlich geprüfte Vollzeit-Folterer am Start.