ZIL / L2ARC Experimente

ZIL / L2ARC Experimente

Ich habe diesen Abschnitt nicht ohne Grund mit dem Wort „Experimente“ versehen. Als ich meinen ZPOOL sowie die Dateisysteme angelegt hatte und viel viel Arbeit in das Finetuning von zfs gesteckt habe vielen mir immer wieder die Stichworte Intent Log ( ZIL ) sowie L2ARC ( Cache ) auf. „Cache“ als Begriff in der Informationstechnologie verknüpft man sicher gern mit Leistungssteigerung und allein aus diesem Grund prüfte ich mehr und mehr Hyperlinks im Netz über Beschreibungen und welche Befehle notwendig sind um das zfs zu optimieren. Ich habe ja bekanntlich 24 GB Arbeitsspeicher in meinem Server und man könnte meinen das dürfte für den Heimbereich mehr als ausreichend sein. Das stelle ich auf keinen Fall in Frage. Ich sehe nur wie schnell freier Arbeitsspeicher immer sofort genutzt wird. Eigentlich gut so. Es gibt es einen schönen Spruch „Free memory is wasted memory“ und zfs macht nun ja sehr regen Gebrauch von Arbeitsspeicher. Und wozu nun noch ZIL auf getrennten Festplatten (also quasi ausgelagert aus dem Pool / RAM) und Datenträger die als Cache-Device funktionieren? Ich fügte also in einem ersten Schritt beide 120 GB SSD in einem gespiegelten Plattenverbund dem zfs Pool „raid1p1“ hinzu …

2013-02-11.23:01:24 zpool add raid1p1 log mirror ada1 ada2
...
        NAME        STATE     READ WRITE CKSUM
        raid1p1     ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada6    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            ada3    ONLINE       0     0     0
            ada4    ONLINE       0     0     0
        logs
          mirror-2  ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
...

… und wartete nun auf den riesigen Performance-Boost. Ich stellte keinen fest. Meine kleine MySQL und die paar wenigen Logdateien von MTA und FreeBSD scheinen nicht ausreichend Stress zu sein. Zu letzteren möchte ich anmerken, daß die 60 GB SSD eigentlich nur zum Booten und für die Betriebssystemtools bereit steht. Alles was irgendwie dynamischer Natur ist liegt in dedizierten Filesystemen des zfs Pools. Also kopierte ich Bilddateien vom Server zur Workstation und wieder zurück. Hmm. Mit dem Befehl „zpool iostat -v 1“ konnte ich ermitteln, daß von den 120 GB im Maximum nur 500 MByte genutzt worden. So erst einmal meine Wahrnehmung was da angeblich in der letzten Sekunde so passiert sein sollte. Das wurmte mich aber. 120 GB liegen quasi ungenutzt im Gehäuse herum. Das geht so nicht. Im nächsten Schritt hängte ich eine weitere 120 GB SSD (beide waren wie bereits geschrieben im System vorhanden und sollten eigentlich für einen Mirrored Root-Pool dienen) in den Pool und dieses Mal als Cache-Device. Wow! Jetzt waren diverse Datentransfers von und zum Server wesentlich schneller und es sah einfach faszinierend aus wie zfs in der „iostat“-Ansicht mit dem ganzen Festplattenverbund arbeitet. Aber der Wurm war immer noch vorhanden. Die fast ungenutzte 120 GB SSD. Das musste sich ändern.

Ich wollte das Intent Log wieder von der SSD entfernen. Geht das einfach so? Laut Manpage und diversen Links sollte es in zfs Version 5 und Pool Version 28 überhaupt kein Problem sein die ZIL wieder als eigenständiges Log-Device zu entfernen. Aber wenn man mal die Anzahl der Fragen im Internet betrachtet wie viele Benutzer sich nicht sicher sind, dann gibt es bestimmt noch ein paar notwendige Hinweise in den zfs-Dokumentationen. Also was tun? Die ZIL hatte zu diesem Zeitpunkt einige MByte in der Belegung stehen. Geht jetzt mein POOL kaputt wie es wohl noch zu Version 19 und kleiner gewesen sein soll?

NEIN! NEIN! NEIN!

Alles läuft wie vorher! Einzig nach den folgenden Befehlen (eigentlich nur beim dritten) …

2013-02-12.12:47:44 zpool detach raid1p1 ada2           // ZIL Festplatte aus Log-Mirror entfernen
2013-02-12.12:53:13 zpool add raid1p1 cache ada2     // Festplatte als L2ARC einbinden

