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 :
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
https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/