ZFS vs. Btrfs – Next-generation bestandssystemen in de bedrijfswereld

ZFS wordt door zijn aanhangers beschreven als ‘the last word in file systems’. In de Linux-wereld wil Btrfs dezelfde positie innemen. Hoe vergelijken beide bestandssystemen zich? En hoe kun je ze in het bedrijfsleven gebruiken? We deden een rondvraag.

De meeste moderne bestandssystemen die we in de Linux-wereld en daarbuiten kennen, zijn voorbeelden van ‘journaling filesystems’. Ext4 is daar een voorbeeld van, maar ook Microsofts NTFS. Dankzij journaling is de kans dat je bij een crash of stroomuitval gegevens verliest klein, omdat het bestandssysteem te allen tijde consistent gehouden wordt. De volgende generatie bestandssystemen staat echter al klaar: ZFS (in de Solaris-wereld) en Btrfs (in de Linux-wereld).

Beide bestandssystemen hebben gelijkwaardige functies. De bekendste functie zijn ‘copy-on-write snapshots’. Daarmee maak je een momentopname van het bestandssysteem. Die neemt echter op dat moment geen enkele extra opslagruimte in. Als je daarna wijzigingen aan het bestandssysteem doorvoert, worden enkel blokken die gewijzigd zijn sinds de snapshot opnieuw opgeslagen. Voor alle andere blokken verwijst het bestandssysteem naar dezelfde gegevens als de snapshot.

Ook data-integriteit is belangrijk bij beide bestandssystemen. Voor elk geschreven blok wordt een ‘checksum’ (een controlegetal) berekend en ook naar het bestandssysteem geschreven. Bij elk blok dat gelezen wordt, leest het bestandssysteem ook het controlegetal in en verifieert of het blok daarmee overeenkomt. Indien niet, dan weet je dat je gegevens corrupt zijn. Als je je schijven in een RAID1-mirror hebt staan, kan het bestandssysteem de fout zelfs automatisch corrigeren, omdat de andere schijf (hopelijk) wel het correcte blok bevat. Verder combineren deze nieuwe bestandssystemen ook ‘volume management’, wat het beheer van je gegevens in heel wat omstandigheden handiger maakt. Al deze features moeten heel wat bedrijven als muziek in de oren klinken.

ZFS
ZFS werd sinds 2001 bij Sun ontwikkeld als nieuw bestandssysteem voor zijn Unix-achtige besturingssysteem Solaris. Voor het gebruik van ZFS in bedrijven heb je verschillende mogelijkheden. Enerzijds heb je Solaris (ondertussen van Oracle), dat de habitat van ZFS is. Maar Oracle heeft de broncode van Solaris, die door Sun onder de naam OpenSolaris vrijgegeven was, opnieuw gesloten. Functionaliteiten die sindsdien aan ZFS toegevoegd zijn, zoals encryptie, zijn propriëtair en niet compatibel met andere implementaties van ZFS. Wie voor deze route kiest, is dus gebonden aan Oracle.

Gelukkig hebben heel wat belangrijke communityleden van het voormalige OpenSolaris, waaronder een aantal kernontwikkelaars van ZFS, hun werk voortgezet onder het project illumos. Dit is een opensource voortzetting van OpenSolaris. Op basis van illumos zijn diverse ‘distributies’ ontwikkeld. Enerzijds heb je OpenIndiana, dat een voortzetting is van de OpenSolaris-distributie, een algemeen desktopbesturingssysteem met GNOME als desktopomgeving.

Aan de andere kant zijn op basis van illumos ook heel wat gespecialiseerde besturingssystemen ontwikkeld en daar zitten voor bedrijven wel een aantal interessante opties tussen. Zo heb je SmartOS, dat bedoeld is om virtuele machines op te draaien. De ontwikkelaars van SmartOS hebben KVM van Linux naar illumos geport en bieden dat aan samen met technologieën uit de Solaris-wereld, waaronder ZFS, DTrace en Zones. ZFS draait ook op FreeBSD, OS X (via een extern programma) en Linux (via een externe kernelmodule en een Solaris Portability Layer). De ontwikkelaars van al die besturingssystemen werken sinds september 2013 in een meer officiële vorm samen aan hun ZFS-implementaties in het project OpenZFS.

