ZFS-kulten

Det er ret almindeligt, at IT-kredse udvikler en vis kultlignende eller “fanboy”-mentalitet. Hvad der forårsager denne reaktion på teknologier og produkter er jeg ikke helt sikker på, men at det sker er ubestrideligt. Et område, jeg aldrig troede, at jeg ville se dette ske, er inden for filsystemer – en af de mest “under motorhjelmen” systemkomponenter og en, der indtil for nylig ikke modtog nogen som helst opmærksomhed selv i nogenlunde tekniske kredse. Lad os bare sige det: misforståelse af, hvornår noget kommer fra Active Directory versus fra NTFS, er næsten allestedsnærværende. Filsystemer ignoreres simpelthen. Siden Windows NT 4 udkom og NTFS var den eneste levedygtige mulighed, er idéen om, at et filsystem ikke er en intrinsisk komponent i et operativsystem, og at der måske er andre muligheder for filopbevaring, næsten forsvundet. Det er i det mindste, hvad der skete indtil for nylig.

Det ene fællesskab, hvor dette i nogen lille grad ikke skete, var Linux-fællesskabet, men selv der vandt Ext2 og dets efterkommere mindshare så fuldstændigt, at selv om de var bredt tilgængelige, var alternative filsystemer sat til side, og kun XFS fik nogen opmærksomhed historisk set, og selv det fik meget lidt.

Hvor der er opstået virkelig mærkelig adfærd, mere for nylig, er omkring Oracles ZFS-filsystem, der oprindeligt blev udviklet til Solaris-operativsystemet og X4500 “Thumper” open storage-platformen (oprindeligt under Sun, inden Oracle-overtagelsen). På det tidspunkt (for ni år siden), da ZFS blev udgivet, var konkurrerende filsystemer for det meste dårligt forberedt til at håndtere store diskarray, som man forventede ville blive lavet i de kommende år. ZFS var designet til at håndtere dem og varslede ind i epoken med storskala-filsystemer. Ligesom de fleste filsystemer på det tidspunkt var ZFS begrænset til et enkelt operativsystem, og mens det var bredt betragtet som et stort spring fremad i filsystemdesign, skabte det få ringe i lagerverdenen og endnu færre i “systems”-verdenen, hvor selv Solaris-administratorer generelt betragtede det som et interessepunkt kun i ganske lang tid og for det meste valgte at holde sig til det velkendte og pålidelige UFS, de havde brugt i mange år.

ZFS var i sandhed et banebrydende filsystem, og jeg var og er stadig stor fortaler for det. Men det er meget vigtigt at forstå, hvorfor ZFS gjorde, hvad det gjorde, hvad dets mål er, hvorfor disse mål var vigtige, og hvordan det gælder for os i dag. Kompleksiteten af ZFS har ført til megen forvirring og misforståelse om, hvordan filsystemet virker, og hvornår det er hensigtsmæssigt at bruge.

Principperne for ZFS var at lave et filsystem, der er i stand til at skalere godt til meget store diskarray. På tidspunktet for dets introduktion var den skala, som ZFS var i stand til, uhørt i andre filsystemer, men der var ikke noget reelt behov i den virkelige verden for et filsystem til at kunne vokse så stort. Når behovet opstod, var mange andre filsystemer såsom NTFS, XFS, Ext3 og andre skaleret til at imødekomme behovet. ZFS anførte bestemt toget mod større filsystemhåndtering, men blev snart efterfulgt af mange andre.

Fordi ZFS opstod i Solaris-verdenen, hvor der som i alle big iron UNIX-systemer ikke er hardware-RAID, måtte software-RAID bruges. Solaris havde altid haft software-RAID tilgængeligt som sit eget undersystem. Beslutningen blev truffet om at bygge en ny software-RAID-implementering direkte ind i ZFS. Dette ville muliggøre forenklet administration via et enkelt sæt værktøjer til både RAID-laget og filsystemet. Det introducerede ingen signifikant ændring eller fordel for ZFS, som det ofte antages; det flyttede blot grænsefladen for software-RAID-laget fra at have sit eget kommandosæt til at være en del af ZFS-kommandosættet.

