Come discusso nella Parte 1 di questa serie, Stratis è un filesystem di gestione del volume (VMF) con funzionalità simili a ZFS e Btrfs. Nel progettare Stratis, abbiamo studiato le scelte fatte dagli sviluppatori di soluzioni esistenti.
Perché non adottare una soluzione esistente?
I motivi variano. Per prima cosa, consideriamo ZFS. Originariamente sviluppato da Sun Microsystems per Solaris (ora di proprietà di Oracle), ZFS è stato portato su Linux. Tuttavia, il codice con licenza CDDL non può essere unito all'albero dei sorgenti Linux con licenza GPL. Se CDDL e GPLv2 siano veramente incompatibili è oggetto di dibattito, ma l'incertezza è sufficiente a rendere i fornitori Linux aziendali non disposti ad adottarlo e supportarlo.
Anche Btrfs è consolidato e non ha problemi di licenza. Per anni è stato il "prescelto" per molti utenti, ma non è ancora arrivato dove dovrebbe essere in termini di stabilità e funzionalità.
Quindi, alimentato dal desiderio di migliorare lo status quo e dalla frustrazione per le opzioni esistenti, è stato concepito Stratis.
In che modo Stratis è diverso
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Una cosa che ZFS e Btrfs hanno mostrato chiaramente è che scrivere un VMF come un filesystem nel kernel richiede un'enorme quantità di lavoro e tempo per risolvere i bug e stabilizzarsi. È essenziale avere ragione quando si tratta di dati preziosi. Ricominciare da zero e adottare lo stesso approccio con Stratis avrebbe probabilmente richiesto anche un decennio, il che non era accettabile.
Stratis ha invece scelto di utilizzare alcune delle altre funzionalità esistenti del kernel Linux:il sottosistema di mappatura dei dispositivi, utilizzato in particolare da LVM per fornire RAID, thin-provisioning e altre funzionalità sopra i dispositivi a blocchi; e il filesystem XFS ben collaudato e ad alte prestazioni. Stratis costruisce il suo pool utilizzando strati di tecnologia esistente, con l'obiettivo di farli apparire come un insieme senza soluzione di continuità per l'utente.
Cosa ha imparato Stratis da ZFS
Per molti utenti, ZFS stabilisce le aspettative per quello che dovrebbe essere un filesystem di prossima generazione. Leggere i commenti online di persone che parlano di ZFS ha aiutato a definire gli obiettivi di sviluppo iniziale di Stratis. Il design di ZFS ha anche evidenziato implicitamente le cose da evitare. Ad esempio, ZFS richiede un passaggio di "importazione" quando si collega un pool creato su un altro sistema. Ci sono alcune ragioni per questo, e ciascuna ragione era probabilmente un problema che Stratis ha dovuto risolvere, adottando lo stesso approccio o uno diverso.
Una cosa che non ci è piaciuta di ZFS è che ha alcune restrizioni sull'aggiunta di nuovi dischi rigidi o sulla sostituzione di unità esistenti con unità più grandi, soprattutto se il pool è configurato per la ridondanza. Certo, c'è una ragione per questo, ma abbiamo pensato che fosse un'area che potevamo migliorare.
Infine, l'utilizzo degli strumenti di ZFS dalla riga di comando, una volta appresi, è una buona esperienza. Volevamo avere la stessa sensazione con lo strumento da riga di comando di Stratis e ci è piaciuta anche la tendenza dello strumento a utilizzare parametri posizionali e limitare la quantità di digitazione richiesta per ogni comando.
Cosa ha imparato Stratis da Btrfs
Una cosa che ci è piaciuta di Btrfs è stato il singolo strumento da riga di comando, con sottocomandi posizionali. Btrfs considera anche la ridondanza (profili Btrfs) come una proprietà del pool, che sembra più facile da capire rispetto all'approccio di ZFS e consente di aggiungere e persino rimuovere le unità.
Infine, esaminare le funzionalità offerte da ZFS e Btrfs, come l'implementazione di snapshot e il supporto di invio/ricezione, ha aiutato a determinare quali funzionalità Stratis dovrebbe includere.
Cosa ha imparato Stratis da LVM
Fin dalle prime fasi di progettazione di Stratis, abbiamo studiato a fondo LVM. LVM è attualmente l'utente più significativo del sottosistema Linux Device Mapper (DM), infatti, DM è gestito dal core team di LVM. Lo abbiamo esaminato sia dalla possibilità di utilizzare effettivamente LVM come livello di Stratis e un esempio di utilizzo di DM, cosa che Stratis potrebbe eseguire direttamente con LVM come peer. Abbiamo esaminato il formato dei metadati su disco di LVM (insieme a ZFS e XFS) per trovare ispirazione nella definizione del formato dei metadati su disco di Stratis.
Tra i progetti elencati, LVM condivide internamente la maggior parte in comune con Stratis, poiché entrambi utilizzano DM. Tuttavia, dal punto di vista dell'utilizzo, LVM è molto più trasparente sul suo funzionamento interno. Ciò offre agli utenti esperti una grande quantità di controllo e opzioni per configurare con precisione il layout del gruppo di volumi (pool) in un modo che Stratis non fa.
Una varietà di soluzioni
Una cosa grandiosa di lavorare su software libero e open source è che non ci sono componenti insostituibili. Ogni parte, anche il kernel, è aperta per la visualizzazione, la modifica e persino la sostituzione se il software attuale non soddisfa le esigenze degli utenti. Non è necessario che un nuovo progetto metta fine a uno esistente se c'è abbastanza supporto perché entrambi possano essere sostenuti in parallelo.
Stratis è un tentativo di incontrare meglio alcuni esigenze degli utenti per la gestione dello storage locale:coloro che cercano una soluzione potente, semplice da usare e senza problemi. Ciò significa fare scelte di progettazione che potrebbero non essere adatte a tutti gli utenti. Le alternative rendono possibili scelte difficili poiché gli utenti hanno altre opzioni. Alla fine, tutti gli utenti traggono vantaggio dalla loro capacità di utilizzare lo strumento che funziona meglio per loro.