GlusterFS : déployer un stockage distribué résilient

GlusterFS transforme plusieurs serveurs Linux en un espace de stockage unifié, répliqué et évolutif. Sans serveur de métadonnées central, chaque nœud est autonome : si l’un tombe, les autres continuent de servir les données. Ce guide vous accompagne de l’installation à la mise en production d’un cluster 3 nœuds avec volume répliqué, commandes testées sur Ubuntu 24.04.

Ce que vous allez apprendre

• Architecture GlusterFS : bricks, volumes, peers et hashing distribué
• Types de volumes : distribué, répliqué, dispersé et leurs combinaisons
• Lab complet : déployer un cluster 3 nœuds avec KVM et cloud-init
• Commandes essentielles : créer, gérer, surveiller et dépanner vos volumes
• Sécurité et bonnes pratiques : TLS, pare-feu, quotas, tuning performance

Version actuelle

Ce guide utilise GlusterFS 11.1 (Ubuntu 24.04 Noble). La version 11.2 est sortie en juillet 2025. Nouveautés introduites dans les release notes 11.0 : amélioration de ~36 % des performances rmdir, support ZFS étendu pour les snapshots, quotas basés sur les namespaces. Les versions 11.1 et 11.2 sont des releases de stabilisation et correctifs.

Qu’est-ce que GlusterFS ?

GlusterFS (Gluster File System) est un système de fichiers distribué open source créé en 2005, racheté par Red Hat en 2011. Il agrège le stockage de plusieurs serveurs pour former un espace unifié accessible en réseau.

Analogie : imaginez une bibliothèque répartie dans plusieurs bâtiments. Chaque bâtiment stocke des livres (les bricks), et un catalogue commun permet de retrouver n’importe quel livre depuis n’importe quel bâtiment. Avec la réplication, chaque livre existe en plusieurs exemplaires dans des bâtiments différents : si un bâtiment ferme, les livres restent accessibles ailleurs.

Caractéristiques principales

Caractéristique	Description
Sans métadonnées centralisées	Les métadonnées sont réparties : chaque brick et le DHT participent à la localisation des fichiers. Pas de point de défaillance unique (contrairement à HDFS).
Scalabilité horizontale	Ajout de nœuds à chaud, jusqu’à plusieurs pétaoctets
Réplication automatique	Copies synchrones sur N nœuds configurables
Auto-réparation	Le Self-Heal Daemon restaure les fichiers après panne
Multi-protocole	FUSE natif, NFS-Ganesha, SMB/CIFS, libgfapi
Open source	Licence GPLv2 / LGPLv3+, communauté active

Glissez pour voir

GlusterFS vs alternatives

Critère	GlusterFS	Ceph	NFS classique
Complexité	Modérée	Élevée	Faible
Type de stockage	Fichier (bloc via iSCSI)	Objet + Bloc + Fichier	Fichier
Métadonnées	Distribuées (pas de serveur central)	Centralisées (MDS)	Centralisées
Cas d’usage idéal	Stockage partagé, clusters web	Cloud privé complet	Partages simples
Scalabilité	Pétaoctets	Exaoctets	Limité
Facilité d’installation	Bonne	Complexe	Très simple

Glissez pour voir

Quand choisir GlusterFS

Choisissez GlusterFS si vous avez besoin d’un stockage partagé résilient entre plusieurs serveurs, sans la complexité de Ceph. C’est idéal pour les clusters web, le partage de fichiers en équipe et le stockage partagé applicatif.

Pour Kubernetes, privilégiez une intégration via CSI : le provisioner historique Heketi est archivé (juillet 2023) et le plugin GlusterFS in-tree a été retiré de Kubernetes en v1.26.

Architecture et concepts clés

Les composants fondamentaux

Un cluster GlusterFS repose sur des concepts simples mais puissants :

• Brick : un répertoire sur un disque d’un serveur. C’est l’unité de base du stockage. Chaque brick correspond à un chemin sur un filesystem (XFS recommandé).

• Volume : la structure logique qui combine plusieurs bricks. C’est le volume que les clients montent pour accéder aux données. Un volume peut être distribué, répliqué, dispersé ou une combinaison.

• Peer (ou nœud) : un serveur membre du Trusted Storage Pool. Les peers communiquent entre eux via le daemon glusterd (port TCP 24007).

• Trusted Storage Pool : l’ensemble des peers qui se font confiance et partagent leurs bricks pour former des volumes.

