Das ZFS-Dateisystem wurde vor allem für den Server- und Rechenzentrumseinsatz konzipiert. Neuerdings sammelt ZFS dort seine Pluspunkte, wo es um Big Data geht. Denn eines der beeindruckendsten Merkmale ist die schiere Größe des adressierbaren Speicherraums.

Big Data braucht neben enormen Speicherkapazitäten auch hohe Datendurchsatzraten, zuverlässige Sicherheitsfeatures, Integrationsmöglichkeiten in virtualisierte Umgebungen und nicht zuletzt die entsprechenden Management-Tools. Das alles möglichst flexibel, skalierbar und kostengünstig. Dazu müssen Hardware-Plattform und Storage-Management-System optimal zusammen arbeiten.

Für Big Data geeignete Storage-Systeme müssen für vier Herausforderungen gerüstet sein:
1) Datenwachstum: Die Beherrschung der Datenflut ist für viele Unternehmen essentiell. Speicherlösungen müssen die ständige Verfügbarkeit dieser Daten sicherstellen, und skalierbar für wachsende Anforderungen sein.
2) Datenschutz: Dazu zählen unter anderem Auto-Sync, Auto-Tier, Auto-CDP für das Backup, Disaster-Recovery, Archivierung und Compliance, heterogene Block und File-Replikation, sowie das Inbox-Virus-Scanning.
3) Datenzugriff: Informationen müssen korrekt gespeichert werden, und für alle Zugangsberechtigten überall und jederzeit verfügbar sein.
4) Datenintegrität: Gespeicherte Daten verlieren mit der Zeit ihre Integrität. Funktionalitäten für die Erkennung und Heilung korrupter Datenblöcke (Scrubbing) zur Sicherstellung von Systemperformance und Datenintegrität müssen mit enormen Datenmengen zu Recht kommen.

Das ZFS-Dateisystem adressiert mehr als eine Million TByte

ZFS (Zettabyte File System) ist ein neues innovatives Dateisystem, welches ursprünglich von Sun Microsystems entwickelt wurde. Das erste Release datiert vom 16. November 2005. Die erste »offizielle« Veröffentlichung erfolgte im Juni 2006.

Das auf Anhieb imponierendste Merkmal von ZFS ist die unvorstellbare Größe des adressierbaren Speichers. Während mit FAT32 beispielsweise keine Dateien mit mehr als 4 GByte möglich sind, kennt das 128-bit-ZFS-Dateisystem praktisch keine Grenzen. Das Dateisystem kann mehr als eine Million TByte adressieren und verwalten. So können sowohl eine einzelne Datei, als auch das gesamte Dateisystem selbst maximal 16 Exbibyte (EiB) groß sein.

Das sind exakt 16 x 2E60 Byte oder 1.048.576 TByte. Im Dateisystem, wie auch in einem einzelnen Verzeichnis, darf die Anzahl an Dateien 2E48 Byte erreichen. »Ein 128-Bit-Dateisystem zu füllen, würde die quantenmechanische Grenze irdischer Datenspeicherung übersteigen«, verdeutlich Jeff Bonwick, Chefentwickler von ZFS, die Dimension dieser Zahlen. »Man könnte einen solchen Pool nicht füllen, ohne die Ozeane zu verdampfen.«

Soll bedeuten: Die zum Speichern einer solchen Datenmenge nötige Energie ist größer als die, die zum Verdampfen sämtlicher Ozeane benötigt würde. Oder anders formuliert: Die theoretischen Grenzen können in der Praxis niemals erreicht werden, die praktischen Optionen sind also unbegrenzt.

ZFS kann schleichende Datenkorruption erkennen und heilen

Im Gegensatz zu herkömmlichen Speicherarchitekturen (mittels RAID-Controller und RAID-Arrays) und der traditionellen Datenverwaltung mittels Volume-Management und Dateisystem-Verwaltung auf drei voneinander unabhängigen Ebenen vereint und kontrolliert ZFS alle drei Funktionalitäten. Das Problem der traditionellen Datenverwaltung mittels der voneinander unabhängig agierenden Ebenen besteht darin, dass Datenkorruptionen auf Blockebene, beispielsweise verursacht durch defekte RAID-Controller, vom darüber liegenden Dateisystem unbemerkt bleiben.

Erst wenn auf diese Daten zugegriffen wird, und diese Daten nicht lesbar sind, wird das Problem sichtbar. Doch dann ist es bereits zu spät und die Daten müssen aufwändig von Band zurückgesichert werden. Das Dateisystem ist nicht in der Lage, diese Daten zu reparieren.

