In diesem Frühling haben wir bereits einige Einführungsthemen besprochen, zum Beispiel, wie man die Geschwindigkeit Ihrer Laufwerke überprüft und was RAID ist. Im zweiten haben wir sogar versprochen, die Leistung verschiedener Multi-Disk-Topologien in ZFS weiter zu untersuchen. Dies ist ein Dateisystem der nächsten Generation, das jetzt überall implementiert wird: von Apple bis Ubuntu.

Tja, heute ist der passendste Tag, um ZFS kennenzulernen, liebe Leser. Wissen Sie einfach, dass es nach einer bescheidenen Einschätzung des Entwicklers von OpenZFS, Matt Arents, „wirklich kompliziert ist“.

Aber bevor wir zu den Zahlen kommen – und die werden kommen, versprochen – zu allen Variationen der acht Laufwerk-Konfigurationen in ZFS, müssen wir über das sprechen, als wie ZFS überhaupt Daten auf der Festplatte speichert.

Zpool, vdev und device

Dieses Diagramm eines vollständigen Pools umfasst drei unterstützende vdevs, jeweils eine aus jeder Klasse, und vier für RAIDz2

Normalerweise gibt es keinen Grund, einen Pool aus nicht übereinstimmenden Typen und Größen von vdevs zu erstellen – aber wenn Sie möchten, steht nichts dem im Weg.

Um das Dateisystem ZFS wirklich zu verstehen, muss man sich die tatsächliche Struktur genauer ansehen. Erstens kombiniert ZFS die traditionellen Ebenen der Volume- und Dateisystemverwaltung. Zweitens verwendet es einen transaktionalen Mechanismus für das Copy-on-write. Diese Merkmale bedeuten, dass das System strukturell sehr anders ist als herkömmliche Dateisysteme und RAID-Arrays. Der erste Satz grundlegender Bausteine zum Verständnis: es ist der Speicherpool (zpool), das virtuelle Gerät (vdev) und das reale Gerät (device).

zpool

Der Speicherpool zpool ist die höchste Struktur in ZFS. Jeder Pool enthält ein oder mehrere virtuelle Geräte. Jedes davon enthält wiederum ein oder mehrere reale Geräte (device). Virtuelle Pools sind autarke Blöcke. Ein physischer Computer kann zwei oder mehr separate Pools enthalten, aber jeder ist völlig unabhängig von den anderen. Pools können keine virtuellen Geräte gemeinsam nutzen.

Die Redundanz von ZFS befindet sich auf der Ebene der virtuellen Geräte, nicht auf der Ebene der Pools. Auf der Ebene der Pools gibt es absolut keine Redundanz – wenn ein vdev-Laufwerk oder ein spezieller vdev verloren geht, geht der gesamte Pool mit ihm verloren.

Moderne Speicherpools können den Verlust des Caches oder des Journals des virtuellen Geräts überstehen – obwohl sie möglicherweise eine kleine Menge an unsauberen Daten verlieren, wenn sie das vdev-Journal während eines Stromausfalls oder Systemausfalls verlieren.

Es gibt ein weit verbreitetes Missverständnis, dass ZFS "Datenstreifen" (Stripes) über den gesamten Pool geschrieben werden. Das ist nicht korrekt. Zpool ist keineswegs ein lustiger RAID0, es ist eher lustig JBOD mit einem komplexen variablen Verteilungssystem.

In der Regel werden die Aufzeichnungen entsprechend dem verfügbaren freien Speicherplatz auf die verfügbaren virtuellen Geräte verteilt, sodass theoretisch alle gleichzeitig gefüllt werden. In neueren Versionen von ZFS wird die aktuelle Nutzung (Auslastung) des vdev berücksichtigt – wenn ein virtuelles Gerät signifikant stärker belastet ist als ein anderes (zum Beispiel aufgrund von Lesevorgängen), wird es vorübergehend für Schreibvorgänge übersprungen, obwohl der höchste Anteil an freiem Speicherplatz verfügbar ist.

Der Auslastungserkennungsmechanismus, der in moderne ZFS-Schreibverteilungsmethoden integriert ist, kann die Verzögerung verringern und die Bandbreite während Zeiten ungewöhnlich hoher Last erhöhen – aber das ist kein Freibrief für unbeabsichtigtes Mischen langsamer HDDs und schneller SSDs in einem Pool. Ein solch unausgewogener Pool wird dennoch mit der Geschwindigkeit des langsamsten Geräts arbeiten, als wäre er ausschließlich aus solchen Geräten zusammengesetzt.

vdev

Jeder Speicherpool besteht aus einem oder mehreren virtuellen Geräten (virtual device, vdev). Jedes vdev umfasst wiederum ein oder mehrere physische Geräte. Die meisten virtuellen Geräte werden zur einfachen Datenspeicherung verwendet, es gibt jedoch mehrere unterstützende vdev-Klassen, einschließlich CACHE, LOG und SPECIAL. Jeder dieser vdev-Typen kann eine der fünf Topologien haben: Einzelgerät (single-device), RAIDz1, RAIDz2, RAIDz3 oder Spiegel (mirror).

