Marvin Pascale

[B.Log]

09 Aprile 2020

Glusterfs

Gluster

GlusterFS è un progetto open source appartenente alla famiglia Red Hat che risponde all’esigenza di alta affidabilità, replica e prestazioni in ambito storage.

Nello specifico GlusterFS è un file system distribuito e scalabile che sfruttando una connessione di tipo client-server permette la memorizzazione di dati su più hosts.

GlusterFS sfrutta connessioni TCP/IP e garantisce piena compatibilità con sistemi eterogenei; è possibile avviare un’istanza di GlusterFS su distribuzioni differenti e formare quello che in Gluster si chiama Volume.

Non molto distante dai protocolli più comuni come CIFS e NFS di cui mantiene la compatibilità GlusterFS dispone di un client nativo che permette tra le altre cose di gestire le connessioni con il cluster, l’alta affidabilità e l’ottimizzazione nella comunicazione client-server.

Prima di andare avanti facciamo un po di chiarezza sui termini che utilizzeremo.

  • Client: è l’host (o più host) che monta il volume;
  • Server: è l’host (o più host) dove risiedono i dati;
  • Brick: è una porzione del file system locale di un server;
  • Volume: è la risorsa che viene messa a disposizione dal/i server

Brick Un brick è una porzione del file system destinata ad ospitare i dati. Su ogni server è possibile definire uno o più brick che andranno a formare uno o più volumi.

Volume Un volume è una condivisione esposta da uno o più server ed è formata da uno o più brick. Il volume è anche il punto di mount che i client utilizzano che disporre del file system.

Il punto di forza di GlusterFS è la grande versatilità unita alla semplicità di installazione e utilizzo. Un volume può essere configurato per prediligere le prestazioni alla resilienza dei dati oppure per resistere ai guasti. Ma non può essere tutto bianco o nero e GlusterFS lo ha capito bene. Vediamo le configurazioni più basilari per un volume.

Fino alla versione 3.9

Distributed

In questa configurazione i file vengono distribuiti in maniera casuale tra i vari brick che formano il volume. Questa configurazione permette una maggiore scalabilità e incremento delle performance ma nessuna garanzia in presenza di guasti. In caso di guasto anche solo di un host quest’ultimo comporterebbe la perdita dei dati in esso contenuti.

Replicated

In questa configurazione i file vengono replicati tra i brick che formano il volume. In questa configurazione si strizza l’occhio all’altra affidabilità e alla resilienza dei dati e nel caso in cui ci fosse un guasto quest’ultimo non comporterebbe la perdita dei dati.

Striped

In questa configurazione i file vengono suddivisi in blocchi che vengono distribuiti nei vari brick che compongono il volume. Questa configurazione porta ad avere maggiori prestazioni in lettura e scrittura su file di grandi dimensioni ma nessuna ridondanza dei dati.

Arrivati a questo punto qualcuno di voi avrà di certo trovato qualche similitudine con le terminologie utilizzate nei volumi RAID ( Redundant Array of Independent Disks) nei quali a mio avviso GlusterFS non si allontana di molto.

A queste tre configurazioni che definiamo base si affiancano i vari incroci tra di essi. Vedremo: distributed replicated, striped replicated, distributed striped e distributed striped replicated.

Distributed replicated

In questa configurazione i file vengono distribuiti e replicati garantendo maggiori prestazioni e resistenza ai guasti. In caso di guasto di un brick questo non comporterebbe la perdita dei dati

Striped replicated

In questa configurazione i file vengono suddivisi in blocchi che vengono distribuiti e replicati tra i brick del volume. In caso di guasto di un brick questo non comporterebbe la perdita dei dati.

Distributed striped

In questa configurazione i file vengono suddivisi in blocchi che vengono distribuiti tra i brick del volume. In caso di guasto di un brick questo comporterebbe la perdita dei dati.

Distributed striped e distributed striped replicated

In questa configurazione i file vengono distribuiti su più volumi all’interno dei quali sono suddivisi in blocchi che vengono distribuiti tra i brick del volume. Questa configurazione porta benefici sulla velocità di lettura e scrittura su file di grandi dimensioni e allo stesso tempo garantisce una resistenza ai guasti. In caso di guasto di un brick questo non comporterebbe la perdita dei dati.

Dalla versione 3.9

Ad un certo punto GlusterFS ha deprecato la modalità “stripped” e ha introdotto una nuova modalità.

Dispersed

In questa configurazione i file vengono suddivisi e vengono calcolati hash di cancellazione. Un frammento di file viene viene memorizzato in un brick e replicato ( se configurata la replica). Questa configurazione punta ad avere una gestione ottimale dello spazio disco ed offre una tolleranza ai guasti. Ad ogni volume viene assegnato un valore di ridondanza che determina la tolleranza ai guasti del volume stesso (numero di brick che si possono perdere senza perdita di dati). L’attuale implementazione di volumi dispersed utilizza blocchi di dimensioni che dipendono dal numero di brick e dalla ridondanza: 512 * (#mattoni - #ridondanza) byte. Questa scelte non deve essere fatta a cuor leggero in quanto una configurazione non ottimale causerebbe un degrado delle prestazioni.

Ad esempio, una configurazione con 6 brick e ridondanza 2 avrà una stripe size di 512 * (6 - 2) = 2048 byte, quindi è considerata ottimale.

Restano invariate le modalità “replicated” e “distributed” con le relative concatenazioni.

Dispersed Distributed volume

In questa configurazione il numero di brick specificato deve essere un multiplo del numero disperse. La ridondanza è esattamente la stessa del dispersed volume.

Dalla teoria alla pratica

Ci sono molte guide in rete e la stessa Red Hat mette a disposizione molta ottima documentazione.

Dopo aver installato il demone glusterd su tutti gli host che parteciperanno al cluster si può procedere con la creazione del volume.

Per gli esempi prenderemo in considerazione un cluster formato da 6 hosts con un solo brick.

Distributed volume

# gluster volume create dataVolume server{1..6}:/brick01

Replicated volume

# gluster volume create dataVolume replica 2 server{1..2}:/brick01

# gluster volume start

Disributed Replicated volume

# gluster volume create dataVolume replica 2 server{1..6}:/brick01

# gluster volume start

Dispersed volume

# gluster volume create dataVolume disperse 6 redundancy 2 server{1..6}:/brick01

# gluster volume start

Dispersed Distributed volume

# gluster volume create dataVolume disperse 3 server{1..6}:/brick01

# gluster volume start

Connessione

Una volta creato un volume bisogna montarlo per iniziare a leggere e scrivere i dati.

La soluzione migliore è quella di installare il client nativo di GlusterFS:

# mount -t glusterfs server1:/dataVolume /mnt

Possono essere specificate che delle opzioni in fase di mount per migliorare prestazione e resistenza ai guasti.

Opzioni di mount

backupvolfile-server=server-name

volfile-max-fetch-attempts=number of attempts

log-level=loglevel

log-file=logfile

transport=transport-type

direct-io-mode=[enable|disable]

use-readdirp=[yes|no]

Nel nostro esempio un comando valido potrebbe essere:

 # mount -t glusterfs -o backupvolfile-server=server2,use-readdirp=no,volfile-max-fetch-attempts=2,log-level=WARNING,log-file=/var/log/gluster.log server1:/dataVolume /mnt/

Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse: