De Cultus van ZFS

Het is vrij gebruikelijk dat in IT-kringen een zekere cultachtige of “fanboy”-mentaliteit ontstaat. Wat deze reactie op technologieën en producten veroorzaakt, weet ik niet precies, maar dat het gebeurt is onmiskenbaar. Eén gebied waarvan ik nooit had gedacht dat ik dit zou zien gebeuren, is het gebied van bestandssystemen – een van de meest “onder de motorkap” gelegen systeemcomponenten en een die tot voor kort letterlijk geen aandacht kreeg, zelfs niet in redelijk technische kringen. Laten we eerlijk zijn: het verkeerd begrijpen of iets van Active Directory of van NTFS komt, is vrijwel alomtegenwoordig. Bestandssystemen worden, heel simpel gezegd, genegeerd. Sinds de release van Windows NT 4, waarbij NTFS de enige levensvatbare optie was, is het idee dat een bestandssysteem geen intrinsiek onderdeel van een besturingssysteem is en dat er andere opties voor bestandsopslag zouden kunnen zijn, vrijwel volledig vervaagd. Dat wil zeggen, tot voor kort.

De ene gemeenschap waar dit, tot op zekere kleine hoogte, niet gebeurde, was de Linux-gemeenschap, maar zelfs daar wonnen Ext2 en zijn afstammelingen zo volledig de mindshare dat, hoewel ze ruim beschikbaar waren, alternatieve bestandssystemen op een zijspoor werden gezet en alleen XFS historisch gezien enige aandacht kreeg, en zelfs dat kreeg maar zeer weinig.

Waar zich recentelijk werkelijk vreemd gedrag heeft voorgedaan, is rond Oracle's ZFS-bestandssysteem, oorspronkelijk ontwikkeld voor het Solaris-besturingssysteem en het X4500 “Thumper” open-storageplatform (oorspronkelijk onder auspiciën van Sun, voorafgaand aan de overname door Oracle). Op het moment (negen jaar geleden) dat ZFS werd uitgebracht, waren concurrerende bestandssystemen grotendeels slecht voorbereid op het verwerken van de grote schijfarrays die in de komende jaren naar verwachting zouden worden gemaakt. ZFS was ontworpen om ze te verwerken en luidde het tijdperk van grootschalige bestandssystemen in. Zoals de meeste bestandssystemen in die tijd was ZFS beperkt tot één enkel besturingssysteem en daarom veroorzaakte het, hoewel algemeen beschouwd als een grote sprong voorwaarts in het ontwerp van bestandssystemen, weinig rimpelingen in de opslagwereld en nog minder in de “systeem”-wereld, waar zelfs Solaris-beheerders het geruime tijd over het algemeen slechts als een interessant detail beschouwden en er meestal voor kozen om vast te houden aan het beproefde UFS dat ze al vele jaren gebruikten.

ZFS was, werkelijk, een baanbrekend bestandssysteem en ik was, en blijf, een groot voorstander ervan. Maar het is heel belangrijk om te begrijpen waarom ZFS deed wat het deed, wat de doelen ervan zijn, waarom die doelen belangrijk waren en hoe het vandaag de dag op ons van toepassing is. De complexiteit van ZFS heeft geleid tot veel verwarring en misverstanden over hoe het bestandssysteem werkt en wanneer het passend is om het te gebruiken.

De voornaamste doelen van ZFS waren om een bestandssysteem te maken dat goed kon schalen naar zeer grote schijfarrays. Op het moment van introductie was de schaal waartoe ZFS in staat was ongehoord in andere bestandssystemen, maar er was geen reële behoefte aan een bestandssysteem dat zo groot kon groeien. Tegen de tijd dat de behoefte ontstond, waren veel andere bestandssystemen zoals NTFS, XFS, Ext3 en andere geschaald om aan de behoefte te voldoen. ZFS leidde zeker de aanval op het verwerken van grotere bestandssystemen, maar werd kort daarna door vele andere vergezeld.