RAIDz1, RAIDz2 und RAIDz3 sind spezielle Varianten dessen, was Old-School-Nutzer als Double Parity RAID bezeichnen würden. 1, 2 und 3 beziehen sich darauf, wie viele Paritätsblöcke für jeden Datenstreifen zugewiesen sind. Anstelle von einzelnen Laufwerken zur Sicherstellung der Parität verteilt RAIDz virtuelle Geräte diese Parität gleichmäßig auf die Laufwerke. Ein RAIDz-Array kann so viele Laufwerke verlieren, wie es Paritätsblöcke hat; wenn es ein weiteres verliert, ist es ausgefallen und nimmt den Speicherpool mit sich.

In Spiegel-virtuellen Geräten (mirror vdev) wird jeder Block auf jedem Gerät im vdev gespeichert. Obwohl die am häufigsten verwendeten Spiegel doppelt sind (two-wide), kann ein Spiegel eine beliebige Anzahl von Geräten haben – in großen Installationen werden oft dreifache Spiegel verwendet, um die Leseleistung und Ausfallsicherheit zu erhöhen. Ein vdev-Spiegel kann jeden Ausfall überstehen, solange mindestens ein Gerät im vdev weiterhin funktioniert.

Einfache vdevs sind von Natur aus gefährlich. Ein solches virtuelles Gerät wird keinen Ausfall überstehen – und wenn es als Speicher oder spezielles vdev verwendet wird, führt ein Ausfall zu einem Verlust des gesamten Pools. Seien Sie hier sehr, sehr vorsichtig.

Virtuelle Geräte CACHE, LOG und SPECIAL können in einer beliebigen der oben genannten Topologien erstellt werden – aber denken Sie daran, dass der Verlust eines virtuellen Geräts SPECIAL den Verlust des Pools bedeutet, daher wird eine redundante Topologie dringend empfohlen.

Gerät

Wahrscheinlich der einfachste zu verstehende Begriff in ZFS – es handelt sich um ein Blockgerät mit zufälligem Zugriff. Denken Sie daran, dass virtuelle Geräte aus einzelnen Geräten bestehen und der Pool aus virtuellen Geräten besteht.

Festplatten – sowohl magnetische als auch SSDs – sind die am häufigsten verwendeten Blockgeräte, die als Bausteine für vdevs eingesetzt werden. Allerdings ist jedes Gerät, das einen Deskriptor in /dev hat, geeignet – sodass ganze Hardware-RAID-Arrays als einzelne Geräte verwendet werden können.

Eine einfache Raw-Datei ist eines der wichtigsten alternativen Blockgeräte, aus denen ein vdev aufgebaut werden kann. Testpools aus Sparse-Dateien sind eine sehr praktische Möglichkeit, um Poolbefehle zu testen und zu sehen, wie viel Speicher im Pool oder virtuellen Gerät dieser Topologie verfügbar ist.

Sie können in nur wenigen Sekunden einen Testpool aus sparsen Dateien erstellen – vergessen Sie nicht, später den gesamten Pool und seine Komponenten zu löschen.

Angenommen, Sie möchten einen Server mit acht Festplatten einrichten und planen, 10 TB (~9300 GiB) Festplatten zu verwenden – aber Sie sind sich nicht sicher, welche Topologie am besten zu Ihren Bedürfnissen passt. Im obigen Beispiel erstellen wir in nur wenigen Sekunden einen Testpool aus sparsen Dateien – und wissen nun, dass ein RAIDz2 vdev mit acht 10 TB Festplatten 50 TiB nutzbaren Speicherplatz bietet.

Eine weitere spezielle Gerätekategorie sind SPARE (Ersatzgeräte). Hot-Swap-fähige Geräte gehören im Gegensatz zu herkömmlichen Geräten dem gesamten Pool und nicht einem einzelnen virtuellen Gerät. Wenn ein vdev im Pool ausfällt und ein Ersatzgerät an den Pool angeschlossen und verfügbar ist, wird es automatisch dem betroffenen vdev zugeordnet.

Nachdem das Ersatzgerät mit dem betroffenen vdev verbunden ist, beginnt es, Datenkopien oder -rekonstruktionen zu erhalten, die auf dem fehlenden Gerät vorhanden sein sollten. Im traditionellen RAID wird dies als Wiederherstellung (rebuilding) bezeichnet, während es in ZFS "Wiederherstellung von Redundanz" (resilvering) genannt wird.

