ZFS-kulten

Det är ganska vanligt att IT-kretsar utvecklar en viss kult- eller “fanboy”-mentalitet. Vad som orsakar denna reaktion på teknologier och produkter är jag inte helt säker på, men att det sker går inte att förneka. Ett område där jag aldrig trodde att jag skulle få se detta inträffa är inom filsystemen – en av de mest “under huven”-aktiga systemkomponenterna och en som, fram tills nyligen, bokstavligen inte fick någon uppmärksamhet ens i hyfsat tekniska kretsar. Vi får helt enkelt erkänna att missförstånd om när något kommer från Active Directory snarare än från NTFS är nästan allmänt utbrett. Filsystem är, helt enkelt, ignorerade. Ända sedan Windows NT 4 släpptes och NTFS var det enda gångbara alternativet har idén att ett filsystem inte är en inneboende komponent i ett operativsystem och att det kan finnas andra alternativ för fillagring så gott som bleknat bort. Det vill säga, fram tills nyligen.

Den enda gemenskap där detta, i någon liten utsträckning, inte inträffade var Linux-gemenskapen, men även där vann Ext2 och dess efterföljare så fullständigt mindshare att även om de var allmänt tillgängliga blev alternativa filsystem åsidosatta och endast XFS fick någon uppmärksamhet historiskt sett, och även det fick väldigt lite.

Där ett verkligt märkligt beteende har uppstått, på senare tid, är kring Oracles ZFS-filsystem, ursprungligen utvecklat för operativsystemet Solaris och den öppna lagringsplattformen X4500 “Thumper” (ursprungligen i Suns regi före Oracles förvärv). Vid den tidpunkten (för nio år sedan) då ZFS släpptes var konkurrerande filsystem för det mesta dåligt rustade för att hantera de stora diskarrayer som förväntades komma att byggas under de kommande åren. ZFS var designat för att hantera dem och inledde tidsåldern av storskaliga filsystem. Liksom de flesta filsystem vid den tiden var ZFS begränsat till endast ett enda operativsystem och därför, även om det allmänt betraktades som ett stort steg framåt inom filsystemsdesign, skapade det få ringar på vattnet i lagringsvärlden och ännu färre i “system”-världen där till och med Solaris-administratörer i allmänhet betraktade det som en kuriositet under ganska lång tid, och för det mesta valde att hålla sig till det beprövade och pålitliga UFS som de hade använt i många år.

ZFS var, verkligen, ett banbrytande filsystem och jag var, och förblir, en stor förespråkare för det. Men det är mycket viktigt att förstå varför ZFS gjorde det det gjorde, vilka dess mål är, varför dessa mål var viktiga och hur det är tillämpligt på oss idag. Komplexiteten i ZFS har lett till mycket förvirring och missförstånd om hur filsystemet fungerar och när det är lämpligt att använda.

De huvudsakliga målen med ZFS var att skapa ett filsystem som kunde skala väl till mycket stora diskarrayer. Vid tidpunkten för dess introduktion var den skala som ZFS klarade av aldrig tidigare skådad i andra filsystem, men det fanns inget verkligt behov av att ett filsystem skulle kunna växa så stort. När behovet väl uppstod hade många andra filsystem såsom NTFS, XFS, Ext3 och andra skalat för att möta behovet. ZFS ledde förvisso vägen mot hantering av större filsystem men fick snart sällskap av många andra.

Eftersom ZFS hade sitt ursprung i Solaris-världen där, liksom i alla stora UNIX-system, det inte finns någon hårdvaru-RAID, var man tvungen att använda mjukvaru-RAID. Solaris hade alltid haft mjukvaru-RAID tillgängligt som sitt eget delsystem. Beslutet fattades att bygga in en ny mjukvaru-RAID-implementering direkt i ZFS. Detta skulle möjliggöra förenklad hantering via en enda uppsättning verktyg för både RAID-lagret och filsystemet. Det införde ingen betydande förändring eller fördel för ZFS, som ofta tros, det flyttade helt enkelt gränssnittet för mjukvaru-RAID-lagret från att vara sin egen uppsättning kommandon till att vara en del av ZFS-kommandouppsättningen.

