VDEV

Ein virtuelles Gerät (virtual device, vdev) ist ein Verbund aus blockorientierten Geräten (LinuxWiki: Block-Device) welche zu einem (virtuellen) Gerät zusammengefasst werden.

Pool

Ein Pool umfasst ein oder mehrere vdevs, welche unterschiedlich konfiguriert (verschiedene RAID-Typen) sein können und ein paar globale Einstellunngen, welche auf alle enthaltenen vdevs zutreffen (deduplizierung, kompression uvm.).

RAIDZx

N = Anzahl Festplatten	Stripe	Mirror	RAIDZ1	RAIDZ2	RAIDZ3
Min. Festplatten	1	2	2	4	5
Fehlertolleranz	0	N-1	1	2	3
Größe Parität	0	(N-1)/N	1	2	3

ARC – Lesecache im RAM

Der Adaptive Replacement Cache (https://www.usenix.org/legacy/events/fast03/tech/full_papers/megiddo/megiddo.pdf) wird von ZFS im RAM abgelegt und enthält häufig angefragten Daten. Demnach sollte der RAM im Hostsystem so groß wie möglich sein. Empfohlen wird ZFS nicht mit weniger als 32GB RAM zu verwenden. Im Detail kann dies jedoch je nach Anwendungsfall variieren.

L2ARC – Lesecache auf SSDs

Level-2-ARC ist eine Lösung für kleine Budgets oder besondere Anforderungen. Dabei wird ein Teil der Daten aus dem ARC, wenn dieser voll ist, in den L2ARC geschoben. Es sollte klar sein, dass ausschließlich enterprise ssds als L2ARC verwendet werden sollten, da es sonst zu einer überaus schlechteren Performance führen kann, als ohne L2ARC und vollem ARC. Stichwort: Latenz

ZIL / LOG – Schreibcache auf SSDs

Um sicherzustellen, dass ein Schreibvorgang abgeschlossen ist, wird jeder Vorgang nach Abschluss bestätigt. Sobald bspw. das Betriebssystem nach einem Schreibvorgang eine solche Bestätigung erhält, ist wohldefiniert, dass die geschriebenen Daten an der vorgegeben Stelle vorhanden sind.

Dieses verhalten führt aber zu Problemen bei Festplatten. Da die Latenz einer Festplatte (Signalweg, Bewegung Lese-/Schreibkopf etc.) sehr hoch ist, kann es bei vielen paralellen Vorgängen dazu führen, dass das Hostsystem im sogenannten „iowait“ einfriert.

Als Antwort auf das Problem bietet ZFS die Möglichkeit, einen Schreibcache zu konfigurieren. Diese fängt alle Schreibvorgänge ab und muss immer schneller als der „echte“ Pool aus (wahrscheinlich) Festplatten. Da der ZIL nur mit SSDs eingerichtet werden sollte, ist klar, dass durch die verringerte Latenz es zu wesentlich weniger iowait kommt.

Bei der Umsetzung sollte jedoch darauf geachtet werden, dass der ZIL immer als Mirror betrieben werden muss, die SSDs PLP besitzen und das Hostsystem über eine UPS verfügt. Da die Daten im ZIL noch nicht auf den Pool geschrieben wurden, würde es ansonsten bei einem Stromausfall oder Hard-reset zu Datenverlust kommen.

Prefetch

demnächst

Demand

demnächst