{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Grundlagen von ZFS: Speichersystem und Leistung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Grundlagen
\n
\nIn diesem Fr\u00fchling haben wir bereits einige Einf\u00fchrungsthemen besprochen, wie zum Beispiel wie Sie die Geschwindigkeit Ihrer Laufwerke \u00fcberpr\u00fcfen k\u00f6nnen<\/a><\/noindex> und was RAID ist<\/a><\/noindex>. In dem zweiten Artikel haben wir sogar versprochen, die Leistung verschiedener Multi-Disk-Topologien in ZFS weiter zu untersuchen. Dies ist ein Next-Generation-Dateisystem, das derzeit \u00fcberall implementiert wird: von Apple<\/a><\/noindex> bis zu Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNun, heute ist der perfekte Tag, um ZFS kennenzulernen, neugierige Leser. Seien Sie sich nur bewusst, dass, laut Sch\u00e4tzung des Entwicklers von OpenZFS, Matt Arens, \u201ees wirklich komplex ist\u201c.<\/p>\n

Aber bevor wir zu den Zahlen kommen \u2013 und die werden kommen, das verspreche ich \u2013 m\u00fcssen wir \u00fcber das sprechen, als<\/i> wie ZFS Daten auf dem Laufwerk speichert.<\/p>\n

Zpool, vdev und device<\/h1>\n

\n\"Grundlagen
\nDieses vollst\u00e4ndige Pool-Diagramm umfasst drei unterst\u00fctzende vdevs, jeweils einen aus jeder Klasse, und vier f\u00fcr RAIDz2.<\/i><\/p>\n

\"Grundlagen
\nNormalerweise gibt es keinen Grund, einen Pool aus unterschiedlichen Typen und Gr\u00f6\u00dfen von vdev zu erstellen \u2013 aber wenn Sie m\u00f6chten, steht Ihnen nichts im Wege.<\/i><\/p>\n

Um das Dateisystem ZFS wirklich zu verstehen, ist es wichtig, seine tats\u00e4chliche Struktur genauer zu betrachten. Zun\u00e4chst einmal vereint ZFS traditionelle Ebenen der Volumenverwaltung und des Dateisystems. Au\u00dferdem verwendet es einen transaktionalen Mechanismus zum Copy-on-Write. Diese Merkmale bedeuten, dass sich das System strukturell erheblich von herk\u00f6mmlichen Dateisystemen und RAID-Arrays unterscheidet. Die ersten grundlegenden Bausteine f\u00fcr das Verst\u00e4ndnis sind: der Storage-Pool (zpool), das virtuelle Ger\u00e4t (vdev) und das physische Ger\u00e4t (device).<\/p>\n

zpool<\/h3>\n

\nDer Storage-Pool zpool ist die oberste Struktur von ZFS. Jeder Pool enth\u00e4lt ein oder mehrere virtuelle Ger\u00e4te. Diese wiederum enthalten ein oder mehrere physische Ger\u00e4te (device). Virtuelle Pools sind eigenst\u00e4ndige Einheiten. Ein physischer Computer kann zwei oder mehr separate Pools enthalten, die jedoch vollst\u00e4ndig unabh\u00e4ngig voneinander sind. Pools k\u00f6nnen keine virtuellen Ger\u00e4te gemeinsam nutzen.<\/p>\n

Die Redundanz von ZFS erfolgt auf der Ebene der virtuellen Ger\u00e4te und nicht auf der Ebene der Pools. Auf der Pool-Ebene gibt es keinerlei Redundanz \u2013 wenn ein vdev-Speicherger\u00e4t oder ein spezielles vdev verloren geht, geht der gesamte Pool ebenfalls verloren.<\/p>\n

Moderne Storage-Pools k\u00f6nnen den Verlust des Caches oder des Journals eines virtuellen Ger\u00e4ts \u00fcberstehen \u2013 sie k\u00f6nnen jedoch eine kleine Menge an nicht gespeicherten Daten verlieren, wenn sie das vdev-Journal w\u00e4hrend eines Stromausfalls oder Systemausfalls verlieren.<\/p>\n

Ein weit verbreitetes Missverst\u00e4ndnis ist, dass die 'Datenstreifen' (Striping) von ZFS \u00fcber den gesamten Pool verteilt werden. Das ist falsch. Zpool ist keineswegs ein unterhaltsamer RAID0, es ist eher ein unterhaltsames JBOD<\/a><\/noindex> mit einem komplexen, variablen Verteilungsmechanismus.<\/p>\n

Im Wesentlichen werden die Schreibvorg\u00e4nge gleichm\u00e4\u00dfig auf die verf\u00fcgbaren virtuellen Ger\u00e4te verteilt, basierend auf dem verf\u00fcgbaren Speicherplatz. Theoretisch werden alle gleichzeitig belegt. In neueren Versionen von ZFS wird die aktuelle Auslastung (Utilisation) der vdev ber\u00fccksichtigt \u2013 falls ein virtuelles Ger\u00e4t wesentlich st\u00e4rker belastet ist als ein anderes (z. B. aufgrund von Lesevorg\u00e4ngen), wird es vor\u00fcbergehend f\u00fcr Schreibvorg\u00e4nge \u00fcbersprungen, selbst wenn es den h\u00f6chsten freien Speicherplatz aufweist.<\/p>\n

Der in moderne ZFS-Schreibstrategien integrierte Mechanismus zur Ermittlung der Auslastung kann die Latenz verringern und die Durchsatzrate w\u00e4hrend Zeiten ungew\u00f6hnlich hoher Belastung erh\u00f6hen \u2013 jedoch ist das nicht. Blankoscheck<\/i> f\u00fcr das unbeabsichtigte Mischen von langsamen HDDs und schnellen SSDs in einem Pool. Ein solch unausgewogener Pool wird stets mit der Geschwindigkeit des langsamsten Ger\u00e4ts arbeiten, als ob er vollst\u00e4ndig aus diesen Ger\u00e4ten zusammengesetzt w\u00e4re.<\/p>\n

vdev<\/h3>\n

\nJeder Speicherpool besteht aus einem oder mehreren virtuellen Ger\u00e4ten (virtual device, vdev). Jedes vdev umfasst wiederum eines oder mehrere physische Ger\u00e4te. Die meisten virtuellen Ger\u00e4te dienen der einfachen Datenspeicherung, aber es gibt mehrere unterst\u00fctzende vdev-Klassen, einschlie\u00dflich CACHE, LOG und SPECIAL. Jeder dieser vdev-Typen kann eine von f\u00fcnf Topologien aufweisen: Einzelger\u00e4t (single-device), RAIDz1, RAIDz2, RAIDz3 oder Spiegelung (mirror).<\/p>\n

RAIDz1, RAIDz2 und RAIDz3 sind spezielle Varianten dessen, was man fr\u00fcher als RAID mit doppelter (diagonaler) Parit\u00e4t bezeichnete. 1, 2 und 3 beziehen sich darauf, wie viele Parit\u00e4tsbl\u00f6cke f\u00fcr jedes Datenband bereitgestellt werden. Anstelle von einzelnen Festplatten zur Bereitstellung der Parit\u00e4t verteilen die virtuellen RAIDz-Ger\u00e4te diese Parit\u00e4t gleichm\u00e4\u00dfig \u00fcber die Festplatten. Ein RAIDz-Array kann so viele Festplatten verlieren, wie es Parit\u00e4tsbl\u00f6cke gibt; wenn eine weitere ausf\u00e4llt, wird es inkompatibel und nimmt den Speicherpool mit sich.<\/p>\n

In spiegelnden virtuellen Ger\u00e4ten (mirror vdev) wird jeder Block auf jedem Ger\u00e4t im vdev gespeichert. W\u00e4hrend die am h\u00e4ufigsten verwendeten Doppelspiegel (two-wide) sind, kann in einem Spiegel eine beliebige Anzahl von Ger\u00e4ten vorhanden sein \u2013 in gr\u00f6\u00dferen Installationen werden h\u00e4ufig dreifache Spiegel verwendet, um die Leseleistung und die Ausfallsicherheit zu erh\u00f6hen. Ein vdev-Spiegel kann jeden Ausfall \u00fcberstehen, solange mindestens ein Ger\u00e4t im vdev weiter funktioniert.<\/p>\n

Einzelne vdevs sind von Natur aus gef\u00e4hrlich. Ein solches virtuelles Ger\u00e4t \u00fcbersteht keinen einzigen Ausfall \u2013 und wenn es als Speicher oder als spezieller vdev verwendet wird, f\u00fchrt sein Ausfall zur Zerst\u00f6rung des gesamten Pools. Seien Sie hier \u00e4u\u00dferst vorsichtig.<\/p>\n

Virtuelle Ger\u00e4te wie CACHE, LOG und SPECIAL k\u00f6nnen in jeder der oben genannten Topologien erstellt werden \u2013 aber bedenken Sie, dass der Verlust eines virtuellen Ger\u00e4ts SPECIAL den Verlust des gesamten Pools bedeutet, daher wird eine redundante Topologie dringend empfohlen.<\/p>\n

device<\/h3>\n

\nWahrscheinlich ist dies der einfachste Begriff in ZFS \u2013 es ist buchst\u00e4blich ein Blockger\u00e4tespeicher. Denken Sie daran, dass virtuelle Ger\u00e4te aus einzelnen Ger\u00e4ten bestehen und ein Pool aus virtuellen Ger\u00e4ten besteht.<\/p>\n

Festplatten \u2013 egal ob magnetisch oder flashbasierend \u2013 sind die am h\u00e4ufigsten verwendeten Blockger\u00e4te, die als Bausteine f\u00fcr vdev dienen. Aber jedes Ger\u00e4t mit einem Deskriptor in \/dev passt \u2013 sodass auch ganze hardwarebasierte RAID-Systeme als einzelne Ger\u00e4te verwendet werden k\u00f6nnen.<\/p>\n

Eine einfache Raw-Datei ist eines der wichtigsten alternativen Blockger\u00e4te, aus denen ein vdev aufgebaut werden kann. Testpools aus Sparse-Dateien<\/a><\/noindex>\u00a0sind eine sehr praktische M\u00f6glichkeit, um Befehle des Pools zu testen und zu sehen, wie viel Speicher im Pool oder im virtuellen Ger\u00e4t dieser Topologie verf\u00fcgbar ist.<\/p>\n

\"Grundlagen
\nSie k\u00f6nnen innerhalb von Sekunden einen Testpool aus Sparse-Dateien erstellen \u2013 aber vergessen Sie nicht, den gesamten Pool und seine Komponenten anschlie\u00dfend zu l\u00f6schen.<\/i> <\/p>\n

Angenommen, Sie m\u00f6chten einen Server mit acht Festplatten einrichten und planen, 10\u00a0TB (~9300 GiB) gro\u00dfe Festplatten zu verwenden, sind sich jedoch nicht sicher, welche Topologie am besten zu Ihren Anforderungen passt. In dem obigen Beispiel erstellen wir in nur wenigen Sekunden einen Testpool aus d\u00fcnn provisionierten Dateien \u2013 und jetzt wissen wir, dass ein RAIDz2 vdev aus acht Festplatten mit 10\u00a0TB eine nutzbare Kapazit\u00e4t von 50\u00a0TiB bietet.<\/p>\n

Eine weitere spezielle Ger\u00e4teklasse sind SPARE (Ersatzger\u00e4te). Hot-Swap-Ger\u00e4te geh\u00f6ren, im Gegensatz zu normalen Ger\u00e4ten, dem gesamten Pool an und nicht einem einzelnen virtuellen Ger\u00e4t. Wenn ein vdev im Pool ausf\u00e4llt und ein Ersatzger\u00e4t mit dem Pool verbunden und verf\u00fcgbar ist, wird es automatisch mit dem betroffenen vdev verbunden.<\/p>\n

Nachdem das Ersatzger\u00e4t mit dem betroffenen vdev verbunden ist, beginnt es, Kopien oder Rekonstruktionen der Daten zu empfangen, die auf dem fehlenden Ger\u00e4t sein sollten. Dies wird in traditionellem RAID als Wiederherstellung (rebuilding) bezeichnet, w\u00e4hrend es in ZFS als \u201eWiederherstellung von Redundanz\u201c (resilvering) bekannt ist.<\/p>\n

Es ist wichtig zu beachten, dass Ersatzger\u00e4te nicht dauerhaft defekte Ger\u00e4te ersetzen. Sie dienen nur als vor\u00fcbergehende L\u00f6sung, um die Zeit zu verk\u00fcrzen, in der eine vdev-Abwertung stattfindet. Nachdem der Administrator das defekte vdev-Ger\u00e4t ersetzt hat, wird die Redundanz wieder auf das permanente Ger\u00e4t hergestellt, w\u00e4hrend das SPARE von der vdev getrennt und wieder als Reserve im gesamten Pool verwendet wird.<\/p>\n

Datens\u00e4tze, Bl\u00f6cke und Sektoren<\/h1>\n

\nDer n\u00e4chste Block in unserer Erkundung von ZFS betrifft nicht so sehr die Hardware, sondern wie die Daten selbst organisiert und gespeichert werden. Hier \u00fcberspringen wir einige Ebenen \u2013 wie den Metaslab \u2013 um \u00dcberladungen zu vermeiden und den \u00dcberblick \u00fcber die Gesamtstruktur zu behalten.<\/p>\n

Datensatz (dataset)<\/h3>\n

\n\"Grundlagen
\nWenn wir einen Datensatz erstellen, zeigt dieser den gesamten verf\u00fcgbaren Speicherplatz im Pool an. Dann setzen wir ein Quota und \u00e4ndern den Einh\u00e4ngepunkt. Voil\u00e0!<\/i> <\/p>\n

\"Grundlagen
\nZvol ist im Wesentlichen ein Datensatz ohne seine Dateisystemschicht, die wir hier durch ein ganz normales Dateisystem wie ext4 ersetzen.<\/i> <\/p>\n

Ein ZFS-Datensatz ist in etwa mit einem standardm\u00e4\u00dfigen gemounteten Dateisystem vergleichbar. Wie bei einem gew\u00f6hnlichen Dateisystem scheint er auf den ersten Blick \u201eeinfach nur ein weiterer Ordner\u201c zu sein. Aber auch wie bei herk\u00f6mmlichen gemounteten Dateisystemen hat jeder ZFS-Datensatz seine eigenen grundlegenden Eigenschaften.<\/p>\n

Zun\u00e4chst kann einem Datensatz ein festgelegtes Kontingent zugewiesen werden. Wenn Sie zfs set quota=100G poolname\/datasetname<\/code>festlegen, k\u00f6nnen Sie nicht mehr als \/poolname\/datasetname<\/code> 100 GiB in den gemounteten Ordner schreiben.<\/p>\n

Haben Sie die Pr\u00e4senz \u2013 und Abwesenheit \u2013 von Schr\u00e4gstrichen am Anfang jeder Zeile bemerkt? Jeder Datensatz hat seinen eigenen Platz sowohl in der ZFS-Hierarchie als auch in der Hierarchie des System-Managements. In der ZFS-Hierarchie gibt es keinen f\u00fchrenden Schr\u00e4gstrich \u2013 Sie beginnen mit dem Poolnamen und dann dem Pfad von einem Datensatz zum n\u00e4chsten. Zum Beispiel: pool\/parent\/child<\/code> f\u00fcr einen Datensatz mit dem Namen child<\/code> unter dem \u00fcbergeordneten Datensatz parent<\/code> in einem Pool mit dem kreativen Namen pool<\/code>.<\/p>\n

Standardm\u00e4\u00dfig entspricht der Mount-Punkt eines Datensatzes seinem Namen in der ZFS-Hierarchie, beginnend mit einem Schr\u00e4gstrich \u2013 der Pool mit dem Namen pool<\/code> wird als \/pool<\/code>gemountet, der Datensatz parent<\/code> wird in \/pool\/parent<\/code>gemountet und der untergeordnete Datensatz child<\/code> wird in \/pool\/parent\/child<\/code>. Aber der System-Mountpunkt des Datensatzes kann ge\u00e4ndert werden.<\/p>\n

Wenn wir angeben, zfs set mountpoint=\/lol pool\/parent\/child<\/code>, dann wird der Datensatz pool\/parent\/child<\/code> im System als \/lol<\/code>.<\/p>\n

Zus\u00e4tzlich zu Datens\u00e4tzen sollten wir Volumes (zvols) erw\u00e4hnen. Ein Volume ist ungef\u00e4hr vergleichbar mit einem Datensatz, wobei es jedoch tats\u00e4chlich kein Dateisystem hat \u2013 es handelt sich einfach um ein Blockger\u00e4t. Sie k\u00f6nnen beispielsweise ein zvol<\/code> mit dem Namen mypool\/myzvol<\/code>, erstellen, es dann mit einem ext4-Dateisystem formatieren und dieses Dateisystem dann einh\u00e4ngen \u2013 jetzt haben Sie ein ext4-Dateisystem, jedoch mit Unterst\u00fctzung f\u00fcr alle Sicherheitsfunktionen von ZFS! Das mag auf einem Computer seltsam erscheinen, macht jedoch viel mehr Sinn als Backend bei der Exportierung eines iSCSI-Ger\u00e4ts.<\/p>\n

Bl\u00f6cke<\/h3>\n

\n\"Grundlagen
\nEine Datei wird durch einen oder mehrere Bl\u00f6cke dargestellt. Jeder Block wird auf einem virtuellen Ger\u00e4t gespeichert. Die Blockgr\u00f6\u00dfe entspricht normalerweise dem Parameter recordsize<\/b>, kann jedoch auf 2^ashift<\/b>verringert werden, wenn er Metadaten oder eine kleine Datei enth\u00e4lt.<\/i><\/p>\n

\"Grundlagen
\nWir meinen es wirklich ernst, gibt es wirklich<\/b> wenn wir vom enormen Leistungsdefizit sprechen, das entsteht, wenn der ashift zu klein eingestellt wird.<\/i><\/p>\n

Im ZFS-Pool werden alle Daten, einschlie\u00dflich Metadaten, in Bl\u00f6cken gespeichert. Die maximale Blockgr\u00f6\u00dfe f\u00fcr jedes Dataset wird im Property festgelegt. recordsize<\/code> (Recordgr\u00f6\u00dfe). Die Recordgr\u00f6\u00dfe kann sich \u00e4ndern, jedoch beeinflusst dies nicht die Gr\u00f6\u00dfe oder Position von bereits in das Dataset geschriebenen Bl\u00f6cken \u2013 sie gilt nur f\u00fcr neue Bl\u00f6cke, die beim Schreiben erstellt werden.<\/p>\n

Sofern nicht anders festgelegt, betr\u00e4gt die aktuelle Standard-Recordgr\u00f6\u00dfe 128 KiB. Dies stellt einen gewissen Kompromiss dar, bei dem die Leistung in den meisten F\u00e4llen weder ideal noch katastrophal sein wird. Recordsize<\/code> kann auf jeden Wert von 4K bis 1M eingestellt werden (mit zus\u00e4tzlichen Anpassungen recordsize<\/code> kann sogar noch h\u00f6her eingestellt werden, was jedoch selten eine gute Idee ist).<\/p>\n

Jeder Block verweist nur auf die Daten einer einzigen Datei \u2013 Sie k\u00f6nnen nicht zwei verschiedene Dateien in einen Block quetschen. Jede Datei besteht aus einem oder mehreren Bl\u00f6cken, abh\u00e4ngig von der Gr\u00f6\u00dfe. Wenn die Gr\u00f6\u00dfe der Datei kleiner als die Recordgr\u00f6\u00dfe ist, wird sie in einem kleineren Block gespeichert \u2013 beispielsweise belegt eine 2 KiB Datei im Block nur einen Sektor von 4 KiB auf der Festplatte.<\/p>\n

Zvols haben keine Eigenschaft recordsize<\/code>\u00a0\u2014 stattdessen besitzen sie eine \u00e4quivalente Eigenschaft volblocksize<\/code>.<\/p>\n

Sektoren<\/h3>\n

\nDer letzte, grundlegende Baustein ist der Sektor. Dies ist die kleinste physische Einheit, die von einem Speicherger\u00e4t geschrieben oder gelesen werden kann. Jahrzehntelang wurden in den meisten Festplatten 512-Byte-Sektoren verwendet. In letzter Zeit sind die meisten Festplatten auf 4 KiB-Sektoren konfiguriert, und in einigen \u2013 insbesondere SSDs \u2013 sind sogar 8 KiB oder noch gr\u00f6\u00dfere Sektoren zu finden.<\/p>\n

Im ZFS-System gibt es eine Eigenschaft, die es erm\u00f6glicht, die Sektorgr\u00f6\u00dfe manuell festzulegen. Diese Eigenschaft ashift<\/code>. Es ist etwas verwirrend, dass ashift eine Potenz von zwei ist. Zum Beispiel, ashift=9<\/code> bedeutet eine Sektorgr\u00f6\u00dfe von 2^9 oder 512 Byte.<\/p>\n

ZFS fordert vom Betriebssystem detaillierte Informationen zu jedem Blockger\u00e4t an, wenn es einem neuen vdev hinzugef\u00fcgt wird, und stellt theoretisch ashift automatisch korrekt auf Basis dieser Informationen ein. Leider l\u00fcgen viele Festplatten \u00fcber ihre Sektorgr\u00f6\u00dfe, um die Kompatibilit\u00e4t mit Windows XP zu wahren, das nicht in der Lage war, Festplatten mit anderen Sektorgr\u00f6\u00dfen zu verstehen.<\/p>\n

Das bedeutet, dass ZFS-Administratoren dringend den tats\u00e4chlichen Sektorgr\u00f6\u00dfen ihrer Ger\u00e4te bekannt sein sollten und diese manuell einstellen m\u00fcssen. ashift<\/code>. Wenn ein zu kleiner ashift eingestellt wird, erh\u00f6ht sich astronomisch die Anzahl der Lese- und Schreibvorg\u00e4nge. Das bedeutet, dass die Schreiboperation f\u00fcr 512-Byte-'Sektoren' in einen echten 4 KiB-Sektor erfordert, zuerst den ersten 'Sektor' zu schreiben, dann den 4 KiB-Sektor zu lesen, ihn mit dem zweiten 512-Byte-'Sektor' zu ver\u00e4ndern, zur\u00fcck in den neuen 4 KiB-Sektor zu schreiben und so weiter f\u00fcr jede Aufzeichnung.<\/p>\n

In der realen Welt betrifft dieser Strafe insbesondere SSDs von Samsung EVO, bei denen ashift=13<\/code>gilt, jedoch l\u00fcgen diese SSDs \u00fcber ihre Sektorgr\u00f6\u00dfe, weshalb standardm\u00e4\u00dfig eingestellt wird. ashift=9<\/code>. Wenn ein erfahrener Systemadministrator diese Einstellung nicht \u00e4ndert, funktioniert dieses SSD langsamer<\/i> als ein herk\u00f6mmliches magnetisches HDD.<\/p>\n

Im Vergleich dazu gibt es f\u00fcr zu gro\u00dfe Gr\u00f6\u00dfen ashift<\/code> praktisch keine Strafe. Es gibt keine sp\u00fcrbare Leistungsminderung, und der Anstieg des ungenutzten Speicherplatzes ist unendlich gering (oder null, wenn die Kompression aktiviert ist). Daher empfehlen wir dringend, selbst f\u00fcr solche Festplatten, die tats\u00e4chlich 512-Byte-Sektoren nutzen, die Einstellung ashift=12<\/code> oder sogar ashift=13<\/code>, um mit Zuversicht in die Zukunft zu blicken.<\/p>\n

Die Eigenschaft ashift<\/code> wird f\u00fcr jedes virtuelle vdev-Ger\u00e4t festgelegt, und nicht f\u00fcr den Pool<\/i>, wie viele f\u00e4lschlicherweise denken \u2013 und kann nach der Festlegung nicht mehr ge\u00e4ndert werden. Wenn Sie versehentlich ashift<\/code> bei der Hinzuf\u00fcgung eines neuen vdev zum Pool verwirrt wurden, haben Sie diesen Pool unwiderruflich mit einem Ger\u00e4t mit niedriger Leistung kontaminiert, und in der Regel gibt es keinen anderen Ausweg, als den Pool zu l\u00f6schen und von vorne zu beginnen. Selbst das Entfernen des vdev wird nicht von einer fehlerhaften Einstellung befreien. ashift<\/code>!<\/p>\n

Der Schreibmechanismus<\/h3>\n

\n\"Grundlagen
\nWenn ein herk\u00f6mmliches Dateisystem Daten \u00fcberschreiben muss \u2013 \u00e4ndert es jeden Block dort, wo er sich befindet.<\/i><\/p>\n

\"Grundlagen
\nDas Copy-on-Write-Dateisystem speichert eine neue Version des Blocks und entsperrt dann die alte Version.<\/i><\/p>\n

\"Grundlagen
\nIm abstrakten Sinne, wenn man die tats\u00e4chliche physische Anordnung der Bl\u00f6cke ignoriert, vereinfacht sich unser \u201aDatenkomet\u2018 zu einem \u201aDatenwurm\u2018, der von links nach rechts \u00fcber die Karte des verf\u00fcgbaren Raums bewegt.<\/i><\/p>\n

\"Grundlagen
\nJetzt haben wir ein gutes Verst\u00e4ndnis daf\u00fcr, wie Copy-on-Write-Snapshots funktionieren \u2013 jeder Block kann mehreren Snapshots zugeordnet werden und bleibt bestehen, bis alle zugeh\u00f6rigen Snapshots gel\u00f6scht werden.<\/i><\/p>\n

Der Copy-on-Write-Mechanismus (CoW) ist das Fundament dessen, was ZFS zu einem so beeindruckenden System macht. Das Grundkonzept ist einfach \u2013 wenn Sie ein traditionelles Dateisystem bitten, eine Datei zu \u00e4ndern, wird es genau das tun, was Sie verlangen. Wenn Sie jedoch ein Copy-on-Write-Dateisystem bitten, dasselbe zu tun, wird es \u201aOkay\u2018 sagen \u2013 aber Sie anl\u00fcgen.<\/p>\n

Stattdessen speichert das Copy-on-Write-Dateisystem eine neue Version des ge\u00e4nderten Blocks und aktualisiert dann die Metadaten der Datei, um die Verbindung zum alten Block zu trennen und den gerade geschriebenen neuen Block zu verkn\u00fcpfen.<\/p>\n

Das Trennen des alten Blocks und das Verkn\u00fcpfen des neuen Blocks erfolgt in einem einzigen Vorgang, weshalb dieser nicht unterbrochen werden kann \u2013 wenn Sie die Stromversorgung nach Abschluss dieser Operation unterbrechen, haben Sie eine neue Version der Datei; wenn Sie vorher die Stromversorgung abstellen, haben Sie die alte Version. In jedem Fall entstehen in der Dateisystemstruktur keine Konflikte.<\/p>\n

Das Copy-on-Write in ZFS erfolgt nicht nur auf der Ebene des Dateisystems, sondern auch auf der Ebene der Festplattenverwaltung. Das bedeutet, dass ZFS nicht unter einem Schreibfehler leidet (RAID-L\u00fccke<\/a><\/noindex>) \u2013 einem Ph\u00e4nomen, bei dem der Stripe nur teilweise vor dem Systemausfall geschrieben werden konnte, was zu Besch\u00e4digungen des Arrays nach dem Neustart f\u00fchrt. Hier wird der Stripe atomar geschrieben, das vdev ist immer konsistent, und Bob ist dein Onkel<\/a><\/noindex>.<\/p>\n

ZIL: ZFS Intent Log<\/h3>\n

\n\"Grundlagen
\nDas ZFS-System behandelt synchronisierte Schreibvorg\u00e4nge auf spezielle Weise \u2013 es speichert sie vor\u00fcbergehend, jedoch sofort im ZIL, bevor sie zusammen mit asynchronen Schreibvorg\u00e4ngen sp\u00e4ter dauerhaft geschrieben werden.<\/i><\/p>\n

\"Grundlagen
\nNormalerweise werden die im ZIL gespeicherten Daten nach der Speicherung nie wieder abgerufen. Dies ist jedoch nach einem Systemausfall m\u00f6glich.<\/i><\/p>\n

\"Grundlagen
\nSLOG, oder sekund\u00e4res LOG-Ger\u00e4t, ist einfach ein spezielles \u2013 und idealerweise sehr schnelles \u2013 vdev, wo das ZIL separat vom Hauptspeicher gespeichert werden kann.<\/i><\/p>\n

\"Grundlagen
\nNach einem Ausfall werden alle verschmutzten Daten im ZIL wiederhergestellt \u2013 in diesem Fall befindet sich das ZIL auf dem SLOG, sodass sie genau von dort wiederhergestellt werden.<\/i><\/p>\n

Es gibt zwei Hauptkategorien von Schreiboperationen \u2013 synchron (sync) und asynchron (async). F\u00fcr die meisten Workloads sind \u00fcberwiegend asynchrone Schreibvorg\u00e4nge \u2013 das Dateisystem erlaubt es, diese zu aggregieren und gepackt auszugeben, was die Fragmentierung reduziert und die Bandbreite signifikant erh\u00f6ht.<\/p>\n

Synchronisierte Schreibvorg\u00e4nge sind eine ganz andere Angelegenheit. Wenn eine Anwendung eine synchronisierte Schreiboperation anfordert, sagt sie dem Dateisystem: 'Du musst dies im nichtfl\u00fcchtigen Speicher festhalten.' jetzt sofort<\/i>, und bis dahin kann ich nichts weiter tun.\u201d Daher m\u00fcssen die synchronen Schreibvorg\u00e4nge sofort auf der Festplatte festgehalten werden \u2013 und wenn das die Fragmentierung erh\u00f6ht oder die Bandbreite verringert, sei es so.<\/p>\n

ZFS behandelt synchrone Schreibvorg\u00e4nge anders als herk\u00f6mmliche Dateisysteme \u2013 anstatt sie sofort in den regul\u00e4ren Speicher zu schreiben, speichert ZFS sie in einem speziellen Speicherbereich, der als ZFS Intent Log (ZIL) bekannt ist. Der Trick dabei ist, dass diese Eintr\u00e4ge auch<\/i> im Speicher bleiben, w\u00e4hrend sie zusammen mit den regul\u00e4ren asynchronen Schreibanforderungen aggregiert werden, um sp\u00e4ter als v\u00f6llig normale TXG (Transaction Groups) in den Speicher geschrieben zu werden.<\/p>\n

Im normalen Betriebsmodus wird das ZIL geschrieben und nie wieder gelesen. Wenn nach wenigen Augenblicken die Eintr\u00e4ge aus dem ZIL im regul\u00e4ren TXG aus dem RAM in den Hauptspeicher geschrieben werden, werden sie vom ZIL getrennt. Das einzige Mal, dass etwas aus dem ZIL gelesen wird, ist beim Import eines Pools.<\/p>\n

Wenn ein ZFS-Fehler auftritt \u2013 sei es ein Betriebssystemausfall oder ein Stromausfall \u2013 und es sich im ZIL Daten befinden, werden diese Daten beim n\u00e4chsten Import des Pools (z.B. beim Neustart des fehlerhaften Systems) gelesen. Alles, was sich im ZIL befindet, wird gelesen, in TXG-Gruppen zusammengefasst, im Hauptspeicher gespeichert und dann im Importprozess vom ZIL abgetrennt.<\/p>\n

Eine der Hilfsklassen von vdev wird als LOG oder SLOG bezeichnet, ein sekund\u00e4res LOG-Ger\u00e4t. Es hat die Aufgabe, dem Pool ein separates und idealerweise viel schnelleres vdev-Ger\u00e4t mit einer sehr hohen Schreibbest\u00e4ndigkeit f\u00fcr die Speicherung des ZIL zur Verf\u00fcgung zu stellen, anstatt das ZIL im Hauptspeicher des vdev zu speichern. Das ZIL verh\u00e4lt sich unabh\u00e4ngig vom Speicherort gleich, aber wenn das vdev mit LOG eine sehr hohe Schreibgeschwindigkeit hat, werden die synchronen Schreibvorg\u00e4nge schneller erfolgen.<\/p>\n

Das Hinzuf\u00fcgen eines vdev mit LOG zu einem Pool kann<\/b> die Leistung von asynchronen Schreibvorg\u00e4ngen nicht verbessern \u2013 selbst wenn Sie alle Schreibvorg\u00e4nge im ZIL mit Hilfe von<\/code>, sie werden dennoch ebenso wie ohne Protokoll an den Hauptspeicher in TXG gebunden sein und im selben Tempo arbeiten. Die einzige direkte Leistungsverbesserung ist die Verz\u00f6gerung der synchronen Schreibvorg\u00e4nge (da eine h\u00f6here Protokollgeschwindigkeit die Ausf\u00fchrung von Vorg\u00e4ngen beschleunigt) sync<\/code>).<\/p>\n

