Réplication de données entre serveurs - GlusterFS (Debian/Ubuntu) - Le Guide Du SecOps (2024)

Bonjour à tous, nous allons voir comment mettre en place un service Gluster-FS qui nous permet de faire du HAS (High-Availability Storage) entre deux serveurs. Cette solution est très populaire dans le monde de l’open source et est notamment utilisée par Amazon. Gluster-FS permet de fusionner un dossier / partition sur deux serveurs ou plus. Son but est de garantir l’intégrité des données dans un système d’information. C’est une solution fiable et pérenne pour votre infrastructure. Elle peut être couplée avec le service HA-Proxy pour mettre en place une solution «load balacing», répartition de charge en français.

Dans un premier temps, nous allons exécuter les différentes commandes suivantes nous permettant de pouvoir récupérer les différents dépôts. Puis, une fois que le service sera installé, nous allons le paramétrer et tester son implantation.

Note: Si vous utilisez le logiciel de virtualisation VMWorkstation, préféré l’utilisation de clone «full» et non pas de clone lié, qui peuvent altérer le bon fonctionnement du service glusterfs-server.

Prérequis :

Pour ce rapport, nous allons utiliser le logiciel de virtualisation VMWare Workstation 15.5.6, qui va nous permettre d’émuler deux machines virtuelles.

• Serveur Debian 1 (IPfixe : 192.168.128.100/24)
• Serveur Debian 2 (IPfixe : 192.168.128.200/24)
• Un accès à internet sur les deux machines
• Toutes les commandes ci-dessous seront exécutés par l’intermédiaire de root

Changement des noms d’hôtes des machines

hostnamectl set-hostname deb1.local # à éffectuer sur la machine deb1hostnamectl set-hostname deb2.local # à éffectuer sur la machine deb2

Modification du fichiers hosts (Résolution DNS locale)

À effectuer sur les deux serveurs :

nano /etc/hosts127.0.0.1 localhost127.0.1.1 debian.local debian192.168.128.100 deb1.local deb1192.168.128.200 deb2.local deb2

Avant de redémarrer pour appliquer les changements, veuillez tester la connectivité entre vos deux serveurs par l’intermédiaire des noms DNS :

À effectuer sur les deux serveurs :

ping deb1 # vérifiez que le retour de ping est correct (ainsi que l'@ ip qui est associée à ce nom : deb1 = 192.168.128.100ping deb2 # vérifier que le retour de ping soit bon (ainsi que l'@ ip qui est associée à ce nom : deb2 = 192.168.128.200

Lors des tests de ping, il ne faut pas qu’une adresse «localhost» vous réponde (127.0.0.1), mais bien les adresses IP de votre réseau

Installation de GlusterFS

Les prochaines directives doivent être effectuées sur les deux serveurs deb1 et deb2

apt-get update && apt-get upgradeapt-get install glusterfs-server

Une fois que l’installation de GlusterFS est terminé sur les deux machines, nous allons démarrer, vérifier le status, et activer le démarrage automatique du service au boot sur les deux serveurs :

systemctl start glusterdsystemctl status glusterd # Vérifie que le service est bien activé et lancésystemctl enable glusterd # permet de lancer le service au boot de la vm (très important)

Configuration

Création d’un «point de référence»

Créons le dossier data à la racine du disque, qui va servir de point de référence pour la suite. (À exécuter sur deb1 et deb2)

mkdir /data

Liaison des serveurs deb1 et deb2

Sur le serveur deb1.local uniquement, exécuter

gluster peer probe deb2.local# peer probe: success.

Le statut du pool de stockage approuvé devrait maintenant ressembler à ceci après l’exécution de la commande suivante.

root@deb1:~# gluster peer statusNumber of Peers: 1Hostname: deb2.localUuid: 2165b843-5dc5-4320-b664-e11c42f7e157State: Peer in Cluster (Connected)

Créons ensuite le partage nommé volume1 à l’aide de la commande suivante sur deb1.local :

root@deb1:~# gluster volume create volume1 replica 2 transport tcp deb1.local:/data/volume1 deb2.local:/data/volume1 force

Résultat de la commande :

volume create: volume1: success: please start the volume to access data

Comme indiqué, nous allons maintenant démarrer le volume :

root@deb1:~# gluster volume start volume1

Vérification et tests de connectivités

Commande à exécuter sur le serveur deb1.local et deb2.local

Exécutez cette commande dans le but de connaitre l’ensemble des informations liées au cluster.

gluster volume info

Installation du «point de réplication»

Sur les deux serveurs deb1, deb2 créons le répertoire suivant:

cd /mntmkdir glusterfs

Maintenant, nous pouvons monter le système de fichiers GlusterFS sur /mnt/glusterfs

Sur deb1

