ZFS on Linux Performance Evaluation

  • Published on
    05-Jan-2017

  • View
    213

  • Download
    1

Transcript

  • ZFS on Linux Performance Evaluation

    Norbert Schramm 6146299

    MasterprojektFachbereich InformatikUniversitt Hamburg

    30. Mrz 2016

    1

  • Inhaltsverzeichnis

    1. Einleitung 31.1. ZFS Entwicklung und Geschichte . . . . . . . . . . . . . . . . . . . . . . . 31.2. Funktionen von ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

    2. ZFS im Vergleich 62.1. verwendete Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    2.1.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2. Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    2.2. Messergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    3. ZFS on Linux 163.1. Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2. Messergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3. Kompression und Deduplikation in der Praxis . . . . . . . . . . . . . . . . 23

    4. Lustre on ZFS 254.1. Lustre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2. Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

    4.2.1. verwendete Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 274.3. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

    5. Zusammenfassung 31

    A. Scripte 33A.1. Installation von ZFS unter Linux mit modifiziertem Kernel . . . . . . . . . 33A.2. Benchmark-scripte fr Bonnie++ . . . . . . . . . . . . . . . . . . . . . . . 34

    2

  • 1. Einleitung

    Zur Speicherung von Daten auf einem Computer ist ein Dateisystem notwendig, dassdie Daten korrekt speichert, verwaltet und das wieder abrufen ermglicht. Hierbei kannman in die verfgbaren Dateisysteme in zwei Gruppen unterteilen, die klassischen unddie modernen Dateisysteme. Zu den Klassischen zhlen bekannte und weit verbreiteteDateisysteme, wie ext4 unter Linux oder NTFS unter Windows. Sie sind seit Jahrenetabliert und ermglichen es, Daten zuverlssig zu speichern. Darber hinaus sind inder jngeren Zeit allerdings neue Herausforderungen hinzugekommen, die ein modernesDateisystem erfllen muss. Unter Linux gibt es hier zum Beispiel im Zusammenhang mitRAID-Verbnden Probleme, wie etwa das langsame wiederherstellen grerer Platten-verbnde oder das Write-Hole-Problem, welches zur Dateninkonsistenz fhren kann.Moderne Dateisysteme, wie ZFS besitzen einen erweiterten Funktionsumfang, um die

    Mglichkeiten des Dateisystems zu erweitern oder die Datensicherheit zu erhhen (sieheKapitel 1.2. In diesem Fall beschftigen wir uns mit dem Dateisystem ZFS. Da diesesursprnglich von Sun Microsystems fr ihr Betriebssystem Solaris entwickelte Dateisy-stem erst auf andere Betriebssysteme portiert werden musste, kann es zu Leistungsunter-schieden kommen. Zustzlich kommt hinzu, dass der Code von ZFS unter der CommonDevelopment and Distribution License (CDDL) von Sun Microsystems verffentlicht wur-de. Diese ist inkompatibel zu der von Linux verwendeten GNU General Public License(GPL), weshalb eine direkt in die Kernelsourcen integrierte Linux-Implementierung nichtmglich ist. Das Projekt ZFS on Linux (ZoL) baute daher den Funktionsumfang in Formeines Kernelmoduls fr Linux nach. Seit April 2013 gilt diese Version als stable relea-se und hat somit das experimentelle Stadium hinter sich gelassen und zur produktivenNutzung freigegeben.Im Kapitel 2 fhre ich daher einen Vergleich von drei unterschiedlichen unixoiden

    Betriebssystemen (Illumos, FreeBSD, Ubuntu) durch, die ZFS untersttzen, um zu un-tersuchen, wie performant die Portierung von ZoL im Vergleich zur originalen Versionist.Im Kapitel 3 wird mit Hilfe des Programms wrstat die ZoL-Version unter Ubuntu

    genauer betrachtet.Das Netzwerkdateisystem Lustre basiert auf dem lokalen Dateisystem ldiskfs, welches

    eine Weiterentwicklung von ext4 ist. Seit dem stable release von ZoL gibt es unter Lustreauch die Mglichkeit, ZFS als lokales Dateisystem zu verwenden. Diese Kombination wirdin Kapitel 4 kurz betrachtet.

    1.1. ZFS Entwicklung und Geschichte

    Der Name ZFS stand ursprnglich fr den Namen Zettabyte File System und wurde vonSun Microsystems seit 2001 als closed source Dateisystem fr das hauseigene Betriebssy-stem Solaris entwickelt [3]. Zusammen mit der Umwandlung von Solaris in OpenSolarisin ein Opensource-Projekt unter der ebenfalls von Sun entwickelten CDDL wurde ZFS2005 verffentlicht. Nach der bernahme von Sun durch Oracle wurden die Arbeiten anOpenSolaris 2010 eingestellt. Zur Weiterentwicklung wurde der ZFS-fork OpenZFS ge-

    3

  • grndet, dessen Mitglieder unter anderem aus Entwicklern der Betriebssysteme Illumos,FreeBSD oder einiger Linux-Distributionen bestehen.Bereits 2006 gab es die erste FUSE-Implementierung, um ZFS unter Linux nutzen zu

    knnen. Da ZFS allerdings eher fr den Einsatz in leistungsstarken Umgebungen ent-wickelt wurde und etwas mehr Rechenleistung der CPU bentigt, als klassische Datei-systeme, verbreitete sich diese Lsung nicht sehr stark. Grter Nachteil von FUSE-Dateisystemen ist der verringerte Datendurchsatz, da die Implementierung im Userspaceerfolgt.Pawel Jakub Dawidek portierte 2008 mit Hilfe von Sun-Entwicklern ZFS in das Be-

    triebssystem FreeBSD, welches ZFS in der Version 7.0 als experimentelles Dateisystemund in Version 8.0 als stabile Variante nutzt. Diese Version ist direkter Bestandteil desBetriebssystems.Nachdem die Arbeiten an Solaris 2010 eingestellt wurden, nahm Illumos als neue Re-

    ferenzplattform fr ZFS seinen Platz ein. Viele Abwandlungen von ZFS auf anderenBetriebssystemen stammen von der unter Illumos genutzten ZFS-Version ab.Das Projekt ZFS on Linux umgeht das Problem der unterschiedlichen Lizenzen (CDDL,

    GPL) und pflegt eine eigene Portierung von ZFS. Diese kann einfach heruntergeladen unddas Linux-Dateisystem damit gepatched werden, um ZFS direkt als performantes Kernel-Modul nutzen zu knnen. Seit der Version 0.6.1 ist ZoL fr den produktiven Einsatzfreigegeben [1]. Laut der Aussage eines Hauptentwicklers aus dem Jahr 2014 liegt ZoL0.6.3 effektiv nur noch nur noch 18 Funktionen hinter der Referenz zurck"[10] wovones fr neun jedoch bereits Workarounds gibt und die restlichen neun mit der folgendenVersion 0.6.4 implementiert werden sollen. Die aktuelle Versionnummer ist 0.6.5.6, womitdavon ausgegangen werden kann, dass ZoL im Funktionsumfang der Illumos-Version innichts nachsteht. Dennoch war es bei meinen Messungen in einem Versuch noch nichtmglich, einen unter Illumos erstellten ZFS-Pool unter Linux zu importieren. Das ProjektOpenZFS hat unter anderem diese Interoperabilitt zum Ziel. Die Version 1.0 soll erreichtwerden, wenn die ioctl-Schnittstelle /dev/zfs fertig entwickelt und stabil ist.

    Im laufe der Entwicklung wurden im originalen ZFS weitere Funktionen hinzugefgt,wie verschiedene Kompressionsalgorithmen und komplexere Partitts-modi fr grereArrays (siehe folgendes Kapitel).

    1.2. Funktionen von ZFS

    Dieses Kapitel beinhaltet eine kurze Auflistung und Erklrung einiger besonderer Funk-tionen, die fr ZFS besonders sind und es von klassischen Dateisystemen unterscheiden.Ein wesentliches Merkmal von ZFS sind 128bit lange Pointer, mit denen Dateien

    adressiert werden. Dies ermglicht es, eine rechnerische Menge von 2128 Bytes gespeichertwerden. Da die meisten Betriebssysteme jedoch aktuell 64bit-Systeme sind, ist der aktuellverfgbare Adressraum auf 264 Bytes beschrnkt, was 16 EiB entspricht. Bei spterenImplementationen ist eine Erweiterung auf 128 Bit ohne Probleme mglich. Bisher werdendie ersten 64 Bit einfach mit 0 dargestellt. Die maximale Dateigre betrgt ebenfalls 264

    Byte, die maximale Anzahl mglicher Dateien im Dateisystem und maximale Anzahl anOrdnern ist auf 248 begrenzt. Laut Marketingaussagen des Chefentwicklers Jeff Bonwick

    4

  • wrde das vollstndige Fllen eines 128 Bit groen Speicherpools mehr Energie bentigenals fr das Verdampfen der Weltmeere von Nten wre[2]. Diese Aussauge untermauertauch die Philosophie von ZFS, ein vorausschauendes und langlebiges Dateisystem zuwerden.Die Datenintegritt spielt bei ZFS ebenfalls eine Groe Rolle. Fr jede Datei wird

    ein Hashwert erstellt und auf dem selben Speichermedium abgelegt. Von jedem Ordnerund dem Ordner darber werden ebenfalls Hashes berechnet, sodass es am oberen Endeeinen Master-Hash gibt, der fr die Datenintegritt aller unter ihm gespeicherten Datengarantiert. Fehlerhafte Daten knnen so erkannt werden und bei redundanter Speicherungselbststndig behoben werden. Daher spricht man bei ZFS gelegentlich auch von einemselbstheilenden Dateisystem. Der Overhead zur Berechnung der Prfsummen und derdafr zustzlich bentigte Speicherplatz sind nur minimal, sodass die IO-Leistung vonZFS nur minimal schlechter ist, als von einem ext4-Dateisystem [8]. Die Garantie, zujedem Zeitpunkt (auch nach einem Stromausfall) ein konsistentes Dateisystem zu haben,macht Tests, wie fsck in klassischen Dateisystemen berflssig.Zur Erhhung der Redundanz in einem Array aus mehreren Festplatten werden hufig

    RAID-Verbnde genutzt. Gerade bei groen Verbnden, wie RAID-5 oder RAID-6 miteiner bzw. zwei Parittsfestplatten, dauert das erstellen und wiederherstellen eines Arrayszum Teil sehr lange, da fr jedes Bit eine Paritt berechnet werden muss. Dies ist demUmstand geschuldet, dass Volumemanager (z.B. mdadm) und Dateisystem nicht kommu-nizieren. ZFS kombiniert die Funktionen beider und arbeitet dadruch viel effizienter. Somuss ein RAID-5 quivalent (unter ZFS raidz genannt) nicht initialisiert werden, sondernkann direkt genutzt werden. Die Paritten fr geschriebene Daten werden erst whrenddes Schreibvorgangs berechnet. Bei einer Wiederherstellung nach einem Ausfall mssenso auch nur vorhandene Daten wiederhergestellt werden und nicht smtliche Blcke desArrays. In der aktuellen Version beherrscht ZFS mit dem Modus raidz3 sogar eine 3-facheParitt. Andere RAID-Modi, wie 0,1,10 werden ebenfalls quivalent untersttzt.Durch die Unterteilung in Storage-Pools knnen Unterverzeichnisse mit unterschied-

    lichen Eigenschaften (Kompression, Deduplikation) ausgestattet werden. Des weiterenknnen verschiedene RAID-Konfigurationen zu einem Pool zusammengesetzt werden,zum Beispiel einer raidz und ein raidz2 zu einem Storage-Pool. Zustzlich knnen zueinem Pool auch noch schnelle Speichermedien als Read-Cache (L2ARC) oder Write-Log(ZIL) zugeordnet werden, um die Leistung des Pools zu erhhen.Ebenfalls zur Datensicherheit trgt die Copy on Write Funktionalitt von ZFS bei.

    Wird eine Datei gelesen, modifiziert und gespeichert, wird die neue Version an eine freieStelle des Dateisystems geschrieben. Erst nach dem erfolgreichen Schreiben wir die alteDatei als inaktiv markiert und der Pointer auf die neue Datei umgeschwenkt. Somit kanneine Datei durch einen Systemabsturz nicht zerstrt werden. Durch CoW wird ebenfallsdas vom RAID-5 bekannte Write-Hole-Problem behoben, bei dem eine Datei trotz Parittzerstrt werden kann, wenn das System whrend des Schreibvorgangs abstrzt.Hand in Hand mit CoW gehen auch Snapshots. Diese ermglichen eine platzsparende

    Versionierung des Dateisystems. Wird ein Snapshot erstellt, werden alle Daten eingefro-ren und nur neu geschriebene oder modifizierte Dateien bentigen weiteren Speicherplatzauf dem Pool.

    5

  • Mit der Einfhrung von Deduplikation knnen bei hnlichen Daten groe Mengen anSpeicherplatz gespart werden. Hierbei wird berprft, ob identische Datenblcke bereitsauf der Festplatte liegen. Ist dies der Fall, so wird fr die neue Datei lediglich ein refe-renzierende Pointer auf die bereits bestehende Datei geschrieben und der Speicherplatzkomplett eingespart. Da dieses Verfahren jedoch sehr viel RAM bentigt (rund 5 GBfreien Hauptspeicher pro TB Speicherplatz [16]), ist es nur bedingt sinnvoll. Pro Daten-block werden 320 Byte RAM bentigt. Nehmen wir an, dass 5 TB Daten eine mittlereBlockgre von 64 kb haben, so entspricht dies 78125000 Blcken. Multipliziert mit 320Byte ergibt das rund 25 GB fr die Dedup-Tabelle.Durch transparente Kompression durch das Dateisystem knnen je nach zu spei-

    cherndem Datentyp groe Mengen an Speicherplatz eingespart werden. Wird eine Dateiauf die Festplatte geschrieben, werden sie vom Prozessor komprimiert und dann auf denDatentrger geschrieben. Dies ermglicht bei gut komprimierbaren Daten nicht nur einenverminderten Speicherplatzbedarf sondern auch Datenraten, die hher sind als die phy-sikalischen Lese-/Schreibraten der Festplatte, siehe Kapitel 2.2.

    2. ZFS im Vergleich

    Da der Funktionsumfang von allen getesteten ZFS-Versionen gleich ist, kann die Perfor-mance der Funktionen direkt mit einander vergleichen werden. Schwerpunkt lag hierbeineben dem eigentlichen Vergleich der unterschiedlichen Betriebssystemversionen auch dieUntersuchung der Funktionen Kompression und Deduplikation.Da der erste Test auf zu alter Hardware stattfand, habe ich mit insgesamt drei verschie-

    denen Computern die Tests auf allen drei Betriebssystemen ausgefhrt, um so gleichzeitigeine Abhngigkeit der Leistung von ZFS in Abhngigkeit von der verwendeten Hardwarezeigen zu knnen. Trotz einer unterschiedlichen Festplatte in einem der drei Systeme istdennoch eine Tendenz zur Abhngigkeit vom Prozessor zu erkennen.

    2.1. verwendete Komponenten

    2.1.1. Hardware

    Insgesamt wurden drei Computer verwendet. Ein Rack-Server Dell R710, eine Worksta-tion von Fujitsu-Siemens-Computers und ein normaler Desktop-Computer. Die Systemesind der Leistung nach aufsteigend aufgezhlt.

    System 1 : Die Workstation von FSC hat einen Intel Xeon E3110 Prozessor mit 2x3.0GHz Takt. Der Prozessor stammt von Intels Core2-Architektur ab und ist seit Q108verfgbar. Er ist damit der lteste getestete Prozessor. Es sind 8 GB RAM verbaut. Frdie getestete Festplatte wurde eine Western Digital Black 1 TB verwendet, welche direktan einem SATA-Port am Server angeschlossen war.

    System 2 : Der Dell-Server hat einen Intel Xeon X5677-Prozessor mit 4 Kernen und 3.46GHz Taktung. Die CPU stammt aus der Nehalem-Architektur und ist somit der zweil-

    6

  • teste Prozessor (Verffentlicht: Q110). Hier waren 32 GB RAM verbaut. Die Festplattewar eine 136 GB 15K SAS-Festplatte, welche ber den integrierten RAID-ControllerPERC6/i als RAID-0 mit einer Festplatte durchgereicht wurde.System 3 : Das modernste System im Test basiert auf einem Intel Corei-5 2500k mit

    4x3.3 GHz Takt. Er stammt aus der Sandy Bridge-Serie von Intel und ist somit eineGeneration neuer, als das vorherige Modell (Verffentlicht: Q111). Als Arbeitsspeicherwurden wieder 8 GB RAM verwendet. Es wurde die gleiche WD Black 1 TB Festplattean einem SATA-Port verwendet, wie im ersten System.

    2.1.2. Betriebssysteme

    Fr einen Vergleich wurden drei unixoide Betriebssysteme verwendet:

    OpenIndiana: OpenIndiana ist ein auf Illumos basierendes Betriebssystem. Da Illumosnach der Einstellung der Entwicklung von OpenSolaris als neue Referenzplattform frZFS gilt, ist OpenIndiana ein Betriebssystem aus Solaris-Basis, fr das ZFS ursprnglichentwickelt wurde. Genutzt wurde die Version oi_151a8 von OpenIndiana auf Basis vonSunOS 5.11 von Juli 2013. ZFS ist als Bestandteil von OpenIndiana bereits vorinstalliert.Im folgenden die Ausgabe des Befehls uname -a

    SunOS openindiana 5.11 oi_151a8 i86pc i386 i86pc Solaris

    FreeBSD: Als Vertreter der Portierungen mit direktem Einbau in das Betriebssystemwurde FreeBSD gewhlt. Die sehr offene BSD-Lizenz ermglichte es, ZFS direkt zu im-plementieren, weshalb ZFS seit Version 8.0 fester Bestandteil des Betriebssystems ist.FreeBSD gilt als ein sehr performantes und stabiles Serverbetriebssystem, besonders imBereich der Paketverarbeitung im Netzwerk. ZFS ist als Bestandteil von FeeBSD bereitsvorinstalliert. Genutzt wurde die aktuelle Version 10.2 mit der folgenden Ausgabe vonuname -a

    FreeBSD freebsd 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 1215:26:37 UTC 2015 rootreleng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERICamd64

    Ubuntu: Fr den Test von ZFS on Linux wurde Ubuntu verwendet. Es ist einer derbekanntesten Vertreter von Linux und basiert auf Debian. ZoL kann direkt ber Paket-quellen einfach installiert werden. In der kommenden Version 16.04 ist es trotz Lizenzpro-blemen geplant, ZFS direkt mit aufzunehmen. Verwendet wurde Ubuntu 14.04.3 LTS. DerKernel wurde mit dem Parameter CONFIG_LOCK_STAT=y"bereits neu kompiliert,um fr die Tests im nchsten Kapitel mit wrstat vorbeireitet zu sein. Auf die Leistungvon ZFS gegenber dem originalen Kernel hat dies bei dieser Testmessung keinen Einfluss.

    Linux ubuntu 3.13.11-ckt33 #1 SMP Tue Mar 8 20:38:30 CET 2016 x86_64 x86_64x86_64 GNU/Linux

    7

  • Da ZFS unter Ubuntu nicht vorinstalliert ist, musste ich etwas Aufwand betreiben, umZFS unter dem modifizierten Kernel lauffhig zu bekommen. Das vollstndige Listing frdie Installation befindet sich im Anhang unter A.1 Als erstes wurden sowohl die SolarisPorting Layer (SPL) als auch die ZFS-Sources aus dem Git-Repository von ZFSonLinuxheruntergeladen und laut Listing installiert 5. Danach wurden die bentigten Paketefr das Kernel-Patching runtergeladen und installiert 6. Hier wurde in der Kernel-configdie Zeile CONFIG_LOCK_STAT=yinkommentiert bzw. editiert und anschlieend neukompiliert. Nach einem Neustart wurde der neue Kernel geladen.Um ZFS unter diesem lauffhig zu bekommen, musste SPL erneut installiert werden.

    Fr die Installation von ZFS waren noch zwei nderungen notwendig. Ein scheinbarbekanntes Problem ist, dass das Kompilieren von ZFS versagt, sobald der Kernel modifi-ziert wurde [15]. Deshalb muss die Datei META editiert werden und in einem nicht ganzsauberen Workaround die Lizenz von CDDL auf GPL gendert werden.

    Des Weiteren muss eine Quelldatei include/linux/vfs_compat.h von ZFS editiert wer-den (siehe Listing 7), da das kompilieren sonst fehlschlgt. Bei einem originalen Kernelwrde diese Schleife nicht ausgefhrt werden. Da der Kernel aber modifiziert wird, mussdie Funktionalitt der Schleife invertiert werden, da es sich im Wesentlichen noch umden originalen Kernel handelt. Nun ist die Installation von ZFS ebenfalls mglich undauf dem modifizierten Kernel lauffhig.

    Auf allen Systemen wies der Befehl zdb die Version 5000 von ZFS aus.

    2.1.3. Benchmarks

    Fr den Vergleich wurde hauptschlich das Programm bonnie++ verwendet, welches aufallen drei Plattformen verfgbar war. Die Benchmarks mit dem Programm iozone konn-ten auf Grund von Zeitmangel nur auf dem Server 2 (Dell) ausgefhrt werden und wurdedeshalb nicht in die Auswertung aufgenommen.

    Bonnie++ ist ein Festplattenbenchmark, welcher sich im wesentlichen in vier Schritteeinteilen lsst [4]:

    Write: sequentielles Schreiben einer Datei auf die Festplatte mit dem write-Befehl

    ReWrite: jede BUFSIZ der Datei wird mir read gelesen, modifiziert und mit writegeschrieben, wofr ebenfalls ein lseek notwendig ist. Da kein neuer Speicherplatzverbraucht wird, wird der Cache des Dateisystems so getestet

    Read: sequentielles auslesen der Datei mit read

    File Creation Tests: erstellen, ndern und entfernen einer groen Zahl von Ver-zeichnissen ohne Inhalt

    Die ersten drei Punkte bilden den Schwerpunkt meiner Analyse. Die komplette Dateimit allen Messwerten aus bonnie++ befindet sich im Anhang des Projekts. Eine Aus-wertung mit hexdump der geschriebenen Daten von bonnie++ ergab, dass es sich um

    8

  • einfache Muster handelt, die grtenteils aus Nullen bestehen. Daher ist die Kompressi-onsrate bermig stark (ca um den Faktor 130x) und nicht die Festplatte, sondern dieKompression auf der CPU der Bottleneck. Die Ergebnisse dieses Benchmarks sind somitnicht realistisch. Ein Test zur Kompressionsrate von wirklichkeitsnahen Beispieldatenwurde im Kapitel 3.3 durchgefhrt.

    Die Installation (als root) wurde wie folgt durchgefhrt:

    pkgadd d http : // ge t . opencsw . org /now/opt/csw/bin / pkgu t i l U/opt/csw/bin / pkgu t i l y i bonnie++/usr / sb in /pkgchk L CSWbonnie++ # l i s t f i l e s

    Listing 1: Installation auf OpenIndiana

    pkg i n s t a l l bonnie++

    Listing 2: Installation auf FreeBSD

    aptget i n s t a l l bonnie++

    Listing 3: Installation auf Ubuntu

    Bonnie++ wurde mit folgenden Parametern aufgerufen:

    bonnie++ -d /tank/ -u root -x 1 -z 0 -q -n 1024 bench.csv

    -d /tank/ : Zielverzeichnis, in dem getestet werden soll

    -u root : Wird das Programm als root ausgefhrt, muss diese Option explizit gesetztwerden

    -x 1 : Anzahl der Durchlufe

    -z 0 : Der Seed des Benchmarks ist 0, damit bei jedem Durchlauf die selben Bedin-gungen mit dem selben Seed herschen

    -q : Quiet, keine grafische Ausgabe whrend des Tests

    -n 1024 : Anzahl n der n*1024 zu erstellenden Dateien fr den File Creation Test

    bench.csv : Speichern der Messergebnisse in eine csv-Datei

    Fr jede einzelne Messung mit bonnie++ wurde der ZFS-Pool neu erzeugt und nach derMessung wieder gelscht. Das folgende Listing 4 zeigt den Ausschnitt fr einen Durchlaufunter Ubuntu. Zuerst wird der Pool erstellt und ein Eintrag in die bench.csv gemacht,

    9

  • was gerade getestet wird. Dann werden die jeweiligen Einstellungen vorgenommen, bon-nie++ ausgefhrt und der Pool wieder zerstrt.

    zpoo l c r e a t e tank /dev/sdbecho "atime=ondedup=o f f compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out1 . x l szpoo l des t roy tank

    Listing 4: Installation auf FreeBSD

    Insgesamt wurden 15 Durchlufe gemacht mit folgenden Einstellungen am ZFS-Pool:

    keine Modifikationen

    deaktivieren der atime fr schnelleres lesen (bei allen folgenden Messungen ebenfallsdeaktiviert)

    Deduplikation

    LZ4-Kompression

    LZJB-Kompression

    GZip-Kompression der Stufen 1-9

    Deduplikation & LZJB-Kompression

    2.2. Messergebnisse

    Im Wesentlichen werde ich mich auf die Messergebnisse des neusten Prozessors beschrn-ken, da dieser in der Praxis die hchste Relevanz hat.Die Abbildung 1 zeigt einen neu erstellten Pool ohne zustzliche Modifikationen an.Zu sehen ist ein relativ gleichmiges Ergebnis, in dem alle drei Betriebssysteme in etwa

    gleichauf liegen. Die Schreib- und Leserate entspricht ungefhr der maximal mglichenDatenrate der Festplatte. Lediglich FreeBSD sticht in der Leseleistung heraus und schafftber 20 MB/s mehr Durchsatz. Grnde fr die Unterschiede sind mglicherweise dasunterschiedliche Handling der Daten durch das jeweilige Betriebssystem, da der jngstegemeinsame Vorfahre aller drei Systeme Unix aus den 80er Jahren ist.Ein sehr einfaches Mittel zur mglichen Steigerung der Leseleistung eines Betriebssy-

    stems ist das deaktivieren der atime. Bei einem Lesezugriff auf eine Datei wird nebendem reinen Lesezugriff auch ein Schreibzugriff ntig um den Wert atime mit der aktuel-len Zeit zu aktualisieren. Diese Information nutzen jedoch nur wenige Anwendungen, wiezum Beispiel Mailprogramme. Zustzlich verlangsamt der Schreibprozess in der Theoriedie Leserate. In Abbildung 2 ist daher ein Vergleich der Leseleistung mit aktiviertem unddeaktivierten atime-Parameter.

    10

  • Abbildung 1: System 3, compression=off, dedup=off, atime=on

    Abbildung 2: System 3, compression=off, dedup=off, atime=off

    11

  • Hier fllt auf, dass OpenIndiana durch diese nderung sofort einen Leistungsgewinnvon ber 20 MB/s verzeichnen kann. Auch bei FreeBSD ist ein leichter Leistungsgewinnzu sehen. Ubuntu zieht aus dieser Optimierung keinen Vorteil. Das knnte daran liegen,dass seit Ubuntu 10.04 standardmig der Wert relatime verwendet wird, welcher unn-tige Schreibzugriffe auf den atime-Wert verhindert. Fr die Schreibleistung bringt dieseOptimierung keine Vorteile.Das aktivieren der Kompression kann - je nach Art der Daten - einen enormen Ge-

    schwindigkeitsvorteil bringen. In Abbildung 3 ist die LZ4-Kompression aktiviert. DieserKompressions-Algorithmus wird fr die Verwendung von ZFS als sog. Immer-an-Featurebeworben. Hintergrund ist, dass der Algorithmus eine relativ gute Datenkompression beirelativ geringem CPU-Overhead bietet.

    Abbildung 3: System 3, compression=lz4, dedup=off, atime=off

    Zustzlich zur Kompression durch LZ4 wird bei aktivierter Komprimierung noch einesog. Zero-Length-Elimination vorgenommen. Das bedeutet, dass lange Kolonnen aus Nul-len in der Datei bereits vor der Eigentlichen Kompression zusammengefasst werden. Diesund die gute Komprimierbarkeit der Testdaten von bonnie++ sorgen fr einen deutlichhheren Durchsatz, als der maximal mgliche physikalische Durchsatz der Festplatte. DieAbbildung zeigt, dass beim schreiben Ubuntu den hchsten Durchsatz erzielt, whrendOpenIndiana beim lesen die schnellsten Werte erzielt. Auch der rewrite-Prozess wirddadurch beschleunigt.Die Deduplikation arbeitet auf Block-Basis. Da whrend des Schreibvorgangs die Has-

    hes der Blcke berechnet werden mssen, sinkt entsprechend die Schreibrate, wie inAbbildung 4 zu sehen. Die Leseleistung entspricht im wesentlichen der eines Pools ohneDeduplikation, da der Leseprozess keinerlei Rechenleistung erfordert. Auch hier sind alledrei Betriebssysteme im wesentlichen gleichauf, wobei die Schreibleistung von OpenIn-diana mit Abstand die wenigsten Einbrche zu verzeichnen hat.In der folgenden Abbildung 5 wurden sowohl Kompression und Deduplikation als auch

    12

  • Abbildung 4: System 3, compression=off, dedup=on, atime=off

    atime=off verwendet. Im direkten Vergleich zur darber liegenden Abbildung 4 siehtman, dass die Verhltnisse in etwa gleich bleiben, kombiniert mit einer hheren Datenratedurch die Kompression. Ebenfalls zu sehen ist, dass in jedem der drei Tests ein anderesBetriebssystem das Feld anfhrt, jedoch alle drei insgesamt nahezu gleichauf liegen.

    Abbildung 5: System 3, compression=lz4, dedup=on, atime=off

    Da ZFS verschiedene Kompressions-Algorithmen anbietet, werden diese in den kom-menden drei Abbildungen fr Write (6), ReWrite (7) und Read (8) dargestellt. Den An-fang machen der bereits oben dargestellte LZ4 und LZJB-Algorithmus, welcher gleichzei-tig der aktuelle Standard fr Kompression unter ZFS ist. Danach folgen die verschiedenenStufen von Gzip (1 entspricht der kleinsten Kompression). In allen Fllen war whrend

    13

  • des Benchmarks der Prozessor der Flaschenhals. Whrend die Festplatte reell nur wenigeMB/s Durchsatz hatte, war ein Kern des Prozessors durchgehend auf 100% Auslastung.

    Abbildung 6: System 3, Schreibrate

    Abbildung 7: System 3, ReWrite-Rate

    Zu sehen ist, dass alle drei Systeme sich hnlich verhalten und leistungstechnisch nahbei einander liegen. In der Schreibrate ist Ubuntu fast immer das schnellste System oderzumindest gleichauf mit OpenIndiana. Einzige Ausreier sind die GZip-Stufen 1 bis 3unter OpenIndiana und FreeBSD in der Leseleistung. In den hheren GZip-Stufen hatUbuntu die beste Leserate und FreeBSD eine deutlich schlechtere.

    Vergleich unterschiedlicher Hardware

    Als Ergnzung dazu setze ich zum direkten Vergleich der oben durchgefhrten Bench-marks auf aktueller Hardware noch ein paar ausgewhlte Vergleiche mit lterer Hardwa-re, um die Abhngigkeit von ZFS im allgemeinen und ZFS on Linux im speziellen von

    14

  • Abbildung 8: System 3, Leserate

    leistungsstarker Hardware zu zeigen.Dazu habe ich in Abbildung 9 den Test auf einem LZ4-komprimierten Pool mit einem

    drei Jahre lteren Xeon E3110-Dualcore-Prozessor mit alter Front-Side-Bus-Technologieausgewhlt.

    Abbildung 9: System 1, compression=lz4, dedup=off, atime=off

    Als erstes fllt auf, dass der Prozessor nur rund 66% des Durchsatzes schafft (DieAnzahl der Kerne spielt in diesem Fall keine Rolle, da nur ein Kern den Datenstromkomprimiert). Das Verhltnis der Datenrate bei OpenIndiana und FreeBSD ist zwischendem Xeon E3110 und dem neueren Corei5-2500k nahezu identisch. Anders sieht es al-lerdings bei Ubuntu aus, welches trotz identischer Festplatte und Software eine deutlichschlechtere Leistung aufweist. Einen Grund hierfr konnte ich leider nicht identifizieren,jedoch vermute ich unter ZFS on Linux eine intensivere Nutzung neuerer Funktionen

    15

  • aktueller Prozessoren.Als Vergleich von allen drei Hardwareplattformen kann leider nur ein Kompressions-

    Benchmark herangezogen werden, da in System 2 eine andere Festplatte verwendet wur-de. Da diese bei einem Kompressionstest jedoch nicht der limitierende Faktor ist, sondernder Prozessor, ist dennoch ein Vergleich mglich.

    Abbildung 10: Vergleich von 3 Prozessoren mit LZ4 Kompression

    In Abbildung 10 sind alle drei Prozessorgenerationen mit allen drei Betriebssystemendargestellt. Die Prozessoren sind dabei ihrem Alter bzw. Leistung nach sortiert. hnlichwie bereits oben in Abbildung 9 fr den E3110-Prozessor zeigt sich auch fr den neue-ren Xeon X5677 ein Leistungseinbruch unter Ubuntu. Ebenso ist eine kontinuierlicheSteigerung des Durchsatzes mit modernerer Hardware zu erkennen.

    3. ZFS on Linux

    3.1. Messaufbau

    Im folgenden Kapitel wird ein kurzer Einblick in das Betriebssystem gegeben, welcheProzesse whrend eines Benchmarks auf einem ZFS-Dateisystem wieviel Kapazittenverwenden.Fr eine Analyse von ZoL nutzen wir das bereits in Kapitel 2.1.1 beschriebene System

    3 mit einem Corei5-2500k Prozessor und das in Kapitel 2.1.2 beschriebene Ubuntu 14.04.Fr die Nutzung von wrstat [6] wurde der Kernel bereits vorbereitet und der LOCK_STAT-

    Parameter aktiviert.

    16

  • Als Analyseprogramm nutze ich wrstat [6]. Dieses sammelt whrend des Aufrufs ei-nes Programms Daten ber verschiedene Methoden, wie das /proc-Verzeichnis oder dasProgramm oprofile. Da letzteres Zugriff auf das normalerweise in Linux nicht unkom-primiert vorhandene vmlinux bentigt, muss mit dem in Listing 11 gezeigten Vorgangerst der Debugkernel runtergeladen werden, bevor im zweiten Schritt wrstat mit seinenAbhngigkeiten installiert wird. Die Konfiguration des Programms erfolgt ber die Dateiwrstat.config, welche in der Doku des Programms erklrt wird. Der vollstndige Aufrufvon bonnie++ mit wrstat lautet wir folgt:

    ~/wrstat/wrstat-run ./wr-results/durchlauf-01/ bonnie++ -u root -d /tank/-x 1 -z 0 -q

    In den vier Durchlufen wurden in ZFS folgende Einstellungen verwendet:

    ZFS ohne Optimierungen (Pure)

    LZJB-Kompression

    Deduplikation

    Deduplikation & LZJB-Kompression

    3.2. Messergebnisse

    Betrachten wir fr den ersten Durchlauf ohne Optimierungen zunchst die Auslastungdes Hauptspeichers in Abbildung 11.

    Abbildung 11: ZFS Pure: Hauptspeicherauslastung

    Bonnie++ beginnt mit einem Write-Vorgang, der sich in das schreiben einzelner Datei-en (bis ca. 100 Sekunden) und dem sequentiellen Schreiben unterteilt (bis ca. 200 Sekun-den). Man sieht deutlich die Auswirkungen des ARC (Adjustable Replacement Cache),welcher ein eigenstndiger Cache fr das ZFS-Dateisystem ist. Neben dem schreiben der

    17

  • Daten auf die Festplatte werden alle Daten in diesen Cache geschrieben, der sich imHauptspeicher befindet. Dieser besteht aus zwei Bereichen (Most Frequently Used Fi-les (MFU), Most Recently Used Files MRU)), welche dynamisch ihr Grenverhltnisanpassen. Da unserer Schreibvorgang doppelt so gro ist, wie der zur Verfgung stehen-de RAM, ist dieser Cache erschpft. Da der ARC nur einen fest definierten Anteil vomgesamten RAM verwendet, bleibt ein gewisser Teil von rund 2000 MB frei.

    Abbildung 12: ZFS Pure: Prozessorzustnde

    Abbildung 12 zeigt die Prozessorauslastung bzw. seine Zustnde. Hier sehr man sehrgut, wie der gefllte ARC zur Folge hat, dass die CPU deutlich hufiger auf IO wartenmuss (der iowait-Wert steigt bei Sekunde 100 von Null auf 20% an).

    Abbildung 13: ZFS Pure: Lockverlauf des Verdrngungsprozesses des ARC

    Ist der ARC voll, muss entschieden werden, welche Dateien verdrngt werden. Dader Cache sequentiell mit Daten vollgeschrieben wird, welche nie gelesen werden, spieltder MRU eine grere Rolle und verdrngt den Platz fr MFU. In diesem Fall verhltsich ZFS wie der Cache von ext4, welches ausschlielich auf dem MRU-Prinzip basiert.

    18

  • Abbildung 13 zeigt den Prozess, welcher die meisten Locks whrend der Messung bean-spruchte. Ab dem Zeitpunkt des vollstndig gefllte RAMs werden Locks erstellt. Da dieDatei doppelt so gro wie der RAM ist und sie danach modifiziert und anschlieend ge-lesen wird, ist dieser Prozess bis zum Ende des Benchmarks aktiv. Da dieser Benchmarknur mit einem Datenstrom arbeitet, sind die Auswirkungen auf die Leistung eher gering.Fr viele parallel arbeitende Prozesse werden die beim Zugriff/Modifikation des ARChufig genutzten Locks schnell zu einem Problem, sodass die Leistung mit steigenderAnzahl paralleler Threads wieder zu sinken beginnt [13].

    Abbildung 14: ZFS Kompression: Prozesse mit hoechster Wartezeit auf Locks

    Mit aktiver Kompression sorgen ebenfalls Bestandteile von ZFS fr die meisten Sperren(Abb. 14). Auf Platz 1 liegt vq_lock, welches ein Bestandteil der vdev_queue ist (Abb.15. Diese ist der ZFS i/o scheduler und unterteilt IOs in 5 Klassen: sync read, sync write,async read, async write, und scrub/resilver. Die aktivste Zeit ist whrend der rewrite-Phase.

    Abbildung 15: ZFS Kompression: Lock_Stat Top 1: vdev_queue

    19

  • Auf Platz 2 (Abb. 16 ist die Funktion dn_mtx, welche Bestandteil von dnode_syncin ZFS ist. Dieser dnode-buffer ist verantwortlich fr das schreiben von Blcken. Wirdeine Datei im RAM modifiziert, wird ein dnode_sync ausgefhrt, um sie zu schreiben.Ein dnode ist ein Objekt, zum Beispiel Metadaten. Entsprechend seiner schreibendenFunktion ist es im write und rewrite-Teil aktiv.

    Abbildung 16: ZFS Kompression: Lock_Stat Top 2: dn_mtx

    Der aus dem ersten Durchlauf bekannte ARC belegt Platz drei (Abb. 17.

    Abbildung 17: ZFS Kompression: Lock_Stat Top 3: arc_user_evicts_block

    Somit sind sind ber 60% aller Waittimes durch ZFS verursacht.Insgesamt ist eine hhere System-Auslastung in Abbildung 18 zu sehen. Addiert man

    die System-Teile auf, so erhlt man ca. 100%, was der Vollauslastung eines Kerns ent-spricht. Grund hierfr ist die CPU, welche die Daten komprimiert. Dieser Prozess ist frden sequentiellen Datenstrom von bonnie++ auf einen Thread begrenzt.Bei der Deduplikation erhht sich die iowait-Zeit des Prozessors deutlich, wie in Abb.

    19 zu sehen. Anders als bei den beiden vorangegangenen Durchlufen, werden bei der

    20

  • Abbildung 18: ZFS Kompression: Prozessorauslastung

    Deduplikation zuerst Hashwerte von jedem Datenblock berechnet, welche mit der DDT(DedupTable) abgeglichen werden mssen. Erst dann wird entschieden, ob ein Blockgeschrieben wird oder nur eine Referenz auf einen bereits bestehenden Block erstelltwird.

    Abbildung 19: ZFS Deduplikation: Prozessorauslastung

    21

  • Die meisten Locks werden durch Metadatenarbeit durch dnode_sync verursacht (Abb.20).

    Abbildung 20: ZFS Deduplikation: Haltezeiten fr Locks

    Zum Abschluss spiegelt sich auch in der Kombination aus Deduplikation und Kompres-sion eine Mischung aus den beiden vorangegangenen Tests wider. So ist der idle-Wert derCPU wieder von 35% bei Dedup auf jetzt knapp 50% angestiegen (Abb. 21. Dies ist eineFolge der verringerten Schreiblast durch die vorangegangene Kompression.

    Abbildung 21: ZFS Deduplikation & Kompression: Prozessorauslastung

    Whrend in der Auflistung der Haltezeiten in Abb. 22 der ARC mit unter 2 ms/skaum eine Rolle spielt, ist die Deduplikation mit ber 200 ms/s fr den Groteil derLocks verantwortlich.Die im vorangegangenen Kapitel gezeigten sehr hohen Datenraten sind eine Folge der

    guten Kompression durch den Prozessor. Die Abbildung 23 zeigt die tatschliche Aus-lastung der physikalischen Festplatte an. Da wrstat fr die Festplattenauslastung keineGraphen fr die vorangegangenen Durchlufe erzeugt hat, ist ein direkter Vergleich leider

    22

  • Abbildung 22: ZFS Deduplikation & Kompression: Haltezeiten fr Locks

    nicht mglich. Jedoch ist aus Beobachtungen die Auslastung bei reiner Kompression bzw.Deduplikation hnlich hoch. Lediglich im ersten Test mit dem unmodifizierten ZFS liegtdie Auslastung wie im vorherigen Kapitel in Abbildung 1 auf dem Niveau des tatschlichmglichen Durchsatz.

    Abbildung 23: ZFS Deduplikation & Kompression: Datenrate der getesteten Festplatte

    3.3. Kompression und Deduplikation in der Praxis

    Da gerade die Kompression in den Tests mit bonnie++ sehr stark von der Realittabweichende Kompressionsraten ermglicht, habe ich mit rund 900 GB Testdaten derenKomprimierbarkeit und die Fhigkeit der Deduplikation berprft. Zum Einsatz kamendafr Daten des Max-Planck-Instituts von einem Ozeanmodell (MPIOM). Der Groteilder Daten sind NetCDF und GRIB-Dateien, welche blicherweise bereits vorkomprimiertsind. Neben der Kompression und Deuplizierbarkeit wurde ebenfalls die Laufzeit desKopiervorgangs mit time gemessen, welche sich als nicht unerheblich herausgestellt hat.

    23

  • Die kompletten Resultate sind Anhang unter 15 zu finden.Die erste Messung ohne beide Funktionen ergab eine Laufzeit von 217,5 Minuten,

    wobei eine mittlere Datenrate von 74.88 MB/s erreicht wurde (siehe Tabelle 1. Die Da-tenrate entspricht der Ausgabe des Kopierbefehls rsync. Datenquelle war ein mit 1 GBitangebundener Dateiserver via NFS.

    Tabelle 1: Messung der Laufzeit fr verschiedene OptimierungenOptimierung geschriebene Daten Laufzeit Datenrate Dedup/Comp.

    default 978621 MB 217m30.527s 74.88 MB/s -LZ4 627305 MB 227m10.272s 71.70 MB/s c = 1.56xGZIP 469593 MB 223m58.709s 72.72 MB/s c = 2.08xDedup 978622 MB 491m28.573s 33.14 MB/s d = 1.04x

    Dedup + LZ4 627311 MB 550m51.974s 29,57 MB/s c = 1.54, d = 1.26

    Bei dem zu Grunde liegenden Datensatz war der GZIP-Algorithmus sowohl bei Kom-pressionsrate, als auch Laufzeit dem LZ4-Algorithmus berlegen, was jedoch eher einenAusnahmefall darstellt. Eine eher schlechte Leistung erzielte die Deduplikation. Wh-rend die Laufzeit sich auf mehr als die doppelte Zeit erhht, ist ihr Platzgewinn miteinem Faktor von 1.04 eher gering. Whrend des Kopiervorgangs entstanden hufigerLeerlaufzeiten, in denen weder Daten geschrieben, noch ber das Netzwerk bertragenwurden.Eine genauere Analyse der DedupTable (DDT) ergab, dass der zur Verfgung stehende

    RAM von 12 GB fr eine Datenmenge von rund 900 GB rausreichen sollte. ZFS on Linuxnutzt standardmig nur maximal 50% des zur Verfgung stehenden RAMS. Darausergibt sich eine fr den ARC nutzbare Kapazitt von 6 GB. Die Metadaten, zu denendie DDT gehrt, belegen wiederum nur maximal 25% des ARC, was 1.5 GB entspricht.Der Befehl zdb -b lustre-ost0 gibt mit dem Wert "bp count"die Anzahl der geschriebenenBlcke aus, in diesem Fall 2738958 Blcke. Fr jeden Block werden 320 Byte als Hash-Wert in die DDT geschrieben. Somit ergibt sich eine DDT-Gre von rund 835 MB. Einemgliche Erklrung ist, dass noch weitere Metadaten von ZFS mit der DDT um die 1.5GB konkurrieren und somit fr die DDT auf die langsame Festplatte ausgewichen werdenmuss, was den Vorgang der Deduplizierung enorm verlngert.Teilt man die Anzahl der geschriebenen Bytes durch den Wer "bp counto erhlt man

    die von ZFS geschriebene durchschnittliche Blockgre, in diesem Fall sind das 121K, wasnahe der Maximalgre von 128K liegt. Bei groen Blcken ist die Chance geringer, einenhnlichen Block mit selbem Aufbau zu finden, was die Mglichkeiten der Deduplizierungweiter einschrnkt.Eine mgliche Optimierungsmanahme ist die manuelle Erhhung des vom RAM nutz-

    baren Teils fr den ARC auf 80 oder 90%. Da der ARC so entworfen ist, dass er keinemanderen Systemprozess Speicher wegnimmt, wrde sich bei erhhtem RAM-Verbrauchdurch andere Prozesse der ARC automatisch anpassen und verkleinern.

    24

  • 4. Lustre on ZFS

    4.1. Lustre

    Lustre ist ein POSIX-kompatibles, verteiltes Dateisystem, welches auf Standardhardwareaufbaut und als Open Source Projekt in der Top100 der grten Supercomputer dasmit rund 60% am hufigsten verwendete Dateisystem ist [7]. Eine der aktuell grtenImplementationen ist das Dateisystem Spider des zweitgrten Supercomputers Titan.Auf rund 26.000 Clients wird insgesamt eine Speicherkapazitt von 32 PB Speicher miteiner parallelen Zugriffsgeschwindigkeit von rund 1 TB/s erreicht [12].Luste besteht aus (wie in Abb. 24) drei Komponenten:

    Management-Einheit (MGS)

    (mehrere) Metadatenserver (MDS) mit mehreren Targets (MDT)

    Objektspeicherserver (OSS) mit einem oder mehreren Speichertargets (OST)

    Die Verbindung untereinander kann ber normalen Ethernet-Verbindungen oder Infi-niband erfolgen.

    Abbildung 24: Lustre grundlegender Aufbau, Quelle: http://lustre.org/about/

    Im Gegensatz zu anderen verteilen Dateisystemen, wie GPFS werden die Metadatennur auf einigen wenigen Servern vorgehalten, welche dadurch auf den parallelen Zugriff

    25

    http://lustre.org/about/

  • auf viele kleine Dateien optimiert werden knnen. Die eigentlichen Daten werden dannauf die eigentlichen Fileserver (OSS) verteilt. Hierbei kann ebenfalls festgelegt werden, obeine Datei nur auf einem Server gespeichert werden soll oder ber Mehrere verteilt. ZurSteigerung der Ausfallsicherheit und Datenintegritt knnen auch mehrere OSS auf das-selbe OST zugreifen (analog dazu MDS/MDT), siehe Abb. 24. Als OST knnen einzelneFestplatten oder Speicherverbnde, wie RAID eingesetzt werden.Als lokales Dateisystem auf einem OST wird typischerweise das hauseigene ldiskfs ein-

    gesetzt, welches eine Weiterentwicklung des ext4-Dateisystems von Linux ist. WenigeWochen nach dem stable-release von ZFS on Linux wurde ZFS als Alternative zu ldiskfsin der Version 2.4 von Lustre als zweites mgliches Dateisystem aufgenommen, um vondessen Vorteilen profitieren zu knnen. So kann neben den oben beschriebenen besserenDatenintegritt von ZFS gegenber klassischen RAID-Verbnden und Dateisystemenauch je nach zu speichernden Daten eine erhebliche Einsparung von Speicherplatz durchdie transparente Datenkompression in ZFS ermglicht werden, was zu effizienterer Nut-zung der vorhandenen Hardware und dem einsparen von Kosten fhrt. ZFS untersttztschnelle Kompressionsalgorithmen, wie LZ4, welche mit nur wenig CPU-Overhead aus-kommen und somit auch auf bisher mit ldiskfs betriebenen Servern zum Einsatz kommenkann.Auch Metadatenserver knnen von ZFS profitieren. Hier finden vorrangig Zugriffe mit

    kleinen Blockgren statt. Werden Daten hufig abgefragt, werden sie von ZFS im sog.Adjustable Replacement Cache (ARC) abgelegt. Dieser ist eine Mischung aus dem unterLinux verwendeten MRU-Cache-Algorithmus (Most Recent Used) und dem MFU-Cache-Algorithmus (Most Frequently Used). Diese Aufteilung ermglicht sowohl ein cachenhufig zugegriffener, als auch neu zugegriffener Dateien. Als Erweiterung es ARC kannauch ein weiteres schnelles Speichermedium, wie eine SSD, als L2ARC genutzt werden.Fr das schreiben kleiner Datenblcke kann ebenfalls auf einer SSD ein Write-Log (dassog. SLOG) genutzt werden. Das darauf befindliche ZIL (ZFS Intend Log) kann beimhufigen schreiben kleiner Datenblcke (Default: 64 KB) einen Geschwindigkeitszuwachsbringen [14]. Ist kein separates SLOG-Device vorhanden, wird das ZIL mit in den ZFS-Pool geschrieben, was fr Leistungsprobleme beim schreiben sorgen kann (siehe Kapitel4 bzw. [11]).

    4.2. Messaufbau

    Lustre wurde auf einem Setup aus drei baugleichen Servern installiert. Jeder Server hateinen Xeon X5560 Prozessor mit 4 Kernen und 8 Threads, 12 GB RAM und je einer500 GB Systemfestplatte und einer fr Lustre/ZFS freien 2 TB Festplatte. Die Verbin-dung untereinander erfolgt mit einem 1 GBit-Uplink an einen gemeinsamen Switch. AlsBetriebssystem wurde CentOS Linux release 7.2.1511 (Core) verwendet mit folgenderKernel-Version:Linux nehalem1.cluster 3.10.0-327.4.5.el7.x86_64 #1 SMP Mon Jan 25 22:07:14

    UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

    Die Installation von Lustre und ZFS erfolgte wie im Listing 12. Wichtig hierbei ist die

    26

  • Deaktivierung von SELinux am Ende des Prozesses.Das erstellen der MGS, MDS und OSS wurde wie in Listing 13 durchgefhrt. Da die

    Management-Einheit und der Metadatenserver in diesem kleinen Testsetup nur wenigLeistung bentigen, wurden sie in 1 GB groe ZFS-pools in eine Datei in /tmp aufnehalem1 gespeichert. Jeder der drei Server hat die freie 2 TB Festplatte als OST0 bisOST2 als Speicherplatz verwendet. Damit der Prozess Lustre beim Start die jeweiligenPools auch einbinden kann, ist die Konfiguration der Datei /etc/ldev.conf wichtig. DieDatei wird geparst und alle Eintrge mit dem eigenen Hostnamen gemountet. Die anderenEintrge werden ignoriert. Zum Schluss wird Lustre gestartet und eingehngt. Der Befehllfs setstripe -c -1 sorgt dafr, dass eingehende Dateien gleichmig auf alle OSTs verteiltgeschrieben werden.

    4.2.1. verwendete Benchmarks

    Als Benchmark kamen bonnie++ fr einen einfachen Test von einem Host (nehalem1)aus zum Einsatz, sowie das parallel von allen drei Hosts ausgefhrte Programm ior. DieInstallation von ior erfolgte wie im Listing 14. Da es parallel ausgefhrt wird, muss zu-erst MPICH installiert werden. Zum laden der MPI-Pfade mssen bei jedem Login in dieShell die folgenden zwei Befehle ausgefhrt werden:

    export PATH=/lustre/software/mpich3/bin:$PATHexport LD_LIBRARY_PATH=/lustre/software/mpich3/lib:${LD_LIBRARY_PATH}

    Der Aufruf von bonnie++ erfolgte hnlich wie in den vorangegangenen Messungen. Eswurde lediglich auf den Parameter -n 1024 verzichtet.

    bonnie++ -d /mnt/lustre/client/ -u root -x 1 -z 0 -q bench.csv

    Ior wurde parallel mit Hilfe von mpiexec aufgerufen:

    mpiexec hosts=nehalem1,nehalem2,nehalem3 -np 6 /lustre/software/ior/bin/ior-v -F -t 1m -b 24g -o /mnt/lustre/client/testfile ior-out.txt

    -hosts: Auflistung aller genutzten Hosts

    -np 6 : Anzahl der ausgefhrten Instanzen von ior (zwei Pro Host)

    -v : Verbose

    -F : Zugriffsart file-per-process

    -t 1m: transferSize 1 Megabyte

    -b 24g : Dateigre fr den Test (entspricht doppelter Menge des RAM eines Hosts)

    -o /mnt/lustre/client/testfile: Testpfad auf das Lustre-Laufwerk

    27

  • 4.3. Ergebnisse

    Da bonnie++ auf einem Host ausgefhrt wird, aber auf drei Hosts die Daten gespeichertwerden, teilen sich die Schreibzugriffe auf eine lokale Festplatte auf und zwei ber dasNetzwerk angebundene OSTs. Da diese nur ber 1 GBit Netzwerkuplink erreichbar sind,ist die Datenrate hier durch das Netzwerk begrenzt. Abbildung 25 zeigt die verschiedenenAusfhrungen von bonnie++, whrend die Einstellungen fr ZFS nach jedem Durchlaufverndert wurden (siehe X-Achse).

    Abbildung 25: Bonnie++ Benchmark auf Lustre auf ZFS-Basis

    Da die Daten gleichmig auf alle drei OSTs geschrieben werden, sind die Zugriffeauf das lokale Laufwerk schneller abgearbeitet, als die entfernten OSTs. Daher ist auchunabhngig von Kompression und Deduplikation schnell ein maximales Durchsatzlimiterreicht. Das Problem an dieser Stelle ist, dass die Daten unkomprimiert ber das Trans-portnetz gesendet werden und erst auf der lokalen Festplatte durch ZFS komprimiertwerden knnen.Abbildung 26 zeigt Die Auslastung von Netzwerk und Festplatte auf dem Host, auf

    dem der Benchmark ausgefhrt wird. Hier sieht man die Aufteilung der write, rewriteund read-Teile des Benchmarks und den anschlieenden Test zum erstellen und lschenvon Dateien. Whrend die lokale Festplatte dank Kompression in allen Teilen nur sehrwenig tatschlichen Durchsatz hat (es werden nur die bereits komprimierten Daten ge-schrieben), ist das Netzwerk der limitierende Faktor. Mit dem LZ4-Algorithmus kannZFS die Testdateien von bonnie++ um den Faktor 115x verkleinern.Im Vergleich dazu sieht man in Abbildung 27 das hier wahrscheinlich Lustre der brem-

    sende Faktor ist, da weder die Festplatte voll ausgelastet ist, noch die Netzwerkverbin-dung gesttigt ist (auer zum Ende des Lesetests).Die folgende Abbildung 28 zeigt analog zu dem bonnie++ Benchmark das Verhalten

    28

  • Abbildung 26: Netzwerk- und Festplattenauslastung auf nehalem1 whrend eines bon-nie++ Durchlaufs mit aktivierter Kompression

    Abbildung 27: Netzwerk- und Festplattenauslastung auf nehalem1 whrend eines bon-nie++ Durchlaufs ohne Kompression

    29

  • des Systems mit verschiedenen ZFS-Parametern fr Kompression und Deduplikation.Wie erwartet ist der Durchsatz von LZ4 am hchsten, gefolgt von LZJB und GZip. Mitior wurden von allen drei Hosts aus jeweils zwei ior-Instanzen mit einer Dateigre von24 GB geschrieben bzw. gelesen, was 144 GB Gesamtdaten entspricht. Die Testdaten vonior lassen sich von ZFS mit dem LZ4-Algorithmus nur um den Faktor 3.9 komprimieren,weshalb diese Messwerte ein fr die Praxis realistischeres Ergebnis zur Folge haben (900GB Testdaten auf dem wr-Cluster konnten mit LZ4 um den Faktor 1.51, mit GZip-6 um2,03 komprimiert werden 15.

    Abbildung 28: Ior-Benchmark auf Lustre auf ZFS-Basis

    Fr die Auslastung der Festplatte und des Netzwerks habe ich parallel zum bonnie++-Durchlauf die Auslastung der beiden Komponenten mit und ohne LZ4-Kompression mitdem Analyseprogramm sar aufgezeichnet separat aufgezeichnet und in einer Grafik zu-sammengefasst. Abbildung 29 zeigt den Verlauf bei aktiver Kompression. Ior fhrt zu-erst einen Schreibtest aller Daten und anschlieend einen Lesetest durch, was auch ander Zweiteilung des Graphen in der Mitte zu erkennen ist, an der die blaue Linie (HDDread) und die rote Linie (HDD write) sich abwechseln.Die anfngliche Schreibrate der Festplatte (rote Linie) zeigt, dass durch die schlechte-

    re Komprimierbarkeit der Testdaten eine erhhte Schreiblast vorhanden ist. Auerdemmssen neben den zwei lokalen Schreibprozessen auch die vier ber das Netzwerk ankom-menden Datenstrme geschrieben werden. Wie die starken Zacken der Kurven andeuten,gab es keine gleichmige Auslastung der Netzwerkverbindung und insgesamt gleich eseher einem Burst-Traffic. Es gibt ebenfalls einen direkten Zusammenhang zwischen Aus-lastung der Festplatte und der Netzwerkverbindung. Laut dem Linux-Programm iotop istwhrend einer Phase mit geringer Datenrate die IO-Auslastung des Prozesses txg_sync

    30

  • sehr hoch. Ein voller ARC-Cache von ZFS kann eine mgliche Ursache sein. [5] Abhilfeknnte mehr Hauptspeicher im jeweiligen System oder ein schneller L2ARC sein, zumBeispiel auf einer SSD.Abbildung 30 zeigt den selben Ablauf ohne Kompression. Hier treten die Bursts in

    Netzwerk und Festplatte schon auf, bevor der ARC den vollstndigen RAM belegt hat.Durch die Glttung durch das 20-Sekunden-Messintervall fallen diese jedoch nur durchkleinere Zacken besonders in der ersten Hlfte des Graphen auf. Eine mgliche Erkl-rung ist die strkere Auslastung der Festplatte. Da diese sechs Datenstrme gleichzeitigverarbeiten muss und durch fehlende Kompression die vollen Daten geschrieben werdenmssen, ist das Netzwerk erst whrend der Lesephase wirklich nennenswert ausgelastet,whrend der Prozessor auf Grund fehlender Kompression keine Arbeit zu verrichten hat.Whrend der Lesephase hatte die CPU eine iowait-Zeit von rund 30%.

    5. Zusammenfassung

    Vor knapp drei Jahren wurde die ZFS-Portierung ZFS on Linux als stable-release verf-fentlicht und fr die Verwendung in Produktivsystemen freigegeben. Zu diesem Zeitpunktgab es noch eine kleine Anzahl an Funktionen, die ZoL im Gegensatz zum originalen ZFSunter Illumos noch nicht beinhaltete. Mit der aktuellen Version soll dieser Unterschiedaufgehoben sein. Es gibt jedoch auch Funktionen, wie Improve N-way mirror read per-formance, die ausschlielich in FreeBSD implementiert sind [9]. Leistungstechnisch stehtdie Linux-Version dem Original gleichauf, was die Messergebnisse in Kapitel 2 ebenfallsuntermauern. Dort ist zu sehen, dass die ZFS-Versionen in unterschiedlichen Bereichenverschieden stark sind und kein eindeutiger Erster hervorgeht.Eine genauere Betrachtung zeigt, dass ZoL sich sehr hnlich wie sein Vorbild verhlt

    und die Arbeiten auf dem ARC mit sehr vielen Locks verrichtet. Diese kann bei starkerparalleler Belastung zu Performanceeinbrchen fhren.Kapitel 4 zeigt, dass ZFS auch als Basis fr Lustre eine gute Alternative zu ldiskfs

    darstellt, da es wartungsrmer ist als ein Verbund aus Dateisystem, Volumemanager undRAID-Verbund und dank transparenter Kompression eine (je nach Nutzdaten) deut-lich effizientere Auslastung der Hardware ermglicht. Notwendig hierfr ist lediglich eindurchschnittlicher Prozessor und mglichst viel RAM, den ZFS mit ARC als Cache nutzt.Seit der Verffentlichung ist die Nutzung von ZoL stetig angestiegen. Bereits kurze

    Zeit spter konnte das parallele Dateisystem Lustre auch ZFS als lokales Dateisystemnutzen und auch kommerzielle Produkte, wie SoftNAS oder die VirtualisierungsplattformProxmox, nutzen ZoL als Basis.Die leichte Verwaltung der Speicherpools, ebenso wie Snapshots, begnstigen das Zu-

    sammenspiel von ZFS mit Linux-Containerisierung, wie Docker.Nicht zuletzt die Funktionen, wie transparente Kompression, Deduplikation, Copy-

    on-Write und eine hohe Datenintegritt machen ZFS zu einem modernen Dateisystem,welches klassische Dateisysteme und RAID-Verbnde ablsen knnte.

    31

  • Abbildung 29: Netzwerk- und Festplattenauslastung auf nehalem1 whrend eines iorDurchlaufs mit Kompression

    Abbildung 30: Netzwerk- und Festplattenauslastung auf nehalem1 whrend eines iorDurchlaufs ohne Kompression

    32

  • A. Scripte

    A.1. Installation von ZFS unter Linux mit modifiziertem Kernel

    sudo aptget i n s t a l l bui lde s s e n t i a l gawk a l i e n f ake roo t \l inuxheaders$ (uname r ) autoconf l i b t o o l z l i b1gdev \uuiddev l i bb l k i ddev l i b s e l i n u xdev g i t l i b a t t r 1dev

    g i t c l one https : // g i t hu b . com/ z f s o n l i n u x / s p l . g i tg i t c l one https : // g i t hu b . com/ z f s o n l i n u x / z f s . g i tcd sp l. / autogen . sh. / c on f i gu r emake debu t i l s debkmodsudo dpkg i . debcd . . / z f s. / autogen . sh. / c on f i gu r emake debu t i l s debkmodsudo dpkg i . deb

    Listing 5: Installation von ZFS unter Ubuntu

    sudo aptget i n s t a l l l inuxsource bui lde s s e n t i a l kerne lpackagemkdir k e rne lcd ke rne lta r xv j f / usr / s r c / l inuxta r . bz2cd l inuxsource cp /boot/ con f ig uname r . c on f i gnano . c on f i g

    # Ze i l e CONFIG_LOCK_STAT=y einkommentieren , mit =y ergaenzenyes "" | make o l d c on f i gmakekpkg i n i t r d bui ldpackagecd . .sudo dpkg i l inuximage 3 .5 . 7 . 7_3. 5 . 7 . 7 10 . 0 0 . Custom_i386 . debsudo i n i t 6

    Listing 6: Linux Kernel patchen

    cd sp l. / autogen . sh. / c on f i gu r emake debu t i l s debkmodsudo dpkg i . debcd . . / z f snano META

    33

  • #Change L icense from CDDL to GPL, needed f o r compi l ing \ZFS with CONFIG_LOCK_STAT=y in Kernel

    nano include/ l i nux /vfs_compat . h#In Z e i l e Z e i l e 128 :#i fndef HAVE_SET_NLINK > #i fde f HAVE_SET_NLINK

    ./ autogen . sh

    . / c on f i gu r emake debu t i l s debkmodsudo dpkg i . deb

    Listing 7: erneute Installation von ZFS fr den modifizierten Kernel

    A.2. Benchmark-scripte fr Bonnie++

    #! / bin /bashzpoo l c r e a t e tank c3t1d0echo "atime=ondedup=o f f compress ion=o f f " >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################1/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankecho "atime=o f f dedup=o f f compress ion=o f f " >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################2/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=o f f " >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################3/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=l z 4 tankecho "atime=o f f dedup=o f f compress ion=l z 4 " >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tank

    34

  • echo "#######################4/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=l z j b tankecho "atime=o f f dedup=o f f compress ion=l z j b " >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################5/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip1 tankecho "atime=o f f dedup=o f f compress ion=gzip1" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################6/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip2 tankecho "atime=o f f dedup=o f f compress ion=gzip2" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################7/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip3 tankecho "atime=o f f dedup=o f f compress ion=gzip3" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################8/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip4 tankecho "atime=o f f dedup=o f f compress ion=gzip4" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################9/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip5 tank

    35

  • echo "atime=o f f dedup=o f f compress ion=gzip5" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################10/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip6 tankecho "atime=o f f dedup=o f f compress ion=gzip6" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################11/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip7 tankecho "atime=o f f dedup=o f f compress ion=gzip7" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################12/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip8 tankecho "atime=o f f dedup=o f f compress ion=gzip8" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################13/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=gzip9 tankecho "atime=o f f dedup=o f f compress ion=gzip9" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csvzpoo l des t roy tankecho "#######################14/15"zpoo l c r e a t e tank c3t1d0z f s s e t atime=of f tankz f s s e t compress ion=on tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=on" >> bench . csv/opt/csw/ sb in /bonnie++ d /tank/ u root x 1 z 0 q n 1024 >>

    bench . csv

    36

  • zpoo l des t roy tankecho " f i n i s h "

    Listing 8: Benchmarkscript fr OpenIndiana

    #! / bin /bashzpoo l c r e a t e tank ada1echo "atime=ondedup=o f f compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################1/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankecho "atime=o f f dedup=o f f compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################2/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################3/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=l z 4 tankecho "atime=o f f dedup=o f f compress ion=l z 4 " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################4/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=l z j b tankecho "atime=o f f dedup=o f f compress ion=l z j b " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################5/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip1 tankecho "atime=o f f dedup=o f f compress ion=gzip1" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tank

    37

  • echo "#######################6/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip2 tankecho "atime=o f f dedup=o f f compress ion=gzip2" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################7/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip3 tankecho "atime=o f f dedup=o f f compress ion=gzip3" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################8/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip4 tankecho "atime=o f f dedup=o f f compress ion=gzip4" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################9/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip5 tankecho "atime=o f f dedup=o f f compress ion=gzip5" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################10/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip6 tankecho "atime=o f f dedup=o f f compress ion=gzip6" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################11/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip7 tankecho "atime=o f f dedup=o f f compress ion=gzip7" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################12/15done"zpoo l c r e a t e tank ada1

    38

  • z f s s e t atime=of f tankz f s s e t compress ion=gzip8 tankecho "atime=o f f dedup=o f f compress ion=gzip8" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################13/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=gzip9 tankecho "atime=o f f dedup=o f f compress ion=gzip9" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho "#######################14/15done"zpoo l c r e a t e tank ada1z f s s e t atime=of f tankz f s s e t compress ion=on tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=on" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csvzpoo l des t roy tankecho " f i n i s h "

    Listing 9: Benchmarkscript fr FreeBSD

    #! / bin /bashzpoo l c r e a t e tank /dev/sdbecho "atime=ondedup=o f f compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out1 . x l szpoo l des t roy tankecho "#######################1/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankecho "atime=o f f dedup=o f f compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out2 . x l szpoo l des t roy tankecho "#######################2/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=on tankecho "atime=o f f dedup=o f f compress ion=on" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csv

    39

  • i ozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out3 . x l szpoo l des t roy tankecho "#######################3/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=o f f " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out4 . x l szpoo l des t roy tankecho "#######################4/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=l z 4 tankecho "atime=o f f dedup=o f f compress ion=l z 4 " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out5 . x l szpoo l des t roy tankecho "#######################5/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=l z j b tankecho "atime=o f f dedup=o f f compress ion=l z j b " >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out6 . x l szpoo l des t roy tankecho "#######################6/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip1 tankecho "atime=o f f dedup=o f f compress ion=gzip1" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out7 . x l szpoo l des t roy tankecho "#######################7/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip2 tankecho "atime=o f f dedup=o f f compress ion=gzip2" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out8 . x l szpoo l des t roy tankecho "#######################8/16done"zpoo l c r e a t e tank /dev/sdb

    40

  • z f s s e t atime=of f tankz f s s e t compress ion=gzip3 tankecho "atime=o f f dedup=o f f compress ion=gzip3" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out9 . x l szpoo l des t roy tankecho "#######################9/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip4 tankecho "atime=o f f dedup=o f f compress ion=gzip4" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b outa . x l szpoo l des t roy tankecho "#######################10/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip5 tankecho "atime=o f f dedup=o f f compress ion=gzip5" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b outb . x l szpoo l des t roy tankecho "#######################11/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip6 tankecho "atime=o f f dedup=o f f compress ion=gzip6" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b outc . x l szpoo l des t roy tankecho "#######################12/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip7 tankecho "atime=o f f dedup=o f f compress ion=gzip7" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b outd . x l szpoo l des t roy tankecho "#######################13/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip8 tankecho "atime=o f f dedup=o f f compress ion=gzip8" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csv

    41

  • i ozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b oute . x l szpoo l des t roy tankecho "#######################14/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=gzip9 tankecho "atime=o f f dedup=o f f compress ion=gzip9" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b out f . x l szpoo l des t roy tankecho "#######################15/16done"zpoo l c r e a t e tank /dev/sdbz f s s e t atime=of f tankz f s s e t compress ion=on tankz f s s e t dedup=on tankecho "atime=o f f dedup=on compress ion=on" >> bench . csvbonnie++ d /tank/ u root x 1 z 0 q n 1024 >> bench . csviozone Mce a s 1g f / tank/ f i l e i 0 i 1 i 2 b outg . x l szpoo l des t roy tankecho " f i n i s h "

    Listing 10: Benchmarkscript fr Ubuntu

    #DebugKernel i n s t a l l i e r e n fu e r o p r o f i l ecodename=$ ( l s b_re l e a s e c | awk { p r i n t $2 } )sudo tee / e t c /apt/ sour c e s . l i s t . d/ddebs . l i s t

  • ln s /home/ s t o e r t eb ek e r /wrstat /wrstatrun / usr / local /bin /wrstatcp wrstat /wrstat . c on f i g . template wrstat /wrstat . c on f i gnano wrstat /wrstat . c on f i g #Pfade fu e r vmlinux und b i n a r i e s f u e r

    e igenen Kernel ergaenzenopro f i l e_vml inux / usr / l i b /debug/boot/vmlinux3.13.068

    g en e r i cop ro f i l e_mi s s i ng_b ina r i e s / l i b /modules /3.13.068 g ene r i c

    / ke rne l /i n s t a l l http : // source f o r g e . net / p r o j e c t s /numpy/ f i l e s / ( download ,

    danach : python se tup . py i n s t a l l )i n s t a l l http : // gnuplotpy . s ou r c e f o r g e . net / ( download , danach :

    python se tup . py i n s t a l l )sudo aptget i n s t a l l gnuplotx11

    Listing 11: Installation von wrstat und Abhaenigkeiten

    yum y g r o up i n s t a l l "DevelopmentTools "yum y i n s t a l l xmlto a s c i i d o c e l f u t i l s l i b e l f deve l z l i bdeve l

    b i nu t i l sdeve l newtdeve l pythondeve l hmaccalc per lExtUti l sEmbed bison e l f u t i l s deve l auditl i b sdeve l

    yum y i n s t a l l q u i l t l i b s e l i n u xdeve lg i t c l one g i t : // g i t . hpdd . i n t e l . com/ f s / l u s t r er e l e a s e . g i tcd l u s t r er e l e a s e /sh . / autogen . shyum y upgraderebootcd l u s t r er e l e a s e /yum y i n s t a l l pythondo c u t i l s. / c on f i gu r e d i sab l e l d i s k f smake rpmsyum y l o c a l i n s t a l l nogpgcheck https : //download . f e d o r a p r o j e c t .

    org /pub/ ep e l /7/x86_64/e/ epe lr e l ea s e 75.noarch . rpmyum y l o c a l i n s t a l l nogpgcheck http : // arch i v e . z f s o n l i n u x . org /

    ep e l / z f sr e l e a s e . e l 7 . noarch . rpmyum y i n s t a l l z f sdkms l i b z f s 2deve lcd /var / l i b /dkms/ sp l / 0 . 6 . 5 . 3 / source /. / c on f i gu r emakecd /var / l i b /dkms/ z f s / 0 . 6 . 5 . 3 / source /yum y i n s t a l l l i buu iddeve l. / c on f i gu r emakecd ~/ lu s t r er e l e a s e /

    43

  • . / c on f i gu r e d i sab l e l d i s k f smake rpmsyum y i n s t a l l s g3_ut i l s expect a t t r l s o fmkdir c l i e n tmv c l i e n t . rpm c l i e n trpm Uvh . x86_64 . rpm

    Listing 12: Installation von Lustre on ZFS auf CentOS 7

    #nehalem1 . c l u s t e r :mkfs . l u s t r e mgs back f s type=z f s devices i z e 1310720 l u s t r e

    mgs/mgs /tmp/ lu s t r emgsmkfs . l u s t r e mdt back f s type=z f s devices i z e 1310720 index

    =0 fsname=z f s l u s mgsnode=nehalem1@tcp l u s t r emdt0/mdt0 /tmp/ lu s t r emdt0

    mkfs . l u s t r e os t back f s type=z f s index=0 fsname=z f s l u s mgsnode=nehalem1@tcp l u s t r eost0 / ost0 /dev/sdb

    #nehalem2 . c l u s t e r :mkfs . l u s t r e os t back f s type=z f s index=1 fsname=z f s l u s

    mgsnode=nehalem1@tcp l u s t r eost1 / ost0 /dev/sdb#nehalem3 . c l u s t e r :mkfs . l u s t r e os t back f s type=z f s index=2 fsname=z f s l u s

    mgsnode=nehalem1@tcp l u s t r eost2 / ost0 /dev/sdb

    #auf a l l e n d r e i Nodes :nano / e tc / ldev . confnehalem1 . c l u s t e r mgs z f s : l u s t r emgs/mgsnehalem1 . c l u s t e r mdt0 z f s : l u s t r emdt0/mdt0nehalem1 . c l u s t e r ost0 z f s : l u s t r eost0 / ost0nehalem2 . c l u s t e r ost1 z f s : l u s t r eost1 / ost0nehalem3 . c l u s t e r ost2 z f s : l u s t r eost2 / ost0

    sy s t emct l s t a r t l u s t r emkdir p /mnt/ l u s t r e / c l i e n tmount t l u s t r e nehalem1 . c l u s t e r : / z f s l u s /mnt/ l u s t r e / c l i e n tl f s s e t s t r i p e c 1 /mnt/ l u s t r e / c l i e n t /

    Listing 13: Einrichtung der Targets fuer Lustre

    yum i n s t a l l gcc gccg f o r t r an gccc++mkdir / l u s t r e / so f tware

    44

  • cd / l u s t r e / so f tware /wget http : //www. mpich . org / s t a t i c /downloads /3.2/mpich3.2. t a r . gzta r xz f mpich3.2 . ta r . gzmkdir / l u s t r e / so f tware /mpich3cd mpich3.2. / c on f i gu r e p r e f i x=/ l u s t r e / so f tware /mpich3/makemake i n s t a l l

    cd / l u s t r e / so f tware /yum y i n s t a l l g i tg i t c l one https : // g i t hu b . com/chaos / i o r . g i tmv ior i o r_srcmkdir / l u s t r e / so f tware / iorcd io r_src /. / boots t rap. / c on f i gu r e p r e f i x=/ l u s t r e / so f tware / ior /makemake i n s t a l l

    Listing 14: Installation von MPICH und ior

    ##########default :s ent 1024786032326 bytes r e c e i v ed 110338 bytes 78518648.64

    bytes / sect o t a l s i z e i s 1024660531722 speedup i s 1 .00

    r e a l 217m30.527 suser 133m42.304 ssys 68m23.729 s

    du s BM 978621MTotal d i sk usage : 0 . 9 TiB Apparent s i z e : 0 . 9 TiB Items :

    5902

    #########LZ4sent 1024786032326 bytes r e c e i v ed 110338 bytes 75183312.62

    bytes / sect o t a l s i z e i s 1024660531722 speedup i s 1 .00

    r e a l 227m10.272 suser 133m11.690 ssys 68m3.047 s

    45

  • du s BM 627305MTotal d i sk usage : 612 .6 GiB Apparent s i z e : 0 . 9 TiB Items :

    5902

    ########GZIPsent 1024786032326 bytes r e c e i v ed 110338 bytes 76257479.83

    bytes / sect o t a l s i z e i s 1024660531722 speedup i s 1 .00

    r e a l 223m58.709 suser 111m13.986 ssys 60m11.878 s

    du s BM 469593MTotal d i sk usage : 458 .6 GiB Apparent s i z e : 0 . 9 TiB Items :

    5902

    ########Dedupsent 1024786032326 bytes r e c e i v ed 110338 bytes 34750882.27

    bytes / sect o t a l s i z e i s 1024660531722 speedup i s 1 .00

    r e a l 491m28.573 suser 133m56.572 ssys 68m37.262 s

    du s BM 978622MTotal d i sk usage : 0 . 9 TiB Apparent s i z e : 0 . 9 TiB Items :

    5902DedupFaktor : 1 .22######## Dedup + LZ4sent 1024786032326 bytes r e c e i v ed 110338 bytes 31004799.72

    bytes / sect o t a l s i z e i s 1024660531722 speedup i s 1 .00

    r e a l 550m51.974 suser 128m27.895 ssys 67m45.197 s

    du s BM 627311MTotal d i sk usage : 612 .6 GiB Apparent s i z e : 0 . 9 TiB Items :

    5902Kompression : 1 ,54

    46

  • DedupFaktor : 1 .26

    Listing 15: Kompressionstest mit Beispieldaten aus dem wr-Cluster

    47

  • Literatur

    [1] admin-magazin.de: ZFS fr Linux einsatzbereit. 2106. url: http://www.admin-magazin.de/News/ZFS-fuer-Linux-einsatzbereit.

    [2] DE Wikipedia: ZFS. 2016. url: https://de.wikipedia.org/wiki/ZFS_%28Dateisystem%29.

    [3] EN Wikipedia: ZFS. 2016. url: https://en.wikipedia.org/wiki/ZFS.

    [4] Explaining Bonnie++. 2016. url: http://www.orangefs.org/trac/orangefs/wiki/ExplainBonnie.

    [5] Github: Stuck txg_sync process, and IO speed issues when ARC is full. 2012. url:https://github.com/zfsonlinux/zfs/issues/3235.

    [6] https://github.com/bolek42/wrstat. 2016. url: https://github.com/bolek42/wrstat.

    [7] Lustre Version 2.4 Released. 2016. url: http://opensfs.org/press-releases/lustre-file-system-version-2-4-released/.

    [8] Hajo Mller. Leistungsanalyse von ZFS on Linux. 2016.

    [9] OpenZFS: Features. 2016. url: http://open-zfs.org/wiki/Features.

    [10] pro-linux.de: Update, aktueller Stand von ZoL. 2104. url: http://www.pro-linux.de/news/1/21509/aktualisierung-der-stand-von-zfs-fuer-linux.html.

    [11] Slow performance due to txg_sync for ZFS 0.6.3 on Ubuntu 14.04. url: http://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04.

    [12] Spider: The center wide file system. 2016. url: https://www.olcf.ornl.gov/kb_articles/spider-the-center-wide-lustre-file-system/.

    [13] Prakash Surya. OpenZFS: Reducing ARC Lock Contention. 2015.

    [14] ZFS Administration, Part III- The ZFS Intent Log. 2012. url: https://pthree.org/2012/12/06/zfs-administration-part-iii-the-zfs-intent-log/.

    [15] ZFS Compile Workaround. 2016. url: https://github.com/zfsonlinux/zfs/issues/2824.

    [16] ZFS Tuning Guide. 2016. url: https://wiki.freebsd.org/ZFSTuningGuide#Deduplication.

    48

    http://www.admin-magazin.de/News/ZFS-fuer-Linux-einsatzbereithttp://www.admin-magazin.de/News/ZFS-fuer-Linux-einsatzbereithttps://de.wikipedia.org/wiki/ZFS_%28Dateisystem%29https://de.wikipedia.org/wiki/ZFS_%28Dateisystem%29https://en.wikipedia.org/wiki/ZFShttp://www.orangefs.org/trac/orangefs/wiki/ExplainBonniehttp://www.orangefs.org/trac/orangefs/wiki/ExplainBonniehttps://github.com/zfsonlinux/zfs/issues/3235https://github.com/bolek42/wrstathttps://github.com/bolek42/wrstathttp://opensfs.org/press-releases/lustre-file-system-version-2-4-released/http://opensfs.org/press-releases/lustre-file-system-version-2-4-released/http://open-zfs.org/wiki/Featureshttp://www.pro-linux.de/news/1/21509/aktualisierung-der-stand-von-zfs-fuer-linux.htmlhttp://www.pro-linux.de/news/1/21509/aktualisierung-der-stand-von-zfs-fuer-linux.htmlhttp://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04http://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04http://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04https://www.olcf.ornl.gov/kb_articles/spider-the-center-wide-lustre-file-system/https://www.olcf.ornl.gov/kb_articles/spider-the-center-wide-lustre-file-system/https://pthree.org/2012/12/06/zfs-administration-part-iii-the-zfs-intent-log/https://pthree.org/2012/12/06/zfs-administration-part-iii-the-zfs-intent-log/https://github.com/zfsonlinux/zfs/issues/2824https://github.com/zfsonlinux/zfs/issues/2824https://wiki.freebsd.org/ZFSTuningGuide#Deduplicationhttps://wiki.freebsd.org/ZFSTuningGuide#Deduplication

    EinleitungZFS Entwicklung und GeschichteFunktionen von ZFS

    ZFS im Vergleichverwendete KomponentenHardwareBetriebssystemeBenchmarks

    Messergebnisse

    ZFS on LinuxMessaufbauMessergebnisseKompression und Deduplikation in der Praxis

    Lustre on ZFSLustreMessaufbauverwendete Benchmarks

    Ergebnisse

    ZusammenfassungScripteInstallation von ZFS unter Linux mit modifiziertem KernelBenchmark-scripte fr Bonnie++

Recommended

View more >