Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Distribuite l’archiviazione replicata quattro nodi di archiviazione con GlusterFS 3.2. x su CentOS 6.3

In questa esercitazione viene illustrato come combinare quattro server di archiviazione singola (in esecuzione CentOS 6.3) per un distributed storage replicato con GlusterFS. Nodi 1 e 2 (replication1), nonché 3 e 4 (replication2) specchio a vicenda, e replication1 ereplication2 saranno combinate su un server di archiviazione più grande (distribuzione). Fondamentalmente, questo è RAID10 sulla rete. Se perdi un server da replication1 e uno da replication2, il volume distribuito continua a funzionare. Il sistema di client (anche CentOS 6.3) sarà in grado di accedere l’archiviazione come se fosse un filesystem locale. GlusterFS è un cluster file system in grado di scalare a parecchi peta-byte. Aggrega vari mattoni di deposito sopra Infiniband RDMA o TCP/IP di interconnessione in un unico sistema di file di rete di grandi dimensioni parallele. Mattoni di deposito possono essere fatto di qualsiasi hardware commodity come server x86_64 con SATA-II RAID e Infiniband HBA.

Io non rilasciano alcuna garanzia che questo funziona per voi!

 

1 Nota preliminare

In questo tutorial io uso cinque sistemi, quattro server e un client:

  • Server1: indirizzo IP 192.168.0.100 (server)
  • Server2: indirizzo IP 192.168.0.101 (server)
  • Server3.example.com: indirizzo IP 192.168.0.102 (server)
  • Server4.example.com: indirizzo IP 192.168.0.103 (server)
  • CLIENT1: indirizzo IP 192.168.0.104 (client)

Tutti i cinque sistemi dovrebbero essere in grado di risolvere i nomi host gli altri sistemi. Se questo non può essere fatto tramite DNS, si deve modificare il file/etc/hosts modo che appaia come segue in tutti i cinque sistemi:

vi /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.100   server1.example.com     server1
192.168.0.101   server2.example.com     server2
192.168.0.102   server3.example.com     server3
192.168.0.103   server4.example.com     server4
192.168.0.104   client1.example.com     client1

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

(È anche possibile utilizzare indirizzi IP anziché nomi host nella configurazione seguente. Se si preferisce utilizzare gli indirizzi IP, non avete di preoccuparsi se i nomi degli host può essere risolto o meno.)

 

2 abilitare i repository aggiuntivi

Server1.example.com/Server2.example.com/Server3.example.com/Server4.example.com/CLIENT1.example.com:

Innanzitutto importiamo le chiavi GPG per pacchetti software:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*

Quindi abbiamo abilitare il repository di EPEL6 sui nostri sistemi di CentOS:

rpm --import https://fedoraproject.org/static/0608B895.txt

CD/tmp
wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
rpm – ivh epel-rilascio-6-7.noarch.rpm

yum install yum-priorities

Modificare /etc/yum.repos.d/epel.repo

vi /etc/yum.repos.d/epel.repo

… e aggiungere la riga priorità = 10 alla sezione [epel] :

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
priority=10
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
[...]

 

3 impostare i server di GlusterFS

Server1.example.com/Server2.example.com/Server3.example.com/Server4.example.com:

GlusterFS è disponibile come pacchetto per EPEL, pertanto possiamo installare come segue:

yum install glusterfs-server

Creare i collegamenti di avvio del sistema per il demone Gluster e avviarlo:

chkconfig – livelli 235 glusterd su
/etc/init.d/glusterd inizio

Il comando

glusterfsd --version

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

[root@server1 ~] # glusterfsd – versione
GlusterFS 3.2.7 costruito su 11 giugno 2012 13:22:28
Revisione di repository: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc < http://www.gluster.com>
GlusterFS viene fornito con assolutamente nessuna garanzia.
È possibile ridistribuire copie di GlusterFS sotto i termini della GNU General Public License.
[root@server1 ~]#

If you use a firewall, ensure that TCP ports 111, 24007, 24008, 24009-(24009 + number of bricks across all volumes) are open on server1.example.comserver2.example.comserver3.example.com, and server4.example.com.

