Dépannage des scénarios courants de split-brain dans un cluster Elasticsearch

Le split-brain est la défaillance d'Elasticsearch dont on parle parce que ça semble dramatique, mais la question utile est plus pratique : est-ce que plus d'une partie du cluster peut prendre des décisions de niveau maître en même temps ? Les versions modernes d'Elasticsearch sont conçues pour empêcher cela grâce à une coordination de cluster basée sur la majorité. Les clusters plus anciens, en particulier ceux d'avant la version 7.0 avec un mauvais paramètre discovery.zen.minimum_master_nodes, étaient plus faciles à mal configurer.

Cet article sépare donc deux situations souvent mélangées. Un vrai split-brain signifie que des partitions indépendantes peuvent chacune élire ou conserver un maître. Une panne d'élection du maître signifie que le cluster ne peut pas élire de maître car il n'a pas de majorité. Le premier risque un état de cluster conflictuel et une incohérence des données. Le second est douloureux, mais c'est généralement le mode de défaillance le plus sûr.

À quoi ressemble un split-brain

Dans un cluster sain, un maître élu gère l'état du cluster : création d'index, décisions d'allocation de shards, mappings, appartenance des nœuds et métadonnées similaires. Les nœuds de données peuvent gérer les lectures et écritures, mais le cluster dépend toujours d'une vue unique du maître sur le monde.

Un scénario de split-brain se produit lorsque des partitions réseau ou de mauvais paramètres de découverte permettent à deux groupes de nœuds de se comporter comme si chaque groupe était le vrai cluster. Un côté peut accepter des écritures sur un index tandis que l'autre côté accepte des écritures différentes. Lorsque la connectivité revient, Elasticsearch ne peut pas simplement fusionner deux historiques conflictuels comme un fichier texte.

Dans Elasticsearch moderne, si une partition n'a pas la majorité des nœuds éligibles au rôle de maître, elle ne devrait pas élire de maître. Cela signifie que certains nœuds peuvent devenir indisponibles au lieu de former un cluster concurrent. C'est le comportement que vous souhaitez.

La version compte

Pour Elasticsearch 6.x et versions antérieures, le paramètre clé était :

discovery.zen.minimum_master_nodes: 2

La règle était la majorité des nœuds éligibles au rôle de maître : (N / 2) + 1, arrondi à l'inférieur pour la division entière avant d'ajouter un. Avec trois nœuds éligibles au rôle de maître, réglez-le sur 2. Avec cinq, réglez-le sur 3. Le régler sur 1 dans un cluster de trois nœuds rendait le split-brain possible.

Pour Elasticsearch 7.x et versions ultérieures, discovery.zen.minimum_master_nodes a disparu. La coordination du cluster a changé et Elasticsearch gère la configuration de vote. Les nouveaux clusters ont toujours besoin d'un amorçage correct avec cluster.initial_master_nodes, mais ce paramètre est uniquement pour la première formation du cluster. Une fois le cluster formé, supprimez-le de la configuration.

N'essayez pas de "réparer" un cluster moderne en ajoutant d'anciens paramètres discovery.zen. Ils ne font plus partie du plan de contrôle.

Causes courantes

Le déclencheur le plus courant est une partition réseau entre les nœuds éligibles au rôle de maître. Dans le cloud, cela peut être un changement de groupe de sécurité, une mauvaise table de routage, une ACL réseau, un problème au niveau de la zone, ou une règle de pare-feu qui bloque le port de transport 9300. Dans les environnements sur site, cela peut être un problème de commutateur, VLAN, DNS, MTU ou de perte de paquets.

Une autre cause est d'exécuter trop peu de nœuds éligibles au rôle de maître. Deux nœuds éligibles au rôle de maître sont problématiques car il n'y a pas de majorité claire après la défaillance de l'un d'eux. Un cluster de production utilise normalement trois nœuds dédiés éligibles au rôle de maître, ou trois nœuds à rôles mixtes dans un petit déploiement.