Es ist wichtig zu beachten, dass Ersatzgeräte defekte Geräte nicht dauerhaft ersetzen. Sie sind lediglich eine vorübergehende Lösung, um die Zeit zu verkürzen, während ein vdev degradierbar ist. Nachdem der Administrator das ausgefallene Gerät im vdev ersetzt hat, erfolgt die Wiedereinrichtung der Redundanz auf das permanente Gerät, und das SPARE-Gerät wird vom vdev getrennt und kehrt zu seiner Funktion als Ersatzgerät für den gesamten Pool zurück.

Datensätze, Blöcke und Sektoren

Der nächste Baustein, den es auf unserer Reise durch ZFS zu verstehen gilt, bezieht sich weniger auf die Hardware als darauf, wie die Daten selbst organisiert und gespeichert werden. Wir überspringen hier einige Ebenen – wie z.B. metaslab –, um es nicht mit Details zu überfrachtet, während wir das Gesamtverständnis der Struktur bewahren.

Datensatz (dataset)

Wenn wir zum ersten Mal einen Datensatz erstellen, zeigt er den gesamten verfügbaren Speicherplatz des Pools an. Dann setzen wir ein Kontingent fest – und ändern den Einhängepunkt. Magie!

Zvol ist größtenteils einfach ein Datensatz, der seiner Dateisystemschicht entledigt ist, die wir hier durch ein völlig normales Dateisystem wie ext4 ersetzen.

Der ZFS-Datensatz ist in etwa mit einem standardmäßig montierten Dateisystem vergleichbar. Wie ein gewöhnliches Dateisystem scheint es auf den ersten Blick "einfach nur ein weiterer Ordner" zu sein. Doch genau wie bei herkömmlichen gemounteten Dateisystemen hat jeder ZFS-Datensatz seine eigenen grundlegenden Eigenschaften.

Zunächst kann einem Datensatz ein festgelegtes Kontingent zugewiesen werden. Wenn Sie zfs set quota=100G poolname/datasetname, dann können Sie nichts in den gemounteten Ordner schreiben /poolname/datasetname was über 100 GiB hinausgeht.

Haben Sie die Anwesenheit – und Abwesenheit – der Schrägstriche zu Beginn jeder Zeile bemerkt? Jeder Datensatz hat seinen Platz sowohl in der ZFS-Hierarchie als auch in der Hierarchie des System-Mounts. In der ZFS-Hierarchie gibt es keinen führenden Schrägstrich – Sie beginnen mit dem Namen des Pools und dann dem Pfad von einem Datensatz zum nächsten. Zum Beispiel, pool/parent/child für einen Datensatz mit dem Namen child unter dem übergeordneten Datensatz parent in einem Pool mit dem kreativen Namen pool.

Standardmäßig entspricht der Mountpunkt des Datensatzes seinem Namen in der ZFS-Hierarchie, mit einem Schrägstrich am Anfang – der Pool namens pool wird als /poolgemountet, der Datensatz parent wird in /pool/parentgemountet, und der untergeordnete Datensatz child wird in /pool/parent/childgemountet. Der systematische Mountpunkt des Datensatzes kann jedoch geändert werden.

Wenn wir angeben, zfs set mountpoint=/lol pool/parent/child, dann wird der Datensatz pool/parent/child im System als /lol.

gemountet. Neben Datensätzen müssen wir auch Volumes (zvols) erwähnen. Ein Volume ist in etwa mit einem Datensatz vergleichbar, es gibt jedoch tatsächlich kein Dateisystem darin – es handelt sich einfach um ein Blockgerät. Sie können beispielsweise ein zvol mit dem Namen mypool/myzvol, dann es mit dem Dateisystem ext4 formatieren und dieses Dateisystem dann mounten – jetzt haben Sie ein ext4-Dateisystem, das alle Sicherheitsfunktionen von ZFS unterstützt! Das mag auf einem Computer albern erscheinen, macht aber viel mehr Sinn als Backend bei der Exportierung eines iSCSI-Geräts.

Blöcke

Eine Datei besteht aus einem oder mehreren Blöcken. Jeder Block wird auf einem virtuellen Gerät gespeichert. Die Blockgröße entspricht normalerweise der Parameter recordsize, kann jedoch auf 2^ashiftreduziert werden, wenn er Metadaten oder eine kleine Datei enthält.

Wir meinen wirklich, tatsächlich dass es einen enormen Leistungseinbruch gibt, wenn ashift zu klein eingestellt wird.

Im ZFS-Pool werden alle Daten, einschließlich Metadaten, in Blöcken gespeichert. Die maximale Blockgröße für jedes Datenset wird in der Eigenschaft " recordsize (Aufzeichnungsgröße) festgelegt. Die Aufzeichnungsgröße kann variieren, beeinflusst jedoch nicht die Größe oder Position bereits in das Datenset geschriebenen Blöcke – sie gilt nur für neue Blöcke beim Schreiben.

