Guide pour la configuration d'un cluster Elasticsearch à haute disponibilité

Configurez un cluster Elasticsearch à haute disponibilité avec des rôles de nœuds, la découverte, les réplicas, le dimensionnement JVM et les vérifications de santé.

Guide pour la configuration d'un cluster Elasticsearch à haute disponibilité

Elasticsearch peut rester disponible en cas de défaillance de nœuds, mais seulement si vous planifiez correctement les élections du maître, le placement des données, les réplicas et la découverte. Un cluster à nœud unique peut fonctionner en développement, mais il ne peut pas protéger votre charge de travail de recherche contre une défaillance de l'hôte.

Ce guide vous montre comment configurer un cluster Elasticsearch à haute disponibilité avec des nœuds dédiés éligibles au rôle de maître, des nœuds de données, des réplicas de fragments et des commandes de validation de base.

Comprendre la haute disponibilité dans Elasticsearch

La haute disponibilité dans Elasticsearch est obtenue grâce à plusieurs mécanismes clés :

  • Architecture distribuée : Elasticsearch distribue intrinsèquement les données et les opérations sur plusieurs nœuds.
  • Rôles des nœuds : Différents nœuds peuvent servir à différentes fins, permettant une allocation spécialisée des ressources et une isolation des pannes.
  • Réplication des fragments : Chaque index est divisé en fragments, et chaque fragment primaire peut avoir un ou plusieurs fragments de réplica, stockés sur différents nœuds.
  • Élection du nœud maître : Un processus d'élection robuste garantit qu'un nœud maître est toujours disponible pour gérer l'état du cluster.
  • Découverte Zen (Zen2) : Ce module gère la découverte des nœuds et l'élection du maître, garantissant que les nœuds peuvent se trouver et former un cluster de manière fiable.

Rôles essentiels des nœuds

Dans une configuration HA, comprendre les rôles des nœuds est crucial. Les rôles principaux pour la HA sont :

  • Nœuds éligibles au rôle de maître : Ces nœuds sont responsables de la gestion de l'état du cluster, y compris la création/suppression d'index, le suivi des nœuds et l'allocation des fragments. Ils ne stockent pas de données et ne traitent pas directement les requêtes de recherche/indexation, sauf s'ils ont également le rôle data. Pour la HA, vous devez avoir un nombre impair (généralement 3) de nœuds dédiés éligibles au rôle de maître pour former un quorum.
  • Nœuds de données : Ces nœuds stockent vos données indexées dans des fragments et effectuent des opérations liées aux données comme la recherche, l'agrégation et l'indexation. Ce sont les chevaux de bataille de votre cluster.
  • Nœuds de coordination uniquement : (Optionnel) Ces nœuds peuvent être utilisés pour acheminer les requêtes, gérer les phases de réduction de recherche et gérer l'indexation en masse. Ils ne contiennent ni données ni état du cluster, mais peuvent décharger le travail des nœuds de données et des nœuds maîtres.

Fragments et réplicas

Elasticsearch stocke vos données dans des fragments. Chaque index se compose d'un ou plusieurs fragments primaires. Pour atteindre une haute disponibilité, vous devez configurer un ou plusieurs fragments de réplica pour chaque fragment primaire. Les fragments de réplica sont des copies des fragments primaires. Si un nœud hébergeant un fragment primaire tombe en panne, un fragment de réplica sur un autre nœud peut être promu pour devenir le nouveau fragment primaire, garantissant ainsi aucune perte de données et une opération continue.

Prérequis pour configurer un cluster HA