Une troisième cause est l'utilisation de répertoires de données obsolètes ou réutilisés. Si vous clonez des machines virtuelles ou réutilisez des disques d'anciens clusters, les nœuds peuvent transporter des métadonnées de cluster que vous n'aviez pas prévues. Cela peut entraîner des échecs de jonction déroutants et, dans les pires cas, la formation accidentelle d'un cluster séparé.

Enfin, une récupération manuelle sous pression peut aggraver le problème. Redémarrer des nœuds au hasard, effacer des chemins de données, ou forcer une allocation non sécurisée avant de savoir quelle partition est faisant autorité peut transformer un incident récupérable en perte de données.

Premières vérifications lors d'un incident

Commencez par demander à chaque nœud accessible ce qu'il pense :

curl -s "http://NŒUD:9200/_cat/master?v"
curl -s "http://NŒUD:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NŒUD:9200/_cluster/health?pretty"

Exécutez ces commandes sur plusieurs nœuds si possible. Si différents nœuds rapportent des maîtres différents ou une appartenance différente des nœuds, vous pourriez être confronté à un cluster partitionné ou à des nœuds isolés.

Vérifiez les logs sur les nœuds éligibles au rôle de maître pour des messages concernant les élections, les jonctions, les déconnexions et les échecs de publication. Les termes de recherche utiles incluent master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception, et handshake.

Ensuite, testez la connectivité de transport, pas seulement HTTP :

nc -vz nœud-1.exemple.interne 9300
nc -vz nœud-2.exemple.interne 9300
nc -vz nœud-3.exemple.interne 9300

Exécutez ces tests de nœud à nœud. Un équilibreur de charge ou une bastion atteignant le port HTTP 9200 vous en dit très peu sur la capacité des nœuds Elasticsearch à former un cluster via le port 9300.

Vérifier la configuration de découverte et d'amorçage

Sur Elasticsearch 7.x et versions ultérieures, inspectez ces paramètres :

cluster.name: mon-cluster
discovery.seed_hosts:
  - nœud-1:9300
  - nœud-2:9300
  - nœud-3:9300

Pour un tout nouveau cluster uniquement :

cluster.initial_master_nodes:
  - nœud-1
  - nœud-2
  - nœud-3

Les noms d'amorçage doivent correspondre à node.name. Une fois le cluster formé, supprimez cluster.initial_master_nodes de tous les nœuds.

Sur Elasticsearch 6.x et versions antérieures, vérifiez :

discovery.zen.minimum_master_nodes: 2

pour un cluster de trois nœuds éligibles au rôle de maître. Confirmez également que tous les nœuds éligibles au rôle de maître ont des hôtes de découverte et des noms de cluster cohérents.

Principes de récupération

Si vous soupçonnez un vrai split-brain, arrêtez de faire des modifications via l'API du cluster jusqu'à ce que vous sachiez quel côté est faisant autorité. La récupération la plus sûre suit généralement cet ordre :

1. Préservez les preuves : collectez les logs, les listes de nœuds, les vues du maître et la santé des index de chaque partition.
2. Restaurez la connectivité réseau ou isolez intentionnellement le mauvais côté.
3. Choisissez la partition faisant autorité en fonction de la majorité, des dernières données valides et de l'impact commercial.
4. Arrêtez Elasticsearch sur les nœuds qui ne doivent pas continuer en tant que partition indépendante.
5. Ramenez les nœuds un par un et vérifiez qu'ils rejoignent le cluster faisant autorité.
6. Restaurez les données manquantes à partir de snapshots si un historique de shard primaire est perdu ou incohérent.

Ne supprimez pas les répertoires translog comme solution de routine pour le split-brain. C'est un conseil dangereux. Les translogs font partie de la récupération Elasticsearch. Supprimer manuellement des fichiers sous le chemin de données peut entraîner une perte de données et ne doit être fait qu'avec des conseils spécifiques à la version du support Elastic ou après avoir accepté la perte et avoir un plan de reconstruction.

Si deux partitions ont accepté des écritures indépendamment, il n'y a peut-être pas de fusion automatique parfaite. Vous devrez peut-être restaurer à partir d'un snapshot, réindexer à partir des systèmes sources, rejouer les logs d'application, ou choisir les données d'un côté comme faisant autorité.