Sofern nicht anders festgelegt, beträgt die aktuelle Standardaufzeichnungsgröße 128 KiB. Dies ist eine Art schwieriger Kompromiss, bei dem die Leistung in den meisten Fällen weder ideal noch schlimm sein wird. Recordsize kann auf einen beliebigen Wert von 4K bis 1M festgelegt werden (mit zusätzlichen Einstellungen recordsize kann es noch größer eingestellt werden, aber das ist selten eine gute Idee).

Jeder Block bezieht sich nur auf die Daten einer einzelnen Datei – Sie können nicht zwei verschiedene Dateien in einen Block stecken. Jede Datei besteht aus einem oder mehreren Blöcken, abhängig von der Größe. Ist die Dateigröße kleiner als die Aufzeichnungsgröße, wird sie in einem kleineren Block gespeichert – zum Beispiel belegt ein 2 KiB großer Block mit einer Datei nur einen 4 KiB großen Sektor auf der Festplatte.

Ist die Datei groß genug und benötigt mehrere Blöcke, dann haben alle Aufzeichnungen mit dieser Datei die Größe recordsize – einschließlich der letzten Aufzeichnung, deren Hauptteil möglicherweise unbenutzter Speicherplatz ist..

Volumes vom Typ zvol haben keine Eigenschaft recordsize – stattdessen haben sie eine äquivalente Eigenschaft volblocksize.

Sektoren

Der letzte, grundlegendste Baustein – der Sektor. Dies ist die kleinste physikalische Einheit, die von dem zugrunde liegenden Gerät geschrieben oder gelesen werden kann. Jahrzehntelang wurden in den meisten Festplatten Sektoren mit 512 Bytes verwendet. In letzter Zeit sind die meisten Festplatten auf 4 KiB-Sektoren eingestellt, und in einigen – insbesondere SSDs – sogar auf 8 KiB oder mehr.

Im ZFS-System gibt es eine Eigenschaft, die es ermöglicht, die Sektorgröße manuell festzulegen. Diese Eigenschaft ashift. Es ist etwas verwirrend, dass ashift eine Potenz von zwei ist. Zum Beispiel ashift=9 bedeutet eine Sektorgröße von 2^9 oder 512 Bytes.

ZFS fragt das Betriebssystem nach detaillierten Informationen zu jedem Blockgerät, wenn es in ein neues vdev hinzugefügt wird, und stellt theoretisch automatisch den ashift entsprechend diesen Informationen ein. Leider lügen viele Festplatten über ihre Sektorgröße, um die Kompatibilität mit Windows XP zu wahren (das nicht in der Lage war, Festplatten mit anderen Sektorgrößen zu erkennen).

Das bedeutet, dass es für den ZFS-Administrator dringend empfohlen wird, die tatsächliche Sektorgröße seiner Geräte zu kennen und manuell einzustellen ashift. Wenn ein zu kleiner ashift eingestellt ist, steigt die Anzahl der Lese-/Schreiboperationen astronomisch an. So bedeutet das Schreiben von 512-Byte-"Sektoren" in einen tatsächlichen Sektor von 4 KiB, dass zuerst der erste "Sektor" geschrieben, dann der 4 KiB-Sektor gelesen, dieser mit dem zweiten 512-Byte-"Sektor" geändert und dann zurück in den neuen 4 KiB-Sektor geschrieben werden muss, und so weiter für jede Aufzeichnung.

In der realen Welt hat dieser Strafen einen großen Einfluss auf die Samsung EVO Solid-State-Laufwerke, für die gelten muss ashift=13, aber diese SSDs lügen über ihre Sektorgröße, weshalb standardmäßig eingestellt wird ashift=9. Wenn ein erfahrener Systemadministrator diesen Parameter nicht ändert, arbeitet diese SSD , als Muster, die verwenden wie eine herkömmliche magnetische HDD.

Im Vergleich dazu gibt es bei einer zu großen Größe ashift praktisch keinen Nachteil. Es gibt keinen echten Leistungsabfall, und der Anstieg des nicht genutzten Raums ist unendlich gering (oder null, wenn die Kompression aktiviert ist). Daher empfehlen wir nachdrücklich sogar für Festplatten, die tatsächlich 512-Byte-Sektoren verwenden, einzustellen ashift=12 oder sogar ashift=13, um sicher in die Zukunft zu blicken.

Eigenschaft ashift wird für jedes virtuelle Gerät vdev eingestellt, und nicht für den Pool, wie viele fälschlicherweise denken – und wird nach der Einstellung nicht mehr geändert. Wenn Sie versehentlich ashift beim Hinzufügen eines neuen vdevs zum Pool durcheinandergebracht haben, haben Sie diesen Pool unwiderruflich mit einem Gerät mit niedriger Leistung verschmutzt, und in der Regel gibt es keinen anderen Ausweg, als den Pool zu löschen und von vorne zu beginnen. Selbst das Entfernen des vdev wird die falsche Konfiguration nicht retten. ashift!

