Hub de Connaissances DevOps
Hub de Connaissances DevOps

Dépannage des échecs courants d'allocation de shards Elasticsearch

Apprenez à dépanner et à résoudre les échecs courants d'allocation de shards Elasticsearch. Ce guide couvre l'identification des shards non alloués, le diagnostic des problèmes tels que les erreurs d'espace disque, l'indisponibilité des nœuds et le filtrage d'allocation, et fournit des solutions concrètes ainsi que les meilleures pratiques pour maintenir un cluster Elasticsearch sain.

30 vues

Dépannage des défaillances courantes d'allocation de shard Elasticsearch

Elasticsearch, un puissant moteur distribué de recherche et d'analyse, repose fortement sur sa capacité à distribuer les données sur plusieurs nœuds à l'aide de shards (fragments). Lorsque ces shards ne parviennent pas à être alloués, cela peut entraîner une indisponibilité des données, des échecs de recherche et une dégradation de l'état du cluster. Il est crucial de comprendre les causes courantes des échecs d'allocation de shard et de savoir comment les diagnostiquer et les résoudre pour maintenir un environnement Elasticsearch stable et performant. Cet article vous guidera à travers les problèmes les plus fréquents et vous fournira des étapes concrètes pour remettre vos shards dans un état attribué.

Ce guide se concentre sur le dépannage pratique pour les environnements Elasticsearch de production. Nous aborderons l'identification des shards non alloués, la compréhension des raisons courantes de l'échec, telles que l'espace disque, les règles d'allocation et les problèmes de nœuds, et fournirons des étapes claires pour résoudre efficacement ces problèmes. En maîtrisant ces techniques, vous pouvez minimiser les temps d'arrêt et assurer la fiabilité de votre cluster Elasticsearch.

Identification des Shards Non Alloués

La première étape du dépannage consiste à identifier quels shards ne sont pas alloués et pourquoi. Elasticsearch fournit plusieurs outils à cet effet :

Utilisation de l'API d'état du cluster (Cluster Health API)

L'API _cluster/health fournit un aperçu de haut niveau de l'état de votre cluster. Recherchez unassigned_shards dans la réponse. Une valeur non nulle indique un problème.

GET _cluster/health

Extrait de réponse d'exemple :

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

Dans cet exemple, "status": "yellow" et "unassigned_shards": 1 indiquent qu'il y a un shard non alloué. Un statut red (rouge) signifie qu'un ou plusieurs shards primaires ne sont pas alloués, ce qui a un impact sur la disponibilité des données. Un statut yellow (jaune) signifie que les shards répliques ne sont pas alloués, mais que les shards primaires le sont, donc vos données sont toujours consultables mais pas entièrement redondantes.

Utilisation de l'API d'explication d'allocation (Allocation Explain API)

Pour des informations détaillées sur la raison pour laquelle un shard spécifique n'est pas alloué, l'API _cluster/allocation/explain est inestimable. Vous pouvez fournir des détails sur le shard ou la laisser analyser l'état du cluster.

Pour obtenir une explication pour tout shard non alloué :

GET _cluster/allocation/explain

Pour obtenir une explication pour un shard spécifique (remplacez index_name et shard_id) :

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Causes et Solutions Courantes

Plusieurs facteurs peuvent entraîner la non-allocation des shards. Voici les plus courants et comment y remédier :

1. Espace Disque Insuffisant