Omdat ZFS zijn oorsprong vond in de Solaris-wereld, waar, zoals bij alle big-iron UNIX-systemen, geen hardware-RAID is, moest software-RAID worden gebruikt. Solaris had altijd al software-RAID beschikbaar gehad als zijn eigen subsysteem. De beslissing werd genomen om een nieuwe software-RAID-implementatie rechtstreeks in ZFS te bouwen. Dit zou vereenvoudigd beheer mogelijk maken via één enkele toolset voor zowel de RAID-laag als het bestandssysteem. Het introduceerde geen significante verandering of voordeel voor ZFS, zoals vaak wordt geloofd; het verschoof simpelweg de interface voor de software-RAID-laag van een eigen commandoset naar onderdeel van de ZFS-commandoset.

ZFS' implementatie van RAID introduceerde stripes met variabele breedte in pariteit-RAID-niveaus. Deze innovatie dichtte een klein pariteit-RAID-risico dat bekendstaat als het “write hole”. Deze innovatie was heel mooi, maar kwam erg laat, aangezien het tijdperk van betrouwbare pariteit-RAID ten einde begon te lopen en het write hole-probleem al werd beschouwd als een onvermeld “achtergrondruis”-risico van pariteit-arrays, omdat het over het algemeen niet als een bedreiging werd beschouwd vanwege de eliminatie ervan door het gebruik van array-caches met batterijback-up en, ongeveer op hetzelfde moment, niet-vluchtige array-caches – vermijd stroomverlies en je vermijdt het write hole. ZFS moest dit probleem aanpakken omdat het, als software-RAID, een groter risico op het write hole liep dan hardware-RAID, aangezien er geen mogelijkheid is voor een cache die beschermd is tegen stroomverlies – hardware-RAID biedt het potentieel voor een extra laag stroombescherming voor arrays.

De werkelijke “innovatie” die ZFS onbedoeld doorvoerde, was dat het, in plaats van simpelweg de gebruikelijke RAID-niveaus 1, 5, 6 en 10 te implementeren, deze niveaus in plaats daarvan “brandde” met zijn eigen naamgevingsconventies. RAID 5 staat bekend als RAIDZ. RAID 6 staat bekend als RAIDZ2. RAID 1 staat gewoon bekend als mirroring. Enzovoort. Dit werd destijds algemeen als dwaas en zinloos verwarrend beschouwd, maar, zoals bleek, werd die verwarring de hoeksteen van ZFS' wederopstanding vele jaren later.

Er dient te worden opgemerkt dat ZFS later 's werelds eerste productie-implementatie van een RAID 7 (oftewel RAID 7.3) triple-parity-RAID-systeem toevoegde en dit RAIDZ3 brandde. Deze latere toevoeging is een belangrijke innovatie voor grootschalige arrays die de uiterste capaciteit nodig hebben en tegelijkertijd uitermate veilig willen blijven, maar bereid zijn prestaties op te offeren om dit te doen. Dit blijft een unieke functie van ZFS, maar een die zelden wordt gebruikt.

In de geest van het laten samenvallen van de opslagstack en het gebruik van één enkele commandoset om alle aspecten van opslag te beheren, werden ook de logical volume management-functies in ZFS opgenomen. Er wordt in bepaalde kringen vaak ten onrechte geloofd dat ZFS logical volume management introduceerde, maar vrijwel alle enterprise-platforms, waaronder AIX, Linux, Windows en zelfs Solaris zelf, hadden al vele jaren logical volume management. ZFS deed dit niet om een nieuw paradigma te introduceren, maar simpelweg om het beheer te consolideren en alle drie de belangrijkste opslaglagen (RAID, logical volume management en bestandssysteem) in één enkele entiteit te verpakken die gemakkelijker te beheren zou zijn en die inherente communicatie op en neer door de stack zou kunnen bieden. Er zijn voor- en nadelen aan deze methode en bijna een decennium later is er nog steeds geen gevormde opinie in de branche.