In einer Umgebung, die bereits eine gro\u00dfe Anzahl synchroner Schreibvorg\u00e4nge erfordert, kann vdev LOG indirekt die asynchrone Schreibgeschwindigkeit und nicht zwischengespeicherte Lesegeschwindigkeit erh\u00f6hen. Das Auslagern von ZIL-Eintr\u00e4gen in einen separaten vdev LOG bedeutet weniger Konkurrenz um IOPS im prim\u00e4ren Speicher, was die Leistung aller Lese- und Schreibvorg\u00e4nge in gewissem Ma\u00dfe steigert.<\/p>\n

Snapshots<\/h3>\n

\nDer Schreibvorgangsspeichermechanismus ist auch eine notwendige Grundlage f\u00fcr atomare ZFS-Snapshots und inkrementelle asynchrone Replikation. In einem aktiven Dateisystem gibt es einen Zeigerbaum, der alle Eintr\u00e4ge mit aktuellen Daten markiert \u2013 wenn Sie einen Snapshot erstellen, machen Sie einfach eine Kopie dieses Zeigerbaums.<\/p>\n

Wenn in einem aktiven Dateisystem ein Eintrag \u00fcberschrieben wird, schreibt ZFS zuerst eine neue Version des Blocks in ungenutzten Speicherplatz. Danach trennt es die alte Version des Blocks vom aktuellen Dateisystem. Sollte jedoch ein Snapshot auf den alten Block verweisen, bleibt dieser unver\u00e4ndert. Der alte Block wird tats\u00e4chlich nicht als freier Speicher wiederhergestellt, bis alle Snapshots, die auf diesen Block verweisen, gel\u00f6scht sind!<\/p>\n