Anders bei ZFS. Anhand von ZFS-spezifischen Funktionalitäten, wie unter anderem Prüfsummen über Meta- und Nutzdaten, ist ZFS in der Lage, schleichende Datenkorruption nicht nur zu erkennen, sondern sogar zu heilen. Mittels »Scrubbing« prüft ZFS im Hintergrund laufend die Integrität der Datenblöcke und versucht, falls ein schadhafter gefunden wurde, diesen zu reparieren. Damit wird zuverlässig verhindert, dass Anwendungen mit falschen Daten gefüttert werden.

Externe Volumen-Manager werden nicht mehr benötigt

»Herkömmliche RAID-Lösungen, seien es nun Software-RAID oder teure RAID-Controller, haben ausgedient«, sagt Bonwick. »Auch externe Volumen-Manager werden nicht mehr benötigt, denn beides ist in ZFS direkt integriert.«

Zentrales Element von ZFS ist der so genannte Storagepool. Er besteht aus einer Anzahl physikalischen Festplatten, die zu redundanten Verbünden gruppiert werden. Als redundante Gruppen bietet ZFS an: N-Wege-Spiegel (2-way.mirror, 3-way-mirror, n-way mirror), RAID-Z (entspricht RAID-5), RAID-Z2 (entspricht RAID-DP) und sogar RAID-Z3 (triple-parity), welches den Ausfall von drei Festplatten gleichzeitig erlaubt.

Die erstellten ZFS-Dateisysteme und die logischen Block-level-basierten Volumen beziehen ihre Speicherkapazitäten aus diesem Storagepool und allokieren nur Datenblöcke, die tatsächlich genutzt werden. Thin-Provisioning ist deshalb in ZFS gleichsam automatisch mit angelegt. ZFS arbeitet zudem mit dynamischen Blockgrößen und verhindert damit, im Gegensatz zu den traditionellen RAID-Technologien, einen Überhang genutzter Speicherblöcke.

Transaktionelle Verarbeitung nach dem Alles-oder-nichts-Prinzip

Ein wichtiger Sicherheitsaspekt ist die transaktionelle Verarbeitung nach dem »Alles-oder-nichts-Prinzip«, wie man sie von Datenbanken kennt, die ja nicht auf File- sondern auf Blockebene arbeiten. Dabei wird ein Vorgang, etwa eine Block- oder Dateiänderung, erst dann gespeichert, wenn er komplett und erfolgreich abgeschlossen werden konnte.

Aufgrund des Copy-on-Write-Verfahrens, bei dem originale Datenblöcke nicht überschrieben, sondern für die Schreiboperationen neue Datenblöcke allokiert werden, wird die Ursprungsdatei während des Vorgangs nicht überschrieben und kann auch nicht beschädigt werden. Sollte ein Schreibvorgang nicht ordnungsgemäß abgeschlossen werden können, ist sichergestellt, dass es zu keinem Datenverlust oder zu Datenkorruption kommen kann.

Ein zusätzliches Sicherheitsfeature sind die Snapshots oder Clones. Beides sind quasi Zeitfenster eines bestimmten Datenbestands und als solche eine praktische Alternative sowohl für das Backup, als auch die Remote-Replikation. Während Snapshots nur gelesen werden können, darf in einen Clone auch geschrieben werden. ZFS kann 264 Snapshots oder Clones erstellen, auch hier also nur eine theoretische Grenze.

ZFS war auch mal Zankapfel

ZFS ist während seiner vergleichsweise kurzen Lebenszeit bereits mehrmals heftig zwischen die Fronten geraten. Schon kurz nach dem Erscheinen von ZFS schien es, als ob Apple darin ein wesentliches Element seiner zukünftigen Betriebssysteme sähe, und es als Standard-Dateisystem erstmals in seiner damals in der Entwicklung befindlichen neuen Version Mac-OS X 10.5 (Leopard) einsetzen wolle. Doch Unstimmigkeiten über die Lizenzierungsmodalitäten führten zum Streit zwischen Sun und Apple, und Ende 2009 zur etwas überraschenden Einstellung dieses ZFS-Projekts.

Streitobjekt war ZFS auch zwischen NetApp und Sun. Wie üblich ging es um gegenseitige Vorwürfe der Patentrechtsverletzung. Im Rahmen dieser Auseinandersetzung forderte Netapp sogar ein gerichtliches Verbreitungsverbot für ZFS, zu dem es dann aber nicht gekommen ist. Wegen der »Inkompatibilitäten« von GPL (Linux) und CDDL (ZFS) gibt es derzeit auch (noch) keine direkte Kernel-Implementierung für Linux.

ZFS ist die Basis des Nexenta Systems-Betriebssystem »NextentaStor«. Darauf basierende Storage-Appliances eigenen sich deshalb besonders für Big-Data-Anwendungen, wie beispielsweise die »NXStor«-Serie von Boston Server & Storage Solutions.

.