[Guida] Sysadmin GNU/Linux: introduzione al file system ZFS – Parte 1

In questa mini-guida per sysadmin, vi esporrò una panoramica su cos’è ZFS e sulla sua struttura. C’è chi lo consiglia e chi, come Linus Torvalds, si espone apertamente contro il suo utilizzo. Ecco come funziona questo file system innovativo, robusto, scalabile e facile da gestire. Per cercare di mantenere un fil rouge tra i vari argomenti trattati, semplificare la trattazione, ed evitare divagazioni, ho inserito qualche link per chiarire alcuni concetti che non sono strettamente legati al funzionamento di ZFS, o per approfondire alcune tematiche connesse. Inoltre ho deciso di suddividere la trattazione in due parti. La parte due verrà pubblicata domani o, al più tardi, lunedì.

ZFS: concetti base

ZFS gestisce l’archiviazione fisica tramite lo storage pool. I file system tradizionali sono stati concepiti per la gestione di un singolo dispositivo fisico. Con l’aumento della quantità dei dati da gestire, e la conseguente necessità di utilizzare più dispositivi di archiviazione contemporaneamente, è stato introdotto il concetto di volume manager. Questo serve per creare, da più dispositivi, una rappresentazione univoca, in modo da gestire l’indirizzamento e garantire la ridondanza dei dati.
ZFS elimina completamente il volume manager, aggregando i dispositivi in uno storage pool, che permette quindi una gestione nativa di più dischi e più volumi. I file system non sono così più vincolati ai singoli dispositivi, consentendo loro di condividere lo spazio su disco con tutti i file system nel pool. Ulteriore vantaggio è che, l’aggiunta di nuovo spazio di archiviazione, non richiede alcuna configurazione da parte del sysadmin, poiché tutti i file system all’interno del pool lo possono utilizzare immediatamente.

Logical Volume Management in GNU/Linux

Per quanto riguarda la topologia di questo filesystem, possiamo considerare lo schema riportato nell’immagine:

Al livello superiore troviamo zpool. Su uno stesso computer è possibile trovare anche vari zpool, ma sono tutti indipendenti tra loro e non possono condividere i vdev che contengono. A questo livello non c’è alcuna ridondanza;
Uno zpool contiene uno o più vdev, acronimo di dispositivi virtuali. Un vdev è un meta-device che rappresenta uno o più dispositivi fisici. Esistono vari tipi di vdev, di cui viene sempre effettuato uno stripe dinamico. I principali sono i seguenti:
- Disk: ovvero i corrispettivi dei dischi fisici;
- Mirror, raidz1, raidz2, raidz3;
- Spare, per il RAID via software proprio di ZFS;
- Cache
- Slog, per il ZFS Intent Log

Creare uno zpool è semplicissimo. Facciamo un esempio banale, supponiamo di avere a disposizione 4 SSD, quindi quattro vdev di tipo disk. L’istruzione da eseguire sarà:

zpool create miopool A B C D

Parallelamente, l’istruzione per eliminarlo sarà zpool destroy miopool. Per verificarne lo stato, invece, usate zpool status miopool, per ottenere un risultato come il seguente:

pool:  miopool
state: ONLINE
scan:  none requested
config:

        NAME        STATE     
        miopool     ONLINE      
          A         ONLINE       
          B         ONLINE       
          C         ONLINE      
          D         ONLINE

COW e ZIL

ZFS utilizza il metodo transazionale ad oggetti copy-on-write. Questa tecnica serve a preservare la coerenza sia a livello di file system che a livello di disk management e, inoltre, non rende più necessario l’esecuzione di fsck dopo un arresto anomalo del sistema. Un filesystem tradizionale, quando si deve sovrascrivere un dato, modifica ciascun blocco letteralmente, portando la perdita del vecchio dato.

ZFZ, invece, scrive una nuova versione del blocco modificato, poi, tramite un’operazione atomica, aggiorna i metadata del file scollegando il vecchio blocco e collegando il nuovo appena scritto. Pertanto, il file system non potrà mai essere danneggiato a causa di un arresto anomalo del sistema, ad esempio dopo un blackout.

Quick Tip: cos’è un’operazione atomica.

Ulteriore funzionalità di ZFS, che serve a recuperare le transazioni che erano nella RAM e non ancora attuate, è il ZFS intent log. Quando il sistema è in esecuzione, ZIL non viene mai letto, ma solo scritto. Se accade un crash, invece, al ripristino del sistema ZFS nota le transazioni mancanti, e le recupera dal ZIL (che è contenuto, come vi ho già spiegato, nel vdev di tipo SLOG).

Per quanto riguarda le scritture sincrone, quindi, prima di essere attuate vengono memorizzate nel ZIL, un po’ come avviene con il journal.

Scrittura sincrona ed asincrona e journaled filesystem

La creazione di un SLOG è semplicissima. Ipotizziamo di avere due SSD. Corrisponde a best practice per un sysadmin, effettuare il mirroring di questi vdev, l’istruzione sarà :

zpool add miopool log mirror X Y

Siamo giunti alla conclusione di questa prima parte su ZFS. Nella prossima continueremo la trattazione degli altri tipi di cache, degli snapshot e di molto altro, stay tuned!

Seguiteci sul nostro canale Telegram, sulla nostra pagina Facebook e su Google News. Nel campo qui sotto è possibile commentare e creare spunti di discussione inerenti le tematiche trattate sul blog.