Archiviazione ad Alta Disponibilità Con GlusterFS 3.2.x Su Debian Wheezy - Replica Automatica dei File (Mirror) Tra Due Server di Archiviazione

Questo tutorial mostra come impostare un’archiviazione ad alta disponibilità con due server di archiviazione (Debian Wheezy) che utilizzano GlusterFS. Ogni server di archiviazione sarà un mirror dell’altro server di archiviazione e i file saranno replicati automaticamente tra entrambi i server di archiviazione. Il sistema client (anch’esso Debian Wheezy) sarà in grado di accedere all’archiviazione come se fosse un filesystem locale. GlusterFS è un filesystem clusterizzato in grado di scalare fino a diversi petabyte. Aggrega vari mattoni di archiviazione su Infiniband RDMA o TCP/IP in un grande sistema di file di rete parallelo. I mattoni di archiviazione possono essere realizzati con qualsiasi hardware commerciale come server x86_64 con RAID SATA-II e HBA Infiniband.

Non fornisco alcuna garanzia che questo funzioni per te!

1 Nota Preliminare

In questo tutorial utilizzo tre sistemi, due server e un client:

• server1.example.com: indirizzo IP 192.168.0.100 (server)
• server2.example.com: indirizzo IP 192.168.0.101 (server)
• client1.example.com: indirizzo IP 192.168.0.102 (client)

Tutti e tre i sistemi dovrebbero essere in grado di risolvere i nomi host degli altri sistemi. Se ciò non può essere fatto tramite DNS, dovresti modificare il file /etc/hosts in modo che appaia come segue su tutti e tre i sistemi:

vi /etc/hosts

| 127.0.0.1 localhost.localdomain localhost 192.168.0.100 server1.example.com server1 192.168.0.101 server2.example.com server2 192.168.0.102 client1.example.com client1 # Le seguenti righe sono desiderabili per host compatibili con IPv6 ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts |

(È anche possibile utilizzare indirizzi IP invece di nomi host nella configurazione seguente. Se preferisci utilizzare indirizzi IP, non devi preoccuparti se i nomi host possono essere risolti o meno.)

2 Configurazione Dei Server GlusterFS

server1.example.com/server2.example.com:

GlusterFS è disponibile come pacchetto per Debian Wheezy, quindi possiamo installarlo come segue:

apt-get install glusterfs-server

Il comando

glusterfsd --version

dovrebbe ora mostrare la versione di GlusterFS che hai appena installato (3.2.7 in questo caso):

root@server1:~# glusterfsd --version  
glusterfs 3.2.7 built on Nov 12 2012 19:30:08  
Repository revision: git://git.gluster.com/glusterfs.git  
Copyright (c) 2006-2011 Gluster Inc.   
GlusterFS viene fornito senza ALCUNA GARANZIA.  
Puoi ridistribuire copie di GlusterFS secondo i termini della GNU General Public License.  
root@server1:~#

Se utilizzi un firewall, assicurati che le porte TCP 111, 24007, 24008, 24009-(24009 + numero di mattoni su tutti i volumi) siano aperte su server1.example.com e server2.example.com.

Successivamente dobbiamo aggiungere server2.example.com al pool di archiviazione fidato (si prega di notare che sto eseguendo tutti i comandi di configurazione di GlusterFS da server1.example.com, ma puoi anche eseguirli da server2.example.com perché la configurazione è replicata tra i nodi GlusterFS - assicurati solo di utilizzare i nomi host o gli indirizzi IP corretti):

server1.example.com:

Su server1.example.com, esegui

gluster peer probe server2.example.com

root@server1:~# gluster peer probe server2.example.com  
Probe successful  
root@server1:~#

Lo stato del pool di archiviazione fidato dovrebbe ora essere simile a questo:

gluster peer status

root@server1:~# gluster peer status  
Number of Peers: 1

Hostname: server2.example.com  
Uuid: d19cb707-7b23-4d11-8e9c-183cd0a18d96  
State: Peer in Cluster (Connected)  
root@server1:~#

Successivamente creiamo la condivisione chiamata testvol con due repliche (si prega di notare che il numero di repliche è uguale al numero di server in questo caso perché vogliamo impostare il mirroring) su server1.example.com e server2.example.com nella directory /data (questa verrà creata se non esiste):

gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data

root@server1:~# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data  
La creazione del volume testvol è stata completata con successo. Si prega di avviare il volume per accedere ai dati.  
root@server1:~#

Avvia il volume:

gluster volume start testvol

È possibile che il comando sopra ti dica che l’azione non è stata completata con successo:

root@server1:~# gluster volume start testvol  
L'avvio del volume testvol non è riuscito  
root@server1:~#

In questo caso dovresti controllare l’output di…

server1.example.com/server2.example.com:

netstat -tap | grep glusterfsd

su entrambi i server.

Se ottieni un output come questo…

root@server1:~# netstat -tap | grep glusterfsd  
tcp        0      0 *:24009                 *:*                     LISTEN      1548/glusterfsd  
tcp        0      0 localhost.localdom:1019 localhost.localdo:24007 ESTABLISHED 1548/glusterfsd  
root@server1:~#

… tutto va bene, ma se non ottieni alcun output…

root@server2:~# netstat -tap | grep glusterfsd  
root@server2:~#

… riavvia il demone GlusterFS sul server corrispondente (server2.example.com in questo caso):

server2.example.com:

/etc/init.d/glusterfs-server restart

Quindi controlla di nuovo l’output di…

