ZFS-kulten

Det er ganske vanlig at IT-kretser utvikler en viss kult-lignende eller “fanboy”-mentalitet. Hva som forårsaker denne reaksjonen på teknologier og produkter er jeg ikke helt sikker på, men at det skjer er ubestridelig. Ett område der jeg aldri trodde jeg ville se dette skje, er innenfor filsystemer – en av de mest “under panseret”-systemkomponentene og en som, inntil nylig, bokstavelig talt ikke mottok noen oppmerksomhet selv i ganske tekniske kretser. La oss innse det, misforståelse av hva som kommer fra Active Directory versus fra NTFS er nesten universell. Filsystemer er, rett og slett, ignorert. Siden Windows NT 4 ble lansert og NTFS var det eneste levedyktige alternativet, har ideen om at et filsystem ikke er en iboende komponent av et operativsystem og at det kan finnes andre alternativer for fillagring nesten fullstendig forsvunnet. Det vil si, inntil nylig.

Det ene fellesskapet der dette, i noen liten grad, ikke skjedde, var Linux-fellesskapet, men selv der vant Ext2 og dens etterkommere så fullstendig i bevissthet at selv om de var allment tilgjengelige, var alternative filsystemer satt på sidelinjen, og bare XFS fikk noen oppmerksomhet, historisk sett, og selv det fikk svært lite.

Der noe virkelig merkelig adferd har forekommet, mer nylig, er rundt Oracles ZFS-filsystem, opprinnelig utviklet for Solaris-operativsystemet og X4500 “Thumper”-åpen lagringsplattform (opprinnelig under Sun, før Oracle-oppkjøpet.) På det tidspunktet (ni år siden) da ZFS ble lansert, var konkurrerende filsystemer for det meste dårlig forberedt på å håndtere store diskarrayer som forventet å bli laget de kommende årene. ZFS var designet for å håndtere dem og innvarslet æraen med storskala filsystemer. Som de fleste filsystemer på den tiden var ZFS begrenset til et enkelt operativsystem, og så, selv om det ble ansett som et stort fremskritt innen filsystemdesign, skapte det få ringvirkninger i lagringsverdenen og enda færre i “systemer”-verdenen, der selv Solaris-administratorer generelt betraktet det som et interessepunkt kun for ganske lang tid, og valgte for det meste å holde seg til den velprøvde UFS som de hadde brukt i mange år.

ZFS var, virkelig, et banebrytende filsystem, og jeg var, og er fortsatt, en stor tilhenger av det. Men det er svært viktig å forstå hvorfor ZFS gjorde det det gjorde, hva målene er, hvorfor disse målene var viktige og hvordan det gjelder oss i dag. Kompleksiteten til ZFS har ført til mye forvirring og misforståelse om hvordan filsystemet fungerer og når det er passende å bruke.

Hovedmålene til ZFS var å lage et filsystem som skalerte godt til svært store diskarrayer. På tidspunktet for introduksjonen var skalaen ZFS var i stand til uhørt i andre filsystemer, men det var ingen reell behov for at et filsystem skulle vokse så stort. Innen behovet oppsto, hadde mange andre filsystemer som NTFS, XFS, Ext3 og andre skalert for å imøtekomme behovet. ZFS ledet definitivt an mot større filsystemhåndtering, men ble raskt fulgt av mange andre.

Fordi ZFS stammer fra Solaris-verdenen der, som alle store UNIX-systemer, det ikke er noen maskinvare-RAID, måtte programvare-RAID brukes. Solaris hadde alltid hatt programvare-RAID tilgjengelig som sitt eget undersystem. Beslutningen ble tatt om å bygge en ny programvare-RAID-implementasjon direkte inn i ZFS. Dette ville muliggjøre forenklet administrasjon via ett enkelt verktøysett for både RAID-laget og filsystemet. Det introduserte ingen vesentlig endring eller fordel for ZFS, slik det ofte tros; det skiftet ganske enkelt grensesnittet for programvare-RAID-laget fra å ha sitt eget kommandosett til å bli en del av ZFS-kommandosettet.

