ZFS The last word in file systems

Transkript

1 ZFS The last word in file systems Aurel Bodenmann 25. April 2007 Aurel Bodenmann 1

2 Geschichte! 3 Was ist ZFS?! 3 Eigenschaften von ZFS! 5 Pooled storage 5 Datenintegrität 6 Das File system wird zur Datenbank 9 Performance 11 Weitere Eigenschaften von ZFS 12 Betriebssystemunterstützung! 15 Aktuelle Einschränkungen! 15 Praktischer Teil - Let the games begin!! 17 Einstieg 18 Erstellen eines Storage pools 18 Status eines Storage pools abfragen 19 Hinzufügen einer weiteren Disk 19 Erstellen von File Systemen 22 Optionen von File systemen ändern 23 Mit Quotas und Reservierung arbeiten 24 Snapshots, Klone und Backup 25 Weitere administrative Aufgaben 27 Wie schnell ist ZFS?! 28 Fazit! 30 Aurel Bodenmann 2

3 GESCHICHTE Am 14. September 2004 präsentierte SUN ihr neues File system ZFS erstmals der Öffentlichkeit 1. Entwickelt unter der Leitung von Jeff Bonwick 2 soll es gemäss SUN the last word in file systems darstellen. Mit der Veröffentlichung von Build 27 von OpenSolaris 10 fand ZFS dann den Weg an die breite Öffentlichkeit und konnte von Interessenten getestet werden. Seit dem Release 6/06 befindet sich ZFS auch in dessen kommerziellem Ableger Solaris was doch als Zugeständnis für die forgeschrittene Stabilität von ZFS interpretiert werden darf. Vor einigen Tagen genauer am 06. April 2007 ist die erste grössere Portierung von ZFS freigegeben worden: Pawel Dawidek 3 - seines Zeichen FreeBSD Entwickler hat ZFS erfolgreich nach FreeBSD portiert. Weitere Portierungen sind im Gange, so wird das kommende Mac OS X 10.5 (Codename Leopard) ebenfalls ZFS unterstützen, auch Linux unterstützt ZFS in einer eingeschränkten Form (siehe später). Die Portierung erleichtert dabei natürlich die Tatsache, dass ZFS von Beginn an als OpenSource freigeben wurde. WAS IST ZFS? ZFS wird von SUN selber wie erwähnt als the last word in file systems angesehen. Dieser wohl aus der Marketing-Abteilung stammender Phrase mag man angesichts der rasanten Entwicklung im Informatik-Bereich mehr oder weniger Vertrauen schenken, Tatsache ist jedoch, das ZFS von einem technischen als auch administrativen Gesichtspunkt her anderen File systemen weit voraus ist. Für was das FS in ZFS steht dürfte klar sein, das Z dürfte hingegen schon eine wesentliche spannendere Herkunft aufweisen. Jeff erläutert die Geschichte in seinem Blog 4 im Detail, das Z stand dabei anscheinend einmal für Zettabyte (entspricht Byte, zum Vergleich: 1 Terabyte = Byte), unterdessen ist es ein sog. Pseudo-Akronym Aurel Bodenmann 3

4 Das Z deutet es schon an: bei der Entwicklung von ZFS wurde darauf geachtet, möglichst alle limitierenden Faktoren für absehbare Zeit aus der Welt zu schaffen. ZFS ist dabei ein 128Bit File system und damit heutigen File systemen mit üblicherweise 64Bit um Längen voraus (ein 128Bit File system kann 256 Billiarden Zettabytes adressieren!). SUN selber rechnet damit, dass wir in 10 bis 15 Jahren ein 65stes Bit brauchen werden (sofern die Gesetze von Moore bis dahin weiterhin Gültigkeit haben) 5. Bei 128Bit hingegen wird dies ungleich länger dauern: Man bräuchte mehr Energie um ein ZFS zu füllen als man benötigen würde um die Ozeane zum Kochen zu bringen wie Jeff humorvoll schildert 6. Nicht alle Grenzen liegen bei 128Bit, einige wie z.b. die Anzahl Dateien liegen wesentlich tiefer (Anm: ZFS verwendet jedoch nicht eine oft limitierende fixe Anzahl Inodes sondern arbeitet mit verketteten Metadaten). Sie wurden jedoch alle so gewählt, dass in absehbarer Zeit (>50 Jahre) nicht mit Engpässen zu rechnen ist 7. Bei der Entwicklung wurde gemäss SUN grössten Wert auf ein stabiles, skalierbares, performantes und dennoch einfach zu administrierendes Design gelegt. Wie der geneigte Leser (hoffentlich) sowohl im theoretischen als auch praktischen Teil sehen wird scheinen dies nicht bloss leere Versprechen zu sein. Die Entwickler von ZFS setzen dieses übrigens regelmässig widrigen Bedingungen aus: ein Programm namens ztest führte dabei jede Nacht einen massiven, parallen Test durch. Das File system wird dabei mit allen möglichen Aktionen überflutet, es werden mehrere Millionen Abstürze simuliert (siehe auch sonst ein sehr lesenswerter Artikel). Und dies alles ohne Datenverlust! Die Entwickler selbst bezeichnen dies meiner Meinung nach sehr treffend damit dass ztest zu Probably more abuse in 20 seconds than you d see in a lifetime führt. Neben den oben erwähnten Design-Richtlinien von ZFS möchte ich noch auf einige spezifische Eigenschaften eingehen welche ZFS aus der Masse der anderen File systeme hervorhebt Aurel Bodenmann 4