Un exemple réaliste

Imaginez un cluster de trois nœuds répartis sur trois sous-réseaux privés. Un changement de pare-feu bloque accidentellement le trafic de transport entre le nœud 1 et les nœuds 2 et 3. Les nœuds 2 et 3 se voient toujours, donc ils conservent ou élisent un maître. Le nœud 1 ne peut pas voir de majorité. Dans un cluster moderne et correctement configuré, le nœud 1 ne devrait pas former un maître concurrent tout seul. Les clients utilisant le nœud 1 peuvent échouer, mais le cluster évite les maîtres conflictuels.

Imaginez maintenant un ancien cluster 6.x avec trois nœuds éligibles au rôle de maître et discovery.zen.minimum_master_nodes: 1. Le nœud 1 peut s'élire lui-même, tandis que les nœuds 2 et 3 élisent un autre maître. C'est le risque classique de split-brain. La solution ne consiste pas seulement à reconnecter le réseau. Vous devez également corriger la configuration du quorum et décider comment gérer les écritures acceptées du mauvais côté.

Prévention

Utilisez trois nœuds éligibles au rôle de maître pour les clusters petits et moyens. Pour les clusters plus grands, faites-en des nœuds maîtres dédiés afin que la charge de recherche et d'indexation n'interfère pas avec la coordination du cluster.

Gardez les nœuds éligibles au rôle de maître sur des réseaux fiables avec une faible perte de paquets. Répartir les nœuds entre les zones peut aider à la disponibilité, mais seulement si le réseau entre les zones est fiable et que la conception du quorum a toujours du sens.

Surveillez les changements de maître. Une élection de maître lors d'une maintenance planifiée est normale. Des élections fréquentes pendant le trafic normal sont un signe d'avertissement.

Surveillez la connectivité de transport et pas seulement la disponibilité HTTP. Un nœud peut répondre sur le port 9200 et toujours ne pas participer correctement au cluster si le trafic de transport est bloqué.

Faites des snapshots régulièrement et testez les restaurations. Les réplicas ne vous protègent pas contre une mauvaise suppression, des données corrompues ou des écritures conflictuelles lors d'un incident grave.

Soyez prudent avec les paramètres d'amorçage. Sur les clusters modernes, cluster.initial_master_nodes n'est pas un paramètre de découverte quotidien. Utilisez-le pour créer un nouveau cluster, puis supprimez-le.

La meilleure récupération de split-brain est celle dont vous n'avez jamais besoin : éligibilité au rôle de maître basée sur la majorité, paramètres de découverte corrects selon la version, règles réseau simples et un plan de snapshot testé.

Comment distinguer le split-brain d'une élection normale

Une élection de maître n'est pas automatiquement un split-brain. Lors d'un redémarrage progressif, d'un flap réseau ou d'une défaillance du nœud maître, Elasticsearch peut élire un nouveau maître. Si le cluster conserve un maître faisant autorité et que l'ancien maître se retire, c'est un comportement normal de système distribué.

Les signes d'avertissement sont des vues différentes de différents nœuds. Si le nœud A se déclare maître tandis que le nœud B déclare le nœud C comme maître, arrêtez-vous et enquêtez. Si deux groupes de nœuds acceptent tous deux des changements d'état du cluster alors qu'ils sont déconnectés, vous avez une situation beaucoup plus grave qu'une brève élection.

Surveillez également le comportement des clients. Les clients attachés à un nœud isolé peuvent voir des échecs même si le côté majoritaire est sain. Cela ne signifie pas que le cluster majoritaire est cassé. Cela peut signifier que votre stratégie de connexion client ou votre équilibreur de charge envoie toujours du trafic vers un nœud qui ne peut pas participer.

Équilibreurs de charge et routage client

La découverte de transport Elasticsearch n'est pas la même que le routage HTTP client. Ne mettez pas la découverte du maître derrière un équilibreur de charge HTTP générique et attendez-vous à ce qu'il résolve l'appartenance au cluster. Les nœuds ont besoin de connectivité de transport entre eux.

