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

Le quorum du nœud maître d'Elasticsearch détermine si votre cluster peut élire un leader en toute sécurité, publier les changements d'état du cluster et éviter que deux côtés isolés du même cluster prennent des décisions différentes.

Le maître élu n'accélère pas les recherches par lui-même. Il coordonne le cluster. Lorsque les élections sont instables, les symptômes peuvent sembler dispersés : la création d'index se bloque, l'allocation des shards s'arrête, Kibana rapporte des états de santé changeants, et les logs répètent des messages indiquant qu'un maître n'est pas découvert.

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

Alors que les nœuds de données effectuent le travail lourd 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, sauf s'il est également configuré comme 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, incluant les index existants, les mappings et paramètres de ces index, et l'emplacement de chaque shard.
2. Gestion des nœuds : Gestion de l'arrivée et du départ des nœuds, mise à jour de l'état du cluster en conséquence.
3. Gestion des index : Création, suppression ou mise à jour des index.
4. Allocation des shards : Décision de l'emplacement des shards primaires et répliques (allocation initiale et rééquilibrage après une panne de nœud).

Si le maître élu tombe en panne, le cluster suspend les travaux liés au maître jusqu'à ce qu'un autre maître soit élu. Les recherches existantes peuvent continuer pour les shards disponibles, mais la création d'index, les mises à jour de mapping et les décisions d'allocation dépendent d'une coordination stable du maître.

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

Dans un système distribué, un processus d'élection est nécessaire chaque fois que le nœud maître actuel tombe en panne 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 autogé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 maître, qui sont 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 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—une majorité des nœuds votants connus—pour garantir le consensus.
3. Sélection du leader : Si un quorum est établi, le sous-système de coordination d'Elasticsearch sélectionne un maître selon ses règles d'élection internes.
4. Vote et engagement : La proposition est soumise au 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 tout nouveau cluster pour la première fois, Elasticsearch doit savoir quels nœuds doivent participer à la configuration de vote initiale. Cela 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]

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

Conseil : Une fois le cluster formé, supprimez cluster.initial_master_nodes de chaque nœud. Le laisser en place peut être dangereux lors des redémarrages ultérieurs, car ce paramètre est uniquement destiné au premier amorçage d'un tout nouveau cluster.

Exigences de quorum et prévention du split-brain

La raison fondamentale des exigences de quorum est de garantir qu'un seul leader peut être élu à tout moment, empêchant ainsi le problème de split-brain.

Qu'est-ce que le split-brain ?

Le split-brain se produit lorsqu'une partition réseau divise le cluster en segments isolés, et que plus d'un segment croit détenir le maître faisant autorité. Si cela se produit, différents côtés peuvent accepter des changements d'état du cluster contradictoires, ce que le quorum est conçu pour empêcher.

La règle du quorum (consensus majoritaire)

Pour éviter le split-brain, Elasticsearch applique une règle de consensus majoritaire, exigeant qu'un nombre minimum de nœuds votants soient d'accord 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 majorité stricte, si le réseau se partitionne, seul le côté le plus grand (qui détient la majorité) peut atteindre le quorum et continuer à fonctionner. Le côté le plus petit, incapable d'élire un maître, s'arrêtera et attendra que la connectivité réseau soit rétablie, évitant ainsi les écritures de données dans le segment partitionné.

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

Avertissement de bonne pratique : Déployez toujours un nombre impair de nœuds éligibles au 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 de vote à 4 nœuds nécessite 3 votes (N/2+1), ce qui signifie qu'il ne peut tolérer qu'une seule panne, 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, trois nœuds éligibles au maître dédiés constituent la base de référence courante. Cela sépare la charge de recherche et d'indexation du travail de coordination. Les petits clusters de développement peuvent exécuter des rôles mixtes, mais un cluster qui compte ne devrait pas laisser une agrégation lourde ou un pic d'ingestion affamer le maître élu.

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

Pour configurer un nœud comme éligible au maître mais ne stockant pas de données ni n'exécutant 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]

# Liez le transport à un réseau privé et restreignez l'accès avec des pare-feu/groupes de sécurité.
# network.host: 10.0.0.1

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]

# Si aucun rôle n'est spécifié, Elasticsearch attribue l'ensemble de rôles par défaut pour cette version.

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 maître à l'aide du 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 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 en raison de règles de pare-feu, de problèmes de routage, de problèmes DNS ou d'une latence élevée. Le port de transport, généralement 9300, doit être accessible entre les nœuds. HTTP, généralement 9200, est destiné à l'accès client/API et n'est pas le canal d'élection.
Inadéquation de configuration	cluster.name est incorrect ou discovery.seed_hosts ne pointe pas vers les bons nœuds éligibles au maître. Vérifiez que tous les nœuds utilisent des paramètres identiques.
Perte de quorum	Trop de nœuds votants sont tombés en panne en même temps, par exemple deux pannes dans une configuration à trois maîtres. Si les nœuds manquants sont définitivement partis, utilisez l'API d'exclusions de configuration de vote avec précaution et seulement après avoir confirmé le mode de défaillance.
E/S disque	Les E/S disque du nœud maître sont saturées, l'empêchant de publier rapidement l'état du cluster, 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

Cette sortie confirme quels nœuds sont actuellement comptés dans le quorum, garantissant que votre configuration correspond à vos objectifs de tolérance aux pannes.

Le modèle de production le plus sûr est simple : trois nœuds éligibles au maître dédiés dans des domaines de défaillance séparés, un réseau de transport stable, des hôtes de semences corrects, et cluster.initial_master_nodes utilisé une seule fois. Lorsque les élections échouent, résistez à l'envie de redémarrer tous les nœuds à la fois. Lisez les logs, confirmez quels nœuds éligibles au maître peuvent se voir mutuellement, et effectuez un changement contrôlé à la fois.