Een van de belangrijkste aspecten van deze consolidatie van drie systemen tot één is dat we nu een zeer verwarrend product hebben om te bespreken. ZFS is een bestandssysteem, ja, maar het is niet alleen een bestandssysteem. Het is een logical volume manager, maar niet alleen een logical volume manager. Mensen verwijzen naar ZFS als een bestandssysteem, wat zijn primaire functie is, maar dat het zoveel meer is dan een bestandssysteem kan zeer verwarrend zijn en maakt vergelijkingen met andere opslagsystemen moeilijk. Destijds geloof ik dat deze verwarring niet werd voorzien.

Wat uit deze verwarrende samenvoeging is voortgekomen, is dat ZFS vaak wordt vergeleken met andere bestandssystemen, zoals XFS of Ext4. Maar dit is verwarrend, aangezien ZFS een complete stack is en XFS slechts één aspect van een stack. ZFS zou beter vergeleken kunnen worden met MD (Linux Software RAID) / LVM / XFS of met SmartArray (HP Hardware RAID) / LVM / XFS dan met XFS alleen. Anders lijkt het alsof ZFS vol functies zit die XFS ontbeert, maar in werkelijkheid is het slechts een semantische overwinning. De meeste van de functies die door ZFS-voorstanders vaak worden aangeprezen, vonden hun oorsprong niet bij ZFS en waren al ruim beschikbaar bij de alternatieve bestandssystemen lang voordat ZFS bestond. Maar het is moeilijk te vergelijken “doet jouw bestandssysteem dat”, want het antwoord is “nee…. mijn RAID of mijn logical volume manager doet dat”. En werkelijk, het is niet ZFS het bestandssysteem dat RAIDZ levert, het is ZFS het software-RAID-subsysteem dat dat doet.

Om zeer grote bestandssystemen op een soepele manier te verwerken, werden er functies voor gegevensintegriteit in ZFS ingebouwd, waaronder een checksum of hash-controle door het hele bestandssysteem heen die de inclusieve software-RAID kon benutten om beschadigde bestanden te repareren. Dit werd als noodzakelijk gezien vanwege de verwachte omvang van ZFS-bestandssystemen in de toekomst. Beschadiging van het bestandssysteem is een zelden gezien fenomeen, maar naarmate bestandssystemen in omvang toenemen, neemt het risico toe. Deze minder bekende functie van ZFS is mogelijk zijn grootste.

ZFS veranderde ook hoe bestandssysteemcontroles worden afgehandeld. Vanwege de aanname dat ZFS op zeer grote bestandssystemen zou worden gebruikt, bestond er een oprechte vrees dat een bestandssysteemcontrole bij het opstarten onmogelijk lang zou kunnen duren om te voltooien, en daarom werd er een alternatieve strategie gevonden. In plaats van te wachten met het uitvoeren van een controle bij het herstarten, zou het systeem vereisen dat er een scrubbing-proces draait dat een vergelijkbare controle uitvoert terwijl het systeem draait. Dit vereist meer systeemoverhead terwijl het systeem live is, maar het systeem is in staat sneller te herstellen van een onverwachte herstart. Een afweging, maar een die algemeen als zeer positief wordt gezien.

ZFS heeft krachtige snapshotting-mogelijkheden in zijn logical-volume-laag en heeft in zijn RAID-laag zeer robuuste caching-mechanismen geïmplementeerd, waardoor ZFS een uitstekende keuze is voor veel toepassingen. Deze functies zijn niet uniek in ZFS, maar zijn ruim beschikbaar in systemen die ouder zijn dan ZFS. Het zijn echter zeer goede implementaties van elk en zeer goed geïntegreerd vanwege de aard van ZFS.

Op een gegeven moment was ZFS open source en in die periode werd de code ervan onderdeel van Apple's Mac OSX- en FreeBSD-besturingssystemen, omdat deze compatibel waren met de ZFS-licentie. Linux kreeg ZFS in die tijd niet vanwege uitdagingen rond licentiëring. Had de ZFS-licentiëring Linux toegestaan om het onbelemmerd te gebruiken, dan zou het Linux-landschap er vandaag de dag waarschijnlijk heel anders uitzien. Mac OSX liet ZFS uiteindelijk vallen, aangezien het niet werd gezien als voldoende voordelen biedend om het in die omgeving te rechtvaardigen. FreeBSD klampte zich vast aan ZFS en in de loop van de tijd werd het het populairste bestandssysteem op het platform, hoewel UFS ook nog steeds zwaar wordt gebruikt. Oracle sloot de broncode van ZFS na de overname van Sun, waardoor FreeBSD achterbleef zonder doorlopende updates voor zijn versie van ZFS, terwijl Oracle ZFS intern bleef ontwikkelen voor Solaris.

