Hinweis zur Positionierung des offenen ZFS 128-bit Filesystems mit copy-on–write transaktions–orientiertem I/O Modell…

Um was geht es hier? ZFS (ex SUN "Zettabyte File System") ist architekturseitig für große Datenmengen und anspruchsvolle I/O-Workloads wie sie z.B. bei NFS oder auch Datenbanken auftreten, konzipiert. Voraussetzung ist eine entsprechend leistungsfähige Server- und Storageumgebung sowie Storage-Know-How, um auch den Funktionsumfang der Storage-Softwarelösung (Volume Management-/Speichermanagement und Filesystem) voll auszunutzen. ZFS ist auf Grund seiner internen 128-bit Struktur prädestiniert für Storagepools, die z.B. aus wirtschaftliche Gründen (Budget) nicht mit Hilfe von Highend-HW aufgebaut werden (z.B. Cloud-Storage / Research / HPC).

• Um open Source - Varianten von ZFS produktiv, stabil und ökonomisch (OPEX/TCO) zu betreiben, sind im kommerziellen Umfeld anwenderseitige IT Engineering-Ressourcen sehr von Vorteil; ferner sollte das I/O-Verhalten von Applikationen bekannt sein. Ein vertieftes Verständnis für den Einfluss von SW-RAID auf die Anwendungsleistung ist nützlich. Beispiel: Nach Anwenderaussagen sollte beobachtet werden, falls ZFS sequential Writes in reine random Write I/O's umwandelt. Wenn diese RAID-5 und RAID-6 Storage zugewiesen werden, können die LUNs innerhalb der internen RAID Gruppe höhere Latenzen erzeugen. Damit ist eine sorgfältige Planung beim LUN-Managements notwendig (z.B. RAID 10 anstelle RAID 6). Um hohe CPU-Ressourcenbelastungen zu vermeiden, sollte für bestimmte Operationen wie ZIL (ZFS Intent Log) ferner ein SSD- bzw. nichtflüchtiger NVRAM Speicher konfiguriert werden (best practise).

• ZFS Intent Log auf SSD: Synchrones Schreiben in ZFS erfolgt in das ZIL. Standardmäßig wird ZIL aus Blöcken innerhalb des Haupt-Speicher-Pool zugewiesen. Das ZIL ist das einzige zpool-Objekt, das ohne Transaktion geschrieben wird. ZIL abschalten bedeutet zwar einen Performancevorteil für syncr.-Writes, jedoch besteht die Gefahr von Daten–Inkonsistenzen. Deshalb sollte ZIL auf einem schnellen Log–Device wie FLASH SSD liegen, während Reads über Caching–Devices beschleunigt werden.

Das häufig angeführte Argument der unbegrenzten Kapazität, sprich Speichergröße (128-bit Zettabyte Filessystem) relativiert sich für viele Rechenzentren, da auch kommerzielle Filesysteme- und Storage-Frames weit in den Petabyte-Bereich skalieren und neben CAPEX vor allem OPEX innerhalb der gesamten Betriebskosten-Betrachtung Berücksichtigung finden sollte (Komplexität, Support, Stabilität, Verwaltungsaufwand...).

• ZFS als Open Source Unix ist als Software unter der Common Development and Distribution License (CDDL) lizensiert. Seit der Einstellung des OpenSolaris-Projektes wird die Entwicklung von ZFS im sog. "Illumos"-Projekt fortgeführt. Dazu gehören Firmen wie Nexenta, Joyent (US) oder Everycity (UK).

• ZFS-Produkte wie NexentaStor können heute fast jede Hardware in ihren Pool einbinden und unterstützt werden SAN und NAS mit Standard–Protokollen CIFS, NFS, iSCSI, FC, HTTP, FTP WebDAV oder FCoE. Nexenta bietet inzwischen eine für kommerzielle Anwendungen funktional breit aufgestellte Software Defined Storage - Lösung an, die im Zusammenhang mit dem gestiegenen Einsatz von Flash Storage für populäre Virtualisierungsprojekte wie VDI (Citrix, VMware...) oder Datenbanken gut geeignet ist.

Abb 1.: Quelle - Whitepaper: "Nexenta Liberates Storage to Deliver a better ROI"

Das Thema "Software Defined xxx" als Grundlage für virtualisierte (Cloud) Rechenzentrums-Infrastrukturen wird populärer... nach SDN jetzt auch beim Storage. Im folgenden finden Sie einen kurzen Überblick zu open Source - Lösungen auf Basis ZFS, die sich naturgemäß als HW-unabhängige Software-Alternative zu den bekannten kommerziellen Angeboten mittels erweiterter Leistungsmerkmale verstehen.

