Déployer GlusterFS : Replica 3, montage, réparation et exploitation

EdwardMoon

GlusterFS présente les disques de plusieurs serveurs comme un système de fichiers unique. Installer les paquets et relier deux nœuds ne suffit pas à garantir la haute disponibilité. Concevez ensemble le nombre de répliques, le quorum, les domaines de panne, les sauvegardes et le support des paquets pour réduire les pertes de données et le split-brain.

Ce guide suit un laboratoire Replica 3, avec une copie complète sur chacun des trois serveurs. Commandes et configurations sont séparées en blocs de code, avec vérifications et conditions d'arrêt. Avant la production, vérifiez les noms de périphériques, les plages réseau et le périmètre de support du fournisseur de paquets.

Vérifier les versions et le support avant déploiement

La dernière version communautaire trouvée dans le répertoire officiel est 11.1. La politique officielle prévoit toutefois environ 12 mois de maintenance par version majeure : 11.1 ne peut donc pas être recommandée sans réserve pour une nouvelle production en 2026. Vérifiez les correctifs de sécurité fournis par la distribution ou le prestataire commercial. Sans solution maintenue, évaluez aussi Ceph, NFS HA ou les services de fichiers cloud. Les commandes sont des exemples de laboratoire supposant un dépôt EL9 validé déjà configuré.

Topologie d'exemple

• Placer les trois serveurs dans des domaines de panne distincts et vérifier l'heure et la résolution directe/inverse.
• Séparer le système et les données des bricks sur des disques ou volumes logiques différents.
• Replica 3 conserve trois copies complètes et nécessite environ trois fois la capacité des données sources.
• La réplication propage aussi suppressions, chiffrement et erreurs applicatives : des sauvegardes indépendantes sont indispensables.

Vérifier les noms et l'heure sur tous les nœuds

getent hosts gluster01 gluster02 gluster03
chronyc tracking
timedatectl status

Exemple de correspondances de noms d'hôtes

10.20.30.11  gluster01
10.20.30.12  gluster02
10.20.30.13  gluster03

1. Préparer un stockage dédié aux bricks

Les étapes suivantes peuvent effacer les données des périphériques. Vérifiez d'abord le véritable périphérique et ses montages sur chaque serveur, puis sécurisez les sauvegardes et l'autorisation de changement. /dev/sdb est un exemple à remplacer.

lsblk -f
findmnt --real
sudo wipefs --no-act /dev/sdb

sudo mkfs.xfs -f -i size=512 /dev/sdb
sudo mkdir -p /bricks/brick1
sudo blkid /dev/sdb

Utilisez l'UUID fourni par blkid pour ajouter une entrée comme celle-ci dans /etc/fstab sur chaque serveur.

UUID=<각-서버의-실제-UUID> /bricks/brick1 xfs defaults,noatime 0 2

sudo mount -a
findmnt /bricks/brick1
df -hT /bricks/brick1
sudo mkdir -p /bricks/brick1/gv0

2. Vérifier les paquets et le service glusterd

Sous EL9, vérifiez d'abord que le dépôt configuré fournit réellement glusterfs-server. Si le paquet manque ou si sa provenance ou signature est douteuse, arrêtez-vous au lieu de télécharger des RPM anciens arbitraires.

sudo dnf repolist
sudo dnf repoquery --info glusterfs-server
sudo dnf install -y glusterfs-server glusterfs-fuse
rpm -q glusterfs-server glusterfs-fuse
glusterfs --version

sudo systemctl enable --now glusterd
sudo systemctl --no-pager --full status glusterd
sudo journalctl -u glusterd -b --no-pager | tail -n 80

3. Limiter le pare-feu au réseau de stockage

Depuis Gluster 10, les ports des bricks sont choisis aléatoirement dans la plage base-port/max-port. Autorisez 24007–24008 et la véritable plage des bricks uniquement depuis le sous-réseau de stockage. La plage suivante est un exemple : alignez-la sur le nombre de bricks et glusterd avant application pendant une maintenance.

sudo grep -E 'base-port|max-port' /etc/glusterfs/glusterd.vol
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=24007-24008 protocol=tcp accept'
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=49152-49200 protocol=tcp accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-all

Pour un nouveau laboratoire utilisant ces règles, définissez option base-port 49152 et option max-port 49200 dans le bloc volume management existant de /etc/glusterfs/glusterd.vol sur tous les nœuds, puis redémarrez glusterd. Ne dupliquez pas les options. En production, examinez les ports et le nombre de bricks et autorisez d'abord la plage actuelle ; ne la réduisez pas sans procédure de maintenance.

sudoedit /etc/glusterfs/glusterd.vol
sudo systemctl restart glusterd
sudo systemctl status glusterd --no-pager
sudo grep -E "base-port|max-port" /etc/glusterfs/glusterd.vol

4. Créer le pool de stockage de confiance

Depuis gluster01, sondez les deux autres serveurs, puis sondez gluster01 une fois depuis gluster02 pour enregistrer les noms de façon cohérente. Ne créez pas le volume tant que tous les pairs ne sont pas Connected.

# Exécuter sur gluster01
sudo gluster peer probe gluster02
sudo gluster peer probe gluster03
sudo gluster peer status
sudo gluster pool list

# Exécuter sur gluster02
sudo gluster peer probe gluster01
sudo gluster peer status

5. Créer et valider un volume Replica 3

Replica 3 copie les fichiers sur trois bricks. Un volume simplement distribué augmente la capacité sans répliques : la perte d'une brick peut donc perdre ses fichiers. Si l'objectif est la haute disponibilité, examinez attentivement Type et la disposition des bricks dans la sortie de création.

sudo gluster volume create gv0 replica 3 transport tcp \
  gluster01:/bricks/brick1/gv0 \
  gluster02:/bricks/brick1/gv0 \
  gluster03:/bricks/brick1/gv0

