GlusterFS

Présentation

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :

• volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :

• volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :

• volume distribué répliqué :

Mise en place

Gluster stocke ses fichiers de conf dynamiquement dans /var/lib/glusterd. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

Installation des packages

Exemple sur Debian10 :

# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :

# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

Ouverture des flux

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :

# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[1]]).

Trusted pool

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :

brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :

# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :

# gluster pool list
UUID						Hostname     State
2b5f991b-8a43-43fc-836b-f6292157489a	brick2		Connected 
9189775d-c84f-48a8-93bc-85e3a10af75d	localhost    Connected

Si on veut supprimer une brique du pool :

# gluster peer detach brick2

Création d'un volume répliqué

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS. Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1. Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :

# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See: 
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
 (y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume. Pour voir :

# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré. Pour le démarrer et vérifier :

# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process				TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1	49152     0          Y       1737 
Brick brick2:/gluster/volumes/volume1	49152     0          Y       1925 
Self-heal Daemon on localhost		N/A       N/A        Y       1948 
Self-heal Daemon on brick1		N/A       N/A        Y       1760 

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

Montage depuis un client

Installer le package "glusterfs-client". Monter en précisant une des briques et en indiquant le point de montage :

# mount -t glusterfs brick1:/volume1 /mnt

Ou depuis /etc/fstab :

brick1:/volume1 /mnt glusterfs defaults 0 0

A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant. Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

Paramétrage du volume

Timeout

Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.

# gluster volume set volume1 network.ping-timeout 5

Limiter les accès

Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :

# gluster volume set volume1 auth.allow 10.34.210.*

On peut mettre plusieurs ips ou réseaux en les séparant par des virgules. Pour revenir au comportement par défaut, il faut autoriser "*". A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre auth.reject. Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

Quotas

On peut activer des quotas pour le volume au niveau des sous-répertoires. Il faut d'abord activer les quotas :

# gluster volume quota volume1 enable

Puis on défini la valeur :

# gluster volume quota volume1 limit-usage /sous-repertoire 100M

Pour voir l'état des quotas :

# gluster volume quota volume1 list

Corbeille

On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.

# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760

On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :

# gluster volume set volume1 features.trash-internal-op on

Administration courante

Retirer une brique

Si on veut retirer une brique.

# gluster peer detach ma_brique

Remplacement d'une brique (si panne par exemple)

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :

# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :

# gluster volume replace-brick volume1  brick1:/Gluster/Volumes/Volume1  brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :

# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :

root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :

root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien  .glusterfs/                 
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :

root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :

# gluster peer detach brick1

Étendre un volume

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :

# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :

brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :

brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :

# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :

# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :

# gluster volume rebalance volume1 status

Ajouter un replica

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.

# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :

# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

Infos détaillées et perfs

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
 %-latency   Avg-latency   Min-Latency   Max-Latency   No. of calls         Fop
 ---------   -----------   -----------   -----------   ------------        ----
      0.00       0.00 us       0.00 us       0.00 us              3  RELEASEDIR
 
    Duration: 251 seconds
   Data Read: 0 bytes
Data Written: 0 bytes
 
Interval 1 Stats:
 
    Duration: 32 seconds
   Data Read: 0 bytes
Data Written: 0 bytes
 
Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
 %-latency   Avg-latency   Min-Latency   Max-Latency   No. of calls         Fop
 ---------   -----------   -----------   -----------   ------------        ----
      0.00       0.00 us       0.00 us       0.00 us              3  RELEASEDIR
 
    Duration: 252 seconds
   Data Read: 0 bytes
Data Written: 0 bytes
 
Interval 1 Stats:
 
    Duration: 32 seconds
   Data Read: 0 bytes
Data Written: 0 bytes

Comparaison avec Ceph

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/