ZFS (ex SUN "Zettabyte File System") präsentiert sich architekturseitig deshalb für sehr grosse Datenmengen (much data) bzw. anspruchsvolle I/O-Workloads wie Datenbanken / NFS. Voraussetzung im RZ ist eine entsprechend leistungsfähige Server- und Storageumgebung sowie fundiertes Admin - Know-How, um den Funktionsumfang der Storage-Softwarelösung (die Volume Management-/Speichermanagement und Filesystem vereint) auch auszuschöpfen. Die Randbedingungen von Storagelösungen speziell für Big Data sollen an dieser Stelle in einem weiteren Blog diskutiert werden.

ZFS ist auf Grund seiner internen 128-bit Struktur prädestiniert für sehr grosse Storagepools, die aus Budget- oder anderen Gründen nicht mit Hilfe von Highend-HW-Frames aufgebaut werden (Cloud-Storage / Research / HPC-Umfeld). Um die open Source Variante von ZFS produktiv, stabil und wirtschaftlich (OPEX/ TCO) zu betreiben, sind gerade im kommerziellen Umfeld Anwenderseitig erfahrene Engineering-Ressourcen von Vorteil; ausserdem sollte das I/O-Verhalten von Applikationen gut bekannt sein.

Ein vertieftes Verständnis für den Einfluss von SW-RAID auf die Anwendungsleistung ist notwendig. Beispiel: Nach Anwenderaussagen ist Vorsicht geboten, wenn ZFS sequential Writes in reine random Write I/O's umwandelt. Typischerweise dann RAID5 und RAID6 - Storage zugewiesen, können diese LUNs innerhalb der internen RAID Gruppe hohe Latenzen erzeugen. Damit ist eine sorgfältige Planung beim LUN-Managements notwendig (hier z.B: RAID 10 anstelle RAID 6). Um hohe CPU-Ressourcenbelastungen zu vermeiden, sollte für bestimmte Operationen wie ZIL* (ZFS Intent Log) ein schneller, dedizierter SSD- oder NVRAM Speicher konfiguriert werden (best practise).

*Anmerkung zu ZFS Intent Log auf SSD: Synchrones Schreiben in ZFS erfolgt in das ZIL. Standardmäßig wird ZIL aus Blöcken innerhalb des Haupt-Speicher-Pool zugewiesen. Das ZIL ist das einzige zpool-Objekt, das ohne Transaktion geschrieben wird. ZIL abschalten bedeutet zwar einen Performancevorteil für syncr.-Writes (NFS, Datenbanken) jedoch besteht dann die Gefahr von Daten–Inkonsistenzen. Deshalb empfiehlt es sich, das ZIL auf ein schnelles Log–Device wie FLASH zu legen, während Reads über Caching–Devices beschleunigt werden können.

Das häufig von ZFS-Anbietern angeführte Argument der unbegrenzten Kapazität, sprich Speichergröße (128-bit Zettabyte Filessystem) relativiert sich aus meiner Sicht hingegen für viele Rechenzentren, da auch kommerzielle Filesysteme- und Storage-Frames derzeit bereits performant weit in den Petabyte-Bereich skalieren und neben CAPEX die TCO innerhalb der gesamten Betriebskosten-Betrachtung Berücksichtigung finden sollte (Komplexität, Support, Stabilität, Verwaltungsaufwand etc.).

ZFS als Open Source Unix ist als Software unter der Common Development and Distribution License (CDDL) lizensiert. Seit Einstellung des OpenSolaris-Projektes wird die Entwicklung von ZFS im sog. "Illumos"-Projekt fortgeführt. Dazu gehören Firmen wie Nexenta, Joyent (US) oder Everycity (UK). ZFS-Produkte wie NexentaStor können heute fast jede Hardware in ihren Pool einbinden und unterstützt werden SAN und NAS mit den Standard–Protokollen CIFS, NFS, iSCSI, FC, HTTP, FTP WebDAV oder FCoE.

Am Beispiel des Softwareanbieters Nexenta finden Sie nachfolgend einige grundsätzliche Leistungsmerkmale der ZFS-Lösung zusammengefasst (Quelle Nexenta):

ARC (Adaptive Replacement Cache): Während beim Storage-Tiering Daten verschoben und an der Quelle gelöscht werden, bleiben sie beim Caching auf der Quelle erhalten. Wenn ein schneller Speicher wie FLASH-SSDs für den Cache genutzt wird, können Applikationen ihre Daten direkt vom Cache holen, ohne erst auf HDDs zurückgreifen zu müssen. Mit ARC bleibt die Cache-Rate konstant hoch, auch bei Random I/Os, da es sich an das IO–Verhalten anpasst.