• glusterd : le daemon de gestion qui tourne sur chaque nœud. Il gère la configuration du cluster, l’ajout de peers et la création de volumes.

• Self-Heal Daemon (shd) : processus automatique qui détecte et répare les incohérences entre les réplicas après une panne ou une coupure réseau.

• Translator : module enfichable dans la pile GlusterFS. Les translators gèrent la distribution (DHT), la réplication (AFR), le cache, les quotas, etc.

Hashing distribué (DHT)

GlusterFS utilise un algorithme de hashing cohérent (Distributed Hash Table) pour déterminer sur quelle brick stocker chaque fichier. Le nom du fichier est hashé, et le résultat détermine la brick cible. Cette approche élimine le besoin d’un serveur de métadonnées central.

Types de volumes

GlusterFS propose plusieurs types de volumes, chacun adapté à un besoin différent en termes de performance, redondance et efficacité d’espace.

Volume distribué

Les fichiers sont répartis entre les bricks selon le hashing DHT. Chaque fichier n’existe que sur une seule brick.

• Avantage : capacité maximale (somme de toutes les bricks)
• Inconvénient : aucune redondance, perte d’une brick = perte de données
• Cas d’usage : stockage temporaire, cache, données non critiques

Volume répliqué

Chaque fichier est copié intégralement sur N bricks (replica 2 ou 3). Toutes les bricks contiennent les mêmes données.

• Avantage : haute disponibilité, tolérance aux pannes
• Inconvénient : capacité = taille d’une seule brick (les autres sont des copies)
• Cas d’usage : bases de données, fichiers critiques, configurations

Volume distribué-répliqué

Combine distribution et réplication. Les fichiers sont distribués entre des groupes de bricks, et chaque groupe réplique ses données.

• Avantage : scalabilité + redondance
• Cas d’usage : clusters de production, stockage web à grande échelle

Volume dispersé (Erasure Coding)

Utilise le codage d’effacement pour répartir les données et la parité entre les bricks. Plus efficace en espace qu’un volume répliqué.

• Avantage : tolérance aux pannes avec moins d’espace perdu
• Inconvénient : latence plus élevée (reconstruction à la lecture)
• Cas d’usage : archivage, stockage froid, gros volumes

Tableau comparatif

Type	Redondance	Capacité utile	Performance	Cas d’usage
Distribué	Non	100%	Haute	Stockage temporaire
Répliqué (replica 3)	Oui	33%	Bonne (lecture)	Données critiques
Distribué-répliqué	Oui	50% (replica 2)	Bonne	Production
Dispersé	Oui	~66% (4+2)	Moyenne	Archivage

Glissez pour voir

Lab : déployer un cluster GlusterFS 3 nœuds

Ce lab utilise 3 machines virtuelles KVM sous Ubuntu 24.04 pour créer un cluster GlusterFS complet avec volume répliqué.

Prérequis

• Hyperviseur KVM avec virsh et virt-install installés
• 3 VMs (1 Go RAM, 1 vCPU chacune suffisent pour le lab)
• 1 disque supplémentaire par VM pour les bricks (5 Go minimum)
• Réseau : les VMs doivent communiquer entre elles (réseau libvirt default)

Disque dédié obligatoire

GlusterFS recommande fortement d’utiliser un disque ou une partition dédiée formatée en XFS pour les bricks. Ne stockez jamais les bricks sur la partition système /.

Créer les VMs avec cloud-init

1. Télécharger l’image cloud Ubuntu 24.04

   wget -q https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img \
     -O /var/lib/libvirt/images/ubuntu-noble.img

2. Préparer le fichier cloud-init

   Ce fichier installe GlusterFS, configure l’utilisateur et prépare le disque brick automatiquement :

   cloud-init-gluster.yaml

   #cloud-config
   hostname: gluster1
   users:
     - name: bob
       sudo: ALL=(ALL) NOPASSWD:ALL
       groups: sudo
       shell: /bin/bash
       lock_passwd: false
       plain_text_passwd: gluster
       ssh_authorized_keys:
         - ssh-ed25519 AAAA... votre-clé-publique
   packages:
     - glusterfs-server
     - glusterfs-client
     - xfsprogs
   runcmd:
     - systemctl enable glusterd
     - systemctl start glusterd
     - |
       if [ -b /dev/vdb ]; then
         mkfs.xfs -f /dev/vdb
         mkdir -p /data/brick1
         echo '/dev/vdb /data/brick1 xfs defaults 0 0' >> /etc/fstab
         mount -a
       fi

   Dupliquez ce fichier pour les 3 nœuds en changeant le hostname (gluster1, gluster2, gluster3).

   Vérifiez le device du disque brick

   Le script cloud-init formate /dev/vdb par défaut. Selon l’hyperviseur ou l’ordre des disques, le device peut être /dev/vdc ou /dev/sdb. Vérifiez avec lsblk -o NAME,SIZE,TYPE avant de l’appliquer en production.