ZFS implementering av RAID införde stripes med variabel bredd i paritets-RAID-nivåer. Denna innovation täppte till en mindre paritets-RAID-risk känd som “skrivhålet”. Denna innovation var mycket trevlig men kom väldigt sent eftersom eran av tillförlitlig paritets-RAID började gå mot sitt slut och skrivhålsproblemet redan betraktades som en outtalad “bakgrundsbrus”-risk hos paritetsarrayer eftersom det i allmänhet inte ansågs vara ett hot, tack vare att det eliminerades genom användning av batteribackade arraycacher och, ungefär samtidigt, icke-flyktiga arraycacher – undvik strömavbrott och du undviker skrivhålet. ZFS behövde ta itu med denna fråga eftersom det, som mjukvaru-RAID, löpte större risk för skrivhålet än vad hårdvaru-RAID gör, eftersom det inte finns någon möjlighet till en cache skyddad mot strömavbrott – hårdvaru-RAID erbjuder potentialen för ytterligare ett lager av strömskydd för arrayer.

Den verkliga “innovation” som ZFS oavsiktligt gjorde var att i stället för att bara implementera de vanliga RAID-nivåerna 1, 5, 6 och 10 så “varumärkte” de i stället dessa nivåer med sina egna namnkonventioner. RAID 5 är känt som RAIDZ. RAID 6 är känt som RAIDZ2. RAID 1 är helt enkelt känt som speglning. Och så vidare. Detta betraktades allmänt som fånigt vid den tiden och meningslöst förvirrande men, som det visade sig, blev den förvirringen hörnstenen i ZFS återupplivande många år senare.

Det bör noteras att ZFS senare lade till branschens första produktionsimplementering av en RAID 7 (alias RAID 7.3) trippelparitets-RAID-system och varumärkte det RAIDZ3. Detta senare tillägg är en viktig innovation för storskaliga arrayer som behöver yttersta kapacitet samtidigt som de förblir extremt säkra men är villiga att offra prestanda för att göra det. Detta förblir en unik egenskap hos ZFS men en som sällan används.

I andan av att slå samman lagringsstacken och använda en enda kommandouppsättning för att hantera alla aspekter av lagring rullades funktionerna för logisk volymhantering in i ZFS också. Det tros ofta felaktigt att ZFS införde logisk volymhantering i vissa kretsar, men nästan alla företagsplattformar, inklusive AIX, Linux, Windows och till och med Solaris självt, hade redan haft logisk volymhantering i många år. ZFS gjorde inte detta för att införa ett nytt paradigm utan helt enkelt för att konsolidera hanteringen och innesluta alla tre nyckellagren för lagring (RAID, logisk volymhantering och filsystem) i en enda enhet som skulle vara lättare att hantera och kunna tillhandahålla inneboende kommunikation upp och ner genom stacken. Det finns för- och nackdelar med denna metod och en branschuppfattning förblir oformad nästan ett decennium senare.

En av de viktigaste aspekterna av denna konsolidering av tre system till ett är att vi nu har en mycket förvirrande produkt att diskutera. ZFS är ett filsystem, ja, men det är inte bara ett filsystem. Det är en logisk volymhanterare, men inte bara en logisk volymhanterare. Folk refererar till ZFS som ett filsystem, vilket är dess primära funktion, men att det är så mycket mer än ett filsystem kan vara mycket förvirrande och gör jämförelser mot andra lagringssystem svåra. Vid den tiden tror jag att denna förvirring inte förutsågs.

Vad som har resulterat från denna förvirrande sammanslagning är att ZFS ofta jämförs med andra filsystem, såsom XFS eller Ext4. Men detta är förvirrande eftersom ZFS är en komplett stack och XFS är endast en aspekt av en stack. ZFS skulle bättre jämföras med MD (Linux mjukvaru-RAID) / LVM / XFS eller med SmartArray (HP hårdvaru-RAID) / LVM / XFS än med XFS ensamt. Annars framstår det som att ZFS är fullt av funktioner som XFS saknar men, i verkligheten, är det bara en semantisk seger. De flesta av de funktioner som ofta lyfts fram av ZFS-förespråkare hade inte sitt ursprung i ZFS och fanns allmänt tillgängliga med de alternativa filsystemen långt innan ZFS existerade. Men det är svårt att jämföra “gör ditt filsystem det” eftersom svaret är “nej…. min RAID eller min logiska volymhanterare gör det.” Och i sanning, det är inte ZFS filsystemet som tillhandahåller RAIDZ, det är ZFS mjukvaru-RAID-delsystemet som gör det.

