Alma Linux Rocky Linux : Installer et paramétrer GlusterFS
Table des matières
GlusterFS est un système de fichiers distribué qui permet de regrouper plusieurs stockages de plusieurs serveurs pour les faire apparaître comme un seul et unique système de fichiers.
Parmi les avantages de GlusterFS, on pourra noter qu'il permet d'augmenter la capacité de stockage et la disponibilité des données en regroupant les ressources des différents noeuds. Il peut se paramétrer de différentes façons :
- Distribué : les données sont réparties sur plusieurs nœuds ou serveurs pour améliorer les performances et l'efficacité en utilisant les ressources de chacun des nœuds. Les données sont réparties de manière à ce que chacun des nœuds ne soit pas surchargé. (par analogie, voyez ça comme un RAID0 sur réseau)
- Répliqué : les données sont copiées sur plusieurs nœuds ou serveurs pour assurer la disponibilité et la tolérance aux pannes. Si un des nœuds tombe en panne, les données sont toujours disponibles sur un autre nœud. (par analogie, voyez ça comme un RAID1 sur réseau)
- Distribué + Répliqué : les données sont à la fois réparties sur plusieurs nœuds pour améliorer les performances et répliquées sur plusieurs nœuds pour assurer la disponibilité et la tolérance aux pannes. C'est une combinaison des avantages des systèmes distribués et répliqués pour offrir une solution de stockage haute disponibilité et à haute performance. (par analogie, voyez ça comme un RAID10 sur réseau)
GlusterFS est très flexible et peut être utilisé dans de nombreux environnements différents afin de stocker des fichiers de tout type, y compris des fichiers multimédias, des bases de données, des applications web.
Côté vocabulaire, on parlera de nœuds et de bricks :
- Les nœuds de stockage travaillent ensemble pour fournir un accès hautement disponible et scalable aux données stockées. Les données sont stockées sur les nœuds de stockage sous forme de bricks, qui peuvent être combinées pour former des volumes de stockage en réseau. Les utilisateurs peuvent accéder aux données stockées sur les nœuds de stockage en montant les volumes de stockage sur leurs systèmes clients.
- Les données sont stockées sur les bricks, qui peuvent être répliqués, distribués ou combinés pour former un volume GlusterFS.
- Les volumes GlusterFS peuvent être montés sur les systèmes clients pour une utilisation transparente et hautement disponible du stockage en réseau.
- Un brick est un sous-système de stockage unitaire composé d'un répertoire sur un nœud de stockage. Les bricks forment la base de la construction de systèmes de stockage distribués en réseau dans GlusterFS.
Ce tutoriel a été réalisé sur Alma Linux 9.
Dans ce tutoriel, je vais utiliser 3 serveurs. Vous devez en avoir au moins 3 pour éviter le phénomène de split brain.
Notez que le split brain est un problème qui peut se produire lorsque deux ou plusieurs nœuds pensent tous être les seuls à avoir la version correcte des données, alors qu'ils ne peuvent pas communiquer entre eux pour synchroniser les données.
Cela peut se produire typiquement en cas de coupure réseau entre 2 nœuds. Si cela se produit, chaque nœud peut effectuer des modifications sur les données sans connaître l'existence des modifications effectuées sur les autres nœuds.
Lorsque les communications entre les nœuds sont rétablies, il peut y avoir une divergence des données, ce qui peut rendre nécessaire une intervention manuelle pour résoudre les conflits.
Dans le cas de GlusterFS avec 2 nœuds, si un nœud redémarre, le stockage du deuxième ne sera pas accessible. Il nous faut donc 3 serveurs.
Cependant, pour éviter d'avoir 3 fois les données stockées (car ça prend de la place), nous allons dans ce tutoriel paramétrer :
- 2 nœuds qui vont stocker les données
- 1 nœud "arbitre".
L'arbitre ne stockera que les noms de fichiers/répertoires (c'est-à-dire l'arborescence) et les attributs étendus (métadonnées) mais aucune donnée, c'est-à-dire que la taille du fichier (comme indiqué par ls -l) sera de zéro octet. Il stockera également d'autres métadonnées gluster comme le dossier .glusterfs et son contenu.
Ainsi, lorsqu'un nœud redémarre (qu'il stocke les données ou que ce soit l'arbitre) les données sont toujours accessibles et cohérentes.
Il est conseillé de faire dialoguer les nœuds ensemble sur un réseau (ou VLAN) dédié. Mais on peut faire sans.
Nous disposons donc de 3 serveurs :
WEB01 : 192.168.21.108 (Serveur Web)
WEB02 : 192.168.21.102 (Serveur Web)
GLUSTER3 : 192.168.21.110 (Arbitre n'ayant pas de serveur Web)
Les serveurs WEB01 et WEB02 disposent d'un disque de 32Go (/dev/sdb) .
C'est sur ce disque que les données seront stockées et répliquées sur les nœuds.
Avant toute chose, assurez-vous que les 3 serveurs sont à jour :
Ensuite sur les 3 serveurs, on va installer le dépôt EPEL + le paquet centos-release-gluster pour installer ces 2 dépôts :
Notez que les dépôts sont actifs une fois installés.
Sur EL9 le paquet centos-release-gluster10 sera installé
Sur EL8 le paquet centos-release-gluster9 sera installé
Sur les 3 serveurs, installez glusterfs-server :
Sur les 3 serveurs, éditez le fichier hosts et ajoutez les entrées des 3 serveurs :
Démarrez le service glusterfs-server :
Si le parefeu est actif, ouvrez le service glusterfs :
Si SELinux est actif, il n'y a rien à faire
Sur les serveurs on va créer un point de montage /gluster pour y stocker les données :
Sur les serveurs qui contiennent les données, je vais monter notre disque additionnel qui va contenir les données :
On monte le tout :
Cette étape de montage d'un volume séparé est facultative sur l'arbitre, puisqu'il ne contiendra que les métadonnées des fichiers qui n'occupent pas de place sur le disque.
Ensuite, on va créer un sous dossier sur nos 3 serveurs qui sera la racine du système de fichiers GlusterFS qui stockera nos données (ici pour un site web) :
Maintenant, on va initier la connexion entre les différents nœuds.
Les commandes suivantes ne sont à saisir sur sur 1 des 3 serveurs (Je me positionne sur WEB01) .
On va appairer les 2 autres serveurs :
Si tout se passe bien, les commandes retournent peer probe: succes.
On peut vérifier l'état avec la commande suivante :
Qui retourne :
Maintenant que les 3 nœuds sont connectés, on va créer notre volume.
Voici la commande :
On notera que :
- wwwgfs est le nom du volume
- replica 2 arbiter 1 signifie que les données sont répliquées sur 2 nœuds et qu'on a un arbitre
- WEB01:/gluster/www WEB02:/gluster/www GLUSTER3:/gluster/www sont les emplacements où les données (ou métadonnées) seront stockées. Les 2 premiers stockent les données, le troisième est l'arbitre.
On démarre ensuite le volume :
Si tout se passe bien, la commande retourne volume start: wwwgfs: success
On peut avoir des infos sur le volume via la commande :
Qui retourne ceci dans notre cas :
Evidemment, on va pas accéder aux données directement par le dossier /gluster/www !
On va sur chacun des serveurs monter ce volume dans le dossier de notre choix (ici dans /var/www/html)
Pour celà on modifie le fichier fstab :
Sur WEB01 :
Sur WEB02 :
Dans les options, on précisera :
- _netdev : Pour que le montage se fasse une fois le réseau opérationnel
- context="system_u:object_r:httpd_sys_rw_content_t:s0" : utilisant SELinux, j'ajoute le contexte SELinux qui correspond à un contenu accessible en lecture écriture pour un serveur Web. Si SELinux est désactivé chez vous, vous pouvez ne pas le mettre.
Puis on monte le volume GlusterFS :
Avec la commande df on peut vérifier que tout est bien monté :
J'ai récupéré le CMS PluXML. J'ai décompressé les fichiers dans /var/www/html.
Sur un de mes nœud on constate que le /gluster/www contient bien nos fichiers :
On notera que sur l'arbitre, les fichiers sont bien là mais n'occuppent aucune place :
Dans notre cas ici, on a 2 serveurs WEB. Lorsque les fichiers sont modifiés sur un serveur WEB, sont modifiés dans la foulée sur l'autre.
Pour compléter sur la haute disponibilité de cet exemple vous pouvez :
- Ajouter 2 entrées A sur le DNS pointant sur chaque serveur WEB
- Paramétrer une VIP avec Pacemaker et Corosync
Introduction
GlusterFS est un système de fichiers distribué qui permet de regrouper plusieurs stockages de plusieurs serveurs pour les faire apparaître comme un seul et unique système de fichiers.
Parmi les avantages de GlusterFS, on pourra noter qu'il permet d'augmenter la capacité de stockage et la disponibilité des données en regroupant les ressources des différents noeuds. Il peut se paramétrer de différentes façons :
- Distribué : les données sont réparties sur plusieurs nœuds ou serveurs pour améliorer les performances et l'efficacité en utilisant les ressources de chacun des nœuds. Les données sont réparties de manière à ce que chacun des nœuds ne soit pas surchargé. (par analogie, voyez ça comme un RAID0 sur réseau)
- Répliqué : les données sont copiées sur plusieurs nœuds ou serveurs pour assurer la disponibilité et la tolérance aux pannes. Si un des nœuds tombe en panne, les données sont toujours disponibles sur un autre nœud. (par analogie, voyez ça comme un RAID1 sur réseau)
- Distribué + Répliqué : les données sont à la fois réparties sur plusieurs nœuds pour améliorer les performances et répliquées sur plusieurs nœuds pour assurer la disponibilité et la tolérance aux pannes. C'est une combinaison des avantages des systèmes distribués et répliqués pour offrir une solution de stockage haute disponibilité et à haute performance. (par analogie, voyez ça comme un RAID10 sur réseau)
GlusterFS est très flexible et peut être utilisé dans de nombreux environnements différents afin de stocker des fichiers de tout type, y compris des fichiers multimédias, des bases de données, des applications web.
Côté vocabulaire, on parlera de nœuds et de bricks :
- Les nœuds de stockage travaillent ensemble pour fournir un accès hautement disponible et scalable aux données stockées. Les données sont stockées sur les nœuds de stockage sous forme de bricks, qui peuvent être combinées pour former des volumes de stockage en réseau. Les utilisateurs peuvent accéder aux données stockées sur les nœuds de stockage en montant les volumes de stockage sur leurs systèmes clients.
- Les données sont stockées sur les bricks, qui peuvent être répliqués, distribués ou combinés pour former un volume GlusterFS.
- Les volumes GlusterFS peuvent être montés sur les systèmes clients pour une utilisation transparente et hautement disponible du stockage en réseau.
- Un brick est un sous-système de stockage unitaire composé d'un répertoire sur un nœud de stockage. Les bricks forment la base de la construction de systèmes de stockage distribués en réseau dans GlusterFS.
Ce tutoriel a été réalisé sur Alma Linux 9.
Prérequis
Contexte du tutoriel
Dans ce tutoriel, je vais utiliser 3 serveurs. Vous devez en avoir au moins 3 pour éviter le phénomène de split brain.
Notez que le split brain est un problème qui peut se produire lorsque deux ou plusieurs nœuds pensent tous être les seuls à avoir la version correcte des données, alors qu'ils ne peuvent pas communiquer entre eux pour synchroniser les données.
Cela peut se produire typiquement en cas de coupure réseau entre 2 nœuds. Si cela se produit, chaque nœud peut effectuer des modifications sur les données sans connaître l'existence des modifications effectuées sur les autres nœuds.
Lorsque les communications entre les nœuds sont rétablies, il peut y avoir une divergence des données, ce qui peut rendre nécessaire une intervention manuelle pour résoudre les conflits.
Dans le cas de GlusterFS avec 2 nœuds, si un nœud redémarre, le stockage du deuxième ne sera pas accessible. Il nous faut donc 3 serveurs.
Cependant, pour éviter d'avoir 3 fois les données stockées (car ça prend de la place), nous allons dans ce tutoriel paramétrer :
- 2 nœuds qui vont stocker les données
- 1 nœud "arbitre".
L'arbitre ne stockera que les noms de fichiers/répertoires (c'est-à-dire l'arborescence) et les attributs étendus (métadonnées) mais aucune donnée, c'est-à-dire que la taille du fichier (comme indiqué par ls -l) sera de zéro octet. Il stockera également d'autres métadonnées gluster comme le dossier .glusterfs et son contenu.
Ainsi, lorsqu'un nœud redémarre (qu'il stocke les données ou que ce soit l'arbitre) les données sont toujours accessibles et cohérentes.
Il est conseillé de faire dialoguer les nœuds ensemble sur un réseau (ou VLAN) dédié. Mais on peut faire sans.
Caractéristiques des serveurs
Nous disposons donc de 3 serveurs :
WEB01 : 192.168.21.108 (Serveur Web)
WEB02 : 192.168.21.102 (Serveur Web)
GLUSTER3 : 192.168.21.110 (Arbitre n'ayant pas de serveur Web)
Les serveurs WEB01 et WEB02 disposent d'un disque de 32Go (/dev/sdb) .
C'est sur ce disque que les données seront stockées et répliquées sur les nœuds.
Installation
Avant toute chose, assurez-vous que les 3 serveurs sont à jour :
Code BASH :
dnf upgrade
Ensuite sur les 3 serveurs, on va installer le dépôt EPEL + le paquet centos-release-gluster pour installer ces 2 dépôts :
Code BASH :
dnf install epel-release centos-release-glusterNotez que les dépôts sont actifs une fois installés.
Sur EL9 le paquet centos-release-gluster10 sera installé
Sur EL8 le paquet centos-release-gluster9 sera installé
Sur les 3 serveurs, installez glusterfs-server :
Code BASH :
dnf install glusterfs-serverConfiguration
Sur les 3 serveurs, éditez le fichier hosts et ajoutez les entrées des 3 serveurs :
Code BASH :
vi /etc/hosts
Code :
192.168.21.108 WEB01
192.168.21.103 WEB02
192.168.21.110 GLUSTER3
Démarrez le service glusterfs-server :
Code BASH :
systemctl enable --now glusterd
Si le parefeu est actif, ouvrez le service glusterfs :
Code BASH :
firewall-cmd --add-service=glusterfs --permanent firewall-cmd --reload
Si SELinux est actif, il n'y a rien à faire
Sur les serveurs on va créer un point de montage /gluster pour y stocker les données :
Code BASH :
mkdir /gluster
Sur les serveurs qui contiennent les données, je vais monter notre disque additionnel qui va contenir les données :
Code BASH :
vi /etc/fstab
Code :
UUID=62ec07d6-0686-4287-a92a-7d9725ce4469 /gluster ext4 defaults 0 0
On monte le tout :
Code BASH :
mount -a
Cette étape de montage d'un volume séparé est facultative sur l'arbitre, puisqu'il ne contiendra que les métadonnées des fichiers qui n'occupent pas de place sur le disque.
Ensuite, on va créer un sous dossier sur nos 3 serveurs qui sera la racine du système de fichiers GlusterFS qui stockera nos données (ici pour un site web) :
Code BASH :
mkdir /gluster/www
Maintenant, on va initier la connexion entre les différents nœuds.
Les commandes suivantes ne sont à saisir sur sur 1 des 3 serveurs (Je me positionne sur WEB01) .
On va appairer les 2 autres serveurs :
Code BASH :
gluster peer probe WEB02 gluster peer probe GLUSTER3
Si tout se passe bien, les commandes retournent peer probe: succes.
On peut vérifier l'état avec la commande suivante :
Code BASH :
gluster peer status
Qui retourne :
Code :
Number of Peers: 2
Hostname: WEB02
Uuid: 73a836aa-428a-4696-927a-fda3f92e8bbf
State: Peer in Cluster (Connected)
Hostname: GLUSTER3
Uuid: 868527d7-ae0c-4635-aac6-cfe9e5d4c7c5
State: Peer in Cluster (Connected)
Maintenant que les 3 nœuds sont connectés, on va créer notre volume.
Voici la commande :
Code BASH :
gluster volume create wwwgfs replica 2 arbiter 1 transport tcp WEB01:/gluster/www WEB02:/gluster/www GLUSTER3:/gluster/www force
On notera que :
- wwwgfs est le nom du volume
- replica 2 arbiter 1 signifie que les données sont répliquées sur 2 nœuds et qu'on a un arbitre
- WEB01:/gluster/www WEB02:/gluster/www GLUSTER3:/gluster/www sont les emplacements où les données (ou métadonnées) seront stockées. Les 2 premiers stockent les données, le troisième est l'arbitre.
On démarre ensuite le volume :
Code BASH :
gluster volume start wwwgfs
Si tout se passe bien, la commande retourne volume start: wwwgfs: success
On peut avoir des infos sur le volume via la commande :
Code BASH :
gluster volume info
Qui retourne ceci dans notre cas :
Code :
Volume Name: wwwgfs
Type: Replicate
Volume ID: 81e05e44-6ded-4942-b778-aae79d416c14
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: WEB01:/gluster/www
Brick2: WEB02:/gluster/www
Brick3: GLUSTER3:/gluster/www (arbiter)
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
Montage du volume GlusterFS
Evidemment, on va pas accéder aux données directement par le dossier /gluster/www !
On va sur chacun des serveurs monter ce volume dans le dossier de notre choix (ici dans /var/www/html)
Pour celà on modifie le fichier fstab :
Code BASH :
vi /etc/fstab
Sur WEB01 :
Code :
WEB01:/wwwgfs /var/www/html glusterfs defaults,_netdev,context="system_u:object_r:httpd_sys_rw_content_t:s0" 0 0
Sur WEB02 :
Code :
WEB02:/wwwgfs /var/www/html glusterfs defaults,_netdev,context="system_u:object_r:httpd_sys_rw_content_t:s0" 0 0
Dans les options, on précisera :
- _netdev : Pour que le montage se fasse une fois le réseau opérationnel
- context="system_u:object_r:httpd_sys_rw_content_t:s0" : utilisant SELinux, j'ajoute le contexte SELinux qui correspond à un contenu accessible en lecture écriture pour un serveur Web. Si SELinux est désactivé chez vous, vous pouvez ne pas le mettre.
Puis on monte le volume GlusterFS :
Code BASH :
mount -a
Avec la commande df on peut vérifier que tout est bien monté :
Code :
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
devtmpfs 4,0M 0 4,0M 0% /dev
tmpfs 982M 0 982M 0% /dev/shm
tmpfs 393M 5,5M 387M 2% /run
/dev/mapper/rootvg-rootlv 9,8G 1,5G 7,8G 16% /
/dev/sda1 974M 197M 710M 22% /boot
/dev/sdb1 32G 13M 30G 1% /gluster
/dev/mapper/rootvg-varloglv 974M 9,5M 897M 2% /var/log
/dev/mapper/rootvg-homelv 1014M 40M 975M 4% /home
tmpfs 197M 0 197M 0% /run/user/0
WEB01:/wwwgfs 32G 334M 30G 2% /var/www/html
Infos complémentaires pour cet exemple
J'ai récupéré le CMS PluXML. J'ai décompressé les fichiers dans /var/www/html.
Sur un de mes nœud on constate que le /gluster/www contient bien nos fichiers :
Code BASH :
ls -l /gluster/www/
Code :
total 140
-rw-r--r--. 2 apache root 56 1 août 20:37 config.php
drwxr-xr-x. 7 apache root 4096 1 août 20:37 core
drwxr-xr-x. 6 apache root 4096 1 août 20:37 data
-rw-r--r--. 2 apache root 1631 1 août 20:37 feed.php
-rw-r--r--. 2 apache root 3247 1 août 20:37 index.php
-rw-r--r--. 2 apache root 14905 1 août 20:37 install.php
-rw-r--r--. 2 apache root 35149 1 août 20:37 LICENSE
drwxr-xr-x. 2 apache root 4096 1 août 20:37 plugins
drwxr-xr-x. 2 apache root 4096 1 août 20:37 readme
-rw-r--r--. 2 apache root 4020 1 août 20:37 sitemap.php
drwxr-xr-x. 3 apache root 4096 1 août 20:37 themes
On notera que sur l'arbitre, les fichiers sont bien là mais n'occuppent aucune place :
Code :
total 72
-rw-r--r--. 2 48 root 0 1 août 20:37 config.php
drwxr-xr-x. 7 48 root 4096 1 août 20:37 core
drwxr-xr-x. 6 48 root 4096 1 août 20:37 data
-rw-r--r--. 2 48 root 0 1 août 20:37 feed.php
-rw-r--r--. 2 48 root 0 1 août 20:37 index.php
-rw-r--r--. 2 48 root 0 1 août 20:37 install.php
-rw-r--r--. 2 48 root 0 1 août 20:37 LICENSE
drwxr-xr-x. 2 48 root 4096 1 août 20:37 plugins
drwxr-xr-x. 2 48 root 4096 1 août 20:37 readme
-rw-r--r--. 2 48 root 0 1 août 20:37 sitemap.php
drwxr-xr-x. 3 48 root 4096 1 août 20:37 themes
Dans notre cas ici, on a 2 serveurs WEB. Lorsque les fichiers sont modifiés sur un serveur WEB, sont modifiés dans la foulée sur l'autre.
Pour compléter sur la haute disponibilité de cet exemple vous pouvez :
- Ajouter 2 entrées A sur le DNS pointant sur chaque serveur WEB
- Paramétrer une VIP avec Pacemaker et Corosync