Nexenta
De bekendste illumos-telg voor bedrijven is NexentaStor, dat zich profileert als storagebesturingssysteem, bijvoorbeeld voor een SAN of NAS. Het is op illumos gebaseerd, met een GNU-userland. Het bedrijf Nexenta laat niet na om de openheid van zijn oplossing te benadrukken. Een bedrijf dat bijvoorbeeld voor storage van NetApp of andere propriëtaire oplossingen kiest, is daaraan gebonden. Kies je voor Nexenta, dan worden je bestanden op ZFS opgeslagen, waarvan de broncode open is en implementaties op diverse besturingssystemen bestaan. Ben je dus niet tevreden over Nexenta, dan kun je je schijven eenvoudigweg importeren in een ander ZFS-ondersteunend besturingssysteem, tenminste als je erop let dat dezelfde versie van ZFS ondersteund is.

NexentaStor is gecertificeerd op heel wat hardware (van Dell, Cisco, HP, SuperMicro en Intel) en kan gebruikt worden in combinatie met aardig wat hypervisors voor het opslaan van ‘virtual machine images’. Je installeert de hardware als een ‘appliance’ in je bedrijf, waarna het de functionaliteit van een SAN (iSCSI en FibreChannel) en NAS (NFS, CIFS, WebDAV en FTP) combineert. Daarbij profiteer je van alle voordelen van het onderliggende bestandssysteem ZFS. Er is een communityversie met een maximale capaciteit tot 18 TB en een trial van 45 dagen voor de enterpriseversie.

We vroegen aan Gijsbert Janssen van Doorn, sales engineer voor Nexenta in de Benelux, waarom klanten zoal voor ZFS kiezen. Hij wijst allereerst op de maturiteit van het bestandssysteem: “Sun heeft indertijd ettelijke miljoenen dollars in R&D geïnvesteerd om ZFS te ontwikkelen. Het heeft zich in de afgelopen jaren ook echt kunnen bewijzen in de industrie.”

Toen werd gevraagd naar welke specifieke functies klanten zoal vragen, antwoordde Gijsbert dat de ZFS-volumes (zvol) vaak gebruikt worden, overigens een functie die Btrfs niet heeft. Zo’n volume laat je toe om een virtueel blokapparaat in een ZFS storagepool aan te maken. Op het eerste gezicht lijkt dat niets speciaals, maar het opent wel heel wat mogelijkheden, zegt Gijsbert: “Zo kun je virtuele blokapparaten voor FibreChannel of iSCSI aanmaken, en dat apparaat kan vertrouwen op de datareplicatie die in de onderliggende pool ingesteld is, zoals een mirror, raidz, raidz2 enzovoort.”

Andere veel gevraagde functies zijn de ARC en L2ARC. ARC staat voor ‘adaptive replacement cache’. Het is een cache die zich in het RAM van de storageserver bevindt, meestal alle RAM behalve 1 GB. Gegevens die van een ZFS-bestandssysteem gelezen worden, worden in die cache opgeslagen. Gegevens die al in de cache aanwezig zijn en nog eens gelezen worden, kunnen daardoor supersnel gelezen worden. Daarom hoor je vaak het advies dat je een server met ZFS met zoveel mogelijk RAM moet uitrusten.

Op een bepaald moment wordt het blijven toevoegen van RAM echter te duur of past er gewoonweg niet meer RAM in de op de markt beschikbare systemen. Daar komt L2ARC (level 2 ARC) van pas. “Je installeert een ssd, die trager is dan het RAM, maar sneller dan je harde schijven,” zegt Gijsbert. “Zo’n cache-ssd bevat dan de frequent gelezen gegevens die niet in de ARC passen. Gegevens worden pas op de harde schijf gelezen als ZFS ze niet in de ARC en niet in de L2ARC vindt.” Zo’n opstelling verhoogt de leesperformance aanzienlijk.

Deduplicatie is een andere functie waarover vaak gesproken wordt, maar in de praktijk blijkt het toch niet altijd toepasbaar, aldus Gijsbert: “Veel klanten vragen ons naar deduplicatie, maar als we dan gaan kijken naar hun usecase, blijkt vaak dat het niet nodig is of dat het gebruik er zelfs niet geschikt voor is. Schakel je deduplicatie in ZFS in, dan vraagt dat heel wat RAM. Wil je meer opslagruimte besparen, dan schakel je beter compressie in, want dat heeft weinig impact op de performance van je systeem. Bovendien kun je in ZFS per bestandssysteem individueel compressie in- of uitschakelen.”