Next we must add server2.example.comserver3.example.com, and server4.example.com to the trusted storage pool (please note that I’m running all GlusterFS configuration commands from server1.example.com, but you can as well run them from server2.example.com or server3.example.com or server4.example.com because the configuration is repliacted between the GlusterFS nodes – just make sure you use the correct hostnames or IP addresses):

server1.example.com:

On server1.example.com, run

gluster peer probe server2.example.com
gluster peer probe server3.example.com
gluster peer probe server4.example.com

Output should be as follows:

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

The status of the trusted storage pool should now be similar to this:

gluster peer status

[root@server1 ~]# gluster peer status
Number of Peers: 3

Hostname: server2.example.com
Uuid: 600ff607-f7fd-43f6-af8d-419df703376d
State: Peer in Cluster (Connected)

Hostname: server3.example.com
Uuid: 1d6a5f3f-c2dd-4727-a050-0431772cc381
State: Peer in Cluster (Connected)

Hostname: server4.example.com
Uuid: 0bd9d445-0b5b-4a91-be6f-02b13c41d5d6
State: Peer in Cluster (Connected)
[root@server1 ~]#

Avanti creiamo la condivisione replicata distribuita denominata testvol con due repliche (si prega di notare che il numero di repliche è dimezzare il numero di server in questo caso perché vogliamo impostare la replica distribuita) su Server1Server2server3.example.comserver4.example.com nella directory /data (questo verrà creato se non esiste):

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

[root@server1 ~] # gluster volume creare testvol replica 2 trasporto tcp server1.example.com:/data server2.example.com:/data server3.example.com:/data server4.example.com:/data
Creazione di volume testvol ha avuto successo. Si prega di iniziare il volume per accedere ai dati.
[root@server1 ~]#

Avviare il volume:

gluster volume start testvol

È possibile che il comando qui sopra indica che l’azione non è riuscita:

[root@server1 ~] # gluster volume iniziare testvol
A partire testvol volume è rimasta soccombente
[root@server1 ~]#

In questo caso si dovrebbe controllare l’output di…

Server1.example.com/Server2.example.com/Server3.example.com/Server4.example.com:

netstat -tap | grep glusterfsd

su entrambi i server.

Se si ottiene un output come questo…

[root@server1 ~] # netstat-toccare | grep glusterfsd
TCP 0 0 *: 24009 *: * LISTEN 1365/glusterfsd
TCP 0 0 localhost:1023 localhost:24007 stabilito 1365/glusterfsd
TCP 0 0 server1.example.com:24009 server1.example.com:1023 stabilito 1365/glusterfsd
[root@server1 ~]#

… va tutto bene, ma se non si ottiene alcun output…

[root@Server2 ~] # netstat-toccare | grep glusterfsd
[root@server2 ~]#

[root@Server3 ~] # netstat-toccare | grep glusterfsd
[root@server3 ~]#

[root@Server4 ~] # netstat-toccare | grep glusterfsd
[root@server4 ~]#

… riavviare il demone GlusterFS sul server corrispondente (Server2server3.example.comserver4.example.com in questo caso):

Server2.example.com/Server3.example.com/Server4.example.com:

/etc/init.d/glusterfsd restart 

Quindi controllare l’output di…

netstat -tap | grep glusterfsd

… ancora una volta su questi server – ora dovrebbe apparire come questo:

[root@Server2 ~] # netstat-toccare | grep glusterfsd
TCP 0 0 *: 24009 *: * LISTEN 1152/glusterfsd
TCP 0 0 localhost.localdom:1018 localhost.localdo:24007 stabilito 1152/glusterfsd
[root@server2 ~]#

[root@Server3 ~] # netstat-toccare | grep glusterfsd
TCP 0 0 *: 24009 *: * LISTEN 1311/glusterfsd
TCP 0 0 localhost.localdom:1018 localhost.localdo:24007 stabilito 1311/glusterfsd
[root@server3 ~]#

[root@Server4 ~] # netstat-toccare | grep glusterfsd
TCP 0 0 *: 24009 *: * LISTEN 1297/glusterfsd
TCP 0 0 localhost.localdom:1019 localhost.localdo:24007 stabilito 1297/glusterfsd
[root@server4 ~]#

Ora torniamo al Server1:

Server1:

È possibile controllare lo stato del volume con il comando

gluster volume info
[root@server1 ~]# gluster volume info