3. Créer les VMs

   Pour chaque nœud, créez le disque système (backing file) et le disque brick :

   # Disque système (image de base partagée)
   qemu-img create -F qcow2 -b /var/lib/libvirt/images/ubuntu-noble.img \
     -f qcow2 /var/lib/libvirt/images/gluster1.qcow2 10G
   
   # Disque brick (5 Go)
   qemu-img create -f qcow2 /var/lib/libvirt/images/gluster1-brick.qcow2 5G
   
   # Créer la VM
   virt-install \
     --name gluster1 \
     --memory 1024 \
     --vcpus 1 \
     --disk path=/var/lib/libvirt/images/gluster1.qcow2,format=qcow2 \
     --disk path=/var/lib/libvirt/images/gluster1-brick.qcow2,format=qcow2 \
     --os-variant ubuntu24.04 \
     --network network=default \
     --cloud-init user-data=cloud-init-gluster1.yaml \
     --noautoconsole

   Répétez pour gluster2 et gluster3.

4. Vérifier que les VMs sont prêtes

   Attendez environ 2 minutes que cloud-init termine, puis vérifiez :

   virsh net-dhcp-leases default

   Expiry Time           MAC address         Protocol   IP address         Hostname
   2026-02-28 11:55:00   52:54:00:aa:bb:01   ipv4       192.168.122.55/24  gluster1
   2026-02-28 11:55:00   52:54:00:aa:bb:02   ipv4       192.168.122.56/24  gluster2
   2026-02-28 11:55:00   52:54:00:aa:bb:03   ipv4       192.168.122.57/24  gluster3

Installer et vérifier GlusterFS

Ubuntu / Debian

GlusterFS est disponible dans les dépôts officiels d’Ubuntu 24.04 :

sudo apt update && sudo apt install -y glusterfs-server glusterfs-client xfsprogs
sudo systemctl enable glusterd && sudo systemctl start glusterd

Rocky / RHEL

Sur Rocky Linux 9 ou RHEL 9, activez le dépôt CentOS Storage SIG :

sudo dnf install -y centos-release-gluster11
sudo dnf install -y glusterfs-server glusterfs-client
sudo systemctl enable glusterd && sudo systemctl start glusterd

Vérification sur chaque nœud :

gluster --version

glusterfs 11.1
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>

systemctl is-active glusterd

active

df -h /data/brick1

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb        5.0G  130M  4.9G   3% /data/brick1

Configurer la résolution de noms

Ajoutez les entrées dans /etc/hosts sur chaque nœud :

/etc/hosts

192.168.122.55  gluster1
192.168.122.56  gluster2
192.168.122.57  gluster3

Alternative DNS

En production, utilisez un DNS interne plutôt que /etc/hosts. GlusterFS utilise les noms d’hôtes dans sa configuration : un changement d’IP ne nécessite alors qu’une mise à jour DNS.

Former le Trusted Storage Pool

Depuis gluster1, ajoutez les deux autres nœuds au pool :

sudo gluster peer probe gluster2

peer probe: success

sudo gluster peer probe gluster3

peer probe: success

Vérification :

sudo gluster peer status

Number of Peers: 2

Hostname: gluster2
Uuid: 83e0c959-c44d-41b4-ad0b-2a892dfdf309
State: Peer in Cluster (Connected)

Hostname: gluster3
Uuid: 480316c9-0d00-4e12-a2b7-99617c1acb39
State: Peer in Cluster (Connected)

sudo gluster pool list

UUID                                    Hostname        State
83e0c959-c44d-41b4-ad0b-2a892dfdf309    gluster2        Connected
480316c9-0d00-4e12-a2b7-99617c1acb39    gluster3        Connected
29a4daae-6855-4581-b965-c6310ced7a72    localhost       Connected

Créer un volume répliqué

1. Créer les répertoires de brick sur chaque nœud

   sudo mkdir -p /data/brick1/vol-replica

   Exécutez cette commande sur gluster1, gluster2 et gluster3.