5 EIGENSCHAFTEN VON ZFS Pooled storage File systeme sind aus historischen Gründen immer für eine Disk ausgelegt. D.h., dass das File system selbst nur auf einer Disk resp. Partition arbeitet. Neben der äusserst geringen Skalierbarkeit ist dieses Konzept natürlich auch aus Gründen der Datensicherheit äusserst schlecht. Um nun dieses Manko zu umgehen, wurden auf Betriebssystem-Ebene sog. Volume manager implementiert (z.b. LVM unter Linux, das GEOM Framework unter FreeBSD etc.). Diese Volume manager fassen mehrere physikalische Disks zusammen und präsentieren sie als eine einzige virtuelle Disk im System. So wird überhaupt erst Skalierbarkeit (im Sinne von Grösse und Durchsatz) sowie Ausfallsicherheit erreicht, kann man doch mehrere Disks in einem RAID zusammenfassen. Dieser Ansatz ist jedoch aus mehreren Gründen unschön, praktisch alle davon lassen sich auf die Trennung von Volume manager und File system zurückführen: Vergrössern/Verkleinern muss in zwei separaten Schritten erfolgen (zuerst FS, dann VM resp. vice versa). Allgemein ist die Administration mühsam und kann sehr tückenhaft sein (mount, fstab, fsck, growfs, fdisk, mkfs usw.) FS hat keine Ahnung/Kontrolle, auf welcher Disk die Daten zu liegen kommen: Falls mehrere FS auf einer virtuellen Disk residieren, führt dies somit zu Performanceverlusten mangels fehlender Absprachen. Die FS greifen u.u. parallen auf die virtuelle Disk zu was zu Engpässen führen kann. Wiederherstellen ist teuer: der VM weiss nicht, welche Daten vom FS gebraucht werden und welche nicht -> es muss immer die komplette Datenmenge auf Parität überprüft werden. Speicherplatz ist fragmentiert; so werden u.u. nicht alle Disks gleichmässig ausgelastet da die Volume manager und auch die File systeme nichts voneinander wissen (siehe Abbildung 1). Aus diesem Grund entschied sich SUN bei der Implementation von ZFS dafür, den Volume manager in das File system zu integrieren. Konkret besitzt ZFS einen sog. Storage pool welcher aus einer beliebigen Menge Disks bestehen kann. Dieser Storage pool abstrahiert also die physikalischen Disks und befreit das File system von Verwaltungsaufgaben (Disk Aurel Bodenmann 5

6 layout, RAID usw). Auf diesem abstrahiertenden Storage pool kann nun wiederum eine beliebige Menge an File systemen erstellt werden. Diese teilen sich den gesamten verfügbaren Platz. Dieses Konzept bietet einige wunderschöne Eigenschaften, so kann man z.b. bei Platzproblemen dem Storage pool einfach eine weitere Disk hinzufügen, alle File systeme nutzen den neuen Platz automatisch. SUN vergleicht dieses Konzept mit der Art und Weise, wie der RAM vom System verwendet wird: das System verwendet allen vorhanden RAM und teil ihn unter den Prozessen auf. Habe ich zuwenig RAM, so füge ich einfach einen weiteren Speicherriegel hinzu. Das System verteilt die dazugewonnene Kapazität automatisch unter den Prozessen. Wir brauchen nichts einzustellen, keine Partionierung, keine Initialisierung, kein erneuts Kompilieren! Das folgende Bild verdeutlicht den Unterschied zwischen VM + FS und ZFS nochmals: Abbildung 1: VM & FS vs. ZFS Datenintegrität Bevor ich näher auf dieses Thema eingehen kann ist es nötig, das von ZFS verwendete Layout zu beschreiben (in stark vereinfachter Form). ZFS ist ein hierarchisches File system, alle Operationen sind im Prinzip Transaktionen (siehe später). Vergleichbar mit einer verketteten Liste (oder aber den Inodes) besteht das ZFS auf einem Baum. In der untersten Ebene befinden sich die Daten, nach oben wird nun die Hierarchie (FS etc.) aufgebaut. An oberster Stelle befindet sich der sog. Ueberblock, dieser ist u.a. auch für das COW-Konzept von grosser Wichtigkeit (auch hierzu siehe später). Diese Elemente sind nun alle verlinkt, wissen also von ihrem Elter resp. ihren Kindern. Genauere Details über die Interna liegen meines Wissens nach z.zt. leider nicht vor, es sei denn, man ist bereit, sich den Sourcecode von ZFS zu Gemüte zu führen. Aurel Bodenmann 6

