ZFS compression und deduplication

Bei Kompression auf Dateisystemebene denken viele direkt an die Implementierung von Microsoft. Mit dem gleichen Gedanken kommt oft ein *UAARRGGGSSS*. Microsoft Kisten mit eingeschalteter Komprimierung sind alles nur nicht mehr performant, es lässt sich kaum Software auf so einer Platte betreiben und man hat schneller Dateisystemfehler als man meep sagen kann. Niemand will das wirklich einschalten! Bei ZFS ist das etwas anders. Natürlich benötigt das komprimieren Systemressourcen und Datenrettungen werden um einiges Aufwändiger…. Bei heutigen CPUs merkt man kaum etwas davon, dass die CPU nun noch den Stream zur Platte komprimieren muss. Diese Funktion bringen viele CPUs schon in Hardware mit. Die CPU ist hier selten das langsamste Gliet in der Kette. Da ist viel eher die Festplatte der Flaschenhals. Mit einer neueren CPU wird es mit eingeschalteter Komprimierung eher schneller als langsamer. Warum? Na, wenn weniger Daten von der Platte gelesen bzw. weniger Daten auf die Platte geschrieben werden müssen, bringt einem das nicht nur mehr Platz auf dem Datenträger sondern zusätzlich noch weniger IOs 😀 Kompression ist also gut, sofern man nicht gerade eine alte Celeron CPU verbaut hat. Zusätzlich werden nicht beim aktivieren stumpf alle Daten komprimiert. Nein, bei aktivierter Komprimierung werden nur die Daten komprimiert abgelegt, welche in diesem Moment geschrieben werden. Schaltet man die Komprimierung wieder ab werden die neuen Daten wieder unkomprimiert gespeichert.Natürlich kann weiterhin aus jedem Zustand auf alle Daten zugegriffen werden. Will man also mal eben viele Daten ablegen / zwischenspeichern könnte man nur dafür kurz die Komprimierung aktivieren.

Dedublication also dedublizierung ist noch so ein extrem cooles Spielzeug. Ist dieses aktiviert werden einmal gespeicherte Blöcke nicht noch einmal auf der Platte gespeichert. Es wird nur hinterlegt wo man die Daten findet. Hat man also auf dem Store virtuelle Maschinen liegen hat man schnell einige gleiche Blöcke. Das kann richtig Platz sparen. Ist der Store als Fileserver oder ähnliches in einem Unternehmen kann man ebenso Platz sparen. Arbeiten viele User an bzw. mit den gleichen Dingen, taucht ein und das gleiche Dokument an den verschiedensten Stellen auf. Egal ob man nun einen Sharepoint-Server oder ähnliches einsetzt oder das ganze nur an einem Ort liegen soll.User sind halt User. Versionierung in der Entwicklung… Hier wird oft mal eine Kopie des alten Baumes angelegt um eine neue Version zu starten.
// Da gibt es bei einem Kunden meines Arbeitgebers einen Administrator. Dieser betreut eine nicht ganz unwichtige Software. Vor jedem Update das er einspielt legt er immer eine Kopie des Programmordners an, jeweils 2 GB… Diese Kopien liegen dann gerne mal noch 2 – 3 weitere Updates herum. Selbst wenn bei einem solchen Update nur 4 – 5 ini Einträge und zwei 500kb exe Dateien getauscht werden. Mit aktivierter dedubplication verbraucht eine solche Kopie nicht mehr 2GB sondern nur noch die Menge der Änderungen 10 MB…. Also soll dieser beratungsresistente Admin seine Kopien machen! 😀 //

Als kleinen Test habe ich Openindiana auf zwei baugleichen Rechnern mit gleichen Einstellungen installiert. Einmal habe ich vor der Installation compression und deduplication aktiviert einmal nicht.

Sobald die Openindianainstallation den zfs Pool (default rpool) angelegt hat führte ich in einer Konsole der LiveDVD folgendes aus:

$ sudo -s
$ zfs set compression=on rpool && zfs set dedup=on rpool

Dann lies ich die Installation ganz normal durchlaufen und habe die Kiste nach der Installation neu gestartet. Direkt nach der Anmeldung des frischen Systems habe ich mir angeschaut was an Daten auf der Platte gelandet ist. Ach ja, die Installation mit compression und deduplication (deduplication konnte hier ja noch nicht richtig ausgespielt werden, belegt nur schon mal Platz im RAM :-P) hat ca. 30 Sekunden länger gedauert….

Als erstes lasse ich mir mal den Komprimierungsgrat ausgeben:

