Archiviazione · 9 min read · Nov 29, 2025

Archiviazione ad alta disponibilità con GlusterFS su CentOS 7 - Specchio tra due server di archiviazione

Questo tutorial mostra come impostare un’archiviazione ad alta disponibilità con due server di archiviazione (CentOS 7.2) che utilizzano GlusterFS. Ogni server di archiviazione sarà uno specchio dell’altro server di archiviazione e i file saranno replicati automaticamente tra entrambi i server di archiviazione. Il sistema client (anch’esso CentOS 7.2) 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 costituiti da qualsiasi hardware commerciale come server x86_64 con RAID SATA-II e HBA Infiniband.

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:

nano /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   client1.example.com     client1

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

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

2 Abilitare repository aggiuntivi

server1.example.com/server2.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*

Poi abilitiamo il repository EPEL 7 sui nostri sistemi CentOS:

yum -y install epel-release
yum -y install yum-priorities

Modifica /etc/yum.repos.d/epel.repo…

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

… e aggiungi la riga priority=10 alla sezione [epel]:

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

Poi aggiorniamo i nostri pacchetti esistenti sul sistema:

yum -y update

3 Configurazione dei server GlusterFS

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

GlusterFS è disponibile nel repository del gruppo di interesse speciale per l’archiviazione di CentOS. Installa il repository con questo comando:

yum -y install centos-release-gluster

Poi installa il server GlusterFS come segue:

yum -y install glusterfs-server

Crea i collegamenti di avvio del sistema per il demone Gluster e avvialo:

systemctl enable glusterd.service  
systemctl start glusterd.service

Il comando

glusterfsd --version

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

[root@server1 ~]# glusterfsd --version  
glusterfs 3.7.12 built on Jun 24 2016 14:11:19  
Repository revision: git://git.gluster.com/glusterfs.git  
Copyright (c) 2006-2013 Red Hat, Inc.   
GlusterFS viene fornito senza ALCUNA GARANZIA.  
È concesso in licenza a te secondo la tua scelta della GNU Lesser  
General Public License, versione 3 o qualsiasi versione successiva (LGPLv3  
o successiva), o della GNU General Public License, versione 2 (GPLv2),  
in tutti i casi come pubblicato dalla Free Software Foundation.

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  
peer probe: success.

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: 582e10da-aa1b-40b8-908c-213f16f57fe5  
State: Peer in Cluster (Connected)

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 force
[root@server1 ~]# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data force  
volume create: testvol: success: please start the volume to access data  
[root@server1 ~]#

Avvia il volume:

gluster volume start testvol

Il risultato dovrebbe essere:

[root@server1 ~]# gluster volume start testvol  
volume start: testvol: success  
[root@server1 ~]#

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

[root@server1 ~]# gluster volume start testvol  
Starting volume testvol has been unsuccessful  
[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 0.0.0.0:49152 0.0.0.0:* LISTEN 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server2.example.c:49148 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server1.example.c:49148 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49150 server1.example.c:24007 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server2.example.c:49142 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server1.example.c:49149 ESTABLISHED 22880/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:

systemctl restart glusterd.service

Poi controlla di nuovo l’output di…

netstat -tap | grep glusterfsd

… su quel server - ora dovrebbe apparire così:

[root@server2 ~]# netstat -tap | grep glusterfsd  
tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server1.example.c:49140 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server2.example.c:49149 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server2.example.c:49143 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server1.example.c:49142 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49150 server2.example.c:24007 ESTABLISHED 10971/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  
Volume ID: e1f825ca-c9d9-4eeb-b6c5-d62c4aa02376  
Status: Started  
Number of Bricks: 1 x 2 = 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
performance.readdir-ahead: on  
[root@server1 ~]#

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

gluster volume set testvol auth.allow 192.168.1.102

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

Le informazioni sul volume dovrebbero ora mostrare lo stato aggiornato:

gluster volume info
[root@server1 ~]# gluster volume info
Volume Name: testvol  
Type: Replicate  
Volume ID: e1f825ca-c9d9-4eeb-b6c5-d62c4aa02376  
Status: Started  
Number of Bricks: 1 x 2 = 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
auth.allow: 192.168.1.102  
performance.readdir-ahead: on  
[root@server1 ~]#

4 Configurazione del client GlusterFS

client1.example.com:

Sul client, possiamo installare il client GlusterFS come segue:

yum -y 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

(Invece di server1.example.com puoi anche usare server2.example.com nel comando sopra!)

Ora dovresti vedere la nuova condivisione negli output di…

mount
[root@client1 ~]# mount  
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)  
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)  
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=930336k,nr_inodes=232584,mode=755)  
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)  
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)  
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)  
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)  
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)  
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)  
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)  
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)  
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)  
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)  
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)  
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)  
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)  
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)  
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)  
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)  
configfs on /sys/kernel/config type configfs (rw,relatime)  
/dev/mapper/centos-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)  
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)  
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)  
debugfs on /sys/kernel/debug type debugfs (rw,relatime)  
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)  
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)  
/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)  
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=188060k,mode=700)  
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  
/dev/mapper/centos-root 28G 1.3G 27G 5% /  
devtmpfs 909M 0 909M 0% /dev  
tmpfs 919M 0 919M 0% /dev/shm  
tmpfs 919M 8.6M 910M 1% /run  
tmpfs 919M 0 919M 0% /sys/fs/cgroup  
/dev/sda1 497M 192M 306M 39% /boot  
tmpfs 184M 0 184M 0% /run/user/0  
server1.example.com:/testvol 28G 12G 17G 41% /mnt/glusterfs  
[root@client1 ~]#

Invece di montare manualmente la condivisione GlusterFS sul client, puoi aggiungere il comando di montaggio al file /etc/rc.local. Non lo aggiungerò a /etc/fstab poiché rc.local viene sempre eseguito dopo che la rete è attiva, il che è necessario per un filesystem di rete.

Apri /etc/rc.local e aggiungi la seguente riga:

nano /etc/rc.local
[...]  
/usr/sbin/mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

(Ancora una volta, invece di server1.example.com puoi anche usare server2.example.com!)

Per testare se il tuo /etc/rc.local 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 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--. 2 root root 0 Jul 1 2016 test1  
-rw-r--r--. 2 root root 0 Jul 1 2016 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

I comandi potrebbero richiedere del tempo per essere eseguiti poiché Glusterfs passa a server2 dopo non riesce più a raggiungere server1. Possiamo vedere qui la tolleranza ai guasti del sistema poiché possiamo ancora lavorare sulla nostra condivisione di archiviazione dati quando server1 è offline. 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--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4

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

server1.example.com:

ls -l /data
[root@server1 ~]# ls -l /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test2  
[root@server1 ~]#

Come puoi vedere, server1.example.com ha automaticamente sincronizzato le modifiche. Nel caso in cui la modifica non sia stata ancora sincronizzata, allora è 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 /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4  
[root@server1 ~]#

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 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4  
[root@server1 ~]#

6 Link

Share: X/Twitter LinkedIn
#Archiviazione

Ricevi i nuovi post nella tua casella di posta.

Nessuno spam. Disiscriviti in qualsiasi momento.