Stockage · 10 min read · Nov 29, 2025

Stockage haute disponibilité avec GlusterFS sur CentOS 7 - Miroir entre deux serveurs de stockage

Ce tutoriel montre comment configurer un stockage haute disponibilité avec deux serveurs de stockage (CentOS 7.2) qui utilisent GlusterFS. Chaque serveur de stockage sera un miroir de l’autre serveur de stockage, et les fichiers seront répliqués automatiquement entre les deux serveurs de stockage. Le système client (CentOS 7.2 également) pourra accéder au stockage comme s’il s’agissait d’un système de fichiers local. GlusterFS est un système de fichiers en cluster capable de s’étendre à plusieurs pétaoctets. Il agrège divers blocs de stockage via Infiniband RDMA ou TCP/IP en un grand système de fichiers réseau parallèle. Les blocs de stockage peuvent être constitués de n’importe quel matériel standard tel que des serveurs x86_64 avec RAID SATA-II et HBA Infiniband.

1 Remarque préliminaire

Dans ce tutoriel, j’utilise trois systèmes, deux serveurs et un client :

  • server1.example.com : adresse IP 192.168.0.100 (serveur)
  • server2.example.com : adresse IP 192.168.0.101 (serveur)
  • client1.example.com : adresse IP 192.168.0.102 (client)

Les trois systèmes doivent être capables de résoudre les noms d’hôte des autres systèmes. Si cela ne peut pas être fait via DNS, vous devez modifier le fichier /etc/hosts afin qu’il ressemble à ceci sur les trois systèmes :

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

(Il est également possible d’utiliser des adresses IP au lieu de noms d’hôte dans la configuration suivante. Si vous préférez utiliser des adresses IP, vous n’avez pas à vous soucier de savoir si les noms d’hôte peuvent être résolus ou non.)

2 Activer des dépôts supplémentaires

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

Tout d’abord, nous importons les clés GPG pour les paquets logiciels :

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

Ensuite, nous activons le dépôt EPEL 7 sur nos systèmes CentOS :

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

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

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

… et ajoutez la ligne priority=10 à la section [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
[...]

Ensuite, nous mettons à jour nos paquets existants sur le système :

yum -y update

3 Configuration des serveurs GlusterFS

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

GlusterFS est disponible dans le dépôt du groupe d’intérêt spécial de stockage de CentOS. Installez le dépôt avec cette commande :

yum -y install centos-release-gluster

Ensuite, installez le serveur GlusterFS comme suit :

yum -y install glusterfs-server

Créez les liens de démarrage système pour le démon Gluster et démarrez-le :

systemctl enable glusterd.service  
systemctl start glusterd.service

La commande

glusterfsd --version

devrait maintenant afficher la version de GlusterFS que vous venez d’installer (3.7.12 dans ce cas) :

[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 comes with ABSOLUTELY NO WARRANTY.  
It is licensed to you under your choice of the GNU Lesser  
General Public License, version 3 or any later version (LGPLv3  
or later), or the GNU General Public License, version 2 (GPLv2),  
in all cases as published by the Free Software Foundation.

Si vous utilisez un pare-feu, assurez-vous que les ports TCP 111, 24007, 24008, 24009-(24009 + nombre de blocs à travers tous les volumes) sont ouverts sur server1.example.com et server2.example.com.

Ensuite, nous devons ajouter server2.example.com au pool de stockage de confiance (veuillez noter que j’exécute toutes les commandes de configuration GlusterFS depuis server1.example.com, mais vous pouvez également les exécuter depuis server2.example.com car la configuration est répliquée entre les nœuds GlusterFS - assurez-vous simplement d’utiliser les bons noms d’hôte ou adresses IP) :

server1.example.com :

Sur server1.example.com, exécutez

gluster peer probe server2.example.com
[root@server1 ~]# gluster peer probe server2.example.com  
peer probe: success.

L’état du pool de stockage de confiance devrait maintenant être similaire à ceci :

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)

Ensuite, nous créons le partage nommé testvol avec deux répliques (veuillez noter que le nombre de répliques est égal au nombre de serveurs dans ce cas car nous voulons configurer le mirroring) sur server1.example.com et server2.example.com dans le répertoire /data (ce dernier sera créé s’il n’existe pas) :

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 ~]#

Démarrez le volume :

gluster volume start testvol