7 Kehren wir zur Datenintegrität zurück. Wir verlangen von File systemen als eine der wichtigsten (wenn nicht sogar der wichtigsten) Eigenschaft, dass eine gespeicherte Datei sich auch noch nach Jahren korrekt lessen lässt. Traditionelle File systeme berechnen dazu für jeden zu schreibenden Datenblock eine Checksumme und legen diese mit den Daten in einem Block ab. Beim Lesen kann nun diese Checksumme auf die Daten angewandt werde, somit werden diese verifiziert. Gekippte Bits werden mit dieser Methode erkannt, weitere Fehler wie Phantom writes, an der falschen Stelle geschriebene/gelesene Daten, versehentliches Überschreiben von Daten etc. lassen sich mit dieser simplen Methode jedoch nicht erkennt. Auch hier liegt das Problem z.t. bei der Trennung zwischen Volume manager und File systeme. Viele Probleme entstehen jedoch schlicht und einfach auch weil die Checksumme zusammen mit dem Daten im gleichen Block abgelegt wird. ZFS bricht diese Koppelung auf und speichert die Checksumme nicht im Block (mit den Daten) sondern im Elter (wir erinnern uns, jeder Datenblock hat einen Elter da das File system hierarchisch aufgebaut ist). Der Elter wiederum wird von seinem Elter überprüft usw. Dadurch ist der komplette Baum selbstvalidierend, ZFS erkennt also nicht nur gekippte Bits sondern eben auch Phantom writes etc. Es versteht sich von selbst, dass diese Validierung völlig transparent gegnüber Applikationen durchgeführt wird, Auch hier fehlen mir weitergehende Details, es darf jedoch erwähnt werden, dass SUN die Datenintegrität von ZFS als eine der obersten Prioritäten bei der Entwicklung betrachtete. Ich möchte an dieser Stelle auch auf eine Präsentation von SUN hinweisen 8, welche dem geneigten Leser weitere Einblicke in die raffinierte Lösung mit dem selbstvalidierenden Baum bietet. Abbildung 2: Selbst-validierender Baum Neben der Wahrung der Datenintegrität ist die Datensicherheit ein ebenso wichtiges Thema. Man schafft hier meist unter der Verwendung von RAID Abhilfe. ZFS bietet hier nichts 8 Aurel Bodenmann 7

8 neues, verbessert jedoch die bekannten Implementationen und macht den RAID zu dem was er sein sollte: Redundant Array of Inexpensive Disks. Hochverfügbare und performante RAID-5 Systeme sind meist in Hardware realisiert und kosten eine Unmenge Geld, was das Inexpensive in RAID ad Absurdum führt. Wieso das? RAID-5 besitzt leider den konzeptionellen Nachteil, dass beim Schreiben zuerst die alten Daten von allen partizipierenden Disks gelesen werden müssen da diese zur Paritätsberechnung benötigt werden. Dies führt dazu, dass das Schreiben auf RAID-5 langsam ist. Um dies nun zu umgehen, haben Hardware-Hersteller teures NVRAM (Non-volatile RAM) verbaut welches die zu schreibenden Daten sicher zwischenspeichern (bis sie dann endgültig auf den Disks landen). Um dieses sog. Write-Hole zu umgehen ohne auf teures Hardware-RAID auszuweichen entwickelte SUN das sog. RAID-Z. RAID-Z verwendet im Gegensatz zum herkömmlichen RAID variable Stripe-Grössenen. Jeder Block ist dabei sein eigener Stripe, die anderen Disks müssen also nicht zuerst gelesen werden um die Parität zu berechnen sondern man kann den Block einfach (verteilt) auf den Disks abspeichern. Zusammen mit dem COW-Konzept eliminiert dies scheinbar das Write-Hole und führt zu einer guten Performance. Auch hier fehlen leider tiefergehende Details von SUN, Interessenten empfehle ich einen Blick in den (etwas auführlicheren) Artikel vom King Jeff Bonwick 9. Übrigens: nicht nur eliminiert RAID-Z das Write-Hole, wir brauchen auch bloss wie gewohnt bloss eine Disk für die Parität zu opfern. Für die Paranoiden ist seit kurzem neben Single-parity auch Doubleparity verfügbar, es dürfen dann gleich zwei Disks ausfallen (in einem Array mit 3 Disks). Das tönt alles fast zu gut um wahr zu sein! 10 Aber es kommt noch besser Wie wir gesehen haben, garantiert uns ZFS durch den selbst-validierenden Baum die Datenintegrität. Bei der Verwendung von RAID (ZFS unterstützt neben RAID-Z auch das gewohnte Spiegeln, also das sog. mirroring ) erkennt ZFS automatisch fehlerhafte Blöcke (z.b. wenn die Disk defekt ist) und holt in diesem Fall die betroffenen Blöcke von einer anderen Disk. Bei der herkömmlichen VM + FS Kombination führt dieser Fall normalerweise entweder zu einem FS Panic (falls Metadaten betroffen sind) oder aber zu korrupten Daten. Nicht so bei ZFS! SUN nennt dieses Konzept übrigens passenderweise Self-healing data. Dass es sich dabei nicht nur um ein Schlagwort aus der Buzzword-Abteilung handelt demonstriert uns Eric Lowe in seinem Blog Aurel Bodenmann 8

