Guide pas à pas pour configurer un cluster de base à trois nœuds

Un cluster Elasticsearch à trois nœuds est la plus petite configuration que je considère comme un véritable cluster plutôt qu'un laboratoire. Il peut élire un maître à la majorité, maintenir les répliques loin des primaires et survivre à la perte d'un nœud si les données et les rôles sont configurés de manière sensée. Ce n'est toujours pas magique. Trois petites machines virtuelles avec des disques pleins ne se comporteront pas comme une plateforme de recherche résiliente simplement parce qu'elles sont trois.

Ce guide utilise une disposition Elasticsearch moderne de base : trois nœuds, tous éligibles au rôle de maître et capables de gérer des données, sur des adresses réseau privées. C'est un point de départ raisonnable pour un petit environnement. Les déploiements de production plus importants séparent souvent les nœuds maîtres dédiés, les niveaux de données, les nœuds d'ingestion, les nœuds d'apprentissage automatique et les nœuds de coordination uniquement. Commencez simplement ici, puis séparez les rôles lorsque la charge de travail le justifie.

Les exemples supposent des hôtes Linux et des installations par paquets ou archives. Adaptez les commandes de service à votre environnement.

Avant de modifier la configuration

Vous avez besoin de trois hôtes ou machines virtuelles distincts. Ne mettez pas trois « nœuds » sur un seul ordinateur portable et ne les appelez pas hautement disponibles. Ils peuvent être utiles pour tester la découverte, mais ils partagent le même domaine de défaillance.

Chaque hôte a besoin :

• De la même version d'Elasticsearch.
• D'une adresse IP privée stable ou d'un nom DNS.
• D'une connectivité de transport entre les nœuds sur le port 9300 par défaut.
• D'un accès HTTP sur le port 9200 depuis votre hôte d'administration ou votre équilibreur de charge, si nécessaire.
• D'assez d'espace disque pour les fragments primaires et de réplique.
• D'une synchronisation temporelle via NTP ou un service similaire.
• D'un chemin de données configuré sur un stockage local ou attaché fiable.

Les distributions récentes d'Elasticsearch incluent un JDK intégré. Si votre packaging ou version nécessite un JDK externe, utilisez la version Java prise en charge pour cette version d'Elasticsearch plutôt que de deviner.

Utilisez des adresses privées dans discovery.seed_hosts. Évitez les IP publiques sauf si vous avez une conception très spécifique et des contrôles réseau stricts.

Pour ce guide, les nœuds sont :

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

Configurer les paramètres communs du cluster

Sur chaque nœud, modifiez elasticsearch.yml. L'emplacement du fichier dépend de la méthode d'installation. Les installations par paquets utilisent généralement /etc/elasticsearch/elasticsearch.yml ; les installations par archive utilisent config/elasticsearch.yml dans le répertoire extrait.

Définissez le même nom de cluster sur les trois nœuds :

cluster.name: my-three-node-cluster

Définissez les hôtes de découverte sur les trois nœuds :

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

Définissez les nœuds maîtres initiaux pour le premier amorçage uniquement :

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Les valeurs doivent correspondre à node.name, pas aux adresses IP, sauf si vos noms de nœuds ressemblent à des chaînes IP. Ce paramètre est uniquement pour former un tout nouveau cluster. Une fois le cluster formé avec succès, supprimez cluster.initial_master_nodes de tous les nœuds et ne le conservez pas pour les redémarrages futurs. Le laisser peut causer des confusions lors de la reprise après sinistre ou des tentatives d'amorçage accidentelles.

Liez-vous à l'interface privée ou à une valeur d'hôte sûre :

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

Utilisez la propre IP de chaque nœud pour network.host. 0.0.0.0 est pratique dans les exemples, mais en production, il peut exposer Elasticsearch sur des interfaces que vous n'aviez pas prévues. Si la configuration de sécurité automatique est activée dans votre version, vous devrez également prendre en compte les certificats TLS, l'inscription et l'authentification.

Configurer le nom de chaque nœud

Sur le nœud 1 :

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Sur le nœud 2 :

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Sur le nœud 3 :

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Si vous exécutez plusieurs nœuds sur une seule machine pour un test, utilisez des valeurs path.data et path.logs séparées. Pour les vrais clusters, un nœud par hôte est généralement le modèle le plus propre.

Choisir les rôles des nœuds

Pour un petit cluster à trois nœuds, les trois nœuds peuvent porter les rôles standard :

node.roles: [ master, data, ingest, remote_cluster_client ]

Cela vous donne trois nœuds éligibles au rôle de maître, donc l'élection du maître fonctionne à la majorité. Avec trois nœuds éligibles au rôle de maître, le cluster peut en perdre un et toujours élire ou conserver un maître. Si deux sont partis, il ne peut pas prendre de décisions sur l'état du cluster en toute sécurité.

Pour un cluster plus grand, les nœuds dédiés éligibles au rôle de maître sont souvent meilleurs car un travail lourd de données ou d'ingestion ne peut pas affamer les tâches de maître. C'est un raffinement de mise à l'échelle, pas une exigence pour cette configuration de base.

Vérifier les bases du système d'exploitation et du réseau

Avant de démarrer Elasticsearch, testez la connectivité de transport entre chaque paire de nœuds :

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

Exécutez ces commandes depuis chaque nœud si possible. Les pare-feu et les groupes de sécurité cloud doivent autoriser le trafic de transport entre nœuds. Le port HTTP 9200 est pour les clients et les appels d'administration ; le port de transport 9300 est ce que les nœuds du cluster utilisent pour communiquer entre eux.

Vérifiez également la propriété des fichiers sur les répertoires de données et de logs. Le processus Elasticsearch doit pouvoir écrire dans les deux.

Démarrer les nœuds

Pour les installations par paquets avec systemd :

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

Pour les installations par archive lors des tests :

bin/elasticsearch

Démarrez les trois nœuds. Ils n'ont pas besoin de démarrer dans un ordre parfait, mais surveillez les logs. Vous voulez voir le cluster se former une fois et les nœuds le rejoindre. Si un nœud dit qu'il ne peut pas trouver de maître, concentrez-vous sur node.name, cluster.name, discovery.seed_hosts, la connectivité de transport et les paramètres TLS/sécurité.

Une fois le cluster formé, supprimez cluster.initial_master_nodes de la configuration de chaque nœud et redémarrez plus tard pendant une fenêtre planifiée si nécessaire. Ne le supprimez pas pendant que vous essayez encore d'amorcer pour la première fois.

Vérifier la santé du cluster

Depuis un hôte qui peut atteindre le port 9200 :

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Un tout nouveau cluster sans indices utilisateur peut afficher un statut vert avec zéro fragment. Les champs à vérifier sont status, number_of_nodes et number_of_data_nodes.

Pour une vue compacte :

curl -s "http://10.0.10.11:9200/_cat/health?v"

Ensuite, vérifiez l'appartenance des nœuds :

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

Vous devriez voir les trois nœuds. Un nœud aura le marqueur de maître élu. Les trois devraient afficher les rôles que vous attendez.

Créer un indice de test avec des répliques

Créez un indice de test pour confirmer le placement des fragments :

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

Vérifiez les fragments :

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

Avec trois fragments primaires et une réplique, vous devriez voir six copies de fragments réparties sur les nœuds. Elasticsearch évitera de placer une réplique sur le même nœud que son primaire.

Si le cluster est jaune, demandez pourquoi :

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

Les causes courantes sont un nombre insuffisant de nœuds de données éligibles, des seuils de disque, une allocation désactivée ou des règles de conscience d'allocation qui ne correspondent pas à vos attributs de nœud.

Tester le comportement en cas de défaillance d'un nœud

Dans un test hors production, arrêtez un nœud :

sudo systemctl stop elasticsearch

Vérifiez la santé depuis un autre nœud :

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

Le cluster devrait toujours avoir un maître car deux des trois nœuds éligibles au rôle de maître restent. Selon le timing, la relocalisation des fragments et le placement des répliques, la santé peut être verte ou jaune pendant qu'Elasticsearch réagit. Redémarrez le nœud et surveillez la récupération :

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

Ce test vaut la peine d'être fait avant que le cluster ne devienne important. Il vous apprend à quoi ressemble une récupération normale, de sorte qu'un incident réel soit moins surprenant.

Quelques garde-fous de production

Activez et comprenez la sécurité pour votre version d'Elasticsearch. N'exposez pas une API HTTP non authentifiée à Internet ou à un réseau interne large.

Faites des instantanés avant de dépendre du cluster. Les répliques protègent contre la perte de nœuds ; les instantanés protègent contre la suppression, la corruption et les erreurs opérationnelles.

Surveillez l'utilisation du disque, la pression du tas JVM, le nombre de nœuds, la santé du cluster, les tâches en attente et le succès des instantanés. Un cluster à trois nœuds n'est résilient que s'il a suffisamment de capacité pour récupérer.

Gardez le nombre de fragments modeste. De nombreux petits fragments créent des frais généraux. Un cluster de base peut être submergé par des milliers de petits indices même si le volume de données n'est pas important.

Enfin, documentez les paramètres d'amorçage et supprimez cluster.initial_master_nodes après la formation. La plupart des problèmes de configuration à trois nœuds proviennent de petites discordances : des noms de nœuds qui ne correspondent pas aux noms d'amorçage, des ports de transport bloqués, des répertoires de données réutilisés à partir d'anciens clusters ou des hypothèses sur les paramètres de sécurité par défaut. Vérifiez ceux-ci d'abord avant de modifier des paramètres plus exotiques.

Notes de sécurité pour les versions actuelles d'Elasticsearch

De nombreuses installations modernes d'Elasticsearch activent les fonctionnalités de sécurité lors de la configuration. Cela signifie que les appels HTTP peuvent nécessiter HTTPS, un certificat CA et des identifiants. Si votre cluster a été auto-configuré avec TLS, une vérification de santé peut ressembler davantage à ceci :

curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://10.0.10.11:9200/_cluster/health?pretty

Ne désactivez pas la sécurité juste pour faire fonctionner une commande de tutoriel. Au lieu de cela, ajustez les exemples pour vos chemins de certificats et comptes de service. En production, créez des utilisateurs nommés ou des clés API avec les privilèges dont ils ont besoin au lieu d'utiliser le superutilisateur intégré pour le travail quotidien.

Le TLS de transport peut également affecter les jonctions de nœuds. Si les nœuds ne peuvent pas se joindre et que les logs mentionnent la confiance dans les certificats, une discordance SAN, un échec de poignée de main ou des erreurs de transport à distance, vérifiez les certificats avant de modifier les paramètres de découverte. Une liste discovery.seed_hosts parfaite n'aidera pas les nœuds qui se rejettent mutuellement lors de la poignée de main TLS.

Échecs de démarrage courants

Si les nœuds ne forment pas un cluster, vérifiez d'abord les choses simples.

cluster.name doit correspondre sur tous les nœuds. Un nœud avec un nom de cluster différent ne rejoindra pas simplement parce qu'il apparaît dans la liste des hôtes de découverte.

node.name doit correspondre aux valeurs utilisées dans cluster.initial_master_nodes lors du premier amorçage. Si la configuration indique node-1 mais que l'amorçage liste es-node-1, la découverte peut stagner.

Le port de transport doit être accessible entre les nœuds. L'accès HTTP sur 9200 ne suffit pas. Utilisez nc, l'inspection des groupes de sécurité ou des captures de paquets si nécessaire.

Les répertoires de données ne doivent pas contenir de métadonnées d'un ancien cluster, sauf si vous avez l'intention de rejoindre exactement ce cluster. Réutiliser un disque d'un test précédent peut produire des erreurs déroutantes concernant les UUID de cluster ou un amorçage non sécurisé.

La mémoire et les vérifications d'amorçage sont importantes lors de la liaison à une adresse non loopback. Elasticsearch peut appliquer des vérifications pour les descripteurs de fichiers, la mémoire virtuelle, le verrouillage de la mémoire et la configuration de la découverte. Lisez le journal de démarrage plutôt que de réessayer aveuglément.

Après que le cluster fonctionne

Créez un référentiel d'instantanés avant que le cluster ne transporte des données importantes. Les répliques ne sont pas des sauvegardes. Une mauvaise suppression, une erreur de mappage ou un bogue d'application se répliquera rapidement sur chaque copie.

Enregistrez les noms de nœuds, les IP, les rôles, les chemins de données, les emplacements des certificats et l'historique d'amorçage dans votre runbook. Pendant une panne, personne ne veut rétro-ingénierer si node-2 est censé être éligible au rôle de maître.

Configurez des alertes pour la perte de nœuds, la santé rouge, la santé jaune prolongée, les seuils de disque, la pression du tas JVM, les échecs d'instantanés et les élections de maître fréquentes. Un cluster à trois nœuds vous donne de la marge pour survivre à une défaillance, mais seulement si vous la remarquez et la réparez avant la deuxième défaillance.

Planifiez la capacité en tenant compte de la récupération. Si chaque nœud fonctionne avec une utilisation de disque très élevée, la perte d'un nœud peut laisser trop peu d'espace pour que les répliques se reconstruisent. Les clusters sains ont besoin de capacité de réserve, pas seulement assez de place pour les primaires d'aujourd'hui.

Pratique du redémarrage progressif

Pratiquez un redémarrage progressif avant d'en avoir besoin pour une mise à niveau de paquet. Redémarrez un nœud, attendez qu'il rejoigne, confirmez la santé et la récupération, puis passez au nœud suivant. Ne redémarrez pas les trois nœuds à la fois, sauf si vous effectuez intentionnellement un arrêt complet du cluster.

Une séquence simple est :

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Si le cluster a de gros fragments, envisagez si l'allocation différée doit être ajustée avant les redémarrages planifiés. L'objectif est d'éviter une reconstruction inutile des répliques lorsqu'un nœud sera de retour dans quelques minutes. Après la maintenance, vérifiez que l'allocation est activée et que les paramètres temporaires sont supprimés.

Testez également le comportement des clients. Les applications doivent utiliser plus d'un point de terminaison Elasticsearch ou un équilibreur de charge qui supprime les nœuds défaillants. Un cluster à trois nœuds n'aide que si les clients peuvent atteindre les nœuds sains restants lorsqu'un nœud est en panne.

Une dernière habitude aide : conservez une copie du fichier elasticsearch.yml final pour chaque nœud dans la gestion de configuration. Les modifications manuelles effectuées lors de la configuration ont tendance à dériver, et la dérive est exactement ce qui rend le remplacement du prochain nœud plus difficile qu'il ne devrait l'être.