EraStor
Net zoals Nexenta bouwt EraStor zijn oplossingen op basis van ZFS. EraStor is een Europees netwerk van opslagleveranciers die besloten hebben om samen te werken onder één naam. Ze delen hun kennis en bieden identieke systemen aan. EraStor is niet alleen Nexenta Premium Partner, maar levert ook systemen met hun eigen besturingssysteem EraStor OS, ontwikkelt door de Roemeense tak van EraStor. Deze storage-oplossing is volledig from scratch bovenop illumos gebouwd. “Het voordeel van onze oplossing is dat we die rechtstreeks aan onze klanten aanbieden en zelf de ondersteuning verzorgen,” zegt Roel De Frene, CEO en sales director van EraStor Europe. “Bij problemen hebben klanten dus rechtstreeks toegang tot de knowhow van de ontwikkelaars van EraStor OS.”

Het beheer verloopt volledig via een gebruiksvriendelijke webinterface, legt Roel uit. “FibreChannel, iSCSI, NFS, AFP, schijven toevoegen, het is allemaal te configureren via onze webinterface. Je hebt zelfs een rechtstreekse interface met IPMI, zodat je fouten, logs en dergelijke op een afstand via de webinterface kunt afhandelen zonder dat je je naar je datacenter moet verplaatsen. En we hebben integratie met VMware.” Vanuit de webinterface heb je ook een rechtstreekse verbinding met de supportafdeling, die negen talen spreekt. En met een klik op het knopje enable tech support access zet je storagesysteem een reverse ssh proxy op, waarna de supportmedewerker op je systeem kan inloggen om problemen te bekijken.

De klanten van EraStor zijn heel gevarieerd. Dat gaat van cloudbedrijven die virtuele machines aanbieden tot de video-industrie en universiteiten. De data-integriteit die ZFS heeft gegarandeerd, vinden ze heel belangrijk, zegt Roel, maar ook de grote volumes gegevens die het bestandssysteem aankan: “Doordat het een 128-bits bestandssysteem is, loop je niet tegen beperkingen op van 32 schijven of 64 TB, wat je bij andere bestandssystemen wel hebt. Tegenwoordig zijn er al schijven van 6 TB.” Een EraStor-systeem kan gemakkelijk 50.000 tot 60.000 IOPS aan. Deduplicatie is volgens Roel vooral interessant in VDI-omgevingen, waar je veel identieke virtuele machines hebt.

Volgens Koen De Jonge, CMO van EraStor, is er een redelijke kans dat het bedrijf ook storage-oplossingen op basis van Linux gaat bouwen, gebaseerd op de ‘ZFS on Linux’ port. “Voor integratie met OpenStack zou dat bijvoorbeeld handig zijn. En de hardwaresupport van Linux is veel uitgebreider dan die van Solaris, waardoor we dan meer keuzevrijheid hebben.” Het nadeel is dan wel dat zo’n oplossing andere interessante Solaris-technologieën moet missen, zoals DTrace en Crossbow.

Bij zijn hostingbedrijf ProcoliX draait Koen al wel ZFS on Linux in productie, op Debian. “Bij één van onze klanten, Wageningen Universiteit, draaien we het ook: zij gebruiken een Ubuntu-systeem met ZFS on Linux voor ‘gene processing’. Maar in situaties waar we enterprise support moeten geven, gebruiken we geen ZFS on Linux. Op enterprise hardware zoals SAS-schijven presteert ZFS op Solaris sowieso beter dan op Linux. Dat verschil kan tot tientallen procenten oplopen.”

Btrfs
Btrfs werd in 2007 ontwikkeld door Chris Mason die toen voor Oracle werkte. Ondertussen is Btrfs in de Linux-kernel opgenomen en is het een gezamenlijke ontwikkeling, met naast mensen van Oracle ook ontwikkelaars van Red Hat, SUSE, Fujitsu en Intel die bijdragen leveren. Sinds enkele jaren is Btrfs al in heel wat Linux-distributies ondersteund, vaak echter nog experimenteel.

Een leuk voordeel van Btrfs is dat je een Ext2/3/4-bestandssysteem offline en in-place kunt omzetten naar Btrfs. Dat gaat met de opdracht btrfs-convert [device]. Je kunt dit zelfs terugdraaien, al zijn dan wel alle wijzigingen verloren die gebeurd zijn na de conversie naar Btrfs.

Gijsbert vindt dat Btrfs een heel interessante functie heeft: “Als je in Btrfs een pool uitbreidt met een schijf, worden de gegevens opnieuw verdeeld over alle schijven. Dat herbalanceren kan, omdat Btrfs gebruikmaakt van een ‘relocation tree’ en dit gaat met een speciaal algoritme. ZFS kan dat echter niet, omdat het niet gebruikmaakt van een relocation tree, maar van block pointers. Herbalanceren wordt daardoor een erg complex proces. Er wordt al wel jaren gesproken van het implementeren van een ‘block pointer rewrite’, maar dat zit er niet direct aan te komen.”

