Il Culto di ZFS

È piuttosto comune che negli ambienti IT si sviluppi una certa mentalità da setta o da “fanboy”. Cosa provochi questa reazione nei confronti di tecnologie e prodotti non saprei dire con certezza, ma che ciò accada è innegabile. Un ambito in cui non avrei mai pensato di vederlo accadere è quello dei filesystem – uno dei componenti di sistema più “sotto il cofano” e uno che, fino a tempi recenti, non riceveva letteralmente alcuna attenzione nemmeno in ambienti discretamente tecnici. Diciamocelo, fraintendere quando qualcosa proviene da Active Directory anziché da NTFS è quasi onnipresente. I filesystem vengono, molto semplicemente, ignorati. Da quando è stato rilasciato Windows NT 4 e NTFS era l’unica opzione praticabile, l’idea che un filesystem non sia un componente intrinseco di un sistema operativo e che possano esistere altre opzioni per l’archiviazione dei file è pressoché svanita. Fino a tempi recenti, cioè.

L’unica community in cui, in qualche piccola misura, ciò non è accaduto era la community Linux, ma persino lì Ext2 e i suoi discendenti hanno conquistato così completamente la mindshare che, sebbene fossero ampiamente disponibili, i filesystem alternativi sono stati relegati ai margini e soltanto XFS ha ricevuto, storicamente, una qualche attenzione, e persino esso ne ha ricevuta ben poca.

Dove si è verificato un comportamento davvero strano, più di recente, è attorno al filesystem ZFS di Oracle, originariamente sviluppato per il sistema operativo Solaris e per la piattaforma di storage aperto X4500 “Thumper” (originariamente sotto l’egida di Sun prima dell’acquisizione da parte di Oracle). All’epoca (nove anni fa) in cui ZFS fu rilasciato, i filesystem concorrenti erano per lo più mal preparati a gestire i grandi array di dischi che ci si aspettava sarebbero stati realizzati negli anni a venire. ZFS era progettato per gestirli e annunciò l’era dei filesystem su larga scala. Come la maggior parte dei filesystem dell’epoca, ZFS era limitato a un solo sistema operativo e quindi, pur essendo ampiamente considerato un grande balzo in avanti nella progettazione dei filesystem, produsse poche increspature nel mondo dello storage e ancor meno nel mondo dei “sistemi”, dove persino gli amministratori Solaris lo considerarono generalmente per parecchio tempo soltanto un punto di interesse, scegliendo per lo più di attenersi al collaudato e affidabile UFS che utilizzavano da molti anni.

ZFS era, davvero, un filesystem rivoluzionario e io ne ero, e ne resto, un grande sostenitore. Ma è molto importante comprendere perché ZFS abbia fatto ciò che ha fatto, quali siano i suoi obiettivi, perché quegli obiettivi fossero importanti e come si applichino a noi oggi. La complessità di ZFS ha portato a molta confusione e a molti fraintendimenti su come funzioni il filesystem e su quando sia appropriato utilizzarlo.

I principali obiettivi di ZFS erano realizzare un filesystem in grado di scalare bene verso array di dischi molto grandi. Al momento della sua introduzione, la scala fino alla quale ZFS era in grado di arrivare era inaudita in altri filesystem, ma non vi era alcuna reale necessità concreta che un filesystem fosse in grado di crescere fino a tali dimensioni. Nel momento in cui tale necessità si presentò, molti altri filesystem come NTFS, XFS, Ext3 e altri avevano scalato per soddisfare l’esigenza. ZFS guidò certamente la carica verso la gestione di filesystem più grandi, ma fu raggiunto da molti altri poco dopo.

Poiché ZFS ebbe origine nel mondo Solaris dove, come in tutti i sistemi UNIX di grandi dimensioni, non esiste il RAID hardware, fu necessario ricorrere al RAID software. Solaris aveva sempre avuto a disposizione il RAID software come proprio sottosistema dedicato. Si decise di costruire una nuova implementazione di RAID software direttamente all’interno di ZFS. Ciò avrebbe consentito una gestione semplificata tramite un unico set di strumenti sia per il livello RAID sia per il filesystem. Non introdusse alcun cambiamento o vantaggio significativo in ZFS, come spesso si crede; spostò semplicemente l’interfaccia del livello RAID software dall’essere un proprio set di comandi all’essere parte del set di comandi di ZFS.