Der Mechanismus des Schreibens

Wenn ein normales Dateisystem Daten neu schreiben muss, ändert es jeden Block dort, wo er sich befindet.

Das Dateisystem mit Copy-on-Write schreibt eine neue Version des Blocks und entsperrt dann die alte Version.

In abstrakter Form, wenn wir die tatsächliche physische Anordnung der Blöcke ignorieren, vereinfacht sich unser „Datenkomet“ zu einem „Datenwurm“, der sich von links nach rechts über die verfügbare Speicherkarte bewegt.

Jetzt können wir uns ein gutes Bild davon machen, wie Snapshots mit Copy-on-Write funktionieren – jeder Block kann mehreren Snapshots angehören und bleibt bestehen, bis alle zugehörigen Snapshots gelöscht werden.

Der Mechanismus Copy-on-Write (CoW) ist das grundlegende Prinzip, das ZFS zu einem so erstaunlichen System macht. Das Hauptkonzept ist einfach – wenn Sie ein traditionelles Dateisystem bitten, eine Datei zu ändern, wird es genau das tun, was Sie verlangen. Wenn Sie ein Copy-on-Write-Dateisystem dasselbe bitten, wird es sagen: „In Ordnung“ – aber es wird Sie anlügen.

Stattdessen schreibt das Copy-on-Write-Dateisystem eine neue Version des geänderten Blocks und aktualisiert die Metadaten der Datei, sodass die Verbindung zum alten Block getrennt und mit dem neuen Block, den Sie gerade geschrieben haben, verbunden wird.

Das Trennen des alten Blocks und das Verknüpfen des neuen Blocks erfolgt in einem einzigen Schritt, sodass es nicht unterbrochen werden kann – wenn Sie die Stromversorgung nach diesem Vorgang zurücksetzen, erhalten Sie die neue Version der Datei, und wenn Sie die Stromversorgung vorher zurücksetzen, haben Sie die alte Version. In jedem Fall treten im Dateisystem keine Konflikte auf.

Copy-on-Write in ZFS geschieht nicht nur auf Dateisystemebene, sondern auch auf der Ebene des Festplattenspeichers. Das bedeutet, dass ZFS nicht anfällig für das Schreibloch ist (Schreibloch im RAID) – ein Phänomen, bei dem ein Stripe nur teilweise geschrieben werden konnte, bevor das System ausfiel, was zu einem beschädigten Array nach dem Neustart führt. Hier wird Stripe atomar geschrieben, vdev ist immer konsistent, und Bob ist dein Onkel..

ZIL: ZFS Intent Log

Das ZFS-System behandelt synchrone Schreibvorgänge auf besondere Weise – es speichert sie vorübergehend, aber sofort im ZIL, bevor es sie später zusammen mit asynchronen Schreibvorgängen dauerhaft speichert.

In der Regel werden die im ZIL geschriebenen Daten nie wieder gelesen. Aber das ist nach einem Systemausfall möglich.

SLOG, oder ein sekundäres LOG-Gerät, ist einfach ein spezieller – idealerweise sehr schneller – vdev, wo ZIL getrennt vom Hauptspeicher aufbewahrt werden kann.

Nach einem Ausfall werden alle schmutzigen Daten im ZIL wiederhergestellt – in diesem Fall befindet sich der ZIL auf dem SLOG, sodass sie genau von dort wiederhergestellt werden.

Es gibt zwei Hauptkategorien von Schreiboperationen – synchrone (sync) und asynchrone (async). Für die meisten Arbeitslasten sind überwiegend mehr als 90 % der Schreiboperationen asynchron – das Dateisystem ermöglicht es, sie zu aggregieren und in Paketen auszugeben, was die Fragmentierung verringert und die Durchsatzrate erheblich steigert.

Synchrone Schreibvorgänge sind eine ganz andere Angelegenheit. Wenn eine Anwendung eine synchrone Speicherung anfordert, sagt sie dem Dateisystem: „Du musst das in nichtflüchtigem Speicher festhalten, jetzt gleich, und bis dahin kann ich nichts anderes tun.“ Daher müssen synchrone Schreibvorgänge sofort auf der Festplatte festgeschrieben werden – und wenn das die Fragmentierung erhöht oder die Durchsatzrate verringert, ist das eben so.

ZFS behandelt synchrone Schreibvorgänge anders als herkömmliche Dateisysteme – anstatt sie sofort in den Standard-Speicher zu schreiben, speichert ZFS sie in einem speziellen Speicherbereich, der als ZFS Intent Log (ZIL) bezeichnet wird. Der Clou dabei ist, dass diese Einträge auch im Speicher aggregiert bleiben, zusammen mit den normalen asynchronen Schreibanfragen, um später als ganz normale TXG (Transaction Groups, Transaktionsgruppen) ins Speichergerät geschrieben zu werden.