Nome del volume: testvol
Tipo: Distribuito-replicare
Stato: avviato
Numero di mattoni: 2 x 2 = 4
Tipo di trasporto: tcp
Mattoni:
Brick1: server1.example.com:/data
Brick2: server2.example.com:/data
Brick3: server3.example.com:/data
Brick4: server4.example.com:/data
[root@server1 ~]#

Per impostazione predefinita, tutti i client possono connettersi al volume. Se si desidera concedere l’accesso a CLIENT1 (= 192.168.0.104) solo, eseguire:

gluster volume set testvol auth.allow 192.168.0.104

Siete pregati di notare che è possibile utilizzare i caratteri jolly per gli indirizzi IP (come 192.168. *) e che è possibile specificare più indirizzi IP separati da virgola (ad esempio 192.168.0.104,192.168.0.105).

Le informazioni di volume dovrebbero ora mostrare lo stato aggiornato:

gluster volume info
[root@server1 ~]# gluster volume info

Nome del volume: testvol
Tipo: Distribuito-replicare
Stato: avviato
Numero di mattoni: 2 x 2 = 4
Tipo di trasporto: tcp
Mattoni:
Brick1: server1.example.com:/data
Brick2: server2.example.com:/data
Brick3: server3.example.com:/data
Brick4: server4.example.com:/data
Opzioni riconfigurati:
auth.allow: 192.168.0.104
[root@server1 ~]#

4 configurazione del Client di GlusterFS

CLIENT1:

Sul client, possiamo installare il client di GlusterFS come segue:

yum install glusterfs-client

Poi creiamo la directory seguente:

mkdir /mnt/glusterfs

Questo è tutto! Ora possiamo montare il filesystem di GlusterFS per /mnt/glusterfs con il seguente comando:

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

(Invece di Server1 è possibile anche utilizzare Server2 o server3.example.com o server4.example.com nel comando precedente!)

Ora dovreste vedere la nuova condivisione nelle uscite del…

mount

[root@CLIENT1 ~] # mount
/dev/mapper/vg_client1-LogVol00 su / tipo ext4 (rw)
proc su/proc tipo proc (rw)
digitare sysfs su /sys sysfs (rw)
devpts su/dev/pts tipo devpts (rw, gid = 5, mode = 620)
tmpfs su /dev/shm tmpfs tipo (rw)
/ dev/sda1 su/boot tipo ext4 (rw)
nessuno su /proc/sys/fs/binfmt_misc tipo binfmt_misc (rw)
sunrpc su /var/lib/nfs/rpc_pipefs tipo rpc_pipefs (rw)
Server1.example.com:/testvol su/mnt/glusterfs digitare fuse.glusterfs (rw, allow_other, default_permissions, max_read = 131072)
[root@CLIENT1 ~]#

… e…

df -h

[root@CLIENT1 ~] # df -h
Dimensione filesystem usato approfitta uso % montato su
/dev/mapper/vg_client1-LogVol00
9,7 G 1,7 G 7,5 G 19% /
tmpfs 499M. 499M 0 0% / dev/shm
/ dev/sda1 504M 39M 440M 9% / boot
Server1.example.com:/testvol
58G 2,1 G 53G 4% / mnt/glusterfs
[root@CLIENT1  ~]#

Invece di montare che il GlusterFS condividere manualmente sul client, è possibile modificare/etc/fstab in modo che la condivisione viene montata automaticamente quando si avvia il client.

Aprire/etc/fstab e aggiungere la seguente riga:

vi /etc/fstab 
[...]
server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0

(Ancora una volta, anziché Server1 è possibile anche utilizzare Server2 o server3.example.com o server4.example.com!)

Per verificare se il proprio modificate/etc/fstab sta lavorando, è necessario riavviare il client:

reboot 

Dopo il riavvio, si dovrebbe trovare la condivisione nelle uscite del…

df -h 

… e…

mount

 

5 collaudo

Ora andiamo a creare alcuni file di prova per la condivisione di GlusterFS:

CLIENT1:

tocco /mnt/glusterfs/test1
tocco /mnt/glusterfs/test2
tocco /mnt/glusterfs/test3
tocco /mnt/glusterfs/test4
tocco /mnt/glusterfs/test5
tocco /mnt/glusterfs/test6