För att på ett elegant sätt hantera mycket stora filsystem byggdes dataintegritetsfunktioner in i ZFS vilket inkluderade en kontrollsumma eller hashkontroll genom hela filsystemet som kunde utnyttja den inkluderade mjukvaru-RAID för att reparera korrupta filer. Detta sågs som nödvändigt på grund av den förväntade storleken på ZFS-filsystem i framtiden. Filsystemskorruption är ett sällan skådat fenomen men i takt med att filsystem växer i storlek ökar risken. Denna mindre kända funktion hos ZFS är möjligen dess främsta.

ZFS ändrade också hur filsystemskontroller hanteras. På grund av antagandet att ZFS kommer att användas på mycket stora filsystem fanns det en genuin rädsla för att en filsystemskontroll vid uppstart skulle kunna ta orimligt lång tid att slutföra och så hittades en alternativ strategi. I stället för att vänta med att göra en kontroll vid omstart skulle systemet kräva att en skrubbningsprocess körs och utför en liknande kontroll medan systemet är igång. Detta kräver mer systemoverhead medan systemet är aktivt men systemet kan återhämta sig från en oväntad omstart snabbare. En kompromiss men en som allmänt ses som mycket positiv.

ZFS har kraftfulla ögonblicksbildsfunktioner i sitt logiska volymlager och i sitt RAID-lager har det implementerat mycket robusta cachemekanismer vilket gör ZFS till ett utmärkt val för många användningsfall. Dessa funktioner är inte unika i ZFS utan finns allmänt tillgängliga i system äldre än ZFS. De är dock mycket goda implementeringar av var och en och mycket väl integrerade tack vare ZFS natur.

En gång i tiden var ZFS öppen källkod och under den eran blev dess kod en del av Apples Mac OSX och FreeBSD operativsystem eftersom de var kompatibla med ZFS-licensen. Linux fick inte ZFS vid den tiden på grund av utmaningar kring licensiering. Hade ZFS-licensieringen tillåtit Linux att använda det obehindrat skulle Linux-landskapet sannolikt se mycket annorlunda ut idag. Mac OSX övergav så småningom ZFS eftersom det inte ansågs ha tillräckliga fördelar för att motivera det i den miljön. FreeBSD höll fast vid ZFS och, med tiden, blev det det mest populära filsystemet på plattformen även om UFS fortfarande används flitigt också. Oracle stängde källkoden för ZFS efter Sun-förvärvet vilket lämnade FreeBSD utan fortsatta uppdateringar till sin version av ZFS medan Oracle fortsatte att utveckla ZFS internt för Solaris.

Idag fortsätter Solaris att använda den ursprungliga ZFS-implementeringen nu med flera uppdateringar sedan sin splittring med öppen källkods-gemenskapen. FreeBSD och andra fortsatte att använda ZFS i det skick det var när koden stängdes, utan längre tillgång till Oracles senaste uppdateringar. Så småningom togs arbetet med att uppdatera den övergivna ZFS-kodbasen med öppen källkod upp och är nu känt som OpenZFS. OpenZFS är fortfarande i sin linda och har ännu inte riktigt satt sin prägel men har viss potential att blåsa nytt liv i ZFS-plattformen i öppen källkods-utrymmet men för närvarande släpar OpenZFS fortfarande efter ZFS.

Öppen källkods-utveckling under de senaste åren i detta utrymme har fokuserat mer på ZFS nya rival BtrFS som utvecklas inföddt på Linux och har gott stöd från många stora operativsystemsleverantörer. BtrFS är mycket nytt men gör stora framsteg mot att nå funktionsparitet med ZFS i implementerade funktioner men har stora ambitioner och har på grund av ZFS stängda källkods-natur fördelen av marknadsmomentum. BtrFS startades, liksom ZFS, av Oracle och har allmänt setts som Oracles syn på framtiden, en ersättare för ZFS till och med hos Oracle. För närvarande har BtrFS redan, liksom ZFS, slagit samman filsystemet, den logiska volymhanteringen och mjukvaru-RAID-lagren, implementerat kontrollsummering för filsystemsintegritet, skalar ännu större än ZFS (samma absoluta gräns men hanterar fler filer), copy-on-write-ögonblicksbilder, osv.