Im normalen Betrieb wird ZIL geschrieben und danach nie wieder gelesen. Wenn nach einigen Momenten die Einträge aus dem ZIL im Hauptspeicher in den üblichen TXG gespeichert werden, werden sie vom ZIL getrennt. Das einzige Mal, dass etwas aus dem ZIL gelesen wird, ist beim Import eines Pools.

Wenn es zu einem ZFS-Ausfall kommt – sei es ein Betriebssystemabsturz oder ein Stromausfall – während sich Daten im ZIL befinden, werden diese Daten beim nächsten Import des Pools (z.B. beim Neustart des Absturzsystems) gelesen. Alles, was sich im ZIL befindet, wird gelesen, in TXG-Gruppen zusammengeführt, im Hauptspeicher festgeschrieben und dann während des Imports vom ZIL getrennt.

Eine der Hilfsklassen vdev nennt sich LOG oder SLOG, das sekundäre Gerät LOG. Es hat eine einzige Aufgabe – einen Pool mit einem separaten und, vorzugsweise, viel schnelleren Gerät vdev mit sehr hoher Schreibbeständigkeit zum Speichern von ZIL bereitzustellen, anstelle von ZIL im Hauptspeicher vdev zu speichern. Das ZIL verhält sich unabhängig vom Speicherort gleich, aber wenn vdev mit LOG eine sehr hohe Schreibgeschwindigkeit hat, werden synchrone Schreibvorgänge schneller ausgeführt.

Das Hinzufügen von vdev mit LOG zum Pool kann die kann Leistung der asynchronen Schreibvorgänge nicht verbessern – selbst wenn Sie alle Schreibvorgänge in ZIL mithilfe von zfs set sync=alwayserzwingen, werden sie dennoch in demselben Maße an den Hauptspeicher in TXG gebunden, wie ohne Journal. Die einzige direkte Leistungsverbesserung ist die Verzögerung der synchronen Schreibvorgänge (da eine höhere Journalgeschwindigkeit die Ausführung der Vorgänge beschleunigt). sync).

In einer Umgebung, die bereits eine große Anzahl synchroner Schreibvorgänge benötigt, kann vdev LOG jedoch indirekt asynchrone Schreibvorgänge und nicht zwischengespeicherte Lesevorgänge beschleunigen. Das Auslagern von ZIL-Schreibvorgängen in ein separates vdev LOG bedeutet weniger Konkurrenz um IOPS im primären Speicher, was die Leistung aller Lese- und Schreibvorgänge in gewissem Maße steigert.

Snapshots

Der Mechanismus der Schreibkopie ist auch eine notwendige Grundlage für atomare Momentaufnahmen von ZFS und inkrementelle asynchrone Replikation. In einem aktiven Dateisystem gibt es einen Baum von Zeigern, der alle Einträge mit den aktuellen Daten markiert – wenn Sie einen Snapshot erstellen, machen Sie einfach eine Kopie dieses Zeigerbaums.

Wenn ein Eintrag in einem aktiven Dateisystem überschrieben wird, schreibt ZFS zuerst die neue Version des Blocks in nicht verwendeten Speicher. Anschließend trennt es die alte Version des Blocks vom aktuellen Dateisystem. Aber wenn irgendein Snapshot auf den alten Block verweist, bleibt er unverändert. Der alte Block wird faktisch nicht als freier Speicher wiederhergestellt, bis alle Snapshots, die auf diesen Block verweisen, gelöscht werden!

Replikation

Meine Steam-Bibliothek nahm im Jahr 2015 158 GiB in Anspruch und umfasste 126.927 Dateien. Das ist ziemlich nah an der optimalen Situation für rsync – die ZFS-Replikation über das Netzwerk war „nur“ um 750 % schneller.

Im selben Netzwerk ist die Replikation einer 40-Gigabyte-Image-Datei einer Windows 7-virtuellen Maschine eine ganz andere Geschichte. Die ZFS-Replikation erfolgt 289 Mal schneller als rsync – oder „nur“ 161 Mal schneller, wenn Sie genug Wissen haben, um rsync mit dem Parameter --inplace aufzurufen.

Wenn das Image der virtuellen Maschine skaliert wird, skalieren die Probleme von rsync ebenfalls mit. Die Größe von 1,9 TiB ist für ein modernes Image einer virtuellen Maschine nicht besonders groß – aber sie ist groß genug, dass die ZFS-Replikation 1148 Mal schneller ist als rsync, selbst mit dem rsync-Argument --inplace.

Sobald Sie verstehen, wie Snapshots funktionieren, wird es einfach sein, das Wesen der Replikation zu erfassen. Da ein Snapshot lediglich einen Baum von Zeigern auf die Datensätze darstellt, folgt daraus, dass wenn wir einen zfs send Snapshot erstellen, wir diesen Baum sowie alle damit verbundenen Datensätze senden. Wenn wir dies über zfs send in zfs receive auf das Zielobjekt übertragen, schreibt es sowohl den tatsächlichen Blockinhalt als auch den Baum von Zeigern, die auf die Blöcke verweisen, in den Ziel-Datensatz.