Replikation<\/h3>\n

\n\"Grundlagen
\nMeine Steam-Bibliothek nahm 2015 158 GiB ein und umfasste 126.927 Dateien. Das ist ziemlich nah an der optimalen Situation f\u00fcr rsync \u2013 die ZFS-Replikation \u00fcber das Netzwerk war \u201enur\u201c 750 % schneller.<\/i><\/p>\n

\"Grundlagen
\nIn demselben Netzwerk ist die Replikation einer 40-Gib-bytes gro\u00dfen Abbilddatei einer Windows 7-VM eine ganz andere Geschichte. Die ZFS-Replikation erfolgt 289 Mal schneller als rsync \u2013 oder 'nur' 161 Mal schneller, wenn Sie wissen, wie Sie rsync mit dem Schalter --inplace aufrufen.<\/i><\/p>\n

\"Grundlagen
\nWenn ein VM-Abbild skaliert wird, skalieren auch die Probleme von rsync mit. Eine Gr\u00f6\u00dfe von 1,9 TiB ist f\u00fcr ein modernes VM-Abbild nicht sehr gro\u00df \u2013 aber sie ist gro\u00df genug, damit die ZFS-Replikation 1148 Mal schneller als rsync ist, selbst mit dem rsync-Argument --inplace.<\/i><\/p>\n