Avant de plonger dans la configuration, assurez-vous que votre environnement répond à ces exigences de base :

  • Paquets ou archives Elasticsearch : Les paquets officiels incluent un JDK intégré dans les versions récentes d'Elasticsearch. Si votre installation utilise un JDK séparé, assurez-vous qu'il est compatible avec votre version d'Elasticsearch.
  • Ressources système : Allouez suffisamment de RAM (par exemple, 8-32 Go), de cœurs CPU et d'espace disque à E/S rapides (SSD recommandé) pour chaque nœud, en particulier les nœuds de données.
  • Configuration réseau : Tous les nœuds doivent pouvoir communiquer entre eux sur des ports spécifiques (par défaut 9300 pour la communication inter-nœuds, 9200 pour l'API HTTP). Assurez-vous que les pare-feu sont configurés de manière appropriée.
  • Système d'exploitation : Une distribution Linux stable (par exemple, Ubuntu, CentOS, RHEL) est généralement préférée pour les déploiements en production.

Guide étape par étape pour la configuration du cluster HA

Cette section décrit le processus d'installation et de configuration d'un cluster Elasticsearch multi-nœuds.

Étape 1 : Installer Elasticsearch sur tous les nœuds

Installez Elasticsearch sur chaque serveur qui fera partie de votre cluster. Vous pouvez utiliser des gestionnaires de paquets (APT pour Debian/Ubuntu, YUM pour RHEL/CentOS) ou télécharger l'archive directement.

Exemple (Debian/Ubuntu via APT) :

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update
sudo apt install elasticsearch

Après l'installation, activez et démarrez le service (bien que nous le configurions d'abord).

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch

Étape 2 : Configurer elasticsearch.yml sur chaque nœud

Le fichier elasticsearch.yml, généralement situé dans /etc/elasticsearch/, est l'endroit où vous définissez les paramètres de votre cluster. Modifiez ce fichier sur chaque nœud avec les configurations appropriées.

Configuration commune pour tous les nœuds

  1. cluster.name : Doit être identique pour tous les nœuds que vous souhaitez joindre au même cluster.

    cluster.name: my-ha-cluster
    
  2. node.name : Un nom unique pour chaque nœud, utile pour l'identification.

    node.name: node-1
    
  3. network.host : Lie Elasticsearch à une interface réseau spécifique. Utilisez 0.0.0.0 pour lier à toutes les interfaces disponibles, ou une adresse IP spécifique.

    network.host: 0.0.0.0
    # ou une adresse IP spécifique pour la sécurité/les configurations multi-NIC
    # network.host: 192.168.1.101
    
  4. http.port : Le port pour la communication client HTTP (par défaut 9200).

    http.port: 9200
    
  5. transport.port : Le port pour la communication inter-nœuds (par défaut 9300). Doit être cohérent.

    transport.port: 9300
    

Paramètres de découverte (cruciaux pour la HA)

Ces paramètres indiquent aux nœuds comment se trouver et former un cluster.

  1. discovery.seed_hosts : Une liste d'adresses des nœuds éligibles au rôle de maître dans votre cluster. C'est ainsi que les nœuds découvrent les nœuds éligibles au rôle de maître initiaux. Fournissez les adresses IP ou les noms d'hôte de tous vos nœuds éligibles au rôle de maître.

    discovery.seed_hosts: ["192.168.1.101", "192.168.1.102", "192.168.1.103"]
    
  2. cluster.initial_master_nodes : Utilisé uniquement lors de l'amorçage d'un tout nouveau cluster pour la première fois. Cette liste doit contenir le node.name des nœuds éligibles au rôle de maître qui participeront à la première élection du maître. Une fois le cluster formé, ce paramètre est ignoré.

    cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]
    
    • Conseil important : Supprimez ou commentez cluster.initial_master_nodes après la formation réussie du cluster. Ne le définissez pas à nouveau pour les redémarrages ou pour l'ajout de nouveaux nœuds.

Configuration des rôles des nœuds

Spécifiez le(s) rôle(s) pour chaque nœud. Une configuration HA courante implique 3 nœuds maîtres dédiés et plusieurs nœuds de données.

  • Nœuds éligibles au rôle de maître (par exemple, node-1, node-2, node-3) :
    node.roles: [master]
    
  • Nœuds de données (par exemple, node-4, node-5, node-6) :
    node.roles: [data]
    
  • Nœuds à rôles mixtes (non recommandé pour une grande production HA) :
    node.roles: [master, data]
    
    • Meilleure pratique : Pour une véritable haute disponibilité et stabilité en production, dédiez des nœuds séparés pour les rôles de maître et de données. Cela isole les processus critiques du maître des opérations de données gourmandes en ressources.

Étape 3 : Configurer la taille du tas JVM

Modifiez /etc/elasticsearch/jvm.options pour définir la taille du tas JVM. Une bonne règle de base est d'allouer 50 % de la RAM disponible, sans jamais dépasser 30-32 Go. Par exemple, si un serveur a 16 Go de RAM, allouez 8 Go :

-Xms8g
-Xmx8g

Étape 4 : Paramètres système