2. Créer le volume (depuis n’importe quel nœud du pool)

   sudo gluster volume create vol-replica replica 3 transport tcp \
     gluster1:/data/brick1/vol-replica \
     gluster2:/data/brick1/vol-replica \
     gluster3:/data/brick1/vol-replica

   volume create: vol-replica: success: please start the volume to access data

3. Démarrer le volume

   sudo gluster volume start vol-replica

   volume start: vol-replica: success

4. Vérifier la configuration

   sudo gluster volume info vol-replica

   Volume Name: vol-replica
   Type: Replicate
   Volume ID: da01e8ee-341f-42ca-b8d7-95107aebfa1f
   Status: Started
   Snapshot Count: 0
   Number of Bricks: 1 x 3 = 3
   Transport-type: tcp
   Bricks:
   Brick1: gluster1:/data/brick1/vol-replica
   Brick2: gluster2:/data/brick1/vol-replica
   Brick3: gluster3:/data/brick1/vol-replica
   Options Reconfigured:
   cluster.granular-entry-heal: on
   storage.fips-mode-rchecksum: on
   transport.address-family: inet
   nfs.disable: on
   performance.client-io-threads: off

Monter le volume sur un client

Installez le client GlusterFS et montez le volume :

sudo apt install -y glusterfs-client
sudo mkdir -p /mnt/gluster-replica
sudo mount -t glusterfs gluster1:/vol-replica /mnt/gluster-replica

Montège tolérant aux pannes

Ajoutez des serveurs de secours pour éviter qu’un nœud indisponible empêche le montage :

sudo mount -t glusterfs \
  -o backupvolfile-server=gluster2:gluster3 \
  gluster1:/vol-replica /mnt/gluster-replica

Le client contacte automatiquement gluster2 ou gluster3 si gluster1 ne répond pas.

Vérification :

df -h /mnt/gluster-replica

Filesystem             Size  Used Avail Use% Mounted on
gluster1:/vol-replica  5.0G  180M  4.8G   4% /mnt/gluster-replica

Tester la réplication

Écrivez un fichier depuis le client :

echo "Bonjour GlusterFS depuis le lab !" | sudo tee /mnt/gluster-replica/test.txt

Puis vérifiez que le fichier est répliqué sur chaque brick :

# Sur gluster1
cat /data/brick1/vol-replica/test.txt
# Sur gluster2
cat /data/brick1/vol-replica/test.txt
# Sur gluster3
cat /data/brick1/vol-replica/test.txt

Les 3 nœuds affichent le même contenu :

Bonjour GlusterFS depuis le lab !

Montage automatique (fstab)

Pour monter le volume au démarrage, ajoutez cette ligne dans /etc/fstab du client :

/etc/fstab

gluster1:/vol-replica  /mnt/gluster-replica  glusterfs  defaults,_netdev  0  0

Option _netdev

L’option _netdev est indispensable : elle indique à systemd d’attendre que le réseau soit disponible avant de tenter le montage. Sans elle, le démarrage peut échouer si le réseau n’est pas encore prêt.

Commandes essentielles

Gestion du cluster

Commande	Description
gluster peer probe <host>	Ajouter un nœud au pool
gluster peer detach <host>	Retirer un nœud du pool
gluster peer status	État des connexions entre pairs
gluster pool list	Liste des nœuds avec UUID et état

Glissez pour voir

Gestion des volumes

Commande	Description
gluster volume create <nom> ...	Créer un volume
gluster volume start <nom>	Démarrer un volume
gluster volume stop <nom>	Arrêter un volume
gluster volume delete <nom>	Supprimer un volume (doit être arrêté)
gluster volume info [nom]	Informations détaillées
gluster volume status [nom]	État des processus (bricks, shd)
gluster volume list	Liste des volumes

Glissez pour voir

Surveillance et diagnostic

sudo gluster volume status vol-replica

Status of volume: vol-replica
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick gluster1:/data/brick1/vol-replica     58311     0          Y       2972
Brick gluster2:/data/brick1/vol-replica     54911     0          Y       2724
Brick gluster3:/data/brick1/vol-replica     54155     0          Y       2727
Self-heal Daemon on localhost               N/A       N/A        Y       2989
Self-heal Daemon on gluster3                N/A       N/A        Y       2744
Self-heal Daemon on gluster2                N/A       N/A        Y       2741

Task Status of Volume vol-replica
------------------------------------------------------------------------------
There are no active volume tasks

Vérifier l’état du heal