Sobald Sie verstanden haben, wie Snapshots funktionieren, ist es nicht schwierig, die Grundz\u00fcge der Replikation zu erfassen. Da ein Snapshot lediglich ein Zeigerbaum auf die Datenbl\u00e4tter ist, folgt daraus, dass wir, wenn wir einen zfs send<\/code> Snapshot erstellen, sowohl diesen Baum als auch alle damit verbundenen Datenbl\u00e4tter versenden. Wenn wir dies an den zfs send<\/code> in zfs receive<\/code> des Zielobjekts \u00fcbergeben, werden sowohl der tats\u00e4chliche Inhalt des Blocks als auch der Zeigerbaum, der auf die Bl\u00f6cke verweist, in den Ziel-Datensatz geschrieben.<\/p>\n

Es wird noch interessanter bei der zweiten zfs send<\/code>. Jetzt haben wir zwei Systeme, von denen jedes enth\u00e4lt poolname\/datasetname@1<\/code>, und Sie erstellen einen neuen Snapshot poolname\/datasetname@2<\/code>. Daher haben Sie im Quellpool datasetname@1<\/code> und datasetname@2<\/code>, w\u00e4hrend im Zielpool bisher nur der erste Snapshot vorhanden ist. datasetname@1<\/code>.<\/p>\n