Es wird noch interessanter beim zweiten zfs send. Jetzt haben wir zwei Systeme, von denen jedes poolname/datasetname@1enthält, und Sie erstellen einen neuen Snapshot poolname/datasetname@2.Daher haben Sie im ursprünglichen Pool datasetname@1 und datasetname@2, während im Zielpool vorerst nur der erste Snapshot vorhanden ist. datasetname@1.

Da wir einen gemeinsamen Snapshot zwischen Quelle und Ziel haben, können wir einen datasetname@1inkrementellen auf ihm durchführen. Wenn wir zum System sagen zfs send zfs send -i poolname/datasetname@1 poolname/datasetname@2 , vergleicht es die beiden Zeigerbäume. Alle Zeiger, die nur in, verweisen offensichtlich auf neue Blöcke – daher benötigen wir den Inhalt dieser Blöcke. @2Im entfernten System ist die Verarbeitung der inkrementellen

ebenso einfach. Zuerst schreiben wir alle neuen Datensätze, die im Stream enthalten sind, send , und fügen dann die Zeiger auf diese Blöcke hinzu. Voilà, wir haben sendes im neuen System! @2 Asynchrone inkrementelle ZFS-Replikation ist eine enorme Verbesserung im Vergleich zu früheren Methoden, die nicht auf Snapshots basieren, wie rsync. In beiden Fällen werden nur die geänderten Daten übertragen – aber rsync muss zuerst

alle Daten von der Festplatte auf beiden Seiten lesen, um die Summe zu überprüfen und sie zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nichts außer den Zeigerbäumen – und allen Blöcken, die im gemeinsamen Snapshot nicht vorhanden sind. lesen Von der Festplatte werden alle Daten von beiden Seiten gelesen, um die Summe zu überprüfen und zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nichts außer den Zeigerbäumen – und beliebigen Blöcken, die nicht im gemeinsamen Snapshot enthalten sind.

Integrierte Kompression

Der Kopiermechanismus beim Schreiben vereinfacht auch das System der integrierten Kompression. In herkömmlichen Dateisystemen ist die Kompression problematisch – sowohl die alte Version als auch die neue Version der geänderten Daten befinden sich im selben Raum.

Wenn man einen Datenblock in der Mitte einer Datei betrachtet, der sein Leben als Megabyte an Nullen bei 0x00000000 beginnt und so weiter – lässt er sich sehr leicht auf einen Sektor auf der Festplatte komprimieren. Aber was passiert, wenn wir dieses Megabyte an Nullen durch ein Megabyte unkomprimierbarer Daten wie JPEG oder pseudorandomem Rauschen ersetzen? Überraschenderweise benötigt dieses Megabyte an Daten nicht einen, sondern 256 Sektoren von 4 KiB, während an dieser Stelle auf der Festplatte nur ein Sektor reserviert ist.

ZFS hat dieses Problem nicht, da geänderte Einträge immer in ungenutzten Raum geschrieben werden – der ursprüngliche Block nimmt nur einen Sektor von 4 KiB ein, und der neue Eintrag benötigt 256, aber das ist kein Problem – der kürzlich geänderte Abschnitt aus der „Mitte“ der Datei würde unabhängig von den Änderungen seiner Größe in ungenutzten Raum geschrieben, daher ist dies für ZFS eine ganz normale Situation.

Die integrierte Kompression von ZFS ist standardmäßig deaktiviert, und das System bietet auswählbare Algorithmen an – derzeit darunter LZ4, gzip (1-9), LZJB und ZLE.

• LZ4 – ist ein Streaming-Algorithmus, der extrem schnelle Kompression und Dekompression bietet und Leistungsgewinne für die meisten Anwendungsfälle ermöglicht – selbst auf relativ langsamen CPUs.
• GZIP – ein angesehener Algorithmus, der von allen Benutzern von Unix-Systemen geschätzt wird. Er kann mit Kompressionsgraden von 1-9 umgesetzt werden, wobei die Kompression und die CPU-Nutzung mit Annäherung an Grad 9 steigen. Der Algorithmus eignet sich gut für alle textbasierten (oder anderen extrem komprimierbaren) Anwendungen, kann jedoch in anderen Fällen häufig Probleme mit der CPU verursachen – verwenden Sie ihn vorsichtig, insbesondere auf höheren Stufen.
• LZJB – der ursprüngliche Algorithmus in ZFS. Er ist veraltet und sollte nicht mehr verwendet werden, LZ4 übertrifft ihn in jeder Hinsicht.
• ZLE — Zero-Level-Kodierung. Sie ändert im Allgemeinen normale Daten nicht, komprimiert jedoch große Nullfolgen. Nützlich für vollständig nicht komprimierbare Datensätze (z. B. JPEG, MP4 oder andere bereits komprimierte Formate), da sie nicht komprimierbare Daten ignoriert, aber ungenutzten Speicherplatz in den endgültigen Aufzeichnungen komprimiert.