Ora controlliamo la directory/dati su Server1Server2server3.example.comserver4.example.comSi noterà che replication1 così come replication2 tenere solo una parte del file/directory che compongono la condivisione GlusterFS sul client, ma i nodi che compongono replication1 (server2server1 e ) o replication2 (server3 e server4) contengono gli stessi file (mirroring):

Server1:

ls -l /data

[root@server1 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test1
-rw-r – r-1 root root 0 2012-12-17 15:49 test2
-rw-r – r-1 root root 0 2012-12-17 15:49 test4
-rw-r – r-1 root root 0 2012-12-17 15:49 test5
[root@server1 ~]#

Server2:

ls -l /data

[root@Server2 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test1
-rw-r – r-1 root root 0 2012-12-17 15:49 test2
-rw-r – r-1 root root 0 2012-12-17 15:49 test4
-rw-r – r-1 root root 0 2012-12-17 15:49 test5
[root@Server2 ~]#

Server3.example.com:

ls -l /data

[root@Server3 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test3
-rw-r – r-1 root root 0 2012-12-17 15:49 test6
[root@Server3 ~]#

server4.example.com:

ls -l /data

[root@Server4 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test3
-rw-r – r-1 root root 0 2012-12-17 15:49 test6
[root@Server4 ~]#

Ora abbiamo arrestato Server1 e server4.example.com e aggiungere o eliminare alcuni file sulla condivisione GlusterFS su CLIENT1.

Server1.example.com/Server4.example.com:

shutdown -h now

CLIENT1:

rm -f /mnt/glusterfs/test5
rm -f /mnt/glusterfs/test6

Le modifiche dovrebbero essere visibili nella directory /data sul Server2 e server3.example.com:

Server2:

ls -l /data

[root@Server2 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test1
-rw-r – r-1 root root 0 2012-12-17 15:49 test2
-rw-r – r-1 root root 0 2012-12-17 15:49 test4
[root@Server2 ~]#

Server3.example.com:

ls -l /data

[root@Server3 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test3
[root@Server3 ~]#

Let’s avvio Server1 e server4.example.com di nuovo e dare un’occhiata alla directory/dati :

Server1:

ls -l /data

[root@server1 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test1
-rw-r – r-1 root root 0 2012-12-17 15:49 test2
-rw-r–r– 1 root root 0 2012-12-17 15:49 test4
-rw-r–r– 1 root root 0 2012-12-17 15:49 test5
[root@server1 ~]#

server4.example.com:

ls -l /data

[root@server4 ~]# ls -l /data
total 0
-rw-r–r– 1 root root 0 2012-12-17 15:49 test3
-rw-r–r– 1 root root 0 2012-12-17 15:49 test6
[root@server4 ~]#

As you see, server1.example.com and server4.example.com haven’t noticed the changes that happened while they were down. This is easy to fix, all we need to do is invoke a read command on the GlusterFS share on client1.example.com, e.g.:

client1.example.com:

ls -l /mnt/glusterfs/

[root@client1 ~]# ls -l /mnt/glusterfs/
total 0
-rw-r–r– 1 root root 0 2012-12-17 15:49 test1
-rw-r–r– 1 root root 0 2012-12-17 15:49 test2
-rw-r–r– 1 root root 0 2012-12-17 15:49 test3
-rw-r–r– 1 root root 0 2012-12-17 15:49 test4
[root@client1 ~]#

Now take a look at the /data directory on server1.example.com and server4.example.com again, and you should see that the changes have been replicated to these nodes:

server1.example.com:

ls -l /data

[root@server1 ~]# ls -l /data
total 0
-rw-r–r– 1 root root 0 2012-12-17 15:49 test1
-rw-r–r– 1 root root 0 2012-12-17 15:49 test2
-rw-r–r– 1 root root 0 2012-12-17 15:49 test4
[root@server1 ~]#

server4.example.com:

ls -l /data

[root@Server4 ~] # ls -l/dati
totale 0
-rw-r – r-1 root root 0 2012-12-17 15:49 test3
[root@Server4 ~]#

 

  • GlusterFS: http://www.gluster.org/
  • GlusterFS 3.2 documentazione: http://download.gluster.com/pub/gluster/glusterfs/3.2/Documentation/AG/html/index.html
  • CentOS: http://www.centos.org/

Piaciuto l'articolo? Condividilo sui social!

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp