Zen Discovery est le module de découverte intégré et historique d’Elasticsearch. Il permet à un nœud de repérer les autres membres du cluster, d’élire un nœud maître et de maintenir la cohérence de l’état du cluster. Toutes les communications entre nœuds passent par le module transport et le mécanisme de découverte repose sur des requêtes de type Ping.
Le processus démarre à partir d’une liste de nœuds d’amorce (seed nodes). Au démarrage ou lors d’une élection, chaque nœud tente de contacter ces cibles pour cartographier les membres du cluster. Cette liste doit idéalement être composée de nœuds éligibles au rôle de maître (master-eligible), c’est-à-dire ceux dont la directive node.master vaut true.
Découverte par unicast
La découverte unicast utilise une liste statique d’hôtes. Chaque entrée peut être un nom d’hôte ou une adresse IP. Les noms d’hôte sont résolus en adresse IP à chaque cycle de ping. Si la résolution DNS change au fil du temps, il peut être nécessaire d’ajuster les paramètres de sécurité de la JVM.
La liste s’configure dans elasticsearch.yml :
discovery.zen.ping.unicast.hosts:
- "es-core-01"
- "es-core-02:9300"
- "192.168.50.12"
Chaque valeur accepte la forme hôte:port ou simplement hôte. Le port par défaut est celui défini par transport.profiles.default.port, sinon transport.tcp.port. Les adresses IPv6 doivent être entre crochets. Par défaut, la liste contient 127.0.0.1 et [::1].
Le délai de résolution DNS est contrôlé par :
discovery.zen.ping.unicast.resolve_timeout: 5s
Découverte basée sur un fichier
En complément de la liste unicast statique, Elasticsearch peut charger les hôtes depuis un fichier externe. Cette appproche permet de modifier dynamiquement les nœuds d’amorce sans redémarrer le service, ce qui est pratique dans des environnements Docker ou Kubernetes où les adresses IP ne sont pas connues à l’avance.
Activez le fournisseur de fichiers :
discovery.zen.hosts_provider: file
Puis créez le fichier $ES_PATH_CONF/unicast_hosts.txt. Elasticsearch surveille ce fichier et recharge son contenu après chaque modification. Les entrées du fichier viennent s’ajouter à celles définies dans discovery.zen.ping.unicast.hosts.
Le format est d’une ligne par nœud. Le port est facultatif et vaut 9300 s’il est omis. Exemple :
# Nœuds maîtresses potentiels
es-master-01
es-master-02:9400
192.168.50.20
192.168.50.21:9500
[2001:db8::a]:9301
Les commentaires commencent par # en début de ligne. Les adresses IPv6 sont obligatoirement entre crochets, même lorsqu’un port est précisé.
Élection du nœud maître
L’élection est déclenchée automatiquement lorsqu’un cluster n’a pas de maître ou que le maître actuel est défaillant. Le paramètre discovery.zen.ping_timeout, fixé à 3 secondes par défaut, définit le temps d’attente des réponses lors du processus de ping. Par défaut, trois tentatives sont effectuées ; si aucune réponse n’est reçue, le cycle reprend. Augmenter cette valeur peut être utile sur des réseaux à forte latence, mais elle ralentit également l’élection.
Une fois le maître identifié, un nœud candidat envoie une requête d’adhésion (join) dont le délai maximal est défini par discovery.zen.join_time (20 fois le ping_timeout par défaut).
Le paramètre discovery.zen.minimum_master_nodes détermine le nombre minimum de nœuds master-eligible requis pour organiser une élection et pour que le maître conserve son mandat. Il doit être fixé à la valeur du quorum, soit généralement (nombre_de_master_eligible / 2) + 1. Un cluster avec seulement deux nœuds éligibles est déconseillé, car le quorum serait de 2 et la défaillance d’un seul nœud bloquerait toute nouvelle élection.
Le paramètre discovery.zen.master_election.ignore_non_master_pings permet d’exclure les nœuds non éligibles des votes lorsqu’il est positionné à true. De son côté, node.master: false retire définitivement un nœud de la course au rôle de maître.
Détection des défaillances
Deux processus de détection s’exécutent en permanence :
- le maître ping tous les autres nœuds pour vérifier qu’ils sont actifs ;
- chaque nœud ping le maître pour confirmer qu’il est toujours en fonction.
Les paramètres associés portent le préfixe discovery.zen.fd :
| Paramètre | Description |
|---|---|
discovery.zen.fd.ping_interval |
Intervalle entre deux pings (par défaut 1 s) |
discovery.zen.fd.ping_timeout |
Délai d’atente d’une réponse (par défaut 30 s) |
discovery.zen.fd.ping_retries |
Nombre de tentatives avant de déclarer un échec (par défaut 3) |
Mise à jour de l’état du cluster
Seul le nœud maître peut modifier l’état du cluster. Il traite les mises à jour une par une, applqué les changements, puis publie le nouvel état aux autres nœuds. Ceux-ci accusent réception sans encore appliquer l’état. Si le maître ne reçoit pas le nombre de confirmations défini par discovery.zen.minimum_master_nodes dans le délai discovery.zen.commit_timeout (30 s par défaut), la mise à jour est rejetée.
Après validation, le nouvel état est transmis et les nœuds l’appliquent. Le maître attend alors les confirmations de tous les nœuds jusqu’au délai discovery.zen.publish_timeout (30 s par défaut) avant de traiter la prochaine mise à jour. Ces deux délais sont modifiables via l’API de mise à jour des paramètres de cluster.
Blocage en l’absence de maître
Le paramètre discovery.zen.no_master_block contrôle les opérations autorisées lorsque le cluster n’a pas de maître ou pas assez de nœuds master-eligible. Deux valeurs sont possibles :
all: toutes les opérations sont bloquées, y compris la lecture de l’état du cluster.write: valeur par défaut. Les écritures sont rejetées ; les lectures reposent sur le dernier état connu et peuvent donc être obsolètes.
Ce blocage ne s’applique pas aux API relatives aux nœuds, telles que cluster stats, node info et node stats, qui restent accessibles sur chaque nœud.