$ zfs get compressratio rpool
NAME   PROPERTY       VALUE  SOURCE
rpool  compressratio  1.52x  -

1.52…. Da müsste ich ja fast die Hälfte an Platz gespart haben! Mal schauen was die deduplication gemacht hat:

$ zpool get dedupratio rpool
NAME   PROPERTY    VALUE  SOURCE
rpool  dedupratio  1.01x  -

Wie zu erwarten nicht _SO_ viel. Es gibt bei der Installation halt kaum doppelte Daten. Denn noch  ist es ein ganz guter Test, denn mit aktivierter deduplication laufen die ganzen Routinen schon mal mit und man sieht wie schnell oder langsam es ist! Schauen wir mal was nun wirklich auf der Platte an Platz verbraucht wurde:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  2,59G  71,4G     3%  1.01x  ONLINE  -

2,59GB für die Grundinstallation mit aktivierter compression und deduplication. Mal schauen was ohne diese beiden Funktionen auf der Platte landet:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  3,93G  70,1G     5%  1.00x  ONLINE  -

Joar das kann sich sehen lassen, oder? Mit entsprechend viel RAM holt man bei eingeschalteter deduplication natürlich eher mehr als weniger Leistung aus deinem Store. Denn jeder Block der nicht geschrieben werden muss lässt der Platte Luft einen anderen Block zu schreiben 😀

Noch etwas zu ZFS compression. Man sollte natürlich darüber nachdenken für welches Volume man die Komprimieren nun einschaltet und für welches nicht. Denn ein Volume auf welchem bereits komprimierte Daten wie Videos, Bilder oder ähnliches abgelegt werden, da wird zfs compression nichts bringen. Es macht es maximal langsamer! Bei Logfiles sieht es natürlich anders aus.
Jetzt lassen sich die Optionen der Komprimierung aber noch etwas genauer anpassen. Mit einem einfachen: zfs set compression=on zfs Datenset greifen die standard Einstellungen. Zur Komprimierung wird gzip verwendet und zwar mit dem compression level 6. Möchte man nun einen höheren Komprimierungslevel haben, zum Beispiel das Maximum 9. Setzt man es wie folgt:

$ zfs set compression=gzip-9 home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression gzip-9 local

Ebenso lässt sich auf einen anderen Algorithmus wechseln:

$ zfs set compression=zle home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression zle local

Umso stärker die Komprimierung umso mehr CPU Zeit geht für die Berechnung drauf. Ob es jetzt beim default level 6 bleibt oder man auf 9 wechselt, dieses hat in meiner Praxis kaum einen Unterschied gemacht. Als Algorithmus zle zu nutzen macht die Sache etwas schneller, verschlechtert den Komprimierungsgrad aber deutlich. Dieses kann ich mit einem gzip-1 fast ebenfalls erreichen! Was man sich vielleicht noch einmal genauer anschauen sollte ist lzjb oder LZ4….

Es bleibt daher, wie so oft, zu bewerten was wohl in der aktuellen Situation das Beste ist!

….und noch was zu ZFS Deduplication!
Hier bitte ebenfalls darüber nachdenken ob und für welches Volume es sinnvoll ist. Deduplication sorgt zwar für Platz und Ruhe auf den Platten. Verbrennt dafür RAM und CPU Zeit!
Im Standard sorgt folgendes:

$ zfs set dedup=on home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup on local

..dafür dass bei jedem zu schreibenden Block eine sha256 Checksumme erstellt wird und wenn die gleich ist mit einem bereits geschriebenen Block wird er nicht geschrieben, sondern es gibt nur eine Art Verweiß auf den bereits geschriebenen. Dieses bedeutet nun aber dass es bei einem von 2\^-256 Blöcken zu einer gleichen Checksumme kommen kann auch wenn die Daten unterschiedlich sind. Wer hier eine höhere Sicherheit haben möchte kann mit einem:

$ zfs set dedup=sha256,verify home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup sha256,verify local

..dafür sorgen, dass bei einer gleichen Checksumme ein Byte-für-Byte Vergleich der Daten gemacht wird. Damit kommt man dann auch diesem Fall auf die Schliche! Ebenso lassen sich hier wieder andere Algorithmen als sha256 einsetzten. fletcher2 oder fletcher4… Gefühlt bringt hier flechter4 zusammen mit verify etwas mehr Performance. Ich bleibe derzeit denn noch lieber bei sha256!

B.t.w.: fletcher4 habe ich unter BSD und Linux Implementierungen schon ein paar mal vermisst. Ob ich hier nur auf eine „alte“ ZFS Version reingefallen bin?