INFN wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== GlusterFS con volumi replicati su base geografica ======
**Persone/Sedi coinvolte**: 
  * Stefano Stalio (LNGS)
  * Federico Zani (Roma2)
  * Domenico Diacono (Bari)
  * Cristina Aiftimiei (Padova)

===== Test preliminari =====

Nei mesi di luglio ed agosto assieme a Federico Zani abbiamo portato avanti con successo dei test 
con un cluster glusterfs (versione 3.4) composto di 2 server in esecuzione rispettivamente a roma2 ed ai lngs.

Abbiamo creato un volume distribuito e replicato con replica 2 (http://gluster.org/community/documentation/index.php/Gluster_3.2:_Creating_Distributed_Replicated_Volumes) e lo abbiamo acceduto
da dei nodi client.

Abbiamo verificato che la replica funziona correttamente anche su base geografica e che il cluster reagisce
correttamente in caso di failure della connessione di rete di uno dei due server. In particolare al ripristino
del server fallito l'operazione di "healing" dello stesso, almeno su un volume piccolo con pochi file, e`
automatica ed immediata.

Abbiamo anche verificato che se il client monta un volume nativamente, in caso di fallimento del server cui il
client si e` esplicitamente collegato, la connessione si sposta automaticamente ed in maniera trasparente sul server
ancora attivo. Lo stesso meccanismo non funziona se il volume viene montato usando NFS.

===== Test con 4 brick su WAN =====

A Settembre abbiamo provato a creare un volume distribuito con replica 2, avendo però 4 brick da 30GB l'uno su 4 sedi geograficamente distribuite.
Il volume è stato creato correttamente ed è stato montato da altri client.

===== Estensione live del volume =====

Abbiamo quindi provato ad estendere il volume aggiungendo altri due brick forniti da peer già presenti nel cluster (Rm2 e Ba).
Per fare dei test esaustivi il volume è stato riempito con 10.000 file piccoli, 10 file da 5GB e 1 file da 10GB.
Una volta aggiunti i brick abbiamo fatto un rebalance del volume con aggiornamento del layout, tramite il comando gluster rebalance (http://gluster.org/community/documentation/index.php/Gluster_3.2:_Rebalancing_Volume_to_Fix_Layout_and_Migrate_Existing_Data).

A questo punto però sono sorti alcuni problemi con la consistenza dei dati: nella cartella "test" dove sono stati creati i 10.015 file, il comando " find . | wc  -l" ne ha tornati 10.932.

Sembra infatti che alcuni file siano stati duplicati nel metadata db di Gluster, pur mantenendo lo stesso inode :

<code>
ls -li /mnt/gluster/test/smallFile-0002*
 9798755117397460850 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00020
10905658325102015450 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00021
12444748725332520572 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00022
 9843852746736237679 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00023
 9843852746736237679 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00023
10171021621287638333 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00024
10218475899404605011 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00025
10218475899404605011 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00025
13215378458937348777 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00026
13157173702809848982 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00027
12365217785308159108 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00028
10696310688379261230 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00029
10696310688379261230 -rw-r----- 1 root adm 84848 Sep 18 12:52 /mnt/gluster/test/smallFile-00029
</code>

===== Prime impressioni =====

Nonostante l'immediatezza nel setup e la semplicità con cui si può creare / estendere un volume, abbiamo riscontrato una certa latenza nel lavorare con cartelle con un grande numero di file (probabilmente data dal fatto che le informazioni devono essere reperite nei vari brick su WAN).

Il problema principale è stato però riscontrato nell'inconsistenza dei dati una volta fatto il rebalance: ci ha lasciato molto perplessi e ci ha portato a credere che - almeno al momento  - GlusterFS possa non essere pronto ad un ambiente di produzione con una configurazione su WAN.

====== Regole di firewall ======

Le regole di firewall da impostare sui client e sui server sono diverse da quelle descritte dalla documentazione ufficiale,
relativa ancora a glusterfs v3.3.
Per il nostro semplice caso, che non prevede il mount di filesystem attraverso NFS, e` necessario solamente che ogni server 
accetti il traffico tcp proveniente dagli altri server e dai client sulle porte 24007 e 49152.
Le connessioni partono normalmente dall porte piu` alte tra quelle privilegiate (tipicamente da 1010 a 1023) e bisogna accertarsi 
che queste siano aperte in uscita sui server e sui client.

Abbiamo anche verificato che i server possono stare dietro ad un NAT 1:1.