9 Das File system wird zur Datenbank Der Titel mag reisserisch tönen, Tatsache ist jedoch, dass SUN sich bei der Entwicklung von ZFS durch das Transaktionen-Modell aus der Datenbank-Welt hat inspirieren lassen. Die grundlegende Idee ist dabei, dass das File system immer in einem konsistenten Zustand sein sollte. Dadurch ist das sonst notwendige fsck nach einem Absturz überflüssig. Traditionelle File systeme überschreiben die betroffenen Blöcke mit den neuen Daten. Dieser antiquarische Ansatz implementiert zu Zeiten als Plattenplatz noch knapp war hat nun den unschönen Nebeneffekt, dass nach einem Stromausfall/Absturz etc. fsck bemüht werden muss um die Konsistenz zu überprüfen. Mit steigenden Plattengrössen ein unzumutbares Unterfangen Als Abhilfe wurde journaling implementiert: bevor die Änderungen geschrieben werden, halten wir sie in einem sog. Journal fest. Nach einem Absturz müssen wir dann bloss im Journal nachschauen, welche Änderungen zuletzt durchgeführt wurden (oder eben nicht) und können das File system relativ rasch wieder in einen konsistenten Zustand überführen. Allerdings darf diese Lösung wohl berechtigt als Symptombekämpfung abgestempelt werden. Neben dem durch das Journaling eingeführten Overhead ist die Ursache des Problems das unkontrollierte Überschreiben von alten Daten keineswegs behoben. SUN geht hier mit ZFS einen äusserst eleganten Weg und nennt dieses Verfahren copy on write (COW). Das zugrundeliegende Konzept ist bestechend: wir überschreiben die alten Daten nicht, sondern schreiben die neuen Daten an eine bislang unbenutzte Stelle. Erst im letzte Augenblick wird atomar auf die neuen Daten umgestellt. Diese Vorgehensweise wird überhaupt erst durch das Konzept des hierarchischen Baums ermöglicht: wir legen die neuen Daten an einer unbenutzten Stelle ab und speichern anschliessend alle indirekten Blöcke (=Elter) ebenfalls neu ab. Erst am Schluss überschreiben wir (atomar!) den Ueberblock. Anschliessend können die alten Daten zum Löschen markiert werden (Anm: es ist möglich, dass hier ein Stromausfall dazu führen kann, dass diese Daten nicht mehr freigegeben werden. Um diese Daten freizugeben, kann der Administrator ein sog. Scrubbing 12 durchführen welche uns diese Leichen löscht). Es lässt sich nachvollziehen, dass ein Stromausfall zu einem beliebigen Zeitpunkt das System immer noch in einem konsistenten Zustand hinterlässt. Die kritische Operation das Überschreiben des Ueberblocks ist atomar und somit eindeutig. Wir benötigen nie mehr ein fsck um unsere Konsistenz wiederherzustellen. Die folgende Graphik visualisiert den Vorgang: 12 Siehe Kapitel Checking ZFS Data Integrity des Solaris ZFS Administration Guide ( Stand February 2007) Aurel Bodenmann 9

10 Abbildung 3: COW Vorgang Neben dem garantiert konsistenten Zustand des File systems ermöglich uns COW ein weiteres interessantes Feature: Snapshots. Ein Snapshot ist wie der Name schon sagt quasi ein persistentes Abbild eines File systems zu einem Zeitpunkt X. Alle anschliessenden Änderungen am File system ändern den Snapshot nicht. Neben der Versionierung ist dies natürlich insbesondere bei Backups interessant (das das Backup nicht in einer unendlich kleinen Zeit durchgeführt werden kann sollte das File system während des gesamten Backups in einem konsistenten, unveränderlichen Zustand sein). Dank COW sind Snapshots äusserst billig zu haben: wird ein Snapshot angelegt, so erstellt ZFS einen neuen Ueberblock mitsamt seinen Kindern. Die Daten werden jedoch nicht dupliziert, die Verwaltungsnodes zeigen auf die selben Daten wie auch der aktuelle Ueberblock. Werden nun im Live-System Daten geändert, so werden wie oben erwähnt die alten Daten nicht überschrieben, vielmehr werden die neuen Daten an einer freien Stelle abgelegt. Nun wird der Ueberblock aus dem Live-System neu geschrieben, unser Ueberblock aus dem Snapshot zeigt jedoch weiterhin auf die alten Daten. Es versteht sich von selbst, dass diese anschliessend nicht zum Löschen markiert werden dürfen. Wie wir sehen, kosten uns Snapshots im laufenden Betrieb (abgesehen vom Speicherplatz) sogar noch weniger als wenn wir darauf verzichten (in diesem Fall müsste man die alten Daten zum Löschen markieren welches zusätzliche I/O generiert)! Aurel Bodenmann 10