ZFS’ implementasjon av RAID introduserte variable breddestriper i paritetens RAID-nivåer. Denne innovasjonen lukket en mindre paritet-RAID-risiko kjent som “write hole”. Denne innovasjonen var svært fin, men kom svært sent, ettersom æraen med pålitelig paritet-RAID begynte å ta slutt og write hole-problemet allerede ble ansett som en unevnt “bakgrunnsstøy”-risiko ved paritetarrayer, da det generelt ikke ble ansett som en trussel på grunn av eliminering gjennom bruk av batteribackede array-cacher og, omtrent på samme tid, ikke-flyktige array-cacher – unngå strømbrudd og du unngår write hole. ZFS trengte å adressere dette problemet fordi, som programvare-RAID, var det mer utsatt for write hole enn maskinvare-RAID er, fordi det ikke er mulighet for en cache beskyttet mot strømbrudd – maskinvare-RAID tilbyr potensialet for et ekstra lag av strømbeskyttelse for arrayer.

Den virkelige “innovasjonen” ZFS utilsiktet gjorde, var at i stedet for bare å implementere de vanlige RAID-nivåene 1, 5, 6 og 10, “merket” de disse nivåene med sine egne navnekonvensjoner. RAID 5 er kjent som RAIDZ. RAID 6 er kjent som RAIDZ2. RAID 1 er bare kjent som speiling. Og så videre. Dette ble på den tiden allment ansett som dumt og unødvendig forvirrende, men, som det viste seg, ble den forvirringen hjørnesteinen i ZFS’ gjenopplivelse mange år senere.

Det bør bemerkes at ZFS senere la til bransjens første produksjonsimplementasjon av et RAID 7 (også kjent som RAID 7.3) trippelparitet RAID-system og merket det RAIDZ3. Dette senere tillegget er en viktig innovasjon for storskala arrayer som trenger det ypperste i kapasitet mens de forblir ekstremt trygge, men er villige til å ofre ytelse for å gjøre det. Dette forblir en unik funksjon ved ZFS, men en som sjelden brukes.

I ånden av å kollapse lagringsstakken og bruke ett enkelt kommandosett for å administrere alle aspekter av lagring, ble de logiske volumhåndteringsfunksjonene rullet inn i ZFS også. Det er ofte feilaktig antatt at ZFS introduserte logisk volumhåndtering i visse kretser, men nesten alle enterprise-plattformer, inkludert AIX, Linux, Windows og til og med Solaris selv, hadde allerede hatt logisk volumhåndtering i mange år. ZFS gjorde ikke dette for å introdusere et nytt paradigme, men rett og slett for å konsolidere administrasjonen og pakke alle tre nøkkel lagringslag (RAID, logisk volumhåndtering og filsystem) inn i én enkelt enhet som ville være enklere å administrere og kunne gi iboende kommunikasjon opp og ned i stakken. Det er fordeler og ulemper med denne metoden, og en bransjemening forblir uformet nesten et tiår senere.

Et av de viktigste aspektene ved denne konsolideringen av tre systemer til ett, er at vi nå har et svært forvirrende produkt å diskutere. ZFS er et filsystem, ja, men det er ikke bare et filsystem. Det er en logisk volumhåndterer, men ikke bare en logisk volumhåndterer. Folk omtaler ZFS som et filsystem, som er dets primære funksjon, men at det er så mye mer enn et filsystem kan være svært forvirrende og gjør sammenligninger mot andre lagringssystemer vanskelige. På den tiden tror jeg at denne forvirringen ikke ble forutsett.

Det som har resultert fra denne forvirrende sammenslåingen, er at ZFS ofte sammenlignes med andre filsystemer, som XFS eller Ext4. Men dette er forvirrende, da ZFS er en komplett stakk og XFS bare er ett aspekt av en stakk. ZFS ville bedre sammenlignes med MD (Linux Software RAID) / LVM / XFS eller med SmartArray (HP Hardware RAID) / LVM/ XFS enn med XFS alene. Ellers fremstår det som om ZFS er full av funksjoner som XFS mangler, men i virkeligheten er det bare en semantisk seier. De fleste funksjonene som ofte fremheves av ZFS-forkjempere stammer ikke fra ZFS og var allment tilgjengelige med de alternative filsystemene lenge før ZFS eksisterte. Men det er vanskelig å sammenligne “gjør filsystemet ditt det” fordi svaret er “nei…. RAID-en min eller den logiske volumhåndtereren min gjør det.” Og det er virkelig ikke ZFS filsystemet som gir RAIDZ; det er ZFS programvare-RAID-undersystemet som gjør det.

For å håndtere svært store filsystemer på en smidig måte, ble dataintegritetsfunksjoner bygget inn i ZFS, som inkluderte en sjekksum eller hash-sjekk gjennom hele filsystemet som kunne utnytte den inkluderte programvare-RAID-en til å reparere korrupte filer. Dette ble ansett som nødvendig på grunn av den forventede størrelsen på ZFS-filsystemer i fremtiden. Filsystemkorrupsjon er et sjelden sett fenomen, men ettersom filsystemer vokser i størrelse øker risikoen. Denne mindre kjente funksjonen ved ZFS er muligens den største.

ZFS endret også hvordan filsystemsjekker håndteres. På grunn av antagelsen om at ZFS vil brukes på svært store filsystemer, var det en genuin frykt for at en filsystemsjekk ved oppstartstidspunktet kunne ta umulig lang tid å fullføre, og så ble en alternativ strategi funnet. I stedet for å vente med å gjøre en sjekk ved omstart, ville systemet kreve at en skrubbingsprosess kjøres og utfører en lignende sjekk mens systemet kjørte. Dette krever mer systemoverhead mens systemet er i live, men systemet er i stand til å komme seg etter en uventet omstart raskere. En avveining, men en som er allment sett som svært positiv.

ZFS har kraftige snapshotfunksjoner i det logiske volumlaget, og i RAID-laget har det implementert svært robuste hurtigbuffermekanismer, noe som gjør ZFS til et utmerket valg for mange brukstilfeller. Disse funksjonene er ikke unike for ZFS, men er allment tilgjengelige i systemer eldre enn ZFS. De er imidlertid svært gode implementasjoner av hver enkelt og svært godt integrert på grunn av ZFS’ natur.

På ett tidspunkt var ZFS åpen kildekode, og i den perioden ble koden en del av Apples Mac OSX og FreeBSD operativsystemer fordi de var kompatible med ZFS-lisensen. Linux fikk ikke ZFS på det tidspunktet på grunn av utfordringer rundt lisensiering. Hadde ZFS-lisensiering tillatt Linux å bruke det ubegrenset, ville Linux-landskapet sannsynligvis vært svært annerledes i dag. Mac OSX droppet til slutt ZFS da det ikke ble ansett å ha nok fordeler til å rettferdiggjøre det i det miljøet. FreeBSD holdt fast ved ZFS, og over tid ble det det mest populære filsystemet på plattformen, selv om UFS fortsatt brukes mye. Oracle lukket kilden til ZFS etter Sun-oppkjøpet, og lot FreeBSD stå uten fortsatte oppdateringer til sin versjon av ZFS mens Oracle fortsatte å utvikle ZFS internt for Solaris.

I dag forblir Solaris ved den opprinnelige ZFS-implementasjonen med nå flere oppdateringer siden splittelsen med åpen kildekode-fellesskapet. FreeBSD og andre fortsatte å bruke ZFS i den tilstanden det var da koden ble lukket, uten lenger å ha tilgang til Oracles siste oppdateringer. Til slutt ble arbeidet med å oppdatere den forlatte åpen kildekode-ZFS-kodebasen tatt opp og er nå kjent som OpenZFS. OpenZFS er fortsatt i sin spede begynnelse og har ennå ikke virkelig gjort seg bemerket, men har noe potensial for å revitalisere ZFS-plattformen i åpen kildekode-rommet, men på dette tidspunktet henger OpenZFS fortsatt etter ZFS.

Åpen kildekode-utvikling de siste årene i dette rommet har fokusert mer på ZFS’ nye rival BtrFS, som utvikles innebygd på Linux og har god støtte fra mange store operativsystemleverandører. BtrFS er svært nytt, men gjør store fremskritt for å nå funksjonparitet med ZFS i implementerte funksjoner, men har store ambisjoner, og på grunn av ZFS’ lukkede kildekode-natur har den fordelen av markedsdynamikk. BtrFS ble startet, som ZFS, av Oracle og har blitt allment ansett som Oracles syn på fremtiden som en erstatning for ZFS selv hos Oracle. På dette tidspunktet har BtrFS allerede, som ZFS, slått sammen filsystemet, logisk volumhåndtering og programvare-RAID-lagene, implementert sjekksumming for filsystemintegritet, skalerer enda større enn ZFS (samme absolutte grense, men håndterer flere filer), copy-on-write-snapshots osv.