L’implementazione del RAID di ZFS introdusse gli stripe a larghezza variabile nei livelli RAID con parità. Questa innovazione chiuse un piccolo rischio del RAID con parità noto come “write hole”. Questa innovazione era molto positiva ma giunse molto tardi, poiché l’era del RAID con parità affidabile stava cominciando a finire e il problema del write hole era già considerato un rischio di “rumore di fondo” non menzionato degli array con parità, in quanto non era generalmente considerato una minaccia per via della sua eliminazione mediante l’uso di cache di array protette da batteria e, all’incirca nello stesso periodo, di cache di array non volatili – evita la perdita di alimentazione ed eviti il write hole. ZFS aveva bisogno di affrontare questo problema perché, in quanto RAID software, era esposto a un rischio maggiore di write hole rispetto al RAID hardware, poiché non vi è alcuna possibilità di una cache protetta dalla perdita di alimentazione – il RAID hardware offre la potenzialità di un ulteriore livello di protezione dell’alimentazione per gli array.

La vera “innovazione” che ZFS apportò inavvertitamente fu che, invece di implementare semplicemente i consueti livelli RAID 1, 5, 6 e 10, “marchiò” invece questi livelli con convenzioni di denominazione proprie. Il RAID 5 è noto come RAIDZ. Il RAID 6 è noto come RAIDZ2. Il RAID 1 è semplicemente noto come mirroring. E così via. All’epoca ciò fu ampiamente considerato sciocco e inutilmente fonte di confusione ma, come si scoprì, fu proprio quella confusione a costituire la pietra angolare della rinascita di ZFS molti anni dopo.

Occorre rilevare che ZFS aggiunse in seguito la prima implementazione di produzione del settore di un sistema RAID a tripla parità RAID 7 (alias RAID 7.3) e lo marchiò RAIDZ3. Questa aggiunta successiva è un’innovazione importante per gli array su larga scala che necessitano della massima capacità rimanendo estremamente sicuri, ma che sono disposti a sacrificare le prestazioni per riuscirci. Questa rimane una caratteristica unica di ZFS, ma una che viene raramente utilizzata.

Nello spirito di comprimere lo stack di storage e di utilizzare un unico set di comandi per gestire tutti gli aspetti dello storage, anche le funzioni di gestione dei volumi logici furono inglobate in ZFS. Si crede spesso erroneamente, in certi ambienti, che ZFS abbia introdotto la gestione dei volumi logici, ma quasi tutte le piattaforme enterprise, tra cui AIX, Linux, Windows e persino Solaris stesso, disponevano già da molti anni della gestione dei volumi logici. ZFS non lo faceva per introdurre un nuovo paradigma, ma semplicemente per consolidare la gestione e racchiudere tutti e tre i livelli chiave dello storage (RAID, gestione dei volumi logici e filesystem) in un’unica entità che fosse più facile da gestire e potesse fornire comunicazioni intrinseche su e giù per lo stack. Vi sono pro e contro in questo metodo e, a quasi un decennio di distanza, l’opinione del settore resta non formata.

Uno degli aspetti più importanti di questo consolidamento di tre sistemi in uno solo è che ora abbiamo un prodotto molto confuso di cui discutere. ZFS è un filesystem, sì, ma non è soltanto un filesystem. È un gestore di volumi logici, ma non soltanto un gestore di volumi logici. Le persone si riferiscono a ZFS come a un filesystem, che è la sua funzione primaria, ma il fatto che sia molto più di un filesystem può generare grande confusione e rende difficili i confronti con altri sistemi di storage. All’epoca ritengo che questa confusione non fosse stata prevista.

Ciò che è derivato da questa fusione confusionaria è che ZFS viene spesso confrontato con altri filesystem, come XFS o Ext4. Ma ciò genera confusione, poiché ZFS è uno stack completo mentre XFS è soltanto un aspetto di uno stack. ZFS sarebbe meglio confrontato con MD (RAID software di Linux) / LVM / XFS oppure con SmartArray (RAID hardware di HP) / LVM / XFS, piuttosto che con il solo XFS. Altrimenti sembra che ZFS sia pieno di funzionalità che a XFS mancano ma, in realtà, è soltanto una vittoria semantica. La maggior parte delle funzionalità spesso decantate dai sostenitori di ZFS non è nata con ZFS ed era comunemente disponibile con i filesystem alternativi molto prima che ZFS esistesse. Ma è difficile confrontare “il tuo filesystem fa questo?” perché la risposta è “no… lo fa il mio RAID o il mio gestore di volumi logici”. E in verità, non è ZFS il filesystem a fornire RAIDZ, è ZFS il sottosistema di RAID software a farlo.

Al fine di gestire con eleganza filesystem molto grandi, in ZFS furono integrate funzionalità di integrità dei dati che includevano un checksum o controllo hash esteso a tutto il filesystem, in grado di sfruttare il RAID software incluso per riparare i file corrotti. Ciò fu ritenuto necessario per via delle dimensioni previste dei filesystem ZFS in futuro. La corruzione del filesystem è un fenomeno raramente osservato, ma con la crescita delle dimensioni dei filesystem il rischio aumenta. Questa funzionalità meno nota di ZFS è forse la sua più grande.

ZFS cambiò anche il modo in cui vengono gestiti i controlli del filesystem. A causa del presupposto che ZFS sarebbe stato utilizzato su filesystem molto grandi, vi era il genuino timore che un controllo del filesystem all’avvio potesse richiedere un tempo impossibilmente lungo per essere completato, e quindi fu trovata una strategia alternativa. Invece di attendere di effettuare un controllo al riavvio, il sistema avrebbe richiesto l’esecuzione di un processo di scrubbing che eseguisse un controllo analogo mentre il sistema era in funzione. Ciò richiede un maggiore overhead di sistema mentre il sistema è attivo, ma il sistema è in grado di ripristinarsi da un riavvio inatteso più rapidamente. Un compromesso, ma uno ampiamente considerato molto positivo.

ZFS dispone di potenti capacità di snapshot nel suo livello di volumi logici e, nel suo livello RAID, ha implementato meccanismi di caching molto robusti che rendono ZFS un’eccellente scelta per molti casi d’uso. Queste funzionalità non sono uniche di ZFS ma sono ampiamente disponibili in sistemi più vecchi di ZFS. Sono, tuttavia, ottime implementazioni di ciascuna e molto ben integrate per via della natura di ZFS.

A un certo punto, ZFS era open source e durante quell’epoca il suo codice divenne parte dei sistemi operativi Mac OSX di Apple e FreeBSD, poiché erano compatibili con la licenza di ZFS. Linux non ottenne ZFS in quel periodo a causa di difficoltà legate alla licenza. Se la licenza di ZFS avesse consentito a Linux di utilizzarlo senza vincoli, il panorama Linux sarebbe probabilmente molto diverso oggi. Mac OSX alla fine abbandonò ZFS, poiché non fu ritenuto avere vantaggi sufficienti a giustificarlo in quell’ambiente. FreeBSD si aggrappò a ZFS e, nel tempo, esso divenne il filesystem più popolare sulla piattaforma, sebbene anche UFS sia tuttora ampiamente utilizzato. Oracle chiuse il sorgente di ZFS dopo l’acquisizione di Sun, lasciando FreeBSD senza aggiornamenti continuativi alla sua versione di ZFS, mentre Oracle continuò a sviluppare ZFS internamente per Solaris.

Oggi Solaris continua a utilizzare l’implementazione originale di ZFS, ora con diversi aggiornamenti dalla sua separazione dalla community open source. FreeBSD e altri continuarono a utilizzare ZFS nello stato in cui si trovava quando il codice fu reso chiuso, non avendo più accesso agli ultimi aggiornamenti di Oracle. Alla fine fu intrapreso il lavoro per aggiornare la codebase open source abbandonata di ZFS, ora nota come OpenZFS. OpenZFS è ancora agli inizi e non ha ancora davvero lasciato il segno, ma ha un certo potenziale per rivitalizzare la piattaforma ZFS nello spazio open source; al momento, tuttavia, OpenZFS resta indietro rispetto a ZFS.

Lo sviluppo open source degli ultimi anni in questo spazio si è concentrato maggiormente sul nuovo rivale di ZFS, BtrFS, che viene sviluppato nativamente su Linux ed è ben supportato da molti dei principali fornitori di sistemi operativi. BtrFS è molto nascente, ma sta facendo importanti passi avanti per raggiungere la parità di funzionalità con ZFS nelle funzionalità implementate, ha grandi aspirazioni e, per via della natura chiusa del sorgente di ZFS, gode del vantaggio del momento di mercato. BtrFS fu avviato, come ZFS, da Oracle ed è stato ampiamente considerato la visione di Oracle del futuro, ossia un sostituto di ZFS persino in Oracle stessa. Allo stato attuale BtrFS ha già, come ZFS, fuso i livelli di filesystem, gestione dei volumi logici e RAID software, implementato il checksum per l’integrità del filesystem, scala addirittura più di ZFS (stesso limite assoluto ma gestisce più file), snapshot copy-on-write e così via.