11 Abbildung 4: Ueberblocks nach dem Ändern von Daten Performance Wir haben gesehen, ZFS bietet uns viele Vorteile gegnüber traditionellen File systemen. Man mag sich nun natürlich die berechtigte Frage stellen, mit was wir für alle diese Vorteile zahlen müssen. Meist lautet die Antwort hier: mangelnde Performance. Nicht so mit ZFS! Wir haben bereits gesehen, dass ZFS nicht unter dem Write-Hole von RAID-5 leidet sondern mit RAID-Z beinahe mit der maximalen Schreibgeschwindigkeit der Disks arbeitet. Auch das COW bietet uns gesteigerte Performance gegenüber dem traditionellen Überschreiben von Datenblöcken, müssen doch die neuen Daten nicht verstreut geschrieben werden sondern können sequentiell an einer bislang unbelegten Stelle abgelegt werden. Nie mehr Defragmentierung! Durch die Integrierung des Volume managers in ZFS lassen sich ausserdem weitere Optimierungen durchführen, so weiss das File system auf welcher Disk seine Daten abgelegt werden und kann z.b. die Blockgrösse dynamisch wählen. Auch auf Applikationen welche mit verschiedenen Blockgrössen arbeiten kann so eingegangen werden. Allgemein darf gesagt werden, dass SUN richtig erkannt hat, dass heutzutage meist weder CPU-Zyklen noch Speicherplatz limitierende Faktoren darstellen. Der Kapazitätsengpass liegt vielmehr in der begrenzten Transferrate der heutigen Disks, wir sollten also wenn möglich unsere Software in Richtung minimalster I/O optimieren. Dies darf durchaus auf Kosten von CPU-Zyklen bedingt durch komplexe Algorithmen und Software geschehen, auch mit Speicherplatz dürfen wir etwas verschwenderischer umgehen als auch schon (COW Aurel Bodenmann 11

12 nutzt diesen Sachverhalt aus). Ein Beispiel: das Erstellen der Checksummen lastet eine 1GHz CPU erst bei ca. 500MB/s aus 13. Etwas sträflich vernachlässig habe ich das folgende, äusserst wichtige Konzept von ZFS: das Erstellen eines File System ist extrem billig! Es ist von der Geschwindigkeit her durchaus mit mkdir vergleichbar! Die Grundidee dahinter ist, dass wir 1 grossen Storage pool erstellen und dann auf diesem eine Vielzahl von File systemen welche sich diesen Pool teilen. SUN empfiehlt sogar, für jeden einzelnen Benutzer, für jedes einzelnde Projekt etc. ein eigenes File system zu erstellen (bislang kammen dafür ja bekanntlich Verzeichnisse zum Einsatz)! So lassen sich fein granulierte Rechte pro Benutzer einstellen (z.b. Quota). Auch lassen sich File systeme ausgehend von einem Snapshot aus klonen, man kann also quasi ein Template für einen Benutzer erstellen und anschliessend für jeden neuen Benutzer dieses Template als Vorlage verwenden. Weiterführende Themen rund um die Performance von ZFS finden sich z.b. bei solarisinternals.com 14. Ebenfalls werde ich später im kleinen Rahmen die Performance zwischen dem altehrwürdigen UFS und ZFS anhand von bonnie++ vergleichen. Weitere Eigenschaften von ZFS Wir haben auf den vergangenen Seiten die wichtigsten Eigenschaften von ZFS kennen gelernt. Diese sowie auch die folgende Auflistung ist keineswegs komplett, in den Manpage sind alle Finessen detailliert beschrieben 15. Einige Eigenschaften möchte ich jedoch kurz erwähnen weil sie mir bemerkenswert oder praktisch erscheinen. Es sind dies: Hierarchische File systeme: wir haben im Kapitel Datenintegrität bereits gesehen, dass ZFS ein hierarchisches File system ist. Dieses Konzept kommt auch bei der Erstellung verschachtelter File systeme zur Anwendung: innerhalb eines File systems selber lassen sich wiederum eine (beinahe) beliebige Anzahl weiterer File systeme erstellen (z.b. /pool/home/foo, wobei <pool> der Storage pool, <home> das Elter- und <foo> das Kinds-File system ist). Diese er tions Aurel Bodenmann 12

