GlusterFS agrège des répertoires sur plusieurs serveurs en un seul système de fichiers montable — utile quand vous avez besoin de sémantique POSIX entre hôtes sans le poids opérationnel de Ceph. Un volume distribué étale les fichiers par hachage, ce qui donne une mise à l’échelle linéaire de la capacité mais pas de redondance ; un volume distribué-répliqué ajoute des répliques au prix d’un doublement du stockage. Cet article documente l’installation à quatre briques que nous utilisons comme point de départ pour les petits déploiements Gluster, le choix entre types de volumes, et les étapes de vérification qui détectent un split-brain avant qu’il ne dévore votre soirée.

Comment vérifier

# Sur chaque pair
apt list --installed glusterfs-server 2>/dev/null
sudo systemctl status glusterd
sudo gluster peer status

# État du pool et du volume
sudo gluster pool list
sudo gluster volume list
sudo gluster volume info shared-data

# État de la réparation (volumes répliqués uniquement)
sudo gluster volume heal shared-data info
sudo gluster volume heal shared-data info split-brain

Ce qui se passe

Un déploiement GlusterFS a trois concepts. Un pair est un serveur exécutant glusterd. Une brique est un répertoire sur un pair contribuant à un volume — typiquement un point de montage sur un disque ou un volume LVM dédié, pas le système de fichiers racine. Un volume est l’agrégation logique que les clients montent ; son type détermine comment les données sont étalées entre briques. Les types courants : distribué (étalé par hachage, sans redondance), répliqué (miroir de N copies), distribué-répliqué (le défaut pratique — distribuer les fichiers entre ensembles de répliques), dispersé (codé par effacement, moins de disques pour la même protection mais écritures plus lentes).

Gluster utilise un client FUSE en espace utilisateur par défaut. Les lectures et écritures passent du processus client à travers FUSE vers le démon glusterfs en espace utilisateur, qui contacte la bonne brique en fonction du hachage du fichier. Il n’y a pas de serveur de métadonnées — chaque client calcule indépendamment les emplacements des briques, c’est pourquoi l’appartenance au pair et le pool de stockage de confiance doivent être cohérents à travers la grappe. Quand vous ajoutez ou retirez des briques, la distribution de hachage change et Gluster lance une opération de rééquilibrage pour déplacer les fichiers existants vers leurs nouveaux emplacements ; c’est une opération en ligne mais gourmande en bande passante.

Les modes d’échec qui font mal sont le split-brain dans les volumes répliqués et l’état de brique périmé après un redémarrage de pair. Le split-brain arrive quand deux répliques acceptent des écritures divergentes pendant une partition réseau ; la réparation n’est pas automatique pour les fichiers où les deux côtés ont changé, et gluster volume heal info split-brain liste les fichiers nécessitant une résolution manuelle. Le correctif est de choisir un gagnant (gluster volume heal <vol> split-brain source-brick <brique> <fichier>) et de laisser le démon de réparation copier à partir de là. L’état de brique périmé arrive quand le disque sous-jacent réapparaît avec des UUID XFS différents après une mise à jour du noyau — Gluster garde les métadonnées de brique dans les extended attributes du chemin de brique, et si elles disparaissent, la brique refuse de démarrer.

La procédure

Sur les quatre nœuds (storage1 à storage4), préparer un volume de brique XFS dédié :

sudo mkfs.xfs -i size=512 -f /dev/sdb
sudo mkdir -p /data/brick1
echo '/dev/sdb /data/brick1 xfs defaults 0 2' | sudo tee -a /etc/fstab
sudo mount /data/brick1
sudo mkdir -p /data/brick1/gv0

Installer le serveur GlusterFS sur les quatre nœuds :

sudo apt update
sudo apt install -y glusterfs-server
sudo systemctl enable --now glusterd

Ouvrir le port de gestion (24007) et les ports de brique (49152+) sur le pare-feu :

sudo ufw allow from 10.0.0.0/16 to any port 24007 proto tcp
sudo ufw allow from 10.0.0.0/16 to any port 49152:49162 proto tcp

Depuis storage1, sonder les autres pairs vers le pool de stockage de confiance :

sudo gluster peer probe storage2
sudo gluster peer probe storage3
sudo gluster peer probe storage4
sudo gluster peer status

Créer un volume distribué-répliqué (replica=2, donc 4 briques = 2 ensembles de répliques) :
```
sudo gluster volume create shared-data replica 2 \
  storage1:/data/brick1/gv0 storage2:/data/brick1/gv0 \
  storage3:/data/brick1/gv0 storage4:/data/brick1/gv0 \
  force
sudo gluster volume start shared-data
```
Le drapeau force est nécessaire car les chemins de brique sont des sous-répertoires du montage ; c’est le schéma normal, pas un contournement.

Définir des défauts raisonnables pour la production :

sudo gluster volume set shared-data performance.cache-size 256MB
sudo gluster volume set shared-data network.ping-timeout 10
sudo gluster volume set shared-data cluster.self-heal-daemon enable
sudo gluster volume set shared-data cluster.quorum-type auto
sudo gluster volume set shared-data cluster.server-quorum-type server

Sur un client, installer glusterfs-client et monter :

sudo apt install -y glusterfs-client
sudo mkdir -p /mnt/shared
sudo mount -t glusterfs storage1:/shared-data /mnt/shared
echo "storage1:/shared-data /mnt/shared glusterfs defaults,_netdev,backupvolfile-server=storage2 0 0" | sudo tee -a /etc/fstab

L’option backupvolfile-server compte — sans elle, le client ne connaît que storage1 pour la récupération initiale de la topologie du volume et le montage échoue au démarrage si ce pair est en panne.

Pièges fréquents

Utiliser le système de fichiers racine comme brique (/data au lieu d’un montage dédié) mène à des conditions de disque plein qui coincent glusterd. Toujours placer les briques sur un volume XFS séparé.
network.ping-timeout est par défaut à 42 secondes, trop long pour la plupart des scénarios de production — un pair bloqué met l’E/S en pause pendant cet intervalle. Descendre à 10s ou même 5s pour les exigences de basse latence.
Le quorum (cluster.quorum-type auto) est ce qui empêche un split-brain de corrompre les écritures pendant une partition réseau ; sans lui, un volume à 2 répliques acceptera les écritures du côté atteignable et il faudra arbitrer les conflits après.
gluster volume heal info après le retour d’une brique vous dit combien de rattrapage est en cours ; de grandes entrées ici signifient que les clients verront des écritures lentes jusqu’à la fin de la réparation.
Le client FUSE met en cache les métadonnées agressivement ; si vous rm -rf depuis un client et qu’un autre client ne voit pas le répertoire disparaître, exécutez find /mnt/shared/chemin -delete à la place ou remontez.

Dans les engagements que nous opérons, GlusterFS apparaît quand un client a besoin de stockage POSIX partagé sur un petit nombre de nœuds — typiquement 3 à 6 — et n’a pas la maturité opérationnelle pour un déploiement Ceph. Nous déployons avec quorum, surveillons les compteurs de réparation via l’exporteur Prometheus, et documentons le runbook de split-brain avant la mise en service de la grappe — parce que la résolution exige de choisir un gagnant, et c’est une décision que le client doit assumer.