Le résultat devrait être :

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

Il est possible que la commande ci-dessus vous indique que l’action n’a pas réussi :

[root@server1 ~]# gluster volume start testvol  
Starting volume testvol has been unsuccessful  
[root@server1 ~]#

Dans ce cas, vous devez vérifier la sortie de…

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

netstat -tap | grep glusterfsd

sur les deux serveurs.

Si vous obtenez une sortie comme ceci…

[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 ~]#

… tout va bien, mais si vous n’obtenez aucune sortie…

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

… redémarrez le démon GlusterFS sur le serveur correspondant (server2.example.com dans ce cas) :

server2.example.com :

systemctl restart glusterd.service

Ensuite, vérifiez à nouveau la sortie de…

netstat -tap | grep glusterfsd

… sur ce serveur - cela devrait maintenant ressembler à ceci :

[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 ~]#

Maintenant, revenons à server1.example.com :

server1.example.com :

Vous pouvez vérifier l’état du volume avec la commande

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 ~]#

Par défaut, tous les clients peuvent se connecter au volume. Si vous souhaitez accorder l’accès uniquement à client1.example.com (= 192.168.1.102), exécutez :

gluster volume set testvol auth.allow 192.168.1.102

Veuillez noter qu’il est possible d’utiliser des caractères génériques pour les adresses IP (comme 192.168.*) et que vous pouvez spécifier plusieurs adresses IP séparées par des virgules (par exemple 192.168.1.102,192.168.1.103).

Les informations sur le volume devraient maintenant afficher le statut mis à jour :

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 Configuration du client GlusterFS

client1.example.com :

Sur le client, nous pouvons installer le client GlusterFS comme suit :

yum -y install glusterfs-client

Ensuite, nous créons le répertoire suivant :

mkdir /mnt/glusterfs

C’est tout ! Maintenant, nous pouvons monter le système de fichiers GlusterFS sur /mnt/glusterfs avec la commande suivante :

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

(À la place de server1.example.com, vous pouvez également utiliser server2.example.com dans la commande ci-dessus !)

Vous devriez maintenant voir le nouveau partage dans les sorties de…

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 ~]#

… et…

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 ~]#

Au lieu de monter manuellement le partage GlusterFS sur le client, vous ajoutez la commande de montage au fichier /etc/rc.local. Je ne l’ajouterai pas à /etc/fstab car rc.local est toujours exécuté après que le réseau soit opérationnel, ce qui est nécessaire pour un système de fichiers réseau.

Ouvrez /etc/rc.local et ajoutez la ligne suivante :

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

(Encore une fois, au lieu de server1.example.com, vous pouvez également utiliser server2.example.com !)

Pour tester si votre /etc/rc.local modifié fonctionne, redémarrez le client :

reboot

Après le redémarrage, vous devriez trouver le partage dans les sorties de…

df -h

… et…

mount

5 Test

Créons maintenant quelques fichiers de test sur le partage GlusterFS :

client1.example.com :

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

Vérifions maintenant le répertoire /data sur server1.example.com et server2.example.com. Les fichiers test1 et test2 devraient être présents sur chaque nœud :

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 ~]

Maintenant, nous éteignons server1.example.com et ajoutons/supprimons quelques fichiers sur le partage GlusterFS sur 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

Les commandes peuvent prendre un certain temps à s’exécuter car Glusterfs bascule vers server2 après qu’il ne peut plus atteindre server1. Nous pouvons voir ici la tolérance aux pannes du système, car nous pouvons toujours travailler sur notre partage de stockage de données lorsque server1 est hors ligne. Les changements devraient être visibles dans le répertoire /data sur 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

Redémarrons server1.example.com et vérifions le répertoire /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 ~]#

Comme vous le voyez, server1.example.com a automatiquement synchronisé les changements. Dans le cas où le changement n’a pas encore été synchronisé, il est facile de corriger cela, il suffit d’invoquer une commande de lecture sur le partage GlusterFS sur client1.example.com, par exemple :

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 ~]#

Maintenant, regardez à nouveau le répertoire /data sur server1.example.com, et vous devriez voir que les changements ont été répliqués sur ce nœud :

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 Liens

Share: X/Twitter LinkedIn
#Stockage

Recevez de nouveaux articles dans votre boîte de réception.

Aucun spam. Désabonnez-vous à tout moment.