Pour les clients, utilisez plusieurs points de terminaison HTTP ou un équilibreur de charge qui supprime rapidement les nœuds non sains. Un nœud qui a perdu son maître peut encore avoir un processus à l'écoute pendant un court instant, mais ce n'est pas une bonne cible pour les écritures. Les vérifications de santé devraient être plus significatives que "le port 9200 est ouvert".

Une vérification de santé HTTP pratique pourrait interroger la santé du cluster localement et rejeter les nœuds qui n'ont pas de maître découvert. L'approche exacte dépend de votre client et de votre infrastructure, mais le principe est simple : n'envoyez pas d'écritures à des nœuds isolés.

Nettoyage post-incident

Une fois le cluster stable, comparez la santé des index, les comptages de documents et les comptages de source de vérité au niveau de l'application. S'il y avait une chance que des écritures atterrissent sur différentes partitions, la santé Elasticsearch seule ne peut pas prouver que les données sont sémantiquement correctes.

Examinez la chronologie. Quel nœud a perdu la connectivité en premier ? Quel nœud était maître avant l'événement ? Les clients ont-ils continué à écrire ? Les snapshots étaient-ils à jour ? Des alertes se sont-elles déclenchées avant que les utilisateurs ne remarquent ? Ces détails déterminent si vous avez besoin seulement d'une correction réseau ou d'un plan de réconciliation des données.

Pour les clusters plus anciens, planifiez le travail de version et de paramètres de découverte. Si vous exécutez encore une version qui dépend de discovery.zen.minimum_master_nodes, assurez-vous qu'il est correct aujourd'hui, puis planifiez une mise à niveau. La prévention du split-brain n'est pas une étape ponctuelle de runbook ; elle fait partie de la gestion du cycle de vie du cluster.

Modifications de configuration à éviter en cas de panique

Ne modifiez pas cluster.name pour faire joindre les nœuds. Cela crée un problème d'identité de cluster différent.

N'effacez pas les chemins de données à moins que vous ne jetiez intentionnellement les copies locales de shards du nœud et que vous ayez confirmé que le cluster a des copies valides ailleurs ou des snapshots disponibles.

N'ajoutez pas cluster.initial_master_nodes à un cluster moderne existant comme correctif de redémarrage général. Ce paramètre est pour l'amorçage initial, pas pour la découverte de routine.

N'abaissez pas les protections de type quorum sur les anciens clusters pour restaurer la disponibilité. Rendre une partition minoritaire accessible en écriture peut sembler un progrès, mais c'est exactement ainsi que des maîtres conflictuels deviennent possibles.

Concevoir pour des domaines de défaillance difficiles

Trois nœuds éligibles au rôle de maître fonctionnent mieux lorsqu'aucun événement d'infrastructure unique ne peut en supprimer deux. Dans une région cloud à trois zones, un nœud éligible au rôle de maître par zone est un modèle courant. Dans un environnement à deux zones, le placement est plus difficile car une zone peut contenir deux votes. Si cette plus grande zone tombe en panne, le vote unique restant ne peut pas élire un maître en toute sécurité. Ce n'est pas qu'Elasticsearch soit fragile ; c'est une question de mathématique de majorité.

Ne résolvez pas cela en ajoutant un nombre pair de nœuds de vote sans réfléchir aux modes de défaillance. Quatre nœuds éligibles au rôle de maître nécessitent toujours une majorité, et une partition deux-deux ne peut pas choisir un côté en toute sécurité. Des nœuds de vote dédiés peuvent aider dans certaines conceptions, mais le principe reste le même : le cluster a besoin d'une majorité fiable pour prendre des décisions sur l'état du cluster.

Notez cela dans les notes d'architecture. Lors d'une panne, les gens demandent souvent pourquoi le nœud survivant ou la zone survivante ne peut pas simplement continuer à servir les écritures. La réponse doit être claire avant l'incident : accepter des écritures sans majorité risque un historique conflictuel.