Hoe ziet dat er in de praktijk uit? Je kunt bijvoorbeeld eenvoudig een normale installatie op één schijf doen in openSUSE, op een Btrfs-bestandssysteem. Wil je je systeem daarna echter omzetten naar een RAID1-opstelling (een mirror), dan kan dat eenvoudig: voeg de tweede schijf (of partitie) toe aan het Btrfs-bestandssysteem en herbalanceer. Alle gegevens worden naar de tweede schijf gekopieerd en ondertussen blijft het besturingssysteem gewoon voortwerken. Wil je je RAID1-opstelling later naar RAID5 omzetten, dan voeg je gewoon een derde schijf toe en herbalanceer alles weer. In ZFS gaat dat niet.

Btrfs is ook flexibeler dan ZFS op andere vlakken. Enkele belangrijke taken die in ZFS op niveau van een blok of een bestandssysteem gebeuren, doet Btrfs op bestandsniveau. Zo kun je in Btrfs heel eenvoudig een kloon van een bestand maken (met cp –reflink=always). Dat is handig voor een virtual machine image van tientallen of honderden gigabytes groot, die dan in enkele milliseconden ‘gekopieerd’ wordt, zonder extra opslagruimte te gebruiken. De kloon is bovendien gewoon beschrijfbaar, waarna hij uiteraard wel extra opslagruimte begint in te nemen. In ZFS gaat dat niet: je kunt enkel een snapshot (van een heel bestandssysteem) klonen. Een individueel bestand daaruit kopiëren vereist effectief dat alle blokken ervan gekopieerd worden. Ook compressie kun je in Btrfs individueel per bestand, directory, subvolume of bestandssysteem instellen, terwijl dat in ZFS enkel per bestandssysteem kan.

SUSE Linux
SUSE zet al enkele jaren sterk in op Btrfs. Sinds SUSE Linux Enterprise 11 Service Pack 2 (SLE 11 SP2) vervoegt Btrfs Ext3, Reiserfs, XFS en OCFS2 als commercieel ondersteunde bestandssystemen — voorheen was het bestandssysteem opgenomen als een ‘technology preview’. De standaardinstallatie gebruikt nog altijd Ext3 en SUSE raadt XFS aan als performance belangrijk is; Btrfs wordt voorgesteld in situaties die snapshots en rollbacks vereisen.

Multivolume- en RAID-opstellingen zijn nog niet ondersteund met Btrfs, maar dat zal nog in een maintenance update toegevoegd worden. “Btrfs kent heel veel nieuwe features, waarvan er veel al production-ready zijn, maar andere nog niet,” legt Gábor Nyers (sales engineer bij SUSE) uit. “We maken bij SUSE onderscheid in de ondersteunde features. De afweging om een feature wel of niet te ondersteunen maken we op basis van onze eigen tests, zodat we zeker weten dat wat we in een SLE-release uitbrengen robuust genoeg is.”

SLE 11 SP2 gebruikt nog GRUB Legacy, dat niet van Btrfs kan opstarten, dus als je voor Btrfs als rootbestandssysteem kiest in het installatieprogramma, creëert het een /boot-partitie met een Ext3-bestandssysteem.

Met de tool Snapper die SUSE ontwikkeld heeft, maakt SLE automatisch gebruik van Btrfs-snapshots op belangrijke momenten. Snapper creëert automatisch snapshots voor en na het uitvoeren van YaST of Zypper. De twee snapshots worden vergeleken en op die manier kun je de wijzigingen terugdraaien. Dat kan via een gebruiksvriendelijke YaST-module voor Snapper, maar ook met de commandline tool snapper. Is een installatie of update misgelopen of heb je je systeemconfiguratie om zeep geholpen, dan draai je eenvoudigweg de juiste snapshot terug.

Op dit moment kun je nog geen kernelupdates of wijzigingen aan de bootconfiguratie terugdraaien met Snapper, omdat de bootpartitie door een gebrek aan ondersteuning in GRUB Legacy nog geen Btrfs gebruikt. SLE12, dat in het midden van 2014 verwacht wordt, zal ook van een Btrfs-partitie kunnen opstarten. “We gaan dan ook GRUB2, Btrfs en Snapper integreren,” zegt Gábor. “Dan kan je vanuit het bootmenu kiezen om SLE op te starten vanaf een vorig snapshot.” Deze functie is in de Solaris-wereld ook al even beschikbaar met gebruikmaking van ZFS-snapshots.