13 ben automatisch die Optionen des Elters 16, so wird eine im Elter eingeschaltete Komprimierung auch in allen Kindern (und Kindes-Kindern etc.) beibehalten (die Optionen lassen sich natürlich auch übersteuern). Einfache Administration: wie wir im praktischen Teil sehen werden gestaltet sich die Administration von ZFS wirklich äusserst einfach. Viele Werte sind sinnvoll vorbelegt, den früher oft benötigten Taschenrechner kann man getrost zur Seite legen. Es gibt bloss zwei Befehle, zpool für das Verwalten von Storage pools und zfs für das Verwalten von File systemen. Beide Befehle kommen mit einer einfachen, gut lesbaren Syntax und sinnvollen Hilfestellungen daher. Intelligentes Prefetching: neben den im Kapitel Performance erwähnten Optimierungen kann ZFS parallele, lineare Zugriffsmuster verschiedener Applikationen erkennen und entsprechend aktivieren. Laden sich z.b. 2 Benutzer eine Datei an einer unterschiedlichen Position ab einem FTP Server, so erkennt das ZFS (auf dem FTP Server) dies und optimiert sein Prefetching entsprechend. Komprimierung: ZFS unterstützt die transparente Komprimierung ont-the-fly, der Administrator darf dabei zwischen verschiedenen Komprimierungalgorithmen wählen 17. Online Vegrösserung: der Storage pool kann Online durch Hinzufügen einer weiteren Disk vergrössert werden. Alle File systeme nutzen dabei den neu dazugewonnenen Platz automatisch, auch kann z.b. die Sicherheit eines bislang auf einer einzelnen Disk operierenden Storage pools durch Hinzufügen einer identischen Disk automatisch erhöht werden (der Storage pool wird in ein RAID umgewandelt). Import/Export: komplette Storage pools lassen sich auf einer Maschine exportieren und z.b. über das Netzwerk auf einer anderen Maschine wieder importieren. Alle Eigenschaften des Storage pools bleiben dabei selbstverständlich erhalten. Backup/Restore: auch ein Backup lässt sich über das Netzwerk durchführen, zusätzlich kann man unter der Verwendung von Snapshots auch inkrementelle 16 Siehe Kapitel ZFS Properties des Solaris ZFS Administration Guide 17 Aurel Bodenmann 13

14 Backups durchführen. Man beachte: ZFS weiss welche Daten sich in der Zwischenzeit geändert haben! D.h. es muss nicht irgend ein Userland-Utility zuerst das komplette File system traversieren um alle geänderten Dateien ausfindig zu machen, durch die integrierte Verwaltung kann ZFS sofort mit dem Transfer der Differenz zweier Snapshots beginnen 18. Quota/Reservierung von Speicherplatz: wir habe gesehen dass SUN empfiehlt, für jeden Benutzer/Projekt etc. ein eigenes File system anzulegen. Pro File system lassen sich dabei ein Quota (also die max. erlaubte Grösse) sowie eine Reservierung (Speicherplatz wird alloziert und freigehalten) spezifizieren. Die Verwendung von Quota ist dabei auch hier billig da sich ein df rasch durchführen lässt (wir arbeiten ja mit einem File system). Würden wir hingegen Quotas auf Verzeichnisebene verwenden, so müsste bei jeder Überprüfung ein teures du durchgeführt werden. OpenSource: ZFS wurde von SUN von Beginn an unter der CDDL 19 (Common Development and Distribution License) freigegeben. An sich ein sehr begrüssenswerter Schritt, lässt sich doch ein File system von ZFS mit mehreren Jahren Entwicklungszeiten, einer grossen Menge an Entwicklern und geschützt durch mehrere Patente nicht so ohne weiteres nachbauen. Leider ist jedoch die CDDL nach Ansicht der Free Software Foundation nicht mit der GPL kompatibel 20 was leider eine Portierung nach Linux verhindert (wohlgemerkt in den Kernel, nicht in das GNU Userland). ACL: last but not least, ZFS unterstützt Access Control Lists im NT-Stil. Damit lassen sich wesentlich feiner granulierte Zugriffsrechte vergeben als dies die alten Zugriffsrechte (chmod etc) erlauben. 18 Siehe Kapitel Saving and Restoring ZFS Data des Solaris ZFS Administration Guide Aurel Bodenmann 14