ZFS, senza dubbio, era un filesystem straordinario ai suoi tempi d’oro e resta un punto di riferimento ancora oggi. Ne ero un sostenitore nel 2005 e tuttora ci credo fermamente. Ma mi ha rattristato vedere la community attorno a ZFS assumere un fervore e uno zelo che non le rendono alcun servizio e che fanno quasi apparire la menzione di ZFS come qualcosa di negativo – con ZFS scelto così universalmente per le ragioni sbagliate: principalmente la convinzione che le sue funzionalità non esistano da nessun’altra parte, che il suo RAID non sia soggetto ai rischi e alle limitazioni a cui quei livelli RAID sono sempre soggetti, o che sia stato progettato per uno scopo diverso (principalmente le prestazioni) rispetto a quello per cui è stato progettato. E quando ZFS è una buona scelta, viene spesso implementato male sulla base di presupposti non veri.

ZFS, ovviamente, non è da biasimare. Né, per quanto mi è dato di capire, lo sono i suoi sostenitori aziendali o i suoi sviluppatori open source. Il punto in cui ZFS sembra essere andato fuori strada è in una community informale e non ufficiale che è venuta a conoscere ZFS solo di recente, spesso credendolo nuovo o di “nuova generazione” perché lo ha scoperto solo di recente. Da quanto ho potuto osservare ciò non avviene quasi mai tramite i canali Solaris o FreeBSD, ma quasi esclusivamente tramite piccole imprese che cercano di utilizzare un “NAS OS” preconfezionato come FreeNAS o NAS4Free e che non hanno familiarità con i sistemi operativi UNIX. L’uso di NAS OS preconfezionati, principalmente da parte di realtà IT che non possiedono né profonde competenze UNIX né di storage e, di conseguenza, scarsa esposizione al più ampio mondo dei filesystem al di fuori di Windows e spesso scarsa o nulla esposizione alla gestione dei volumi logici e al RAID, in particolare al RAID software in generale, sembra condurre a una cultura del “mito” attorno a ZFS, con esso che assume uno status quasi inopinabile e infallibile.

Questo seguito da setta e il generale fraintendimento di ZFS conducono spesso ad applicazioni errate di ZFS o a una catena di decisioni basate su presupposti sbagliati che possono portare molto fuori strada.

Uno dei cambiamenti più sorprendenti in questo spazio è il cambiamento di adesione dal RAID hardware al RAID software. Tradizionalmente, il RAID software era un paria negli ambienti di amministrazione Windows senza una valida ragione – gli amministratori Windows e le piccole imprese, spesso non avendo familiarità con server UNIX di più grandi dimensioni, credevano che il RAID hardware fosse onnipresente quando, in realtà, i sistemi su più larga scala hanno sempre utilizzato il RAID software. Il RAID hardware era, in modo quasi trasversale all’intero settore, considerato una necessità e il RAID software completamente rifuggito. Quello stesso pubblico, ora di fronte al movimento del “Culto di ZFS”, reagisce ora in modo esattamente opposto, credendo che il RAID hardware sia negativo e che il RAID software di ZFS sia l’unica opzione praticabile. Il cambiamento è drastico e nessuno dei due approcci è valido – sia il RAID hardware sia quello software, ed entrambi in molte implementazioni, sono opzioni del tutto valide e persino utilizzando ZFS l’impiego del RAID hardware potrebbe facilmente essere appropriato.

ZFS viene spesso scelto perché si crede che sia l’opzione con le prestazioni più elevate tra i filesystem, ma questo non è mai stato un obiettivo di progettazione chiave di ZFS. Le funzionalità che gli consentono di scalare così tanto e di gestire così tanti aspetti diversi dello storage rendono in realtà molto difficile essere altamente performante. ZFS, al momento della sua creazione, non ci si aspettava nemmeno fosse veloce quanto il venerabile UFS che girava sugli stessi sistemi. Tuttavia, ciò è spesso secondario rispetto al fatto che le prestazioni del filesystem siano ampiamente irrilevanti, poiché tutti i filesystem moderni sono estremamente veloci e la velocità del filesystem è raramente un fattore importante – specialmente al di fuori di sistemi di storage enormi, di fascia alta e su scala molto ampia.

Un interessante studio su dieci filesystem su Linux prodotto da Phoronix nel 2013 mostrò enormi differenze tra i filesystem in base al carico di lavoro, ma nessun chiaro vincitore per quanto riguarda le prestazioni complessive. Ciò che lo studio mostrò in modo conclusivo è che abbinare il carico di lavoro al filesystem è la scelta più importante, che ZFS si colloca sul versante più lento di tutti i filesystem mainstream anche nelle sue implementazioni più moderne e che scegliere un filesystem per ragioni di prestazioni senza una comprensione molto approfondita del carico di lavoro produrrà prestazioni imprevedibili – nessun filesystem dovrebbe essere scelto alla cieca se le prestazioni sono un fattore importante. Purtroppo, poiché il test fu effettuato su Linux, mancava UFS, che è spesso il principale concorrente di ZFS specialmente su Solaris e FreeBSD, e mancava HFS+ di Mac OSX.

Il passaggio dal RAID hardware al RAID software comporta rischi aggiuntivi, spesso imprevisti, anche per le realtà non esperte di UNIX. Sebbene ZFS consenta l’hot swap, si dimentica spesso che l’hot swap è principalmente una funzionalità dell’hardware, non del software, ed è anche ampiamente ignorato che il blind swapping (la rimozione di dischi rigidi senza prima metterli offline nel sistema operativo) non è sinonimo di hot swapping, e ciò può condurre a disastri per le realtà che passano da una tradizione di RAID hardware, che gestiva per loro compatibilità, hot swap e blind swapping in modo trasparente, a un sistema di RAID software che richiede molta più pianificazione, coordinamento e comprensione del sistema per essere utilizzato in sicurezza.

Un’errata convinzione minore, ma comunque comune, su ZFS è che si tratti di un filesystem clusterizzato adatto all’uso in scenari di DAS o SAN condivisi alla OCFS, VxFS e GFS2. ZFS non è un filesystem clusterizzato e condivide le stesse limitazioni in quello spazio di tutti i suoi comuni concorrenti.

ZFS può essere un’eccellente scelta, ma è ben lungi dall’essere l’unica. ZFS comporta grandi controindicazioni, non ultima delle quali le limitazioni di sistema operativo a esso associate e, sebbene abbia molti vantaggi, pochi, se non nessuno, sono unici di ZFS ed è molto raro che una qualsiasi realtà ne tragga beneficio da ciascuno di essi. Come per qualsiasi tecnologia, vi sono dei compromessi da accettare. Una taglia non va bene per tutti. La chiave per sapere quando ZFS è adatto a voi sta nel comprendere cosa sia ZFS, cosa sia e cosa non sia unico in esso, quali siano i suoi obiettivi di progettazione, come il confronto di uno stack di storage con un puro filesystem produca risultati fuorvianti e quali limitazioni intrinseche vi siano legate.

ZFS è una considerazione chiave e la scelta comune quando Solaris o FreeBSD sono il sistema operativo prescelto. Salvo rare eccezioni, il sistema operativo non dovrebbe mai essere scelto in funzione di ZFS, ma al contrario ZFS dovrebbe essere spesso scelto, ma non sempre, una volta scelto il sistema operativo. Il sistema operativo dovrebbe guidare le scelte del filesystem in tutti i casi tranne i più rari. La scelta del sistema operativo è così drasticamente più importante della scelta del filesystem.

ZFS può essere utilizzato su Linux ma non vi è considerato un’opzione enterprise, bensì piuttosto un sistema da hobby per la sperimentazione, poiché nessun fornitore enterprise (come Red Hat, Suse o Canonical) supporta ZFS su Linux e poiché Linux dispone già di ottime alternative. Un giorno ZFS potrebbe essere promosso a filesystem di prima classe in Linux, ma ciò non è previsto, dal momento che BtrFS è già entrato nel kernel mainline ed è stato incluso nelle release di produzione di diversi importanti fornitori.

Sebbene ZFS si veda nella stragrande maggioranza dei deployment Solaris e FreeBSD, ciò è principalmente dovuto al fatto che si è spostato nella posizione di filesystem predefinito e non perché sia chiaramente la scelta superiore in quei casi o sia stato persino valutato in modo critico. ZFS è perfettamente adatto a essere un filesystem generico là dove è nativo e supportato.

Qual è il caso d’uso primario di ZFS?

L’obiettivo di progettazione e il principale caso d’uso di ZFS riguardano i sistemi di storage aperto Solaris e FreeBSD che forniscono storage condiviso ad altri server oppure fungono da enormi repository di dati per applicazioni installate localmente. In questi casi, l’attenzione di ZFS alla scalabilità e all’integrità dei dati risplende davvero. ZFS pende fortemente verso le realtà di scala grande ed enterprise e generalmente si allontana dall’applicabilità nello spazio delle piccole e medie imprese, dove le competenze su Solaris e FreeBSD, così come le esigenze di storage su larga scala, sono rare.

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