Glusterfs-server Que se passe-t-il en cas de split brain (conflit de fichiers)
Attention : cet article est un retour d'expérience.
Introduction
Un split brain est une expression indiquant des conflits sur un ou plusieurs fichiers. Ces conflits résultent de modifications sur un même fichier répartis sur plusieurs machines. Les split brain arrivent généralement lorsqu'on utilise deux machines (replica 2) ou que la grappe est réparties de façon homogène sur deux réseaux perturbés par une coupure. Avec glusterfs-server, à part en replica 3 ou en replica 3 arbiter 1 pour ceux chez qui il fonctionne, vous tomberez tôt ou tard sur un split brain.
Réparation
NB : Lors de mon essai, après avoir fixé le split brain sur un replica 2, glusterfs-server a commencé à planter plein tube (l'autre machine la voit connecté, mais elle est incapable d'accomplir un “gluster peer status” sans renvoyer “peer status: failed” et ce jusqu'à avoir ré-installé glusterfs-server sur la dite machine et surtout reforgé complètement les clés TLS). Le lendemain le volume a split brain à nouveau et les commandes indiquées ci-bas n'ont menées à RIEN. Si vous le pouvez, n'utilisez pas glusterfs-server.
- Lancez la fonction heal sur votre volume. (qui sert à ???)
gluster volume heal nomVolume
- Lancez la commande ls -R pour afficher les fichiers éventuellement “cassé”.
ls -R /media/partitionGluster/
- Démontez votre volume.
umount /media/partitionGluster/
- Affichez les éléments.
getfattr -d -m . -e hex /media/chemin/nomVolume
- Forcez la valeur d'un attribut.
setfattr -n nom_attribut -v valeur_de_lattribut /media/chemin/nomVolume
- Re-montez votre volume.
mount /media/partitionGluster/
- Affichez son contenu pour déclencher automatiquement la fonction heal de glusterfs. (à vérifier ;) )
ls -l /media/partitionGluster/
Retour d'expérience et anecdotes
Pour une raison obscure, la réparation a provoqué l'expiration des clés TLS, j'ai donc dû les reforger.
J'ai aussi du retirer de la grappe une machine accessible en WAN car, bien que cette dernière ne fasse pas partie du raid, la fonction heal ne fonctionnait pas a cause d'un commit qui ne se transmettait pas.
Nextcloud ne fonctionnait plus du tout sauf sur un nom de domaine où, pour une raison obscure, on pouvait encore se connecter à la WEBUI sauf si on avait tenté de se connecter depuis les autres hostname (dans quel cas il fallait supprimer ses cookies avant de ré-essayer). Les montages davfs2 et les clients de synchronisation continuait de fonctionner et ce malgré que les comptes ne pouvaient plus se connecter à la WEBUI.
Nextcloud a enchaîné plein de bug assez surprenant ainsi que des lags bien relou.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.