sudo gluster volume info gv0
sudo gluster volume start gv0
sudo gluster volume status gv0 detail

Après démarrage, vérifiez que les trois bricks sont Online. L'option force peut contourner des avertissements sur des chemins ou une topologie incorrects ; ne l'utilisez pas sans comprendre leur cause.

6. Monter les clients et vérifier le redémarrage

Installez glusterfs-fuse sur le client. Indiquez les deux autres serveurs dans backup-volfile-servers si le premier serveur volfile est indisponible. Cette option ne remplace pas la réplication des données.

sudo dnf install -y glusterfs-fuse
sudo mkdir -p /mnt/gv0
sudo mount -t glusterfs gluster01:/gv0 /mnt/gv0 \
  -o backup-volfile-servers=gluster02:gluster03
findmnt /mnt/gv0
df -hT /mnt/gv0

Pour le montage automatique après redémarrage, ajoutez l'entrée suivante dans /etc/fstab du client.

gluster01:/gv0 /mnt/gv0 glusterfs defaults,_netdev,backup-volfile-servers=gluster02:gluster03 0 0

sudo umount /mnt/gv0
sudo mount -a
findmnt /mnt/gv0
sudo touch /mnt/gv0/.mount-test
stat /mnt/gv0/.mount-test

7. Tester écritures, réplication et récupération

Avant les données de production, testez les écritures et la réplication avec des fichiers de test distincts. Accéder directement aux chemins des bricks contourne les métadonnées Gluster : les applications doivent toujours passer par le point de montage Gluster.

date -Is | sudo tee /mnt/gv0/healthcheck.txt
sha256sum /mnt/gv0/healthcheck.txt
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary

Effectuez les tests de panne planifiés pendant une maintenance, après vérification des sauvegardes et de la récupération. Ajoutez des fichiers de test lorsqu'un nœud est isolé, puis vérifiez que les entrées heal en attente reviennent à zéro après son retour. Ne forcez pas les écritures après perte de majorité et n'écrivez pas simultanément dans plusieurs partitions réseau.

sudo gluster peer status
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
sudo gluster volume heal gv0 info
sudo gluster volume heal gv0 info split-brain

8. Gérer la réparation et le split-brain en sécurité

Les entrées heal en attente peuvent être réparées automatiquement. Un split-brain signifie que Gluster ne sait pas quelle copie fait autorité. Choisir automatiquement le fichier le plus récent ou le plus gros peut écraser les bonnes données. Arrêtez les écritures, sauvegardez et comparez d'abord les contenus et sommes de contrôle.

sudo gluster volume heal gv0 info split-brain
sudo getfattr -d -m . -e hex /bricks/brick1/gv0/<문제-파일>
sudo stat /bricks/brick1/gv0/<문제-파일>
sudo sha256sum /bricks/brick1/gv0/<문제-파일>

N'utilisez la récupération source-brick sur le fichier concerné qu'après confirmation de la copie faisant autorité par un opérateur et le responsable applicatif. Remplacez les chemins d'hôte, de brick et de fichier par des valeurs vérifiées.

sudo gluster volume heal gv0 split-brain \
  source-brick gluster01:/bricks/brick1/gv0 /<문제-파일>

sudo gluster volume heal gv0 info split-brain
sudo gluster volume heal gv0 info summary

9. Diagnostiquer avec les journaux et l'état du système

Avant de redémarrer des serveurs pour une erreur de montage, collectez au même instant les pairs, volumes, ports des bricks, réparations, capacités, inodes et journaux. Un /var/lib/glusterd plein peut notamment perturber le démon d'administration.

sudo gluster pool list
sudo gluster volume info gv0
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
df -hT /var/lib/glusterd /bricks/brick1
df -i /var/lib/glusterd /bricks/brick1
sudo ss -lntp | grep -E ':(2400[78]|4915[2-9]|491[6-9][0-9]|49200)\b'
sudo journalctl -u glusterd -b --no-pager | tail -n 200

Si la commande heal elle-même échoue, examinez glfsheal et les journaux des bricks concernées. Les chemins et ports dépendent de la version et du paquet ; comparez-les à volume status.

sudo ls -1 /var/log/glusterfs/
sudo tail -n 200 /var/log/glusterfs/glfsheal-gv0.log
sudo find /var/log/glusterfs/bricks -maxdepth 1 -type f -name '*.log' -print

10. Points à vérifier en exploitation

1. Documenter la durée du support de sécurité et le chemin de mise à niveau du fournisseur.
2. Placer les trois serveurs dans des domaines indépendants d'alimentation, de baie et de réseau.
3. Autoriser les ports d'administration et de bricks uniquement depuis les réseaux nécessaires et conserver SELinux.
4. Surveiller en continu pairs, bricks, réparation, split-brain, capacité, inodes et latence.
5. Conserver des sauvegardes indépendantes contre les suppressions et rançongiciels et tester régulièrement la restauration.
6. Répéter le remplacement de nœuds, les mises à niveau et le choix de la copie de référence avant les interventions.

Contrôles minimaux quotidiens ou automatisés

sudo gluster peer status
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary
df -P /bricks/brick1
df -Pi /bricks/brick1

Articles associés

• GlusterFS ou DRBD : réplication, cohérence et choix de la HA
• Diagnostiquer No space left on device sous Linux

Conclusion

Un déploiement GlusterFS sûr commence par définir le comportement en panne. Construisez une topologie Replica 3 avec décisions majoritaires, puis gérez ensemble bricks dédiées, pare-feu restreint, noms cohérents, validation d'état et suivi des réparations. Les sauvegardes indépendantes, tests de restauration et paquets maintenus complètent le service de fichiers exploitable.