Quando si ha a che fare con più server, sicuramente prima o poi nascerà l’esigenza di avere un unico posto dove salvare i propri dati, in modo da poterci accedere contemporaneamente da più server. Questo è uno dei problemi più difficili da affrontare quando si progetta un sistema di server, in quanto esistono moltissimi metodi per arrivare allo scopo ma ciascuno ha le sue peculiarità che lo rendono più o meno adatto ad essere sfruttato in determinate applicazioni.
Diciamo che fare un confronto non è cosa semplice, anche perchè in alcuni casi è possibile avere situazioni ibride di due sistemi concatenati (ad es. NFS su GlusterFS)
NFS
NFS è il sistema di condivisione file classico del modo Unix: è senza ombra di dubbio il più usato, il più conosciuto ed il più semplice da implementare. Per quanto riguarda il funzionamento, il server NFS ha accesso ad uno spazio fisico a blocchi che può essere formattato utilizzando un qualsiasi FileSystem con funzionalità POSIX. Il server NFS ha il compito di gestire l’accesso contemporaneo ai dati contenuti all’interno del dispositivo a blocchi, oltre ovviamente a gestire i permessi utente. I client NFS (gli altri server della rete) potranno montare la directory condivisa (in gergo esportata) come se fosse un disco locale, un po’ come avviene con la condivisione di windows CIFS/SAMBA.
I punti a favore di questo sistema sono senza dubbio la facilità di implementazione, la stabilità del protocollo e, tutto sommato, discrete velocità di rete.
I punti debili di questo sistema sono la totale impossibilità di scalare “on line” aggiungendo nuovo storage nel momento in cui se ne ha la necessità, il fatto di avere un SPoF (Single Point of Failure) costituito dal server NFS che è suscettibile a guasti e che rischia di sovraccaricarsi in maniera considerevole all’aumentare di richieste di rete.
OCFS2 e GFS
OCFS2 e GFS sono due FileSystem concettualemente simili in quanto prevedono nativamente l’accesso contemporaneo ai file: OCFS2 è sviluppato da Oracle mentre GFS2 è sviluppato da RedHat. La teoria di funzionamento è identica: ogni server che ha accesso allo storage deve avere attivo un demone che dialoga continuamente con gli altri server in modo da conoscere esattamente lo stato dello storage. Il disco condiviso viene montato in locale deve essere formattato con il suo filesystem, non è possibile utilizzare un filesystem tradizionale (ext3, xfs, ecc); la cosa interessante è che, trattandosi della formattazione di un disco, questo può essere di qualsiasi tipo, basta che sia accessibile da tutti i server: quindi può essere un disco di rete iSCSI o AoE, ma anche una partizione locale replicata su un secondo server attraverso DRBD8 configurato in modalità Attivo/Attivo o un disco FireWire collegato a più server.
Da un confronto tra i due filesystem, GFS è il più semplice da configurare dato che utilizza i tools di alta affidabilità di RedHat, mentre OCFS2 è più macchinoso. OCFS2 è però nettamente più veloce anche se non supporta le quote in nessun modo (è una delle cose in implementazione).
I maggiori pregi di questo sistema è che non serve un server che faccia da tramite e quindi non si ha un SPoF e le prestazioni sono le migliori in assoluto (specie con OCFS2).
Il difetto principale, deriva direttamente dal pregio: non avendo un server che gestisce la condivisione dei file, ogni nuovo nodo che entra a far parte del cluster comporta un riconfigurazione di tutto il cluster. Anche la scalabilità del sistema è relativa: anche ammettendo di avere un dispositivo di storage che consente di “aggiungere dischi”, è necessario eseguire un resize della partizione con rischi, annessi e connessi.
I figli di FUSE
FUSE è l’acronimo di File System in Userspace ed è un nuovo metodo di utilizzo di dispositivi di rete. Molti filesystem di nuova generazione utilizzano questo sistema per gestire i dischi di rete. L’utilizzo di un ulteriore layer per la comunicazione tra disco e client va nella direzione opposta rispetto all’utilizzo di un filesystem cluster come OCFS2 o GFS, cosa che porta una maggiore flessibilità e stabilità a discapito di una leggera perdita in termini di prestazioni.
Analizziamo due filesystem che fanno affidamento a FUSE: GlusterFS e MooseFS.
GlusterFS
GlusterFS è un filesystem che in questo momento va molto “di moda”. Consente di unire più “commodity computer” per realizzare un cluster di storage server: è possibile realizzare uno stripe (unire lo storage di più server, simile concettualmente al raid 0) o un mirror (avere lo stesso dato copiato su più server, simile concettualmente al RAID 1). Lo storage ove viene creato il filesystem Gluster è, come per NFS, un filesystem comune (EXT3, XFS, ecc,)
Una volta creato lo storage, è possibile accedevi sia utilizzando il protocollo NFS, sia il protocollo CIFS (Samba), sia, come dicevo pocanzi, usando il protocollo nativo attraverso FUSE: questo sistema è quello che garantisce le migliori performance.
Il pregio maggiore di questo protocollo è a mio avviso che non esiste alcun SPoF: tutti i server sono autoritativi allo stesso modo, quando un client monta la partizione attraverso FUSE seve specificare un server, ma poi la comunicazione avviene direttamente con tutto il cluster. Altro pregio è la diffusione: essendo molto diffuso e mantenuto, è anche molto stabile.
Il difetto maggiore a mio avviso è la complessità concettuale: Gluster è formato da tanti layer ciascuno dei quali assove una sua funzione: comprenderli e tarali non è semplicissimo e l’ordinaria manutenzione (aggiungere un nodo ecc.) è spesso fonte di problemi. Le prestazioni del sistema sono buone in lettura se configurato in modalità mirror (le letture possono avvenire contemporaneamente da più nodi), però in scrittura non sono esaltanti.
MooseFS
Operativamente è simile a GlusterFS in quanto condivide FUSE per il montaggio dei dischi in rete, MooseFS è però diverso in quanto a sistema di gestione che lo rende simile a Openstack Swift. In Moose, a differenza di Gluster, i nodi non sono paritetici, ma si compone di un Master Server, un Metalogger server (che può essere promosso a Master in caso di guasto) e di X nodi dati.
Il Master fa da Proxy e conosce esattamente dove sono salvati i dati all’interno dei nodi dati; i dati possono essere replicati su un numero arbitrario di zone in modo da avere sia un sistema tollerante ai guasti sia un sistema di lettura parallelo. Purtroppo, al contrario di OpenStack Swift, anche le scritture avvengono in parallelo, cosa che di fatto lo rende un po’ lento in questo frangente.
Due cose interessanti di questo FileSystem sono l’interfaccia web per il controllo dello stato del cluster e il plugin appena rilasciato per l’integrazione diretta con OpenNebula.
Il principale pregio di questo sistema è la facilità di implementazione e di scalabilità, unita a una velocità generale di tutto rispetto.
Il principale difetto è la quantità di server necessari ad implementare un sistema funzionante: almeno 3 per ambienti di test, almeno 5 per ambienti in produzione.
Ceph
Ceph è l’ultimo Filesystem che prendiamo in considerazione. Diciamo che promette bene e, non a caso, è stato già introdotto nella mainline del kernel linux. Ultima cosa che mi sarei aspettato, quindi, è di avere problemi di sorta, cosa che puntualmente è avvenuta cercando di creare un ambiente misto di nodi a 32 e a 64 bit.
Concettualmente è simile a MooseFS, però introduce due feature interessanti: il driver nel kernel è in grado di lavorare a diretto contatto con lo storage del cluster, senza quindi necessitare di FUSE, pertanto dovrebbe garantire prestazioni superiori; inoltre introduce un proxy in grado di esporre una interfaccia REST API compatibile con Amazon S3.
Diciamo che è ancora un prodotto giovane e, a causa delle limitazioni di gioventù, non ho potuto sperimentarlo in maniera approfondita, peranto ritornerò a provarlo sicuramente in futuro.
