Comprendre l'élection du nœud maître Elasticsearch et les exigences de quorum

Elasticsearch est un système distribué qui repose sur la coordination entre les nœuds pour maintenir une vue cohérente de l'état du cluster. Au cœur de cette coordination se trouve le nœud maître. Le nœud maître est la source unique de vérité pour les métadonnées du cluster, et assurer sa stabilité et son élection correcte est primordial pour la santé, la scalabilité et la résilience du cluster.

Cet article détaille les responsabilités critiques du nœud maître, explique le processus d'élection moderne utilisé dans les versions récentes d'Elasticsearch (7.x+) et clarifie le concept essentiel de quorum, le mécanisme nécessaire pour prévenir le scénario dévastateur connu sous le nom de problème de "split-brain" (cerveau divisé).

Le rôle critique du nœud maître

Bien que les nœuds de données gèrent la charge lourde d'indexation, de recherche et de stockage des données, le nœud maître est responsable de la gestion de la structure et des métadonnées de l'ensemble du cluster. Il ne participe généralement pas aux opérations de requête ou d'indexation à moins qu'il ne soit également configuré comme un nœud de données.

Responsabilités du nœud maître

1. Gestion de l'état du cluster : Le maître maintient et publie l'état du cluster, un plan de la configuration actuelle du cluster, y compris quels indices existent, les mappings et les paramètres de ces indices, et l'emplacement de chaque shard.
2. Gestion des nœuds : Gère l'ajout et le retrait des nœuds, mettant à jour l'état du cluster en conséquence.
3. Gestion des indices : Création, suppression ou mise à jour des indices.
4. Allocation des shards : Décide où les shards primaires et répliques doivent résider (allocation initiale et rééquilibrage après défaillance d'un nœud).

Si le nœud maître échoue, le cluster ne peut pas effectuer de tâches administratives ni réallouer de shards tant qu'un nouveau maître n'a pas été élu avec succès.

Comprendre l'élection du maître et le vote

Dans un système distribué, un processus d'élection est requis chaque fois que le nœud maître actuel échoue ou devient inaccessible. Depuis Elasticsearch 7.0, le mécanisme d'élection a été considérablement simplifié et renforcé, principalement par l'élimination du paramètre complexe discovery.zen.minimum_master_nodes et l'introduction de Configurations de vote auto-gérées.

Le processus d'élection (Elasticsearch 7.x+)

L'élection du maître est désormais gérée automatiquement par les nœuds éligibles au rôle de maître, définis dans la configuration à l'aide de node.roles: [master, data], ou simplement node.roles: [master] pour les maîtres dédiés.

1. Découverte des candidats : Les nœuds éligibles au rôle de maître communiquent pour déterminer l'ensemble des membres votants actifs.
2. Vérification du quorum : Les nœuds vérifient s'ils peuvent atteindre un quorum, c'est-à-dire une majorité des nœuds votants connus, pour assurer le consensus.
3. Sélection du leader : Si un quorum est établi, le candidat le mieux classé (basé sur un mécanisme de départage comme l'ID de l'état du cluster) est proposé comme nouveau maître.
4. Vote et engagement : La proposition est soumise à un vote et, si elle est acceptée par la majorité, le nouveau maître prend le contrôle et publie le nouvel état du cluster.

Amorçage initial du cluster

Lors du démarrage d'un cluster tout neuf pour la première fois, Elasticsearch doit savoir quels nœuds doivent participer à la configuration de vote initiale. Ceci est géré à l'aide du paramètre cluster.initial_master_nodes. Ce paramètre ne doit être utilisé qu'une seule fois lors du démarrage initial du cluster.

# Extrait de elasticsearch.yml pour la configuration initiale
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Lister les noms de tous les nœuds éligibles au rôle de maître utilisés pour l'amorçage initial
cluster.initial_master_nodes: [node-1, node-2, node-3]

Astuce : Une fois le cluster en fonctionnement et stable, vous devriez supprimer ou commenter le paramètre cluster.initial_master_nodes des fichiers de configuration de tous les nœuds pour éviter des problèmes potentiels si les nœuds sont redémarrés ultérieurement dans un état mixte.

Exigences de quorum et prévention du split-brain

La raison fondamentale des exigences de quorum est de garantir qu'un seul leader puisse être élu à la fois, prévenant ainsi le problème du split-brain.

Qu'est-ce que le Split-Brain ?

Le split-brain se produit lorsqu'une partition réseau divise le cluster en deux segments isolés ou plus, et que chaque segment se croit être le maître faisant autorité. Si cela se produit, les nœuds des différents segments peuvent accepter indépendamment des requêtes d'indexation et allouer des shards, entraînant une incohérence et une corruption des données lorsque le réseau finit par se rétablir.

La règle du quorum (consensus majoritaire)

Pour prévenir le split-brain, Elasticsearch applique une règle de consensus majoritaire, exigeant qu'un nombre minimum de nœuds votants s'accordent sur tout changement d'état du cluster. Ce minimum est le quorum, calculé comme suit :

$$\text{Quorum} = \lfloor (\text{Nombre de nœuds votants} / 2) \rfloor + 1$$

En exigeant une stricte majorité, si le réseau se partitionne, seul le côté le plus important (qui détient la majorité) peut atteindre le quorum et continuer à fonctionner. Le côté le moins important, incapable d'élire un maître, s'arrêtera et attendra la restauration de la connectivité réseau, évitant ainsi les écritures de données sur le segment partitionné.

Nombre de nœuds maîtres votants (N)	Quorum requis (N/2 + 1)
3	2
5	3
7	4

Avertissement Meilleure Pratique : Déployez toujours un nombre impair de nœuds éligibles au rôle de maître (par exemple, trois ou cinq). Déployer un nombre pair (par exemple, quatre) offre la même tolérance aux pannes que le nombre impair précédent (trois), mais nécessite plus de ressources. Par exemple, un cluster votant à 4 nœuds nécessite 3 votes (N/2+1), ce qui signifie qu'il ne peut tolérer qu'une seule défaillance, comme un cluster à 3 nœuds, mais utilise un serveur supplémentaire.

Configuration de nœuds maîtres dédiés

Pour les environnements de production, en particulier les clusters de grande taille (20+ nœuds de données), il est fortement recommandé d'utiliser des nœuds maîtres dédiés. Cela sépare les tâches gourmandes en ressources de recherche/indexation des tâches administratives cruciales du maître.

Exemple de configuration de nœud (Maître dédié)

Pour configurer un nœud comme éligible au rôle de maître mais qui ne stocke pas de données et n'exécute pas de pipelines d'ingestion, utilisez les rôles suivants dans elasticsearch.yml:

# Nœud 1 : Maître dédié
node.name: es-master-01
node.roles: [master]

# Désactiver le trafic HTTP/Transport pour les maîtres purs (facultatif, mais bonne pratique de sécurité)
# http.enabled: false 
# transport.bind_host: [adresse_ip_privée_du_maître]

Exemple de configuration de nœud (Nœud de données dédié)

Inversement, un nœud de données dédié doit être empêché de participer au processus d'élection du maître :

# Nœud 4 : Nœud de données dédié
node.name: es-data-04
node.roles: [data]

# Remarque : Si aucun rôle n'est spécifié, Elasticsearch utilise par défaut [master, data, ingest] (par défaut avant la version 8.0)

Paramètres de découverte du cluster

Tous les nœuds doivent être configurés pour trouver le même ensemble de nœuds éligibles au rôle de maître en utilisant le paramètre discovery.seed_hosts. Ce paramètre liste les adresses réseau où Elasticsearch peut tenter de contacter d'autres nœuds pour rejoindre le cluster.

# Paramètre commun pour tous les nœuds du cluster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Cette liste doit contenir les adresses des nœuds éligibles au rôle de maître (es-master-01, es-master-02, es-master-03, etc.).

Dépannage des problèmes d'élection

Si le cluster ne parvient pas à élire un maître, il entre généralement dans un état "rouge" ou "jaune" et enregistre des erreurs persistantes. Les causes courantes incluent :

Problème	Description et solution
Problèmes réseau	Les nœuds ne peuvent pas communiquer entre eux en raison de règles de pare-feu, de problèmes de routage ou d'une latence élevée. Assurez-vous que les ports 9200 (HTTP) et 9300 (Transport) sont ouverts entre les nœuds.
Incohérence de configuration	cluster.name est incorrect ou discovery.seed_hosts ne pointe pas vers les bons nœuds éligibles au rôle de maître. Vérifiez que tous les nœuds utilisent des paramètres identiques.
Perte de quorum	Trop de nœuds éligibles au rôle de maître ont échoué simultanément (par exemple, deux échecs dans une configuration maîtres à 3 nœuds). Une intervention manuelle (par exemple, en utilisant l'API api/cluster/decommission/voting_config_exclusions) peut être nécessaire pour supprimer de force les nœuds défaillants de la liste de vote.
E/S disque	Les E/S disque du nœud maître sont saturées, l'empêchant de publier l'état du cluster rapidement, entraînant des délais d'attente et des élections répétées.

Vérification de la configuration de vote

Vous pouvez inspecter la configuration de vote actuelle à l'aide de l'API Cluster :

GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred

Cette sortie confirme quels nœuds sont actuellement pris en compte pour le quorum, garantissant que votre configuration correspond à vos objectifs de tolérance aux pannes.

Résumé

Le processus d'élection du nœud maître est l'épine dorsale de la résilience d'un cluster Elasticsearch. En comprenant les responsabilités du maître et en implémentant correctement la règle du quorum (en utilisant un nombre impair de nœuds éligibles au rôle de maître et en assurant un cluster.initial_master_nodes correct lors de l'amorçage), les administrateurs peuvent prévenir de manière fiable les scénarios de split-brain et maintenir un système distribué hautement disponible. Utilisez toujours des nœuds maîtres dédiés en production pour isoler les tâches administratives et assurer une publication fiable de l'état du cluster.