Questo tutorial mostra come combinare quattro server di archiviazione singoli (che eseguono CentOS 6.3) in uno storage replicato distribuito con GlusterFS. I nodi 1 e 2 (replica1) e 3 e 4 (replica2) si rispecchieranno a vicenda e la replica1 e la replica2 verranno combinate in un server di archiviazione più grande (distribuzione). Fondamentalmente, questo è RAID10 su rete. Se si perde un server dalla replica1 e uno dalla replica2, il volume distribuito continua a funzionare. Il sistema client (anche CentOS 6.3) sarà in grado di accedere allo storage come se fosse un filesystem locale.GlusterFS è un file system in cluster in grado di scalare a diversi peta-byte. Aggrega vari blocchi di archiviazione su Infiniband RDMA o interconnessione TCP/IP in un unico file system di rete parallelo di grandi dimensioni. I mattoni di archiviazione possono essere realizzati con qualsiasi hardware di consumo come server x86_64 con RAID SATA-II e HBA Infiniband.
Non garantisco che questo funzionerà per te!
1 Nota preliminare
In questo tutorial utilizzo cinque sistemi, quattro server e un client:
- server1.example.com:indirizzo IP 192.168.0.100 (server)
- server2.example.com: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.example.com:indirizzo IP 192.168.0.104 (client)
Tutti e cinque 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 cinque i 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 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 Abilita repository aggiuntivi
server1.example.com/server2.example.com/server3.example.com/server4.example.com/client1.example.com:
Per prima cosa importiamo le chiavi GPG per i pacchetti software:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
Quindi abilitiamo il repository EPEL6 sui nostri sistemi 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-release-6- 7.noarch.rpm
yum install yum-priorities
Modifica /etc/yum.repos.d/epel.repo...
vi /etc/yum.repos.d/epel.repo
... e aggiungi la linea priority=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 Configurazione dei server GlusterFS
server1.example.com/server2.example.com/server3.example.com/server4.example.com:
GlusterFS è disponibile come pacchetto per EPEL, quindi possiamo installarlo come segue:
yum install glusterfs-server
Crea i collegamenti di avvio del sistema per il demone Gluster e avvialo:
chkconfig --levels 235 glusterd su
/etc/init.d/glusterd start
Il comando
glusterfsd --version
ora dovrebbe mostrare la versione GlusterFS che hai appena installato (3.2.7 in questo caso):
[[email protected] ~]# glusterfsd --version
glusterfs 3.2.7 costruito su Jun 11 2012 13:22:28
Revisione del repository:git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc.
GlusterFS viene fornito con ASSOLUTAMENTE NESSUNA GARANZIA.
È possibile ridistribuire copie di GlusterFS secondo i termini di la GNU General Public License.
[[email protected] ~]#
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, server2.example.com, server3.example.com e server4.example.com.
Successivamente dobbiamo aggiungere server2.example.com, server3.example.com e server4.example.com al pool di archiviazione attendibile (si noti che sto eseguendo tutti i comandi di configurazione GlusterFS da server1.example.com, ma è possibile come eseguili bene da server2.example.com o server3.example.com o server4.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
gluster peer probe server3.example.com
gluster peer probe server4.example.com
L'output dovrebbe essere il seguente:
[[email protected] ~]# gluster peer probe server2.example.com
Sondaggio riuscita
[[email protected] ~]#
Lo stato del pool di archiviazione attendibile dovrebbe ora essere simile a questo:
gluster peer status
[[email protected] ~]# stato del peer gluster
Numero di peer:3
Nome host:server2.example.com
Uuid:600ff607-f7fd-43f6-af8d-419df703376d
Stato:peer in cluster (connesso)
Nome host:server3.example.com
Uuid:1d6a5f3f-c2dd-4727-a050-0431772cc381
Stato:peer in cluster (connesso)
Nome host:server4.example.com
Uuid:0bd9d445-0b5b-4a91-be6f-02b13c41d5d6
Stato:peer in cluster (connesso)
[[email protected] ~]#
Quindi creiamo la condivisione replicata distribuita denominata testvol con due repliche (si noti che il numero di repliche è la metà del numero di server in questo caso perché vogliamo impostare la replica distribuita) su server1.example.com, server2.example.com , server3.example.com e server4.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 server3.example.com:/data server4.example.com:/data
[[email protected] ~]# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data server3.example.com:/data server4.example.com:/data
La creazione del volume testvol è riuscita. Avvia il volume per accedere ai dati.
[[email protected] ~]#
Avvia il volume:
gluster volume start testvol
È possibile che il comando precedente ti dica che l'azione non è andata a buon fine:
[[email protected] ~]# gluster volume start testvol
L'avvio del volume testvol non è riuscito
[[email protected] ~]#
In questo caso dovresti 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 ottieni un output in questo modo...
[[email protetta] ~]# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Ascolta 1365 /Glusterfsd
TCP 0 0 LocalHost:1023 LocalHost:24007 Istituito 1365 /Glusterfsd
TCP 0 0 Server1.example.com:24009 server1.example.com:1023 ESTABLISHED 1365/glusterfsd
[[email protected] ~]#
... va tutto bene, ma se non ottieni alcun output...
[[email protetta] ~]# netstat -tap | grep glusterfsd
[[email protected] ~]#
[[email protetta] ~]# netstat -tap | grep glusterfsd
[[email protected] ~]#
[[email protetta] ~]# netstat -tap | grep glusterfsd
[[email protected] ~]#
... riavvia il demone GlusterFS sul server corrispondente (server2.example.com, server3.example.com e server4.example.com in questo caso):
server2.example.com/server3.example.com/server4.example.com:
/etc/init.d/glusterfsd restart
Quindi controlla l'output di...
netstat -tap | grep glusterfsd
... ancora su questi server - ora dovrebbe apparire così:
[[email protetta] ~]# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Ascolta 1152 /Glusterfsd
TCP 0 0 localhost.localdom:1018 localhost.localdo:24007 stabilito 1152 /glusterfsd
[[e -mail protetto] ~ ]#
[[email protetta] ~]# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Ascolta 1311 /Glusterfsd
TCP 0 0 localhost.localdom:1018 localhost.localdo:24007 stabilito 1311 /glusterfsd
[[e -mail protetto] ~ ~ ]#
[[email protetta] ~]# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Ascolta 1297 /Glusterfsd
TCP 0 0 localhost.localdom:1019 localhost.localdo:24007 stabilito 1297 /glusterfsd
[[e -mail protetto] ~ ~ ]#
Ora torniamo a server1.example.com:
server1.example.com:
Puoi controllare lo stato del volume con il comando
gluster volume info
[[email protected] ~]# gluster volume info
Nome volume:testvol
Tipo:replicato distribuito
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
[[email protected] ~]#
Per impostazione predefinita, tutti i client possono connettersi al volume. Se desideri concedere l'accesso solo a client1.example.com (=192.168.0.104), esegui:
gluster volume set testvol auth.allow 192.168.0.104
Si noti che è possibile utilizzare caratteri jolly per gli indirizzi IP (come 192.168.*) e che è possibile specificare più indirizzi IP separati da virgole (es. 192.168.0.104,192.168.0.105).
Le informazioni sul volume dovrebbero ora mostrare lo stato aggiornato:
gluster volume info
[[email protected] ~]# gluster volume info
Nome volume:testvol
Tipo:replicato distribuito
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 riconfigurate:
auth.allow:192.168.0.104
[[email protected] ~]#
4 Configurazione del client GlusterFS
client1.example.com:
Sul client, possiamo installare il client GlusterFS come segue:
yum install glusterfs-client
Quindi creiamo la seguente directory:
mkdir /mnt/glusterfs
Questo è tutto! Ora possiamo montare il filesystem GlusterFS su /mnt/glusterfs con il seguente comando:
mount.glusterfs server1.example.com:/testvol /mnt/glusterfs
(Invece di server1.example.com puoi anche utilizzare server2.example.com o server3.example.com o server4.example.com nel comando precedente!)
Ora dovresti vedere la nuova condivisione negli output di...
mount
[[email protected] ~]# mount
/dev/mapper/vg_client1-LogVol00 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts su /dev/pts tipo devpts (rw,gid=5,mode=620)
tmpfs su /dev/shm tipo tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
server1.example.com:/testvol su /mnt/glusterfs digita fuse.glusterfs (rw,allow_other,default_permissions,max_read=131072)
[[email protected] ~]#
... e...
df -h
[[email protected] ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_client1-LogVol00
9.7G 1.7G 7.5G 19% br < 19 /> tmpfs 499m 0 499m 0%/dev/shm
/dev/sda1 504m 39m 440m 9%/boot
server1.example.com:/testvol
58g 2.1g 53g 4%/ mnt/glusterfs
[[email protected] ~]#
Invece di montare manualmente la condivisione GlusterFS sul client, è possibile 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 |
(Di nuovo, invece di server1.example.com puoi anche usare server2.example.com o server3.example.com o server4.example.com!)
Per verificare se il tuo /etc/fstab modificato funziona, riavvia il client:
reboot
Dopo il riavvio, dovresti trovare la condivisione negli output di...
df -h
... e...
mount
5 Test
Ora creiamo alcuni file di prova sulla condivisione GlusterFS:
client1.example.com:
touch /mnt/glusterfs/test1
touch /mnt/glusterfs/test2
touch /mnt/glusterfs/test3
touch /mnt/glusterfs/test4
touch /mnt/glusterfs/ test5
tocca /mnt/glusterfs/test6
Ora controlliamo la directory /data su server1.example.com, server2.example.com, server3.example.com e server4.example.com. Noterai che replica1 e replica2 contengono solo una parte dei file/directory che compongono la condivisione GlusterFS sul client, ma i nodi che compongono replica1 (server1 e server2) o replica2 (server3 e server4) contengono lo stesso file (mirroring):
server1.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test5
[[email protected] ~]#
server2.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test5
[[email protected] ~]#
server3.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test6
[[email protected] ~]#
server4.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test6
[[email protected] ~]#
Ora chiudiamo server1.example.com e server4.example.com e aggiungiamo/eliminiamo alcuni file nella condivisione GlusterFS su client1.example.com.
server1.example.com/server4.example.com:
shutdown -h now
client1.example.com:
rm -f /mnt/glusterfs/test5
rm -f /mnt/glusterfs/test6
Le modifiche dovrebbero essere visibili nella directory /data su server2.example.com e server3.example.com:
server2.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
[[email protetta] ~]#
server3.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
[ [email protetta] ~]#
Avviamo nuovamente server1.example.com e server4.example.com e diamo un'occhiata alla directory /data:
server1.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test5
[[email protected] ~]#
server4.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test6
[[email protected] ~]#
Come puoi vedere, server1.example.com e server4.example.com non hanno notato i cambiamenti avvenuti mentre erano inattivi. 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/
[[email protetta] ~]# ls -l /mnt/glusterfs/
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
[[email protected] ~]#
Ora dai un'occhiata alla directory /data su server1.example.com e server4.example.com di nuovo e dovresti vedere che le modifiche sono state replicate su questi nodi:
server1.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test1
- rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test2
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test4
[[email protetta] ~]#
server4.example.com:
ls -l /data
[[email protetta] ~]# ls -l /data
totale 0
-rw-r--r-- 1 radice radice 0 17-12-2012 15:49 test3
[ [email protetta] ~]#
6 link
- GlusterFS:http://www.gluster.org/
- Documentazione di GlusterFS 3.2:http://download.gluster.com/pub/gluster/glusterfs/3.2/Documentation/AG/html/index.html
- CentOS:http://www.centos.org/