ZFS var uten tvil et fantastisk filsystem i sin storhetstid og er fortsatt et av de ledende i dag. Jeg var en tilhenger av det i 2005 og tror fortsatt sterkt på det. Men det har bedrøvet meg å se fellesskapet rundt ZFS ta på seg en glød og nidkjærhet som ikke tjener det, og som gjør at omtalen av ZFS nesten virker negativ – ZFS som så universelt velges av feil grunner: primært en tro på at funksjonene ikke finnes noe annet sted, at RAID-en ikke er underlagt de risikoene og begrensningene som de RAID-nivåene alltid er underlagt, eller at det ble designet for et annet formål (primært ytelse) enn det det ble designet for. Og når ZFS er et godt valg, er det ofte implementert dårlig basert på usanne antagelser.

ZFS er selvfølgelig ikke å klandre. Heller ikke, så vidt jeg kan bedømme, er dets bedriftsstøttespillere eller dets åpen kildekode-utviklere. Der ZFS ser ut til å ha gått galt er i et løst, uoffisielt fellesskap som bare nylig har blitt kjent med ZFS, og som ofte tror at det er nytt eller “neste generasjon” fordi de bare nylig har oppdaget det. Ut fra det jeg har sett er dette nesten aldri via Solaris- eller FreeBSD-kanaler, men nesten utelukkende mindre bedrifter som ønsker å bruke et pakkert “NAS OS” som FreeNAS eller NAS4Free, som ikke er kjent med UNIX-OS-er. Bruken av pakkede NAS-OS-er, primært av IT-avdelinger som verken har dyp UNIX- eller lagringskompetanse og, følgelig, liten eksponering mot den bredere verdenen av filsystemer utenfor Windows og ofte liten til ingen eksponering mot logisk volumhåndtering og RAID, særlig programvare-RAID overhodet, ser ut til å lede til en “myte”-kultur rundt ZFS, der det inntar en nesten uangripelig, ufeilbarlig status.

Denne kult-lignende følgen og generelle misforståelsen av ZFS fører ofte til feilanvendelser av ZFS eller en kjede av beslutningsprosesser basert på dårlige antagelser som kan føre én langt på avveie.

En av de mest forbløffende endringene i dette rommet er skiftet i tilhengere fra maskinvare-RAID til programvare-RAID. Tradisjonelt var programvare-RAID en paria i Windows-administrasjonskretser uten god grunn – Windows-administratorer og små bedrifter, som ofte ikke var kjent med større UNIX-servere, trodde at maskinvare-RAID var universelt når, i virkeligheten, brukte systemer i større skala alltid programvare-RAID. Maskinvare-RAID ble nesten industri-bredt ansett som en nødvendighet, og programvare-RAID ble fullstendig avvist. Det samme publikumet, nå konfrontert med “ZFS-kulten”-bevegelsen, reagerer nå på nøyaktig motsatt måte, og tror at maskinvare-RAID er dårlig og at ZFS’ programvare-RAID er det eneste levedyktige alternativet. Skiftet er dramatisk, og ingen av tilnærmingene er gyldige – både maskinvare- og programvare-RAID, og begge i mange implementasjoner, er svært gyldige alternativer, og til og med ved bruk av ZFS kan bruk av maskinvare-RAID lett være hensiktsmessig.

ZFS velges ofte fordi det antas å være det høyeste ytelsesalternativet innen filsystemer, men dette var aldri et nøkkeldesignmål for ZFS. Funksjonene som lar det skalere så stort og håndtere så mange forskjellige aspekter av lagring, gjør det faktisk svært vanskelig å være høyt ytende. ZFS, på tidspunktet for opprettelsen, ble ikke engang forventet å være like raskt som den ærverdige UFS som kjørte på de samme systemene som det. Imidlertid er dette ofte sekundært til det faktum at filsystemytelse er allment uvesentlig, da alle moderne filsystemer er ekstremt raske og filsystemhastighet sjelden er en viktig faktor – særlig utenfor massive, høyende lagringssystemer i svært stor skala.