Wenn man sich die Uhrzeit betrachtet, dann sieht man meine Verunsicherung und 
die Zeit die ich für kleinere Tests und eine Beobachtung genutzt habe. Außerdem wollte ich nun einen
gespiegelten ZIL-Mirror und zwei Cache Festplatten nutzen. Ich hatte aber nur zwei 120 GB SSD 🙂

2013-02-15.17:20:58 zpool remove raid1p1 log ada1   // ZIL komplett entfernen

… dauerte es gefühlt eine Ewigkeit (Real ca. 2-3 Sekunden) bis zfs das Intent-Log von der 120 GB SSD (Device ada1) wieder entfernt hatte. Während dieser Phase spürte ich auf jeden Fall ein Anspannung in mir. Über 70 Tausend mir „wichtige“ Bilder entscheidet man halt nicht ganz so schnell. Es gab auch keine vollständige Datensicherung. Aber gut! Stichproben ob noch etwas funktionierte blieben natürlich nicht aus. Also schnell ein paar Bilder quer durch mein Archiv geöffnet und alles war gut. Keine fehlende Bilddaten oder komisches Verhalten bei Antwortzeiten etc. Natürlich ist das kein Garant dafür, daß mein Dateisystem nicht doch eine „Lücke“ bekommen hat aber ich bin mittlerweile so von zfs überzeugt das ich sogar Geld in Form von bedruckten Papier dafür zahlen würde. Eine tolle Entwicklung.

Weiter geht es! Also nur zwei Festplatten die „RAM-ähnliche“ Geschwindigkeiten für Caching-Aufgaben erfüllen würden. Ich möchte aber eine gespiegelte ZIL haben sowie Cache-Devices. Was nun? Die Lösung kam eigentlich nach wenigen Minuten beim Nachdenken. Warum nicht einfach per „gpart“ die beiden SSD-Festplatten in Partitionen unterteilen? Diesen Gedanken wollte ich dann auch umgehend in die Tat umsetzen:

gpart recover ada1                   // GPT Struktur wiederherstellen
gpart recover ada2

gpart add -b 34 -s 2048000 -t freebsd-zfs -i 1 -l zfslog1 ada1  // 1 GB Platz reservieren
gpart add -b 34 -s 2048000 -t freebsd-zfs -i 1 -l zfslog2 ada2

gpart add -t freebsd-zfs -i 2 -l zfscache1 ada1                // Rest für Cache Partition
gpart add -t freebsd-zfs -i 2 -l zfscache2 ada2

[root@trinitron ~]# gpart show
=>       34  117231341  ada0  GPT  (55G)
         34        128     1  freebsd-boot  (64k)
        162  111148928     2  freebsd-ufs  (53G)
  111149090    5861376     3  freebsd-swap  (2.8G)
  117010466     220909        - free -  (107M)

=>       34  234441581  ada1  GPT  (111G)
         34    2048000     1  freebsd-zfs  (1G)
    2048034  232393581     2  freebsd-zfs  (110G)

=>       34  234441581  ada2  GPT  (111G)
         34    2048000     1  freebsd-zfs  (1G)
    2048034  232393581     2  freebsd-zfs  (110G)

Nun hatte ich zwei GPT-Festplatten mit jeweils einer Partition mit der Größe von 1 GByte sowie jeweils eine zweite Partition mit 110 GByte verfügbar. Ich wollte nun die beiden Partitionen mit je 1 GB in einen gespiegelt Intent Log-Pool überführen sowie die beiden verbliebenen Partitionen als Cache Device verwenden. Nachfolgend die verwendeten Befehle:

2013-02-15.17:39:54 zpool add raid1p1 log mirror ada1p1 ada2p1
2013-02-15.17:40:42 zpool add raid1p1 cache ada1p2 ada2p2

Das Ergebnis gefiel mir 🙂 Die Leistung war nun wesentlich höher als die vorherige Pool-Konfiguration. zfs beschreibt beide Cache-Partitionen scheinbar im Round-Robin-Verfahren und die ZIL ist in einer gespiegelten Umgebung. Einzig die Größe von 1 GB könnte eventuell etwas sehr knapp gewählt sein. Auf der anderen Seite handelt es sich hier um einen Server für den Heimeinsatz der wohl kaum eine Belastung erfahren sollte wie sie im Enterprise-Segment an der Tagesordnung ist. Da kenne ich aus meinem eigenen Berufsumfeld, daß Datentransferraten über 10 Gbit-Ethernet-Links mit 750 MByte/s zu NAS-Filern unter AIX Power 7 ablaufen und das nicht nur in Spitzen. Aber diesen Anspruch habe ich nicht 😉

Nun ja! Das Ergebnis sieht man auf dieser Seite

Letzte Beiträge