Da wir zwischen Quelle und Ziel einen gemeinsamen Snapshot haben datasetname@1<\/code>, k\u00f6nnen wir einen inkrementellen<\/i> zfs send<\/code> dar\u00fcber erstellen. Wenn wir dem System sagen zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, es vergleicht zwei Zeigerb\u00e4ume. Alle Zeiger, die nur in @2<\/code>, verweisen offensichtlich auf neue Bl\u00f6cke \u2013 daher ben\u00f6tigen wir den Inhalt dieser Bl\u00f6cke.<\/p>\n

In einem Remote-System ist die Verarbeitung der inkrementellen send<\/code> genauso einfach. Zun\u00e4chst schreiben wir alle neuen Eintr\u00e4ge, die im Stream enthalten sind, send<\/code>, und f\u00fcgen dann Verweise auf diese Bl\u00f6cke hinzu. Voil\u00e0, wir haben @2<\/code> im neuen System!<\/p>\n

Die asynchrone inkrementelle ZFS-Replikation stellt eine enorme Verbesserung im Vergleich zu fr\u00fcheren, nicht snapshotbasierten Methoden wie rsync dar. In beiden F\u00e4llen werden nur die ge\u00e4nderten Daten \u00fcbertragen \u2013 aber rsync muss zun\u00e4chst hier lesen<\/i> alle Daten von beiden Seiten von der Festplatte lesen, um die Pr\u00fcfziffer zu \u00fcberpr\u00fcfen und zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nichts au\u00dfer den Zeigerb\u00e4umen \u2013 und gegebenenfalls die Bl\u00f6cke, die im gemeinsamen Snapshot nicht vorhanden sind.<\/p>\n