ZFS’ implementering af RAID introducerede variable bredde-stripes i paritetsmæssige RAID-niveauer. Denne innovation lukkede en mindre paritetsmæssig RAID-risiko kendt som “write hole”. Denne innovation var meget fin, men kom meget sent, da epoken med pålideligt paritetsmæssigt RAID begyndte at slutte, og write hole-problemet allerede blev betragtet som en uomtalt “baggrundsstøj”-risiko ved paritetsmæssige arrays, da det generelt ikke blev betragtet som en trussel på grund af dets eliminering via brugen af batterisikrede array-caches og, omtrent på samme tid, ikke-flygtige array-caches – undgå strømafbrydelse og du undgår write hole. ZFS var nødt til at adressere dette problem fordi det som software-RAID var mere udsat for write hole end hardware-RAID er, da der ikke er mulighed for en cache beskyttet mod strømtab – hardware-RAID tilbyder mulighed for et ekstra lag af strømbeskyttelse for arrays.

Den virkelige “innovation”, som ZFS utilsigtet lavede, var, at i stedet for blot at implementere de sædvanlige RAID-niveauer 1, 5, 6 og 10, “brandede” de disse niveauer med deres egne navnekonventioner. RAID 5 er kendt som RAIDZ. RAID 6 er kendt som RAIDZ2. RAID 1 er blot kendt som mirroring. Og så videre. Dette blev bredt betragtet som fjollet på det tidspunkt og unødigt forvirrende, men som det viste sig, blev den forvirring hjørnestenen i ZFS’ genoplivning mange år senere.

Det skal bemærkes, at ZFS senere tilføjede branchens første produktionsimplementering af et RAID 7 (alias RAID 7.3) tredobbelt-paritetsmæssigt RAID-system og kaldte det RAIDZ3. Denne senere tilføjelse er en vigtig innovation for storskala-arrays, der har brug for det ypperste i kapacitet, mens de forbliver ekstremt sikre, men som er villige til at ofre ydeevne for at gøre det. Dette er fortsat en unik funktion ved ZFS, men en, der sjældent bruges.

I ånden om at sammenlægge lagerstakken og bruge et enkelt kommandosæt til at administrere alle aspekter af lagring blev de logiske volumenadministrationsfunktioner også integreret i ZFS. Det antages fejlagtigt i visse kredse, at ZFS introducerede logisk volumenadministration, men næsten alle enterprise-platforme, herunder AIX, Linux, Windows og selv Solaris, havde allerede haft logisk volumenadministration i mange år. ZFS gjorde dette ikke for at introducere et nyt paradigme, men blot for at konsolidere administrationen og pakke alle tre nøglelagringslag (RAID, logisk volumenadministration og filsystem) ind i en enkelt enhed, der ville være nemmere at administrere og kunne give iboende kommunikation op og ned af stakken. Der er fordele og ulemper ved denne metode, og en branche-opfattelse er næsten et årti senere stadig ikke dannet.

Et af de vigtigste aspekter ved denne konsolidering af tre systemer til ét er, at vi nu har et meget forvirrende produkt at diskutere. ZFS er et filsystem, ja, men det er ikke kun et filsystem. Det er en logisk volumenmanager, men ikke kun en logisk volumenmanager. Folk omtaler ZFS som et filsystem, hvilket er dets primære funktion, men at det er så meget mere end et filsystem kan være meget forvirrende og gør sammenligninger med andre lagersystemer vanskelige. På det tidspunkt tror jeg, at denne forvirring ikke var forudset.

Hvad der er resulteret af denne forvirrende sammenlægning er, at ZFS ofte sammenlignes med andre filsystemer, såsom XFS eller Ext4. Men dette er forvirrende, da ZFS er en komplet stak, og XFS kun er ét aspekt af en stak. ZFS ville bedre sammenlignes med MD (Linux Software RAID) / LVM / XFS eller med SmartArray (HP Hardware RAID) / LVM / XFS end med XFS alene. Ellers ser det ud til, at ZFS er fuld af funktioner, som XFS mangler, men i virkeligheden er det kun en semantisk sejr. De fleste funktioner, der ofte prises af ZFS-fortalere, opstod ikke med ZFS og var almindeligt tilgængelige med de alternative filsystemer længe inden ZFS eksisterede. Men det er svært at sammenligne “gør dit filsystem det”, fordi svaret er “nej... mit RAID eller min logiske volumenmanager gør det.” Og i virkeligheden er det ikke ZFS-filsystemet, der leverer RAIDZ, det er ZFS-software-RAID-undersystemet, der gør det.

For at håndtere meget store filsystemer elegant blev dataintegritetsfunktioner bygget ind i ZFS, som inkluderede en checksum- eller hash-kontrol gennem hele filsystemet, der kunne udnytte det inkluderede software-RAID til at reparere beskadigede filer. Dette blev set som nødvendigt på grund af den forventede størrelse af ZFS-filsystemer i fremtiden. Filsystemkorruption er et sjældent fænomen, men efterhånden som filsystemer vokser i størrelse, øges risikoen. Denne mindre kendte funktion ved ZFS er muligvis dens største.

ZFS ændrede også, hvordan filsystemkontroller håndteres. På grund af antagelsen om, at ZFS vil blive brugt på meget store filsystemer, var der en reel frygt for, at en filsystemkontrol ved opstart kunne tage umuligt lang tid at fuldføre, og så blev der fundet en alternativ strategi. I stedet for at vente med at lave en kontrol ved genstart, ville systemet kræve, at en scrubbing-proces kørte og udførte en lignende kontrol, mens systemet kørte. Dette kræver mere systemoverhead, mens systemet er i live, men systemet er i stand til at komme sig hurtigere fra en uventet genstart. En afvejning, men en der er bredt set som meget positiv.

ZFS har kraftfulde snapshot-funktioner i dets logiske volumenlag, og i dets RAID-lag har det implementeret meget robuste cachingmekanismer, der gør ZFS til et glimrende valg til mange use cases. Disse funktioner er ikke unikke for ZFS, men er bredt tilgængelige i systemer ældre end ZFS. De er dog meget gode implementeringer af hver og meget godt integrerede på grund af ZFS’ natur.

På et tidspunkt var ZFS open source, og i den æra blev dets kode en del af Apples Mac OSX og FreeBSD-operativsystemerne, fordi de var kompatible med ZFS-licensen. Linux fik ikke ZFS på det tidspunkt på grund af udfordringer omkring licensering. Hvis ZFS-licensering havde tilladt Linux at bruge det ubegrænset, ville Linux-landskabet sandsynligvis være meget anderledes i dag. Mac OSX droppede til sidst ZFS, da det ikke blev set som at have nok fordele til at retfærdiggøre det i det miljø. FreeBSD holdt sig til ZFS, og over tid blev det det mest populære filsystem på platformen, selvom UFS stadig er meget brugt. Oracle lukkede kilden til ZFS efter Sun-overtagelsen, hvilket efterlod FreeBSD uden løbende opdateringer til sin version af ZFS, mens Oracle fortsatte med at udvikle ZFS internt til Solaris.

I dag bruger Solaris stadig den originale ZFS-implementering nu med adskillige opdateringer siden dens opsplitning fra open source-fællesskabet. FreeBSD og andre fortsatte med at bruge ZFS i den tilstand, det var i, da koden blev lukket, og har ikke længere adgang til Oracles seneste opdateringer. Til sidst blev arbejdet med at opdatere den forladte open source ZFS-kodebase taget op og er nu kendt som OpenZFS. OpenZFS er stadig i sin vorden og har endnu ikke rigtig sat sit præg, men har et vist potentiale for at genoplive ZFS-platformen i open source-rummet, men på dette tidspunkt halter OpenZFS stadig efter ZFS.

Open source-udviklingen de seneste år på dette område har fokuseret mere på ZFS’ nye rival BtrFS, der bliver udviklet nativt på Linux og er godt understøttet af mange store operativsystemleverandører. BtrFS er meget ny, men gør store fremskridt for at nå funktionsparitet med ZFS i implementerede funktioner, men har store ambitioner og har på grund af ZFS’ lukkede kilde fordelen af markedsmomentet. BtrFS blev startet, ligesom ZFS, af Oracle og er bredt set som Oracles syn på fremtiden som en erstatning for ZFS selv hos Oracle. På dette tidspunkt har BtrFS allerede, ligesom ZFS, fusioneret filsystemet, logisk volumenadministration og software-RAID-lag, implementeret checksumming for filsystemintegritet, skalerer endnu større end ZFS (samme absolutte grænse, men håndterer flere filer), copy-on-write snapshots osv.

ZFS var uden tvivl et fantastisk filsystem i sin storhedstid og er fortsat en leder i dag. Jeg var fortaler for det i 2005, og jeg tror stadig kraftigt på det. Men det har bedrøvet mig at se fællesskabet omkring ZFS tage en iver og nidkærhed til sig, der ikke tjener det godt og gør nævnelsen af ZFS næsten til noget negativt – ZFS der så universelt vælges af de forkerte årsager: primært en tro på, at dets funktioner ikke findes andetsteds, at dets RAID ikke er underlagt de risici og begrænsninger, som disse RAID-niveauer altid er underlagt, eller at det er designet til et andet formål (primært ydeevne) end det, det er designet til. Og når ZFS er et godt valg, implementeres det ofte dårligt baseret på usande antagelser.

ZFS er naturligvis ikke skyldig. Heller ikke, så vidt jeg kan se, er dets virksomhedsmæssige støtter eller dets open source-udviklere. Hvor ZFS ser ud til at være gået galt, er i et løst, uofficielt fællesskab, der kun for nylig er kommet til at kende ZFS, der ofte tror, det er nyt eller “næste generation”, fordi de kun for nylig opdagede det. Ud fra hvad jeg har set, sker dette næsten aldrig via Solaris- eller FreeBSD-kanaler, men næsten udelukkende mindre virksomheder, der ønsker at bruge et pakkeret “NAS OS” som FreeNAS eller NAS4Free, der ikke er fortrolige med UNIX-OS'er. Brugen af pakkerede NAS OS'er, primært af IT-afdelinger, der hverken besidder dybe UNIX- eller lagerfærdigheder og følgelig ringe eksponering for den bredere verden af filsystemer uden for Windows og ofte lidt til ingen eksponering for logisk volumenadministration og RAID, især software-RAID overhovedet, ser ud til at føre til en “myte”-kultur omkring ZFS med det, der tager en næsten uantastelig, ufejlbarlig status til sig.

Denne kultlignende tilhængerbase og generelle misforståelse af ZFS fører ofte til fejlagtige applikationer af ZFS eller en kæde af beslutningstagning baseret på dårlige antagelser, der kan lede én meget på afveje.

En af de mest fantastiske ændringer på dette område er skiftet i tilhængerbase fra hardware-RAID til software-RAID. Traditionelt var software-RAID en paria i Windows-administrationskredse uden god grund – Windows-administratorer og små virksomheder, der ofte ikke var fortrolige med større UNIX-servere, troede, at hardware-RAID var allestedsnærværende, når det faktisk altid var software-RAID, der blev brugt i større skala systemer. Hardware-RAID var næsten branchebred betragtet som en nødvendighed, og software-RAID blev fuldstændigt afvist. Det samme publikum, nu konfronteret med “ZFS-kult”-bevægelsen, reagerer nu nøjagtigt på den modsatte måde, idet de tror, at hardware-RAID er dårligt, og at ZFS’ software-RAID er den eneste levedygtige mulighed. Skiftet er dramatisk, og ingen af tilgangene er gyldige – både hardware- og software-RAID og begge i mange implementeringer er meget gyldige muligheder, og selv ved brug af ZFS kan brugen af hardware-RAID let være passende.

ZFS vælges ofte, fordi man tror, det er den højest ydende mulighed i filsystemer, men dette var aldrig et nøgledesignmål for ZFS. De funktioner, der giver det mulighed for at skalere så stort og håndtere så mange forskellige aspekter af lagring, gør det faktisk meget vanskeligt at være højtydende. ZFS, på tidspunktet for dets oprettelse, forventedes ikke engang at være så hurtig som det ærvædige UFS, der kørte på de samme systemer. Dette er dog ofte sekundært i forhold til det faktum, at filsystemydeevne er bredt set som ligegyldig, da alle moderne filsystemer er ekstremt hurtige, og filsystemhastighed sjældent er en vigtig faktor – især uden for massive, højintensive lagersystemer i meget stor skala.