15 BETRIEBSSYSTEMUNTERSTÜTZUNG Es dürfte sich von selbst verstehen, dass ZFS unter Solaris und dessen OpenSource-Ableger Opensolaris läuft. Somit steht es auch unter allen Opensolaris Distributionen wie z.b. NexentaOS 21 zur Verfügung. Wie zu Beginn erwähnt steht ZFS desweiteren im aktuellen Entwickler-Zweig von FreeBSD (7.0) zur Verfügung und scheint sich gut zu bewähren 22. Auch das kommende Mac OS X 10.5 (Codename: Leopard) wird ZFS unterstützen 23. Leider entwickeln sich die Dinge bei Linux nicht so positiv: zwar steht ZFS als Userspace-File system (FUSE) zur Verfügung 24, an einen ernsthaften Einsatz ist dabei jedoch nicht zu denken (Performance, Stabilität etc.). Die GPL unter welcher der Linux Kernel steht ist nicht mit der CDDL von SUN kompatibel. Aus diesem Grund darf der ZFS Code nicht im Kernelspace verwendet werden. Ein meiner Meinung nach äusserst ärgerliches Rumreiten auf lizenztechnischen Details, einer Portierung würde vermutlich technisch gesehen nur wenig im Wege stehen und die Linux Gemeide würde somit in den Genuss eines hervorragenden File systems kommen. Aber vielleicht kommt es ja zu einem inoffiziellen Patch? Ein Nachbauen dürfte übrigens neben der ungeheuren Grösse des Projekts vor allem an patentrechtlichen Einschränkungen zum Scheitern verurteilt sein. AKTUELLE EINSCHRÄNKUNGEN ZFS ist work in progress, wer mag kann sich den aktuellen Fortschritt anhand des jeweils neusten Opensolaris Builds zu Gemüte ziehen. Wikipedia listet einige Einschränkungen auf 25, wovon davon gewisse konzeptioneller Art sind und wohl daher in absehbarer Zeit nicht behoben werden können. Die aus meiner Sicht wichtigsten Einschränkungen sind: Aurel Bodenmann 15

16 Kein root Support: momentan lässt sich ZFS auf keinem System als root-file system verwenden. Dies wird sich wohl in absehbarer Zeit ändern, damit würden auch die meist aufwendige Partitionierung des root-file systems wegfallen (man könnte einfach separate File system mit jeweiligem Quota resp. Reservierung für /var, /tmp etc. anlegen). Kein Verkleinern möglich: ZFS lässt sich zwar Online vergrössern, leider aber noch nicht verkleinern. Eine aus Versehen hinzugefügte Disk lässt sich somit u.u. nicht mehr aus dem Storage Pool entfernen. An dieser Einschränkung wird im Moment gearbeitet, sie sollte also in absehbarer Zeit verschwinden. RAID-Z lässt sich nicht vergrössern: es ist zwar möglich, einen weiteren RAID-Z Verbund dem Storage pool hinzuzufügen, dazu sind jedoch mindestens 2 Disks notwendig. Vergrössern von RAID-Systemen kann u.u. sehr kompliziert sein, es ist daher fraglich, ob diese Funktion in absehbarer Zeit implementiert wird. Keine Verschlüsselung: momentan kann ZFS die Daten noch nicht transparent verschlüsseln, ein Projekt arbeitet jedoch bereits an einer transparenter Verschlüsselung Aurel Bodenmann 16

17 PRAKTISCHER TEIL - LET THE GAMES BEGIN! Im praktischen Teil soll es darum gehen, einen ersten, quasi spielerischen Einstieg in die Welt des ZFS zu wagen und einige der im theoretischen Teil besprochenen Eigenschaften auszutesten. Natürlich kann diese Abhandlung keinesweg vollständig sein, ich empfehle daher dem interessierten Leser unbedingt die Lektüre des Solaris ZFS Administration Guide 27. Dieser erklärt umfassend und verständlich die administrativen Aufgaben welche beim Einsatz von ZFS anfallen. Auch sehr wertvolle Informationen liefert solarisinternals.org 28, gerade auch was die Performance betrifft 29. Ich habe für meine Arbeit Opensolaris Build 59 verwendet und werde mich im Folgenden auf dieses Betriebssystem beschränken; unter FreeBSD resp. Mac OS X dürfte aber der Ablauf ähnlich sein. Für meine Testzwecke habe ich zwei identische 80GB Harddisks von Samsung verwendet, dies erlaubt mir, auch das RAID im Modus Mirror auszutesten. Die Harddisks tragen dabei den Gerätenamen c0d1 und c1d1 (also jeweils die Slave Platte am ersten resp. zweiten DIE Bus). Es gilt noch zu erwähnen, dass das Betriebssystem auf einer dritten Platte residiert, was uns für unsere Versuche eine gewisse Narrenfreiheit gewährt. Ausserdem ist Solaris recht eigen was die Benennung der Disks anbelangt: die komplette Disk lässt sich nicht über z.b. c0d1 ansprechen sondern über die Partition mit der ID 0, also c0d1p0. Im Folgenden werden Sie deshalb immer die Angabe c0d1p0 sehen, gemeint ist damit: die komplette Disk Aurel Bodenmann 17