Pour un volume répliqué, le Self-Heal répare automatiquement les incohérences. Vérifiez son état :

sudo gluster volume heal vol-replica info

Brick gluster1:/data/brick1/vol-replica
Status: Connected
Number of entries: 0

Brick gluster2:/data/brick1/vol-replica
Status: Connected
Number of entries: 0

Brick gluster3:/data/brick1/vol-replica
Status: Connected
Number of entries: 0

Number of entries: 0 signifie qu’il n’y a aucun fichier à réparer. Si ce nombre est élevé après un redémarrage de nœud, le heal est en cours.

Optimisation et quotas

Tuning des performances

GlusterFS expose des dizaines d’options de performance accessibles via gluster volume set :

# Augmenter le cache de lecture (défaut : 32 Mo)
sudo gluster volume set vol-replica performance.cache-size 256MB

# Augmenter les threads d'E/S (défaut : 16)
sudo gluster volume set vol-replica performance.io-thread-count 32

# Agrandir la fenêtre d'écriture différée (défaut : 1 Mo)
sudo gluster volume set vol-replica performance.write-behind-window-size 1MB

Vérifier les options appliquées :

sudo gluster volume get vol-replica performance.cache-size

Activer les quotas

Les quotas permettent de limiter l’espace utilisé par répertoire :

# Activer les quotas sur le volume
sudo gluster volume quota vol-replica enable

# Limiter le répertoire racine à 2 Go
sudo gluster volume quota vol-replica limit-usage / 2GB

# Vérifier les quotas
sudo gluster volume quota vol-replica list

                  Path                   Hard-limit  Soft-limit      Used  Available  Soft-limit exceeded? Hard-limit exceeded?
-------------------------------------------------------------------------------------------------------------------------------
/                                          2.0GB     80%(1.6GB) 512Bytes   2.0GB              No                   No

Profiling (diagnostic de performance)

Pour identifier les goulots d’étranglement, activez le profiling :

sudo gluster volume profile vol-replica start
sudo gluster volume profile vol-replica info

Brick: gluster1:/data/brick1/vol-replica
----------------------------------------
Cumulative Stats:
   Block Size:                 32b+
 No. of Reads:                    1
No. of Writes:                    1
 %-latency   Avg-latency   Min-Latency   Max-Latency   No. of calls         Fop
 ---------   -----------   -----------   -----------   ------------        ----
      0.00       0.00 ns       0.00 ns       0.00 ns              2     RELEASE
      0.00       0.00 ns       0.00 ns       0.00 ns             14  RELEASEDIR

    Duration: 122 seconds
   Data Read: 34 bytes
Data Written: 34 bytes

Arrêtez le profiling une fois le diagnostic terminé :

sudo gluster volume profile vol-replica stop

Sécurité

Ports à ouvrir dans le pare-feu

GlusterFS utilise plusieurs ports TCP qu’il faut autoriser entre les nœuds :

Port	Service	Direction
24007	glusterd (management)	Tous les nœuds
24008	glusterd (handshake)	Tous les nœuds
49152-49251	Bricks (un port par brick)	Tous les nœuds

Glissez pour voir

Ouvrez autant de ports que de bricks hébergées sur le nœud, à partir de 49152. Par exemple, 5 bricks sur un même serveur nécessitent les ports 49152–49156.

# Exemple avec ufw
sudo ufw allow from 192.168.122.0/24 to any port 24007:24008 proto tcp
sudo ufw allow from 192.168.122.0/24 to any port 49152:49251 proto tcp

Réseau dédié en production

Ne jamais exposer les ports GlusterFS sur Internet. Utilisez un réseau dédié au stockage (VLAN ou interface réseau séparée) pour isoler le trafic GlusterFS du trafic applicatif.

Chiffrement TLS

GlusterFS supporte le chiffrement TLS pour sécuriser les communications entre les nœuds et les clients :

1. Générer les certificats sur chaque nœud

   openssl req -new -x509 -days 365 -nodes \
     -out /etc/ssl/glusterfs.pem \
     -keyout /etc/ssl/glusterfs.key \
     -subj "/CN=$(hostname)"

2. Copier le certificat CA (ou utiliser des certificats signés par la même CA) sur tous les nœuds dans /etc/ssl/glusterfs.ca

3. Activer TLS sur chaque nœud

   # Créer le fichier qui active TLS pour le management
   sudo touch /var/lib/glusterd/secure-access
   
   # Redémarrer glusterd
   sudo systemctl restart glusterd