ZFS var, utan tvekan, ett fantastiskt filsystem i sin storhetstid och förblir en ledare idag. Jag var en förespråkare för det 2005 och jag tror fortfarande starkt på det. Men det har bedrövat mig att se gemenskapen kring ZFS anta en hänförelse och fanatism som inte gör det någon tjänst och får omnämnandet av ZFS att nästan framstå som något negativt – ZFS blir så universellt valt av fel skäl: främst en övertygelse om att dess funktioner inte existerar någon annanstans, att dess RAID inte är föremål för de risker och begränsningar som dessa RAID-nivåer alltid är föremål för eller att det designades för ett annat syfte (främst prestanda) än vad det designades för. Och när ZFS är ett bra val implementeras det ofta dåligt baserat på osanna antaganden.

ZFS, naturligtvis, är inte att skylla på. Inte heller, så vitt jag kan se, är dess företagsstödjare eller dess öppen källkods-utvecklare det. Där ZFS verkar ha gått snett är i en lös, inofficiell gemenskap som först nyligen har kommit att lära känna ZFS, och ofta tror att det är nytt eller “nästa generation” eftersom de först nyligen har upptäckt det. Från vad jag har sett är detta nästan aldrig via Solaris- eller FreeBSD-kanaler utan nästan uteslutande mindre företag som vill använda ett paketerat “NAS-OS” som FreeNAS eller NAS4Free vilka inte är bekanta med UNIX-operativsystem. Användningen av paketerade NAS-operativsystem, främst av IT-verksamheter som varken besitter djupa UNIX- eller lagringsfärdigheter och, följaktligen, liten exponering för den bredare världen av filsystem utanför Windows och ofta liten till ingen exponering för logisk volymhantering och RAID, särskilt mjukvaru-RAID överhuvudtaget, verkar leda till en “myt”-kultur kring ZFS där det antar en nästan obestridlig, ofelbar status.

Denna kultliknande efterföljd och allmänna missförstånd av ZFS leder ofta till felaktiga tillämpningar av ZFS eller en kedja av beslutsfattande baserat på dåliga antaganden som kan leda en mycket vilse.

En av de mest häpnadsväckande förändringarna i detta utrymme är förändringen i efterföljd från hårdvaru-RAID till mjukvaru-RAID. Traditionellt var mjukvaru-RAID en paria i Windows-administrationskretsar utan god grund – Windows-administratörer och småföretag, ofta obekanta med större UNIX-servrar, trodde att hårdvaru-RAID var allestädes närvarande när, i själva verket, storskaliga system alltid använde mjukvaru-RAID. Hårdvaru-RAID betraktades, nästan branschövergripande, som en nödvändighet och mjukvaru-RAID undveks helt. Samma publik, nu konfronterad med rörelsen “ZFS-kulten”, reagerar nu på exakt motsatt sätt och tror att hårdvaru-RAID är dåligt och att ZFS mjukvaru-RAID är det enda gångbara alternativet. Skiftet är dramatiskt och ingetdera tillvägagångssättet är giltigt – både hårdvaru- och mjukvaru-RAID och bägge i många implementeringar är mycket giltiga alternativ och till och med när man använder ZFS kan användningen av hårdvaru-RAID lätt vara lämplig.

ZFS väljs ofta för att det tros att det är det högst presterande alternativet bland filsystem men detta var aldrig ett centralt designmål för ZFS. De funktioner som låter det skala så stort och hantera så många olika aspekter av lagring gör faktiskt att vara högpresterande mycket svårt. ZFS förväntades, vid tidpunkten för dess skapande, inte ens vara så snabbt som det vördade UFS som körde på samma system som det. Detta är dock ofta sekundärt till det faktum att filsystemsprestanda i stort är ovidkommande eftersom alla moderna filsystem är extremt snabba och filsystemshastighet sällan är en viktig faktor – särskilt utanför massiva, avancerade lagringssystem i mycket stor skala.