18 Einstieg ZFS administriert man mit Hilfe zweier Befehle: zpool: Verwaltet den Storage pool, hier fügt man z.b. physikalische Disks hinzu (wahlweise mit RAID). Desweiteren benötigt man diesen Befehl um eine Übersicht über alle vorhandenen Storage pools und deren Stati zu erhalten. Auch wird dieser Befehl benötigt, um das sog. Scrubbing durchzuführen (Überprüfen auf Konsistenz). Details finden sich in der Manpage zpool(1) 30. zfs: Die meisten Befehle wird man jedoch mit zfs durchführen. Dieser verwaltet die File systeme in einem Storage pool. Neben dem Üblichen (Erstellen/ Löschen/Migrieren) lassen sich mit zfs auch die besprochenen Snapshots erstellen, Backups durchführen und verschiedene Optionen setzen. Auch hier sei auf die Manpage zfs(1) 31 verwiesen. Zuerst werden wir also sinnvollerweise einen Storage pool erstellen und diesen dann mit File systemen bevölkern. Erstellen eines Storage pools Man darf zwar ZFS auch nur eine Partition innerhalb eine Disk zur Verfügung stellen, empfohlen wird aber, ZFS immer gleich die ganze Disk zu spendieren. Dies werde ich ebenfalls so handhaben. Storage pools erstellt man mit dem Befehl # zpool create <name> [mirror raidz raidz2] <disk1> <disk2> <diskn> Die Angabe eines RAID-Levels ist natürlich nur bei mehreren Disks zulässig. Zu Beginn erstelle ich einen Storage pool bestehend aus 1 Disk, anschliessend werde ich eine weitere Disk hinzufügen: # zpool create foo c0d1p0 Ich habe nun also den Storage pool foo erstellt. Dieser wird nun initialisiert und automatisch nach /foo gemountet. Alle File systeme innerhalb dieses Storage pools werden ebenfalls als Unterverzeichnisse von /foo gemountet. Der Mountpoint könnte bei der Erstellung mit der Option m spezifiziert werden, er kann auch auf none oder legacy gesetzt werden. Im ersten Aurel Bodenmann 18

19 Fall würde der Storage pool selbst nicht gemountet, die File systeme könnten aber gemountet werden. Im zweiten Fall kann ich das Verwalten der Mountpoints durch ZFS verhindern und meinen Storage pool (samt File systemen) mit dem traditionellen mount mounten (wird nicht empfohlen). Status eines Storage pools abfragen Mit zpool list erhalte ich eine Übersicht aller vorhandenen Storage pools in meinem System. Auch hier gilt: der Befehl kennt eine weitere Anzahl von Optionen, diese sind allesamt in der Manpage zpool(1) festgehalten. Interessiere ich mich für den Health-Status meiner Storage pools, so liefert mir zpool status diese Information: # zpool status pool: foo state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM foo ONLINE c0d1p0 ONLINE errors: No known data errors Wie wir sehen, ist der Pool foo funktionsfähig und zugreifbar (ONLINE). Wie erwähnt erkennt ZFS Datenkorruption, aus diesem Grund sehen wir im Health-Status auch gleich die eventuell vorhanden Lese-, Schreib- und Checksummenfehler (READ, WRITE, CKSUM). Hinzufügen einer weiteren Disk Mein System ist mit 2 Disks ausgestattet, der Pool foo nutzt aber bislang nur 1 Disk. Wir fügen nun unserem Pool im laufenden Betrieb (Online) die zweite Disk hinzu und erhöhen somit die Ausfallsicherheit (wir erstellen einen RAID vom Level Mirror ). # zpool attach foo c0d1p0 c1d1p0 Aurel Bodenmann 19

20 Wie man sieht, muss man zusätzlich zur neu zu verwendenden Disk c1d1 auch noch die bereits verwendete Disk c0d1 angeben. Die ist logisch, muss ZFS wissen aus welchen Disks es den neuen RAID formenieren soll. Ein zpool status bestätigt uns den Erfolg dieser Aktion: # zpool status pool: foo state: ONLINE scrub: resilver completed with 0 errors on Tue Apr 24 12:23: config: NAME STATE READ WRITE CKSUM foo ONLINE mirror ONLINE c0d1p0 ONLINE c1d1p0 ONLINE errors: No known data errors Wie man sieht, wurde der Storage pool foo automatisch von einer einzelnen Disk in ein RAID vom Level Mirror umgewandelt. Die Zeile scrub zeigt uns dabei an, dass das sog. Resilvering erfolgreich durchgeführt wurde. Mit Resilvering bezeichnet SUN das Überprüfen auf Parität. Wir können nun probeweise eine Disk Offline nehmen und den Status erneut ausgeben: # zpool offline foo c0d1p0 Bringing device c0d1p0 offline # zpool status pool: foo state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. Aurel Bodenmann 20