4. Activer TLS sur le volume

   sudo gluster volume set vol-replica client.ssl on
   sudo gluster volume set vol-replica server.ssl on

Restriction d’accès aux volumes

Limitez les machines autorisées à monter un volume :

sudo gluster volume set vol-replica auth.allow 192.168.122.*

Dépannage

Problèmes courants

Symptôme	Cause probable	Solution
peer probe: failed	Pare-feu bloque le port 24007	Ouvrir les ports 24007-24008
Transport endpoint is not connected	Volume non démarré ou brick hors ligne	gluster volume start <vol> et vérifier volume status
Split-brain detected	Écriture simultanée après partition réseau	Résoudre avec gluster volume heal <vol> split-brain
Brick already in use	Le répertoire brick est déjà utilisé par un autre volume	Utiliser un sous-répertoire différent
Heal pending entries > 0	Fichiers en cours de réparation après panne	Attendre la fin du heal, surveiller avec heal info
No space left on device	Brick pleine	Ajouter des bricks ou activer les quotas en amont
Connection refused lors du montage	glusterd non démarré sur le serveur cible	systemctl start glusterd sur le serveur

Glissez pour voir

Commandes de diagnostic

# État complet du cluster
sudo gluster peer status
sudo gluster volume status all

# Vérifier les fichiers à réparer
sudo gluster volume heal vol-replica info

# Forcer la réparation manuelle
sudo gluster volume heal vol-replica full

# Logs GlusterFS
sudo tail -50 /var/log/glusterfs/glusterd.log
sudo tail -50 /var/log/glusterfs/bricks/*.log

Résoudre un split-brain

Un split-brain survient quand deux réplicas divergent après une partition réseau. Pour le résoudre :

# Identifier les fichiers en split-brain
sudo gluster volume heal vol-replica info split-brain

# Choisir la source de vérité (la brick la plus récente)
sudo gluster volume heal vol-replica split-brain source-brick \
  gluster1:/data/brick1/vol-replica /chemin/fichier

Bonnes pratiques

Stockage

• Utilisez XFS pour les partitions brick (meilleure performance avec GlusterFS grâce au support des attributs étendus)
• Disque dédié par brick, jamais la partition système
• Taille homogène des bricks dans un même volume pour éviter les déséquilibres de distribution

Réseau

• Réseau dédié (10 GbE minimum en production) pour le trafic GlusterFS
• Jumbo frames (MTU 9000) pour réduire l’overhead réseau sur les liaisons rapides
• Pas de NAT entre les nœuds : GlusterFS nécessite une connectivité directe

Exploitation

• Activez le quorum serveur sur les volumes répliqués pour prévenir le split-brain : en cas de partition réseau, mieux vaut refuser les écritures que créer des divergences.

  gluster volume set vol-replica cluster.server-quorum-type server
  gluster volume set all cluster.server-quorum-ratio 51%

• Surveillez le heal régulièrement avec gluster volume heal <vol> info

• Activez les quotas pour prévenir le remplissage non contrôlé

• Sauvegardez indépendamment de la réplication (la réplication n’est pas un backup)

• Testez les pannes : arrêtez un nœud en lab pour valider que l’accès aux données continue

À retenir

• GlusterFS agrège le stockage de plusieurs serveurs Linux en un espace unifié, sans serveur de métadonnées central
• Le Trusted Storage Pool se forme avec gluster peer probe : un nœud peut rejoindre ou quitter le pool à chaud
• Les volumes répliqués (replica 3) offrent la meilleure résilience pour les données critiques
• Les bricks doivent être sur des disques dédiés formatés en XFS
• Le Self-Heal Daemon répare automatiquement les réplicas après une panne
• En production, isolez le trafic GlusterFS sur un réseau dédié et activez TLS
• La réplication n’est pas un backup : sauvegardez vos données indépendamment

Prochaines étapes

NFS : partage de fichiers réseau Comprendre et configurer NFS pour le partage de fichiers entre serveurs Linux

MinIO : stockage objet S3-compatible Déployer un stockage objet compatible S3 en self-hosted

Stockage Kubernetes Persistent Volumes, StorageClass et provisioners pour Kubernetes

Créer des VMs avec KVM Créer et gérer des machines virtuelles avec virt-install et virsh

Ressources

• Site officiel : gluster.org
• Documentation : docs.gluster.org
• GitHub : gluster/glusterfs
• Release notes v11 : docs.gluster.org/release-notes/11.0

×

📖 Voir la documentation →