Copy-on-Write: Storage-Systeme nutzen meist das "Read-write-modify-Verfahren"; originale Blöcke werden während einer Schreiboperation mit neuen Daten überschrieben. Ein "RAID-5 Write-hole" entsteht, wenn das System zwischen der Änderung von Daten und der Neuberechnung der Paritätsdaten z.B auf Grund von Stromausfall abstürzen sollte (die Folge wären falsche Paritätsdaten). Diese Fehler werden immer erst erkannt, wenn die Daten bereits verloren sind. Dagegen hilft ein batteriegepufferter schneller Speicher auf Basis NVRAM. ZFS vermeidet dies, indemdie ursprünglichen Daten nie mit neuen Daten überschrieben werden (Copy-on-Write Verfahren); stattdessen werden geänderte Daten allokiert und der gesamte Prüfsummenbaum neu berechnet. Auf diese Weise sollen die Daten konsistent bleiben. Um das Schreiben zu beschleunigen, kommt bei ZFS das "copy-on-write transactional I/O Modell" zum Einsatz: Wenn aktive Daten mit neuen Daten ersetzt werden sollen, wird ein neuer Block zugewiesen. Die Metadaten als Referenz des Originals ändern sich, um auf den neuen Block zu verweisen. Als Resultat sind die meisten I/O in ZFS sequentiell und deshalb schneller zu finden. Außerdem nutzt ZFS ein Log, in dem alle Schreiboperationen gelistet sind.

RAID-Z Software: Bei ZFS ist die RAID-Funktionalität in der Software abgebildet. RAID-Z (oder RAID-Z1) ähnelt RAID-5 und bietet einfache Parität, aber es benötigt kein NVRAM durch das o.g. "Copy-on-Write-Verfahren". RAID-Z2 bietet die gleiche Redundanz wie RAID-6 (Dual-Parity), RAID-Z3 liefert dreifache Parität. Diese wird mit den aktuell verfügbaren 4TB-Festplatten wichtiger. Denn mit zunehmender Festplattengröße steigt die Rebuild-Zeit bei einem Plattenausfall und damit das Risiko weiterer Ausfälle während dieses Vorgangs. Raid-Z kann auch zwischen belegten und freien Blöcken unterscheiden. Bei der Wiederherstellung wird das System also nur den belegten Speicherplatz rekonstruieren, was Zeit spart. Mit ZFS RAID-Z gibt es kein RAID Write Hole Problem. Alle Schreibvorgänge sind "full striped high-performance Writes". ZFS verwendet hierzu eine variable Striping-Sizing. Jeder Block repräsentiert sein eigenes Stripe-Set. Da in ZFS das "Array" und Dateisystem integriert ist, sind über die mitgeführten Metadaten alle erforderlichen Informationen verfügbar, um ggf. verlorene Daten auf HDD wiederherzustellen.

Speichervirtualisierung im ZFS Storagepool: Klassische nicht-virtualisierte Dateisysteme organisieren Festplatten in Partitionen und Volumes. Der ZFS-Storagepool kombiniert alle Festplatten zu einer Einheit. Diesen elastischen Pool und die darin enthaltenen dynamischen "logischen" Partitionen lassen sich einfacher als isolierte physische Datenpools verwalten. Administratoren können HDDs nach Bedarf zum Storagepool und Dateisystemen hinzuzufügen oder bei laufenden Systemen Speicherplatz schaffen, wenn er benötigt wird; siehe auch Thin Provisioning von Speicherplatz in virtuellen Umgebungen.

Datenkorruption (silent data corruption) ausgeschlossen: ZFS arbeitet mit verteilten End-to-End-Prüfsummen, die dafür sorgen, dass jedes einzelne Bit im gesamten Dateisystem überprüft oder falls notwendig automatisiert wiederhergestellt wird. ZFS bildet Prüfsummen über Metadaten und Nutzdaten ab und speichert die Informationen in einem extra "Parent Block" ab. Die Prüfsummen werden hierarchisch in einem sog. Merkle-Baum erstellt. Auf diese Weise wird die Datenintegrität konsistent über alle Informationen sichergestellt.

Vollständige Snapshot-Historie: In ZFS können Snapshots und beschreibbare Clones unbeschränkt ohne Speicherreservierung erstellt werden. Aufgrund des Copy on Write-Verfahrens sind die älteren Daten weiter vorhanden. Snapshots lassen sich sowohl archivieren als auch mounten. Das Erstellen von Snapshots ist ohne Performance-Einbußen möglich.

Eine weitere offene auf Linux basierte Storage Software - Lösung im NAS-Umfeld ist der Red Hat Storage Server, der durch seine n-node Cluster Architektur mit skalierbarem global namespace in der v.2.0 inzwischen auch object-storage-Funktionen für komplexe unstrukturierte Datenmengen bereitstellt.