Vandaag de dag blijft Solaris de oorspronkelijke ZFS-implementatie gebruiken, nu met diverse updates sinds de splitsing met de open-sourcegemeenschap. FreeBSD en andere bleven ZFS gebruiken in de staat waarin het verkeerde toen de code closed source werd, zonder nog langer toegang te hebben tot Oracle's nieuwste updates. Uiteindelijk werd het werk om de verlaten open-source-ZFS-codebase bij te werken opgepakt en staat nu bekend als OpenZFS. OpenZFS staat nog in de kinderschoenen en heeft nog niet echt zijn stempel gedrukt, maar heeft enig potentieel om het ZFS-platform in de open-sourceruimte nieuw leven in te blazen, maar op dit moment loopt OpenZFS nog achter op ZFS.

Open-sourceontwikkeling in deze ruimte heeft zich de afgelopen jaren meer gericht op ZFS' nieuwe rivaal BtrFS, dat native op Linux wordt ontwikkeld en goed wordt ondersteund door veel grote leveranciers van besturingssystemen. BtrFS staat nog zeer in zijn kinderschoenen, maar boekt grote vooruitgang om featurepariteit met ZFS te bereiken in geïmplementeerde functies, maar heeft grote aspiraties en heeft, vanwege de closed-source-aard van ZFS, het voordeel van marktmomentum. BtrFS werd, net als ZFS, gestart door Oracle en wordt algemeen gezien als Oracle's visie op de toekomst, als een vervanging voor ZFS zelfs bij Oracle. Op dit moment heeft BtrFS al, net als ZFS, het bestandssysteem, logical volume management en de software-RAID-laag samengevoegd, checksumming voor bestandssysteemintegriteit geïmplementeerd, schaalt het zelfs groter dan ZFS (dezelfde absolute limiet, maar verwerkt meer bestanden), copy-on-write-snapshots, enzovoort.

ZFS was, zonder twijfel, een verbazingwekkend bestandssysteem in zijn hoogtijdagen en blijft vandaag de dag een leider. Ik was er in 2005 een voorstander van en ik geloof er nog steeds sterk in. Maar het heeft me verdriet gedaan om de gemeenschap rond ZFS een fervor en zeloterie te zien aannemen die het geen dienst bewijst en die de vermelding van ZFS bijna als iets negatiefs doet lijken – doordat ZFS zo alomtegenwoordig om de verkeerde redenen wordt gekozen: voornamelijk een geloof dat zijn functies nergens anders bestaan, dat zijn RAID niet onderhevig is aan de risico's en beperkingen waaraan die RAID-niveaus altijd onderhevig zijn, of dat het voor een ander doel (voornamelijk prestaties) was ontworpen dan waarvoor het werd ontworpen. En wanneer ZFS een goede keuze is, wordt het vaak slecht geïmplementeerd op basis van onjuiste aannames.

ZFS treft uiteraard geen blaam. Noch, voor zover ik kan zien, treft die zijn zakelijke supporters of zijn open-sourceontwikkelaars. Waar ZFS lijkt te zijn ontspoord, is in een losse, onofficiële gemeenschap die ZFS pas recentelijk heeft leren kennen en die vaak gelooft dat het nieuw of “next generation” is omdat zij het pas recentelijk hebben ontdekt. Van wat ik heb gezien, is dit vrijwel nooit via Solaris- of FreeBSD-kanalen, maar vrijwel uitsluitend kleinere bedrijven die een ingepakt “NAS-OS” zoals FreeNAS of NAS4Free willen gebruiken en die niet vertrouwd zijn met UNIX-besturingssystemen. Het gebruik van ingepakte NAS-besturingssystemen, voornamelijk door IT-afdelingen die noch diepgaande UNIX- noch opslagvaardigheden bezitten en die bijgevolg weinig blootstelling hebben aan de bredere wereld van bestandssystemen buiten Windows en vaak weinig tot geen blootstelling aan logical volume management en RAID, met name software-RAID überhaupt, lijkt te leiden tot een “mythe”-cultuur rond ZFS, waarbij het een bijna onbetwistbare, onfeilbare status aanneemt.