Pour la production, augmentez vm.max_map_count et ulimit pour les fichiers ouverts sur tous les nœuds. Ajoutez ces lignes à /etc/sysctl.conf et appliquez (sudo sysctl -p).

vm.max_map_count=262144

Et dans /etc/security/limits.conf (ou /etc/security/limits.d/99-elasticsearch.conf) :

elasticsearch - nofile 65536
elasticsearch - memlock unlimited

Étape 5 : Démarrer les services Elasticsearch

Démarrez le service Elasticsearch sur tous les nœuds configurés. Il est souvent recommandé de démarrer d'abord les nœuds éligibles au rôle de maître, mais avec la découverte moderne, l'ordre est moins critique tant que discovery.seed_hosts est correctement configuré.

sudo systemctl start elasticsearch

Vérifiez l'état du service et les journaux pour toute erreur :

sudo systemctl status elasticsearch
sudo journalctl -f -u elasticsearch

Étape 6 : Vérifier la santé du cluster

Une fois tous les nœuds en cours d'exécution, vérifiez la santé du cluster à l'aide de l'API Elasticsearch. Vous pouvez interroger n'importe quel nœud du cluster.

curl -X GET "localhost:9200/_cat/health?v&pretty"

Sortie attendue :

epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1678886400 12:00:00  my-ha-cluster  green      6          3       0    0    0    0        0             0                  -                 100.0%
  • status : Doit être green (tous les fragments primaires et de réplica sont alloués) ou yellow (tous les fragments primaires sont alloués, mais certains fragments de réplica ne le sont pas encore). red indique un problème grave.
  • node.total : Doit correspondre au nombre total de nœuds que vous avez démarrés.
  • node.data : Doit correspondre au nombre de nœuds de données.

Vérifiez les nœuds pour vous assurer qu'ils ont tous rejoint le cluster :

curl -X GET "localhost:9200/_cat/nodes?v&pretty"

Sortie attendue (exemple pour 3 nœuds maîtres, 3 nœuds de données) :

ip         heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
192.168.1.101          21          87   0    0.00    0.01     0.05 m           *      node-1
192.168.1.102          20          88   0    0.00    0.01     0.05 m           -      node-2
192.168.1.103          22          86   0    0.00    0.01     0.05 m           -      node-3
192.168.1.104          35          90   1    0.10    0.12     0.11 d           -      node-4
192.168.1.105          32          89   1    0.11    0.13     0.10 d           -      node-5
192.168.1.106          30          91   1    0.12    0.10     0.09 d           -      node-6

Cela montre node-1 comme le maître élu (* sous la colonne master) et les autres nœuds comme faisant partie du cluster.

Étape 7 : Configurer le partitionnement et la réplication des index

Pour les index nouvellement créés, Elasticsearch utilise par défaut un fragment primaire et un réplica (index.number_of_shards: 1, index.number_of_replicas: 1). Pour la HA, vous voulez généralement au moins un réplica, ce qui signifie que vos données existent sur au moins deux nœuds différents. Cela garantit que si un nœud tombe en panne, un réplica est disponible ailleurs.

Lors de la création d'un index, spécifiez ces paramètres :

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

Si la sécurité est activée, utilisez HTTPS et des identifiants ou une clé API dans votre commande curl. Par exemple :

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

Vérifications opérationnelles

Une fois le cluster vert, vérifiez le comportement en cas de panne avant que le trafic de production n'en dépende :

  • Arrêtez un nœud de données et confirmez que les réplicas sont promus et que les primaires restent disponibles.
  • Arrêtez le nœud maître élu et confirmez qu'un autre nœud éligible au rôle de maître est élu.
  • Vérifiez _cat/shards?v pour les fragments non attribués après que le cluster se soit stabilisé.
  • Confirmez que les clients se connectent via plusieurs nœuds ou un équilibreur de charge plutôt qu'un seul point de terminaison HTTP.

Conclusion finale

La haute disponibilité d'Elasticsearch découle de trois choix pratiques : maintenir un quorum de maîtres fiable, placer les réplicas de fragments sur différents nœuds et rendre les clients résilients à la perte de nœuds. Commencez avec trois nœuds dédiés éligibles au rôle de maître, suffisamment de nœuds de données pour contenir les fragments primaires et de réplica, et une procédure de récupération testée pour les redémarrages et les pannes de nœuds.