C'est sans doute la cause la plus fréquente des échecs d'allocation de shard. Lorsqu'un nœud manque d'espace disque, Elasticsearch empêche de nouveaux shards d'y être alloués pour éviter la corruption des données et assurer la stabilité. Il pourrait également expulser des shards existants.

  • Symptôme : L' Allocation Explain API signalera souvent des messages comme "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" (impossible d'allouer car l'utilisation du disque [X%] dépasse le seuil bas [Y%]) ou "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]" (impossible d'allouer car l'utilisation du disque [X%] dépasse le seuil haut [Y%]).
  • Diagnostic : Vérifiez l'utilisation du disque sur vos nœuds de données. Vous pouvez utiliser l'API _cat/allocation pour un aperçu rapide :
    bash GET _cat/allocation?v
    Recherchez les nœuds avec des pourcentages élevés d'utilisation du disque.
  • Solutions :
    • Ajouter plus d'espace disque : La solution la plus simple est d'ajouter plus de stockage aux nœuds affectés ou de remplacer les disques existants par de plus grands.
    • Supprimer les index inutilisés : Identifiez et supprimez les index anciens ou inutiles qui consomment de l'espace disque.
    • Ajuster les seuils (watermarks) : Vous pouvez ajuster les seuils d'utilisation du disque (cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage) dans votre configuration elasticsearch.yml ou dynamiquement via l'API des paramètres de cluster. Cependant, la prudence est de mise lors de leur ajustement, car ils sont conçus pour protéger votre cluster. Les abaisser sans augmenter la capacité peut entraîner d'autres problèmes.
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • Ajouter plus de nœuds : Faites évoluer votre cluster en ajoutant plus de nœuds de données. Cela répartit les données et réduit la charge sur les nœuds individuels.
    • Forcer la fusion (Force Merge) ou supprimer les données anciennes : Si vous avez des données de séries temporelles, envisagez d'utiliser l'API _forcemerge sur les index plus anciens pour réduire le nombre de segments (ce qui peut libérer de l'espace disque) ou utilisez la gestion du cycle de vie des index (ILM) pour supprimer automatiquement les données anciennes.

2. Nœud Non Disponible ou en Redémarrage

Si un nœud est hors service, en cours de redémarrage ou rencontre des problèmes réseau, tous les shards résidant sur ce nœud deviendront non alloués. S'il s'agit d'un shard primaire, l'état du cluster passera au rouge.

  • Symptôme : L' Allocation Explain API indiquera que le shard ne peut pas être alloué car le nœud n'est pas disponible ou est marqué comme (excluded) (exclu) parce qu'il est hors service.
  • Diagnostic : Utilisez l'API _cat/nodes pour vérifier l'état de vos nœuds. Assurez-vous que tous les nœuds attendus sont répertoriés et sains.
    bash GET _cat/nodes?v
    Vérifiez les journaux Elasticsearch sur le nœud affecté pour détecter toute erreur ou signe d'arrêt.
  • Solutions :
    • Redémarrer le nœud : Si le nœud est hors service, tentez de redémarrer le service Elasticsearch.
    • Résoudre les problèmes réseau : Assurez-vous que le nœud peut communiquer avec d'autres nœuds du cluster.
    • Vérifier les journaux : Examinez les journaux Elasticsearch du nœud spécifique pour identifier la cause première de la défaillance (par exemple, manque de mémoire, erreurs de disque, problèmes JVM).
    • Augmenter index.unassigned.node_left.delayed_timeout : Si les nœuds rejoignent et quittent fréquemment le cluster (par exemple, lors de redémarrages glissants), vous pourriez voir des shards répliques devenir temporairement non alloués. Le paramètre index.unassigned.node_left.delayed_timeout (valeur par défaut : 1 minute) permet à Elasticsearch d'attendre avant de marquer les shards sur un nœud parti comme non alloués, donnant ainsi au nœud le temps de rejoindre le cluster. Augmentez cette valeur si nécessaire, mais soyez conscient de l'impact sur le temps de récupération.

3. Filtrage d'Allocation et Règles de Sensibilisation (Awareness Rules)

Elasticsearch vous permet de contrôler l'endroit où les shards sont alloués à l'aide de diverses règles d'allocation, telles que les attributs de nœud et les anti-affinités. Si ces règles empêchent l'allocation, les shards peuvent devenir non alloués.

  • Symptôme : L' Allocation Explain API signalera que l'allocation est désactivée pour des attributs spécifiques ou qu'aucun nœud approprié n'est disponible selon les règles configurées.
  • Diagnostic :
    • Vérifiez les paramètres de votre index pour index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.*, et index.routing.allocation.total_shards_per_node.
    • Vérifiez les paramètres au niveau du cluster pour cluster.routing.allocation.enable (par exemple, all, primaries, new_primaries, none).
    • Vérifiez les attributs de nœud à l'aide de GET _cat/nodeattrs?v.
  • Solutions :
    • Mettre à jour les paramètres d'index : Supprimez ou ajustez les règles de routage d'index restrictives. Par exemple, pour autoriser l'allocation à n'importe quel nœud :
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • Mettre à jour les paramètres de cluster : Activez temporairement l'allocation si elle était désactivée :
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      N'oubliez pas de rétablir ce paramètre s'il n'était censé être que temporaire.
    • Mettre à jour les attributs de nœud : Assurez-vous que vos nœuds ont les attributs attendus définis dans elasticsearch.yml (par exemple, node.attr.zone: us-east-1) et que ces attributs correspondent à vos règles d'allocation. Après avoir modifié elasticsearch.yml, les nœuds doivent être redémarrés pour que les changements prennent effet.

4. Données de Shard Corrompues (Rare)

Dans de rares cas, les données d'un shard peuvent être corrompues, empêchant Elasticsearch de démarrer ou d'allouer le shard. Cela est plus fréquent en cas de problèmes de disque sous-jacents.

  • Symptôme : Les journaux peuvent afficher des erreurs liées à la lecture des données de shard ou à la corruption d'index. L' Allocation Explain API peut ne pas donner de raison claire ou pointer vers une erreur de lecture.
  • Diagnostic : Examinez attentivement les journaux Elasticsearch sur le nœud où le shard est censé être localisé. Recherchez les erreurs d'E/S ou les messages de corruption de données.
  • Solutions :
    • Restaurer à partir d'une capture (snapshot) : La solution la plus fiable consiste à restaurer l'index affecté (ou l'intégralité du cluster) à partir d'une capture connue et valide. C'est pourquoi des sauvegardes régulières sont essentielles.
    • Forcer la suppression du Shard (Dernier Recours) : Si vous ne pouvez pas restaurer à partir d'une capture et que les données ne sont pas critiques ou peuvent être ré-indexées, vous pourriez avoir besoin de forcer la suppression du shard corrompu. Il s'agit d'une opération avancée qui ne doit être effectuée que lorsque vous comprenez les implications. Vous devez généralement arrêter le nœud affecté, supprimer manuellement le répertoire des données du shard, puis redémarrer le nœud. Cela entraînera une perte de données pour ce shard. Consultez la documentation Elasticsearch pour la procédure exacte correspondant à votre version.

5. Capacité de Relocalisation Insuffisante

Lorsqu'un nœud quitte le cluster ou que des problèmes d'espace disque surviennent, Elasticsearch tente de relocaliser les shards vers d'autres nœuds. S'il n'y a pas assez de nœuds appropriés ou si le cluster est déjà soumis à une forte charge, la relocalisation des shards peut stagner, conduisant à des initializing_shards ou unassigned_shards.

  • Symptôme : Les shards restent à l'état initializing (initialisation) ou relocating (relocalisation) pendant de longues périodes, ou les nouveaux shards ne parviennent pas à être alloués.
  • Diagnostic : Vérifiez _cat/shards et _cat/allocation pour voir les statuts des shards et l'utilisation du disque. Surveillez l'état du cluster et l'utilisation du CPU/IO des nœuds.
  • Solutions :
    • Ajouter plus de nœuds : Augmentez la capacité de votre cluster en ajoutant plus de nœuds de données.
    • Libérer des ressources : Réglez les goulots d'étranglement de performance sur les nœuds existants (par exemple, CPU élevé, E/S disque lentes).
    • Ajuster les paramètres d'allocation de shard : Vous pouvez affiner des paramètres tels que cluster.routing.allocation.node_concurrent_recoveries (nombre de shards pouvant être récupérés simultanément sur un nœud) et cluster.routing.allocation.node_concurrent_incoming_recoveries (nombre de shards pouvant être récupérés simultanément à partir d'un autre nœud). Soyez prudent, car l'augmentation de ces valeurs peut exercer une pression accrue sur le cluster.

Meilleures Pratiques de Prévention

  • Surveiller l'espace disque : Surveillez de manière proactive l'utilisation du disque sur tous les nœuds de données. Configurez des alertes lorsque l'utilisation du disque dépasse des seuils prédéfinis (par exemple, 80 % ou 85 %).
  • Mettre en œuvre la gestion du cycle de vie des index (ILM) : Automatisez la gestion des données de séries temporelles, y compris le roulement, la réduction et la suppression des index anciens. Cela aide à contrôler l'utilisation de l'espace disque.
  • Captures régulières (Snapshots) : Assurez-vous d'avoir une stratégie de sauvegarde robuste avec des captures régulières et automatisées de vos données. Testez périodiquement votre processus de restauration.
  • Comprendre les règles d'allocation : Planifiez et configurez soigneusement les règles d'allocation de shard en fonction de votre matériel, de vos données et de vos exigences de disponibilité.
  • Matériel adéquat : Assurez-vous que vos nœuds disposent de capacités suffisantes en CPU, RAM et I/O pour gérer la charge de travail et les processus de récupération de shard.
  • Surveillance de l'état du cluster : Vérifiez régulièrement l'état de votre cluster à l'aide de l'API _cluster/health et visualisez-le avec des outils comme Stack Monitoring de Kibana.

Conclusion

Les défaillances d'allocation de shard dans Elasticsearch peuvent être un problème intimidant, mais en diagnostiquant systématiquement le problème à l'aide d'outils comme le Cluster Health API et l'Allocation Explain API, et en comprenant les causes courantes telles que l'espace disque, la disponibilité des nœuds et les règles d'allocation, vous pouvez les résoudre efficacement. La surveillance proactive et le respect des meilleures pratiques, telles que les sauvegardes régulières et l'ILM, sont essentiels pour prévenir ces problèmes dès le départ et garantir un cluster Elasticsearch stable et sain.