GlusterFS a divisé le cerveau sans chemin, qu'est-ce que cela signifie?

Je vérifiais juste le statut de mes volumes glusterfs et j'en ai un avec des entrées split-brain qui n'ont pas de chemin:

# gluster volume heal private_uploads info
Brick server01:/var/lib/glusterfs/brick01/uploads/
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
Number of entries: 2

Brick server02:/var/lib/glusterfs/brick01/uploads/
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
Number of entries: 2

Qu'est-ce que ça veut dire? Comment je le répare?

J'utilise GlusterFS 3.5.9:

# gluster --version
glusterfs 3.5.9 built on Mar 28 2016 07:10:17
Repository revision: git://git.gluster.com/glusterfs.git

Qu'est-ce que le Split-Brain?

Comme mentionné dans la documentation officielle sur la gestion de Split-Brain fournie par RedHat, le split-brain est un état où des incohérences de données ou de disponibilité provenant de la maintenance de deux ensembles de données distincts avec chevauchement de portée, soit en raison de serveurs dans une conception de réseau, ou une condition de défaillance basée sur des serveurs qui ne communiquent pas et ne synchronisent pas leurs données entre eux. Et c'est un terme applicable à la configuration répliquée.

Faites attention à ce qu'il soit dit "une condition de panne basée sur des serveurs qui ne communiquent pas et ne synchronisent pas leurs données entre eux" - en raison de toute probabilité - mais cela ne signifie pas que vos nœuds pourraient perdre la connexion. Le pair peut être encore en cluster et connecté.

Types de cerveau divisé:

Nous avons trois types différents de split-brain, et pour autant que je puisse voir le vôtre, c'est split-brain d'entrée. Pour expliquer trois types de split-brain:

• Données split-brain: Le contenu du fichier sous split-brain est différent dans différentes paires de répliques et la guérison automatique n'est pas possible.

• Métadonnées split-brain :, Les métadonnées des fichiers (exemple, attribut étendu défini par l'utilisateur) sont différentes et la guérison automatique n'est pas possible.

• Entrée split-brain: Cela se produit lorsqu'un fichier a différents gfids sur chacune des paires de répliques.

Qu'est-ce que GFID?

L'identifiant de fichier interne GlusterFS (GFID) est un uuid unique à chaque fichier de l'ensemble du cluster. Ceci est analogue au numéro d'inode dans un système de fichiers normal. Le GFID d'un fichier est stocké dans son xattr nommé trusted.gfid. Pour trouver le chemin depuis GFID, je vous recommande fortement de lire cet article officiel fourni par GlusterFS.

Comment résoudre le split-brain d'entrée?

Il existe plusieurs méthodes pour empêcher le split-brain de se produire, mais pour le résoudre, les fichiers de lien gfid correspondants doivent être supprimés. Les fichiers gfid-link sont présents dans le répertoire .glusterfs du répertoire de niveau supérieur de la brique. Par ailleurs, méfiez-vous qu'avant de supprimer les liens gfid, vous devez vous assurer qu'il n'y a pas de liens durs vers les fichiers présents sur cette brique. S'il existe des liens physiques, vous devez également les supprimer. Ensuite, vous pouvez utiliser le processus d'auto-guérison en exécutant les commandes suivantes.

En attendant, pour afficher la liste des fichiers sur un volume qui sont dans un état de cerveau divisé, vous pouvez utiliser:

# gluster volume heal VOLNAME info split-brain

Vous devez également savoir que pour les volumes répliqués, lorsqu'une brique se déconnecte et revient en ligne, l'auto-réparation est nécessaire pour resynchroniser toutes les répliques.

Pour vérifier l'état de guérison des volumes et des fichiers, vous pouvez utiliser:

# gluster volume heal VOLNAME info

Puisque vous utilisez la version 3.5, vous ne disposez pas de la réparation automatique. Donc, après avoir effectué les étapes mentionnées précédemment, vous devez déclencher l'auto-guérison. Faire cela:

• Uniquement sur les fichiers à soigner:

  # gluster volume heal VOLNAME

• Sur tous les fichiers:

  # gluster volume heal VOLNAME full

J'espère que cela vous aidera à résoudre votre problème. Veuillez lire les documents officiels pour plus d'informations. À votre santé.

Je pense que le document est assez clair, il vous a même donné un exemple similaire.

Et pour les commandes de guérison de Gluesterfs telles que

gluster volume heal ** VOLNAME ** split-brain latest-mtime ** FILE **

FILE peut être soit le nom de fichier complet vu depuis la racine du volume (ou) la représentation de la chaîne gfid du fichier

Vous n'avez donc pas besoin de vous inquiéter à ce sujet.

Et comme le dit GFID en chemin :

L'identifiant de fichier interne GlusterFS (GFID) est un uuid unique à chaque fichier de l'ensemble du cluster.

ce script peut vous dire à quel nom de fichier appartient quel gfid, mais la séparation du cerveau s'est produite, il peut ne pas avoir de nom de fichier.

Vous exécutez la version 3.5 et n'avez pas de cmd de réparation semi-automatique, vous devrez donc peut-être corriger manuellement la confliction, ce qui signifie normalement décider quel fichier gfid doit être supprimé.

Comment je le répare?

La résolution du cerveau divisé peut être trouvée ici . En cas est ne serait pas beaucoup d' aide, le manuel comment faire ici devrait faire le travail. Pour le cas, je vois que l'article est également utile.

Comment éviter Split-brain.

La protection contre les partitions réseau se fait via un algorithme de vote de quorum. En cas de défaillance d'un hôte ou de scénario de cerveau divisé dans lequel les nœuds continuent de fonctionner mais ne peuvent plus communiquer entre eux, le ou les nœuds restants de la grappe font la course pour placer une réservation SCSI sur le lecteur témoin. Dans le cas d'un cerveau divisé, le témoin aidera à décider lequel des hôtes qui détient une copie des données devrait prendre le contrôle.

Quelques exemples.

VMware VSAN permet d'exécuter un cluster à 2 nœuds avec le lecteur témoin exécuté sur un troisième hôte ou dans le cloud. La source

StarWind Virtual SAN s'exécute dans une configuration à seulement 2 nœuds à l'aide du service Microsoft Failover Cluster, qui contient également un mécanisme de vote de quorum pour éviter le problème de split-brain. La source

Pour les deux, le réseau Heartbeat est utilisé pour servir / surveiller la communication entre les nœuds et le quorum. Afin d'éviter un split-brain, je vois qu'il est obligatoire d'aller avec des canaux Heartbeat redondants.

split-brain se produit lorsque deux nœuds d'un cluster sont déconnectés. Chaque nœud pense que l'autre ne fonctionne pas.

Pour y remédier, vous devez comprendre pourquoi vos deux nœuds ne se parlent plus.