Wir empfehlen die LZ4-Kompression für nahezu alle Anwendungsfälle; die Leistungseinbußen bei der Verarbeitung nicht komprimierbarer Daten sind minimal, und Zuwachs die Leistungssteigerung für typische Daten ist erheblich. Das Kopieren eines Abbilds einer virtuellen Maschine für eine neue Installation des Betriebssystems Windows (frisch installiertes OS, keine Daten sind bereits vorhanden) mit compression=lz4 verlief 27 % schneller als mit compression=none, in in diesem Test von 2015..

ARC — Adaptive Replacement Cache.

ZFS ist das einzige uns bekannte moderne Dateisystem, das einen eigenen Lese-Caching-Mechanismus verwendet und sich nicht auf den Betriebssystem-Seiten-Cache zur Speicherung von Kopien kürzlich gelesener Blöcke im RAM verlässt.

Obwohl der eigene Cache nicht ohne Probleme ist — ZFS kann nicht so schnell auf neue Anfragen zur Speicherzuweisung reagieren wie der Kernel, sodass ein neuer Aufruf malloc() zur Speicherzuteilung fehlschlagen kann, wenn er RAM benötigt, der derzeit vom ARC belegt ist. Aber es gibt gute Gründe, den eigenen Cache zu verwenden, zumindest jetzt.

Alle bekannten modernen Betriebssysteme, einschließlich MacOS, Windows, Linux und BSD, verwenden für die Implementierung des Seiten-Caches den LRU-Algorithmus (Least Recently Used). Dies ist ein einfacher Algorithmus, der einen zwischengespeicherten Block nach jedem Lesen 'nach oben' in die Warteschlange verschiebt und 'nach unten' in der Warteschlange verdrängt, wenn es notwendig ist, um neue Cache-Fehler (Blöcke, die von der Festplatte gelesen werden sollten und nicht aus dem Cache) nach oben hinzuzufügen.

Normalerweise funktioniert der Algorithmus gut, aber in Systemen mit großen Arbeitsdatensätzen führt LRU leicht zu Thrashing — die Verdrängung häufig benötigter Blöcke, um Platz für Blöcke zu schaffen, die nie wieder aus dem Cache gelesen werden.

ARC — ein wesentlich weniger naiver Algorithmus, der als „gewichteter“ Cache betrachtet werden kann. Nach jedem Lesen eines zwischengespeicherten Blocks wird er etwas „schwerer“ und es wird schwieriger, ihn auszusondern – und selbst nach der Aussortierung wird der Block verfolgt für einen bestimmten Zeitraum. Ein Block, der ausgesondert wurde, aber dann wieder in den Cache gelesen werden muss, wird ebenfalls „schwerer“.

Das Endergebnis all dessen ist ein Cache mit einem viel höheren Trefferverhältnis – dem Verhältnis zwischen Cache-Hits (Lesen, das aus dem Cache erfolgt) und Cache-Misses (Lesen von der Festplatte). Dies ist eine äußerst wichtige Statistik – zum einen werden die Cache-Hits um ein Vielfaches schneller bedient, zum anderen können die Cache-Misses ebenfalls schneller bedient werden, da je mehr Cache-Hits es gibt, desto weniger parallele Anfragen an die Festplatte gestellt werden und desto weniger Verzögerung für die verbleibenden Misses, die von der Festplatte bedient werden müssen.

Fazit

Nachdem wir die grundlegende Semantik von ZFS untersucht haben – wie das Schreiben bei der Sicherung funktioniert sowie die Beziehungen zwischen Storage-Pools, virtuellen Geräten, Blöcken, Sektoren und Dateien – sind wir bereit, über die tatsächliche Leistung mit echten Zahlen zu sprechen.

Im nächsten Abschnitt werden wir die tatsächliche Leistung von Spiegel-Pools mit vdev und RAIDz vergleichen, sowohl miteinander als auch im Vergleich zu traditionellen RAID-Topologien des Linux-Kernels, die wir untersucht haben. zuvor.

Zuerst wollten wir nur die Grundlagen – die ZFS-Topologien – betrachten, aber nach Versionen zu speichern?..) Schließlich speichern wir Versionen, damit wir sie später verwenden können, das heißt, um "zurückzuspringen", falls notwendig. werden wir bereit sein, über eine fortgeschrittene Konfiguration und Feinabstimmung von ZFS zu sprechen, einschließlich der Verwendung von unterstützenden Typen von vdev, wie L2ARC, SLOG und Spezialzuweisung.

Quelle: habr.com