Integrierte Kompression<\/h3>\n

\nDer Mechanismus f\u00fcr Copy-on-Write vereinfacht auch das System der integrierten Kompression. In traditionellen Dateisystemen ist die Kompression problematisch \u2013 sowohl die alte als auch die neue Version der ge\u00e4nderten Daten befinden sich im selben Raum.<\/p>\n

Wenn man einen Datenblock in der Mitte einer Datei betrachtet, der als Megabyte von Nullen bei 0x00000000 beginnt und so weiter, l\u00e4sst 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 pseudorandom Rauschen, ersetzen? Unerwartet ben\u00f6tigt dieses Megabyte an Daten nicht einen, sondern 256 Sektoren mit 4 KiB, und an dieser Stelle auf der Festplatte ist nur ein Sektor reserviert.<\/p>\n

ZFS hat dieses Problem nicht, da \u00c4nderungen immer in ungenutztem Speicher geschrieben werden \u2013 der urspr\u00fcngliche Block nimmt nur einen Sektor von 4 KiB ein, und der neue Eintrag ben\u00f6tigt 256, aber das ist kein Problem \u2013 der zuletzt ge\u00e4nderte Block aus der \u201eMitte\u201c der Datei w\u00fcrde unabh\u00e4ngig davon, ob seine Gr\u00f6\u00dfe sich \u00e4ndert oder nicht, in ungenutztem Speicher geschrieben werden, daher ist dies f\u00fcr ZFS eine ganz normale Situation.<\/p>\n

Die integrierte Kompression von ZFS ist standardm\u00e4\u00dfig deaktiviert und das System bietet optionale Algorithmen an \u2013 aktuell geh\u00f6ren dazu LZ4, gzip (1-9), LZJB und ZLE.<\/p>\n

Wenn die Datei gro\u00df genug ist und mehrere Bl\u00f6cke ben\u00f6tigt, haben alle Eintr\u00e4ge mit dieser Datei die Gr\u00f6\u00dfe recordsize<\/code>\u00a0\u2014 einschlie\u00dflich des letzten Eintrags, dessen Hauptteil ungenutzter Speicherplatz sein kann. unbenutzter Speicher<\/a><\/noindex>.<\/p>\n