En interessant undersøgelse af ti filsystemer på Linux udgivet af Phoronix i 2013 viste massive forskelle i filsystemer efter arbejdsbelastning, men ingen klare vindere hvad angår overordnet ydeevne. Det undersøgelsen viste konkluderende, er, at matchning af arbejdsbelastning til filsystem er det vigtigste valg, at ZFS falder til den langsommere side af alle mainstream-filsystemer selv i dets mere moderne implementeringer, og at valg af et filsystem af ydeevnemæssige årsager uden en meget dyb forståelse af arbejdsbelastningen vil resultere i uforudsigelig ydeevne – intet filsystem bør vælges i blinde, hvis ydeevne er en vigtig faktor. Desværre, fordi testen blev udført på Linux, manglede den UFS, der ofte er ZFS’ nøglekonkurrent, især på Solaris og FreeBSD, og den manglede HFS+ fra Mac OSX.

Flytning fra hardware-RAID til software-RAID medfører yderligere, ofte uforudsete risici for shops, der ikke er erfarne med UNIX. Mens ZFS tillader hot swapping, glemmes det ofte, at hot swap primært er en hardwarefunktion, ikke en softwarefunktion, og det er også bredt ukendt, at blind swapping (fjernelse af harddiske uden først at tage dem offline i operativsystemet) ikke er synonymt med hot swapping, og dette kan føre til katastrofer for shops, der bevæger sig fra en tradition med hardware-RAID, der håndterede kompatibilitet, hot swap og blind swapping gennemsigtigt for dem, til et software-RAID-system, der kræver langt mere planlægning, koordination og forståelse af systemet for at bruge det sikkert.

En mindre, men stadig almindelig misforståelse af ZFS er, at det er et klynget filsystem egnet til brug på delte DAS- eller SAN-scenarier a la OCFS, VxFS og GFS2. ZFS er ikke et klynget filsystem og deler de samme begrænsninger i det rum som alle dets almindelige konkurrenter.

ZFS kan være et glimrende valg, men det er langt fra det eneste. ZFS kommer med store forbehold, ikke mindst de operativsystembegrænsninger, der er forbundet med det, og selvom det har mange fordele, er få, hvis nogen, unikke for ZFS, og det er meget sjældent, at nogen shop vil drage fordel af dem alle. Som med enhver teknologi er der afvejninger at gøre. Én størrelse passer ikke til alle. Nøglen til at vide, hvornår ZFS er det rigtige for dig, er at forstå, hvad ZFS er, hvad der er og ikke er unikt ved det, hvad dets designmål er, hvordan sammenligning af et lagersystem med et rent filsystem giver vildledende resultater, og hvilke iboende begrænsninger der er knyttet til det.

ZFS er et nøgleovervejelse og det almindelige valg, når Solaris eller FreeBSD er det valgte operativsystem. Med sjælden undtagelse bør operativsystemet aldrig vælges for ZFS, men ZFS bør i stedet ofte vælges, men ikke altid, når operativsystemet er valgt. OS'en bør drive filsystemvalgene i alle undtagen de sjældneste tilfælde. Valget af operativsystem er så dramatisk vigtigere end valget af filsystem.

ZFS kan bruges på Linux, men betragtes ikke som en enterprise-mulighed der, men mere som et hobbysystem til eksperimentering, da ingen enterprise-leverandør (som Red Hat, Suse eller Canonical) understøtter ZFS på Linux, og da Linux allerede har gode alternativer. En dag kan ZFS blive forfremmet til et førsteklasses filsystem i Linux, men dette forventes ikke, da BtrFS allerede er kommet ind i mainline-kernen og er inkluderet i produktionsudgivelser af adskillige store leverandører.

Mens ZFS vil ses i langt størstedelen af Solaris- og FreeBSD-installationer, er dette primært fordi det er rykket ind i positionen som standard-filsystem og ikke fordi det klart er det overlegne valg i disse tilfælde eller endog er blevet evalueret kritisk. ZFS er fuldt ud egnet til at være et almennyttigt filsystem, hvor det er nativt og understøttet.

Hvad er ZFS’ primære use case?

ZFS’ designmål og primære use case er for Solaris- og FreeBSD-open storage-systemer, der enten leverer delt lagring til andre servere eller som massive dataarkiver til lokalt installerede applikationer. I disse tilfælde virkelig skinner ZFS’ fokus på skalerbarhed og dataintegritet. ZFS læner sig kraftigt mod store og enterprise-skala shops og generelt væk fra anvendelighed i SMB-rummet, hvor Solaris- og FreeBSD-færdigheder samt storskala lagringsbehov er sjældne.

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