En intressant studie av tio filsystem på Linux framställd av Phoronix 2013 visade massiva skillnader mellan filsystem beroende på arbetsbelastning men inga tydliga vinnare vad gäller övergripande prestanda. Vad studien visade definitivt är att matcha arbetsbelastning mot filsystem är det viktigaste valet, att ZFS faller mot den långsammare sidan av alla vanligt förekommande filsystem även i sina mer moderna implementeringar och att välja ett filsystem av prestandaskäl utan en mycket djup förståelse av arbetsbelastningen kommer att resultera i oförutsägbar prestanda – inget filsystem bör väljas blint om prestanda är en viktig faktor. Tyvärr, eftersom testet gjordes på Linux, saknade det UFS som ofta är ZFS främsta konkurrent särskilt på Solaris och FreeBSD och det saknade HFS+ från Mac OSX.

Att flytta från hårdvaru-RAID till mjukvaru-RAID medför ytterligare, ofta oförutsedda risker för verksamheter som inte har erfarenhet av UNIX också. Även om ZFS tillåter hot swapping, glöms det ofta bort att hot swap främst är en funktion hos hårdvara, inte hos mjukvara, och det är också allmänt okänt att blind swapping (borttagning av hårddiskar utan att först ta dem offline i operativsystemet) inte är synonymt med hot swapping och detta kan leda till katastrofer för verksamheter som flyttar från en tradition av hårdvaru-RAID som hanterade kompatibilitet, hot swap och blind swapping transparent åt dem till ett mjukvaru-RAID-system som kräver mycket mer planering, samordning och förståelse av systemet för att kunna användas säkert.

En mindre, men fortfarande vanlig missuppfattning om ZFS, är att det är ett klustrat filsystem lämpligt för användning i scenarier med delad DAS eller SAN à la OCFS, VxFS och GFS2. ZFS är inte ett klustrat filsystem och delar samma begränsningar i det utrymmet som alla sina vanliga konkurrenter.

ZFS kan vara ett utmärkt val men det är långt ifrån det enda. ZFS kommer med stora förbehåll, inte minst de operativsystemsbegränsningar som är förknippade med det, och även om det har många fördelar är få, om ens någon, unika för ZFS och det är mycket sällsynt att någon verksamhet kommer att dra nytta av var och en av dem. Som med all teknik finns det kompromisser att göra. En storlek passar inte alla. Nyckeln till att veta när ZFS är rätt för dig är att förstå vad ZFS är, vad som är och inte är unikt med det, vilka dess designmål är, hur jämförelse av ett lagringssystem mot ett rent filsystem ger missvisande resultat och vilka inneboende begränsningar som är knutna till det.

ZFS är en viktig övervägning och det vanliga valet när Solaris eller FreeBSD är det valda operativsystemet. Med sällsynta undantag bör operativsystemet aldrig väljas för ZFS skull, utan i stället bör ZFS ofta väljas, men inte alltid, när operativsystemet väljs. Operativsystemet bör driva filsystemsvalen i alla utom de allra mest sällsynta fallen. Valet av operativsystem är så dramatiskt mycket viktigare än valet av filsystem.

ZFS kan användas på Linux men betraktas inte som ett företagsalternativ där utan mer som ett hobbysystem för experimenterande eftersom ingen företagsleverantör (såsom Red Hat, Suse eller Canonical) stödjer ZFS på Linux och eftersom Linux redan har utmärkta alternativ. Någon dag kan ZFS komma att befordras till ett förstklassigt filsystem i Linux men detta förväntas inte eftersom BtrFS redan har trätt in i huvudkärnan och inkluderats i produktionsutgåvor av flera stora leverantörer.

Även om ZFS kommer att ses i den stora majoriteten av Solaris- och FreeBSD-driftsättningar, är detta främst för att det har flyttat in i positionen som standardfilsystem och inte för att det tydligt är det överlägsna valet i dessa fall eller ens har utvärderats kritiskt. ZFS är ypperligt väl lämpat för att vara ett allmänt filsystem där det är inföddt och har stöd.

Vad är ZFS primära användningsfall?

ZFS designmål och huvudsakliga användningsfall är för öppna lagringssystem på Solaris och FreeBSD som tillhandahåller antingen delad lagring till andra servrar eller som massiva dataförråd för lokalt installerade applikationer. I dessa fall lyser ZFS fokus på skalbarhet och dataintegritet verkligen igenom. ZFS lutar starkt mot stora verksamheter och företagsskala och i allmänhet bort från tillämplighet i utrymmet för små och medelstora företag där färdigheter i Solaris och FreeBSD, liksom storskaliga lagringsbehov, är sällsynta.

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