SLE 12 heeft nog heel wat verbeteringen op het vlak van Btrfs en Snapper in petto. Zo zal Snapper voor diffs Btrfs send/receive gebruiken, wat sneller gaat omdat de opdracht dan enkel naar de transactielogs moet kijken. Btrfs send/receive is momenteel een experimentele functie waarmee snapshots als bitstromen kunnen worden gezonden en ontvangen, naar analogie met de gelijknamige functionaliteit in ZFS.

“In SLE 12 zal Btrfs ook geïntegreerd worden met Samba4 door de Samba VFS Module. Die module verbetert de performance van server-side kopieën,” aldus Gábor. Bij een traditionele kopie leest de client een bestand in van de SMB-server en schrijft die terug naar de server, met overbodig netwerkverkeer en een dubbel bestand op de server als gevolg. Samba 4.1 en later ondersteunen server-side kopieën: de client vraagt dan aan de SMB-server om een kopie te maken van het bestand. Het extra netwerkverkeer wordt daardoor vermeden, maar het bestand blijft dubbel op de server staan. Met een server-side kopie bij gebruik van de Samba VFS Module wordt het bestand op de server niet gekopieerd, maar gekloond, waardoor het niet dubbel wordt opgeslagen. Deze functie kan in smb.conf per share ingeschakeld worden met de optie vfs objects = btrfs.

Red Hat
Bij Red Hat kijkt men nog wat voorzichtiger naar Btrfs. Red Hat Enterprise Linux 7, dat deze zomer uitkomt, bevat Btrfs, maar enkel als ‘technology preview’. Het standaard bestandssysteem wordt XFS. Gerald Sternagl, business unit manager voor Storage in EMEA bij Red Hat, legt die beslissing uit: “We beschouwen Btrfs nog niet als production-ready. De features zijn er op papier, maar het bestandssysteem is nog niet matuur genoeg. XFS daarentegen is al tien jaar op de markt”

Dat Btrfs als tech preview aangeboden wordt, betekent wel dat gebruikers het nieuwe bestandssysteem kunnen uitproberen. “Onze klanten weten dat ze voorzichtig moeten zijn, maar we fixen nog de hele tijd bugs in Btrfs en de stabiliteit en performance verbeteren dan ook zienderogen,” zegt Gerald. “Zodra RHEL 7 uit is, verwacht ik wel dat klanten ernaar gaan kijken.” Hij verwacht dat het nog enkele jaren zal duren voor Red Hat Btrfs als production-ready beschouwt.

Vooral de performance is momenteel nog een probleem, vindt Gerald. “XFS is in negen van de tien gevallen sneller. We willen dat Btrfs minstens zo performant is als XFS voor we het kunnen aanraden.” Technologisch is Btrfs volgens hem wel veelbelovend: “Op dit moment gebruiken we nog verschillende technologieën voor het bestandssysteem, volume management en RAID, en daar komt heel wat beheer bij kijken. Btrfs vereenvoudigt dat allemaal drastisch. Ook de snapshots zijn een belangrijke feature.”

Aram Kananov, platform business unit manager in EMEA bij Red Hat, benadrukt ook dat een ‘standaard bestandssysteem’ in Red Hat slechts een suggestie is: “Er bestaat niet zoiets als het beste bestandssysteem dat voor iedereen optimaal is. XFS heeft bijvoorbeeld de beste performance op multi-cpu multi-core systemen in de meeste multithreaded toepassingen. Maar voor singlethreaded toepassingen presteert Ext4 dan weer vaak beter. Als we Btrfs dus over enkele jaren production-ready maken in RHEL, zullen we onze klanten altijd de keuze laten.” Oracle ondersteunt overigens wel al Btrfs, sinds release 2 van zijn enterprisekernel die in maart 2012 uitkwam.

SUSE Linux Enterprise heeft met de Snapper-module in YaST een gebruiksvriendelijke interface voor Btrfs-snapshots.

Links
Illumos: http://www.illumos.org

OpenZFS: http://open-zfs.org

OpenIndiana: http://openindiana.org/

Nexenta: http://nexenta.com

EraStor: http://www.erastor.eu/

EraStor OS: http://syneto.net/products/storage-os/

ZFS on Linux: http://zfsonlinux.org/

Btrfs: https://btrfs.wiki.kernel.org

SUSE: https://www.suse.com/

Snapper: http://snapper.io/

Red Hat: http://www.redhat.com/