mount.glusterfs deb2.local:/volume1 /mnt/glusterfs

Sur deb2

mount.glusterfs deb1.local:/volume1 /mnt/glusterfs

Tapez la commande suivante pour vérifier que les directives ont bien été prises en comptes :

df -h # sur les deux serveurs 

Montage Persistant

Au lieu de monter manuellement à chaque boot le partage GlusterFS vous pouvez modifier /etc /fstab afin que le partage soit monté automatiquement à chaque démarrage des serveurs.

Sur deb1

nano /etc/fstab

[...]deb2.local:/volume1 /mnt/glusterfs glusterfs defaults,_netdev 0 0

Puis enregistrez directement le fichier

Sur deb2, nous allons faire la même chose, en changeant le nom d’hôte de la machine.

nano /etc/fstab

[...]deb1.local:/volume1 /mnt/glusterfs glusterfs defaults,_netdev 0 0

Puis enregistrez directement le fichier

Pour tester si votre /etc/fstab fonctionne, redémarrez les deux machines

Après le reboot des deux machines, vous devriez voir que les deux points de montages sont toujours effectifs, lors de l’exécution de df -h sur les deux serveurs.

Sur deb1

Sur deb2

Conseils : Lors de l’extinction de ses serveurs, vérifiez que les points de montages sont toujours présents avec df -h. En effet, si pour une raison x, un des deux serveurs peut mettre plus de temps à démarrer, cela peut «rompre» le lien de réplication (HAS) entre les deux temporairement.

La solution dans ce cas est de redémarrer le serveur problématique et de vérifier que le point de montage est bel et bien de nouveau présent avec df -h lors du redémarrage de la machine problématique

Contrôle d’accès :

À ce stade, n’importe qui peut se connecter à votre volume de stockage sans aucune restriction. Vous pouvez modifier cette situation en définissant l’option auth.allow, qui définit les adresses IP des clients qui doivent avoir accès au volume.

gluster volume set volume1 auth.allow 192.168.128.100, 192.168.128.200

Test de la réplication inter-serveurs

Dans cette section, nous allons tester si nos serveurs se répliquent bien entre eux (que les données sur deb1, sont bien présentes sur deb2 et vice- versa

Essayez de créer x fichiers depuis deb1 dans le dossier /mnt/glusterfs, et vérifiez que les fichiers soient automatiquement clonés sur deb2 dans le dossier /mnt/glusterfs.

Sur deb1 :

cd /mnt/glusterfstouch helloworld worldhello hellools

Sur deb2

cd /mnt/glusterfsls

Inversons le processus pour vérifier que deb1 recopie bien les données depuis deb2.

Sur deb2

cd /mnt/glusterfstouch coucoud france linuxls

Sur deb1

cd /mnt/glusterfsls

Dans les deux cas, nous constatons que la réplication a bien eu lieu et de manière instantanée.

Cas concrès

Attention ! Pour cette partie vous devez avoir un accès SSH/SFTP sur vos deux serveurs, ainsi que des droits d’écritures / lectures pour upluader des fichiers sur (deb1 ou deb2) /mnt/glusterfs

L’image ci-dessous vous montre l’upluad par SFTP d’un fichier «lourd» vers le dossier /mnt/glusterfs de deb1. Dès que l’upluad commence sur deb1.local (192.168.128.100), la réplication commence instantanément sur deb2 (192.168.128.200) comme vous le démontre l’image ci-dessous.

Test de la haute disponibilité en cas d’incident

Nous allons arrêter deb1.local et ajouter des fichiers sur le partage GlusterFS depuis deb2

shutdown now # sur deb1

Sur deb2

Note : La création de fichiers / copie de fichiers peut s’avérer plus longue et prendre quelques secondes (~ 30-45 secondes). En effet pendant ce laps de temps le service GlusterFS sur deb2 cherchent à joindre deb1, et c’est pour cela que les fichier ne se créer/copie pas de manière immédiate, car ils sont mis en suspens, le temps que deb2 comprenne que deb1 n’est plus joignable

touch shut down replication valid# Création de fichiers pour le test

Après avoir créé ces fichiers, démarrer de nouveau votre serveur deb1, et vérifier une fois le système démarré, si la réplication a bien eu lieu (patienter quelques secondes … :)) :

Sur deb1 :

ls /mnt/glusterfs

Vérification tierce par SFTP sur les deux serveurs

C’est là que nous constatons la puissance de cette solution, en effet la reprise du service sur panne se fait de manière transparente, et le premiers nœud du cluster (deb1) se reconnecte automatiquement à son partenaire ou bout de quelques secondes (deb2).

Si vous êtes encore là, j’espère que vous avez pu réussir l’installation et la configuration de cette solution sans trop prise de tête. ^^

À bientôt 🙂

Brlndtech