netstat -tap | grep glusterfsd

… su quel server - dovrebbe ora apparire così:

root@server2:~# netstat -tap | grep glusterfsd  
tcp        0      0 *:24010                 *:*                     LISTEN      1458/glusterfsd  
tcp        0      0 localhost.localdom:1021 localhost.localdo:24007 ESTABLISHED 1458/glusterfsd  
root@server2:~#

Ora torniamo a server1.example.com:

server1.example.com:

Puoi controllare lo stato del volume con il comando

gluster volume info

root@server1:~# gluster volume info

Volume Name: testvol  
Type: Replicate  
Status: Started  
Number of Bricks: 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
root@server1:~#

Per impostazione predefinita, tutti i client possono connettersi al volume. Se desideri concedere accesso solo a client1.example.com (= 192.168.0.102), esegui:

gluster volume set testvol auth.allow 192.168.0.102

Si prega di notare che è possibile utilizzare caratteri jolly per gli indirizzi IP (come 192.168.*) e che puoi specificare più indirizzi IP separati da virgola (ad es. 192.168.0.102,192.168.0.103).

Le informazioni sul volume dovrebbero ora mostrare lo stato aggiornato:

gluster volume info

root@server1:~# gluster volume info

Volume Name: testvol  
Type: Replicate  
Status: Started  
Number of Bricks: 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
auth.allow: 192.168.0.102  
root@server1:~#

3 Configurazione Del Client GlusterFS

client1.example.com:

Sul client, possiamo installare il client GlusterFS come segue:

apt-get install glusterfs-client

Poi creiamo la seguente directory:

mkdir /mnt/glusterfs

Ecco fatto! Ora possiamo montare il filesystem GlusterFS su /mnt/glusterfs con il seguente comando:

mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

(Al posto di server1.example.com puoi anche utilizzare server2.example.com nel comando sopra!)

Dovresti ora vedere la nuova condivisione negli output di…

mount

root@client1:~# mount  
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)  
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)  
odev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=126813,mode=755)  
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)  
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102704k,mode=755)  
/dev/mapper/server1-root on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)  
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)  
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=205400k)  
/dev/sda1 on /boot type ext2 (rw,relatime,errors=continue)  
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)  
server1.example.com:/testvol on /mnt/glusterfs type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)  
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)  
root@client1:~#

… e…

df -h

root@client1:~# df -h  
Filesystem                    Size  Used Avail Use% Mounted on  
rootfs                         29G  1.2G   26G   5% /  
udev                           10M     0   10M   0% /dev  
tmpfs                         101M  240K  101M   1% /run  
/dev/mapper/server1-root       29G  1.2G   26G   5% /  
tmpfs                         5.0M     0  5.0M   0% /run/lock  
tmpfs                         201M     0  201M   0% /run/shm  
/dev/sda1                     228M   18M  199M   9% /boot  
server1.example.com:/testvol   29G  1.2G   26G   5% /mnt/glusterfs  
root@client1:~#

Invece di montare manualmente la condivisione GlusterFS sul client, potresti modificare /etc/fstab in modo che la condivisione venga montata automaticamente all’avvio del client.

Apri /etc/fstab e aggiungi la seguente riga:

vi /etc/fstab

| [...] server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0 |

(Ancora una volta, al posto di server1.example.com puoi anche utilizzare server2.example.com!)

Per testare se la tua modifica a /etc/fstab funziona, riavvia il client:

reboot

Dopo il riavvio, dovresti trovare la condivisione negli output di…

df -h

… e…

mount

4 Test

Ora creiamo alcuni file di test sulla condivisione GlusterFS:

client1.example.com:

touch /mnt/glusterfs/test1  
touch /mnt/glusterfs/test2

Ora controlliamo la directory /data su server1.example.com e server2.example.com. I file test1 e test2 dovrebbero essere presenti su ciascun nodo:

server1.example.com/server2.example.com:

ls -l /data

root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test2  
root@server1:~#

Ora spegniamo server1.example.com e aggiungiamo/eliminiamo alcuni file sulla condivisione GlusterFS su client1.example.com.

server1.example.com:

shutdown -h now

client1.example.com:

touch /mnt/glusterfs/test3  
touch /mnt/glusterfs/test4  
rm -f /mnt/glusterfs/test2

Le modifiche dovrebbero essere visibili nella directory /data su server2.example.com:

server2.example.com:

ls -l /data

root@server2:~# ls -l /data  
total 8  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@server2:~#

Riavviamo server1.example.com e diamo un’occhiata alla directory /data:

server1.example.com:

ls -l /data

root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test2  
root@server1:~#

Come vedi, server1.example.com non ha notato le modifiche che sono avvenute mentre era spento. Questo è facile da risolvere, tutto ciò che dobbiamo fare è invocare un comando di lettura sulla condivisione GlusterFS su client1.example.com, ad esempio:

client1.example.com:

ls -l /mnt/glusterfs/

root@client1:~# ls -l /mnt/glusterfs/  
total 8  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@client1:~#

Ora dai un’occhiata alla directory /data su server1.example.com di nuovo, e dovresti vedere che le modifiche sono state replicate a quel nodo:

server1.example.com:

ls -l /data

root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@server1:~#

5 Link

• GlusterFS: http://www.gluster.org/
• Documentazione GlusterFS 3.2: http://download.gluster.com/pub/gluster/glusterfs/3.2/Documentation/AG/html/index.html
• Debian: http://www.debian.org/