Deze cultachtige aanhang en het algemene misverstand over ZFS leidt vaak tot verkeerde toepassingen van ZFS of een keten van besluitvorming op basis van onjuiste aannames die iemand zeer ver op een dwaalspoor kan brengen.

Een van de meest verbazingwekkende veranderingen in deze ruimte is de verschuiving in aanhang van hardware-RAID naar software-RAID. Traditioneel was software-RAID een paria in Windows-beheerkringen zonder goede reden – Windows-beheerders en kleine bedrijven, vaak onbekend met grotere UNIX-servers, geloofden dat hardware-RAID alomtegenwoordig was, terwijl in feite grootschaligere systemen altijd software-RAID gebruikten. Hardware-RAID werd, vrijwel branchebreed, als een noodzaak beschouwd en software-RAID volledig geschuwd. Datzelfde publiek, nu geconfronteerd met de “Cultus van ZFS”-beweging, reageert nu op precies de tegenovergestelde manier, gelovend dat hardware-RAID slecht is en dat ZFS' software-RAID de enige levensvatbare optie is. De verschuiving is dramatisch en geen van beide benaderingen is geldig – zowel hardware- als software-RAID, en beide in veel implementaties, zijn zeer geldige opties, en zelfs bij gebruik van ZFS zou het gebruik van hardware-RAID gemakkelijk passend kunnen zijn.

ZFS wordt vaak gekozen omdat men gelooft dat het de hoogst presterende optie in bestandssystemen is, maar dit was nooit een belangrijk ontwerpdoel van ZFS. De functies die het in staat stellen zo groot te schalen en zoveel verschillende aspecten van opslag te verwerken, maken het juist erg moeilijk om zeer goed presterend te zijn. ZFS werd, op het moment van zijn ontstaan, niet eens verwacht zo snel te zijn als het eerbiedwaardige UFS dat op dezelfde systemen draaide. Dit is echter vaak secundair aan het feit dat bestandssysteemprestaties grotendeels irrelevant zijn, aangezien alle moderne bestandssystemen uitermate snel zijn en bestandssysteemsnelheid zelden een belangrijke factor is – met name buiten enorme, high-end opslagsystemen op zeer grote schaal.

Een interessant onderzoek naar tien bestandssystemen op Linux, geproduceerd door Phoronix in 2013, toonde enorme verschillen tussen bestandssystemen per workload, maar geen duidelijke winnaars wat betreft de algehele prestaties. Wat het onderzoek overtuigend aantoonde, is dat het afstemmen van de workload op het bestandssysteem de belangrijkste keuze is, dat ZFS aan de langzamere kant van alle gangbare bestandssystemen valt, zelfs in zijn modernere implementaties, en dat het kiezen van een bestandssysteem om prestatieredenen zonder een zeer diepgaand begrip van de workload zal resulteren in onvoorspelbare prestaties – geen enkel bestandssysteem zou blindelings moeten worden gekozen als prestaties een belangrijke factor zijn. Helaas ontbrak het, omdat de test op Linux werd uitgevoerd, aan UFS, dat vaak ZFS' belangrijkste concurrent is, met name op Solaris en FreeBSD, en ontbrak het aan HFS+ van Mac OSX.

De overstap van hardware-RAID naar software-RAID brengt aanvullende, vaak onvoorziene risico's met zich mee voor afdelingen die niet ervaren zijn in UNIX. Hoewel ZFS hot-swapping mogelijk maakt, wordt vaak vergeten dat hot-swap voornamelijk een functie van hardware is, niet van software, en het is ook breed onbekend dat blind swapping (het verwijderen van harde schijven zonder ze eerst in het besturingssysteem offline te halen) niet synoniem is met hot-swapping, en dit kan leiden tot rampen voor afdelingen die overstappen van een traditie van hardware-RAID die compatibiliteit, hot-swap en blind swapping transparant voor hen afhandelde, naar een software-RAID-systeem dat veel meer planning, coördinatie en begrip van het systeem vereist om het veilig te gebruiken.

Een mindere, maar nog steeds veelvoorkomende misvatting over ZFS is dat het een clustered bestandssysteem is dat geschikt is voor gebruik in gedeelde DAS- of SAN-scenario's à la OCFS, VxFS en GFS2. ZFS is geen clustered bestandssysteem en deelt in die ruimte dezelfde beperkingen als al zijn gangbare concurrenten.

ZFS kan een uitstekende keuze zijn, maar het is verre van de enige. ZFS komt met grote kanttekeningen, niet in de laatste plaats de beperkingen van het besturingssysteem die ermee samenhangen, en hoewel het veel voordelen heeft, zijn er weinig, indien überhaupt enige, uniek aan ZFS, en het is zeer zeldzaam dat een afdeling van elk afzonderlijk voordeel zal profiteren. Zoals bij elke technologie zijn er afwegingen te maken. Eén maat past niet iedereen. De sleutel om te weten wanneer ZFS geschikt voor je is, is te begrijpen wat ZFS is, wat er wel en niet uniek aan is, wat zijn ontwerpdoelen zijn, hoe het vergelijken van een opslagsysteem met een puur bestandssysteem misleidende resultaten oplevert en welke inherente beperkingen eraan verbonden zijn.

ZFS is een belangrijke overweging en de gangbare keuze wanneer Solaris of FreeBSD het gekozen besturingssysteem is. Op zeldzame uitzonderingen na zou het besturingssysteem nooit vanwege ZFS gekozen moeten worden, maar in plaats daarvan zou ZFS vaak, maar niet altijd, gekozen moeten worden wanneer het besturingssysteem is gekozen. Het besturingssysteem zou in vrijwel alle gevallen, op de zeldzaamste na, de bestandssysteemkeuzes moeten sturen. De keuze van het besturingssysteem is zo veel dramatischer belangrijker dan de keuze van het bestandssysteem.

ZFS kan op Linux worden gebruikt, maar wordt daar niet als een enterprise-optie beschouwd, maar meer als een hobbysysteem voor experimenten, aangezien geen enkele enterprise-leverancier (zoals Red Hat, Suse of Canonical) ZFS op Linux ondersteunt en aangezien Linux al uitstekende alternatieven heeft. Ooit zou ZFS wellicht gepromoveerd kunnen worden tot een eersteklas bestandssysteem in Linux, maar dit wordt niet verwacht, aangezien BtrFS al de mainline-kernel is binnengekomen en in productiereleases door diverse grote leveranciers is opgenomen.

Hoewel ZFS in de overgrote meerderheid van Solaris- en FreeBSD-implementaties te zien zal zijn, komt dit voornamelijk doordat het de positie van standaardbestandssysteem heeft ingenomen en niet omdat het in die gevallen duidelijk de superieure keuze is of zelfs maar kritisch is geëvalueerd. ZFS is uitstekend geschikt om een algemeen bestandssysteem te zijn waar het native en ondersteund is.

Wat is ZFS' primaire toepassing?

ZFS' ontwerpdoel en voornaamste toepassing is voor Solaris- en FreeBSD-open-storagesystemen die ofwel gedeelde opslag aan andere servers bieden, ofwel als enorme gegevensopslagplaatsen voor lokaal geïnstalleerde applicaties dienen. In deze gevallen schitteren ZFS' focus op schaalbaarheid en gegevensintegriteit werkelijk. ZFS neigt sterk naar grote en enterprise-scale-afdelingen en over het algemeen weg van toepasbaarheid in de ruimte van het midden- en kleinbedrijf, waar Solaris- en FreeBSD-vaardigheden, evenals grootschalige opslagbehoeften, zeldzaam zijn.

Referentie: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1