En interessant studie av ti filsystemer på Linux produsert av Phoronix i 2013 viste massive forskjeller i filsystemer etter arbeidsbelastning, men ingen klare vinnere når det gjelder samlet ytelse. Det studien viste konklusivt er at å matche arbeidsbelastning til filsystem er det viktigste valget, at ZFS faller på den tregere siden av alle mainstream-filsystemer selv i sine mer moderne implementasjoner, og at valg av et filsystem av ytelsesårsaker uten en svært dyp forståelse av arbeidsbelastningen vil resultere i uforutsigbar ytelse – ingen filsystem bør velges blindt hvis ytelse er en viktig faktor. Dessverre, fordi testen ble utført på Linux, manglet den UFS som ofte er ZFS’ viktigste konkurrent, særlig på Solaris og FreeBSD, og den manglet HFS+ fra Mac OSX.

Å flytte fra maskinvare-RAID til programvare-RAID medfører også ytterligere, ofte uforutsette risikoer for butikker som ikke har erfaring med UNIX. Selv om ZFS tillater hot swap, er det ofte glemt at hot swap primært er en funksjon av maskinvare, ikke av programvare, og det er også allment ukjent at blind swapping (fjerning av harddisker uten først å ta dem offline i operativsystemet) ikke er synonymt med hot swapping, og dette kan føre til katastrofer for butikker som beveger seg fra en tradisjon med maskinvare-RAID som håndterte kompatibilitet, hot swap og blind swapping transparent for dem, til et programvare-RAID-system som krever mye mer planlegging, koordinering og forståelse av systemet for å bruke trygt.

En mindre, men fortsatt vanlig misoppfatning om ZFS, er at det er et klustret filsystem egnet for bruk i delte DAS- eller SAN-scenarier a la OCFS, VxFS og GFS2. ZFS er ikke et klustret filsystem og deler de samme begrensningene i det rommet som alle sine vanlige konkurrenter.

ZFS kan være et utmerket valg, men det er langt fra det eneste. ZFS kommer med store forbehold, ikke minst operativsystembegrensningene forbundet med det, og selv om det har mange fordeler, er få, om noen, unike for ZFS, og det er svært sjelden at noen virksomhet vil dra nytte av alle av dem. Som med enhver teknologi er det avveininger som må gjøres. Én størrelse passer ikke alle. Nøkkelen til å vite når ZFS er riktig for deg, er å forstå hva ZFS er, hva som er og ikke er unikt med det, hva designmålene er, hvordan sammenligning av et lagringslagersystem med et rent filsystem produserer villedende resultater og hvilke iboende begrensninger som er knyttet til det.

ZFS er en nøkkelbetraktning og det vanlige valget når Solaris eller FreeBSD er det valgte operativsystemet. Med sjeldne unntak bør operativsystemet aldri velges for ZFS, men i stedet bør ZFS ofte velges, men ikke alltid, når operativsystemet er valgt. OS-et bør drive filsystemvalgene i alle unntatt de sjeldneste tilfellene. Valget av operativsystem er så dramatisk mye viktigere enn valget av filsystem.

ZFS kan brukes på Linux, men regnes ikke som et enterprise-alternativ der, men mer som et hobbysystem for eksperimentering, da ingen enterprise-leverandør (som Red Hat, Suse eller Canonical) støtter ZFS på Linux, og siden Linux allerede har gode alternativer. En dag kan ZFS bli forfremmet til et førsteklasses filsystem i Linux, men dette er ikke forventet, da BtrFS allerede har entret mainline-kjernen og blitt inkludert i produksjonsutgivelser av flere store leverandører.

Selv om ZFS vil bli sett i det store flertallet av Solaris- og FreeBSD-distribusjoner, er dette primært fordi det har beveget seg inn i posisjonen som standardfilsystem og ikke fordi det er klart det overlegne valget i disse tilfellene eller til og med har blitt kritisk evaluert. ZFS er fullt ut egnet til å være et generelt filsystem der det er innebygd og støttet.

Hva er ZFS’ primære brukstilfelle?

ZFS’ designmål og primære brukstilfelle er for Solaris- og FreeBSD-åpne lagringssystemer som enten gir delt lagring til andre servere eller som massive datalagre for lokalt installerte applikasjoner. I disse tilfellene virkelig lyser ZFS’ fokus på skalerbarhet og dataintegritet. ZFS lener seg tungt mot store og enterprise-skala virksomheter og generelt bort fra anvendelighet i SMB-markedet der Solaris- og FreeBSD-ferdigheter, samt storskala lagringsbehov, er sjeldne.

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