Problèmes d'allocation de shards Elasticsearch : causes et solutions

Les problèmes d'allocation de shards Elasticsearch se manifestent généralement par une santé de cluster jaune ou rouge. Jaune signifie que vos shards primaires sont attribués mais qu'au moins un réplica ne l'est pas. Rouge signifie qu'au moins un shard primaire n'est pas attribué, donc certaines données peuvent être indisponibles jusqu'à ce que vous les récupériez.

Ce guide vous montre comment trouver le bloqueur d'allocation, lire la sortie de l'API Allocation Explain et choisir la correction la moins risquée. L'objectif est de restaurer l'allocation sans aggraver la perte de données.

Comprendre les états des shards et la santé du cluster

Les shards sont l'unité qu'Elasticsearch place sur les nœuds de données. Ils peuvent exister dans plusieurs états :

STARTED : Le shard est actif et répond aux requêtes.
RELOCATING : Le shard se déplace d'un nœud à un autre.
INITIALIZING : Le shard est en cours de création ou de récupération.
UNASSIGNED : Le shard existe dans les métadonnées du cluster mais n'est pas alloué à un nœud.

La santé du cluster suit ces états de shard :

Vert : Tous les shards primaires et réplicas sont alloués.
Jaune : Tous les shards primaires sont alloués, mais un ou plusieurs réplicas ne sont pas attribués.
Rouge : Un ou plusieurs shards primaires ne sont pas attribués. Les recherches peuvent renvoyer des résultats partiels ou échouer pour les index concernés, et les écritures sur ces index peuvent échouer.

Causes courantes des échecs d'allocation de shards

Elasticsearch utilise des décideurs d'allocation avant de placer un shard. Une seule décision NO peut maintenir un shard non attribué.

Seuils de disque

La pression sur le disque est l'une des causes les plus courantes. Elasticsearch utilise des seuils de disque pour éviter de remplir un nœud. Une fois qu'un nœud dépasse le seuil bas ou haut, les décisions d'allocation deviennent plus restrictives. Au stade de saturation, Elasticsearch peut ajouter un blocage en lecture seule aux index concernés pour protéger le nœud contre le manque d'espace disque.

Paramètre	Valeur par défaut courante	Effet
`cluster.routing.allocation.disk.watermark.low`	85%	Évite d'allouer des shards supplémentaires aux nœuds au-dessus de ce seuil.
`cluster.routing.allocation.disk.watermark.high`	90%	Tente de déplacer les shards et évite de placer des shards sur le nœud.
`cluster.routing.allocation.disk.watermark.flood_stage`	95%	Peut bloquer les écritures sur les index concernés.

Confirmez les paramètres réels de votre cluster avant de modifier quoi que ce soit :

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Ensuite, vérifiez l'utilisation du disque des nœuds :

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total,shards

Libérez de l'espace, ajoutez du disque, ajoutez des nœuds de données, supprimez les anciens index ou réduisez la pression des réplicas. Si un blocage de stade de saturation a été défini, supprimez-le uniquement après avoir résolu la pression sur le disque :

PUT /my_index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Rôles des nœuds et filtres d'allocation

Les shards d'index ne s'allouent qu'aux nœuds ayant un rôle de données et des filtres d'allocation correspondants. Si vous utilisez des attributs de nœud pour les niveaux chaud/froid, les racks, les zones ou les types de stockage, une faute de frappe peut bloquer les shards.

Par exemple, un index avec index.routing.allocation.require.box_type: high_io ne s'allouera que sur les nœuds configurés avec node.attr.box_type: high_io.

Vérifiez les filtres d'index et les attributs des nœuds :

GET /my_index/_settings?filter_path=*.settings.index.routing.allocation
GET /_cat/nodeattrs?v
GET /_cat/nodes?v&h=name,roles,disk.used_percent

Corrigez le paramètre d'index ou ajoutez un nœud de données éligible. Ne supprimez pas la sensibilisation à l'allocation à la légère dans les clusters multi-zones ; cela pourrait placer toutes les copies d'un shard dans le même domaine de défaillance.

Shards primaires manquants

Si un shard primaire n'est pas attribué, le nœud qui détenait le primaire actif peut avoir disparu, l'index peut avoir été restauré récemment, ou les règles d'allocation peuvent bloquer tous les nœuds éligibles. Ne supposez pas que les données sont perdues tant que l'API Allocation Explain ne vous a pas dit pourquoi Elasticsearch ne peut pas allouer le shard.

Les scénarios courants incluent :

Un nœud détenant la seule bonne copie primaire a planté.
Les filtres d'allocation excluent tous les nœuds de données pouvant héberger le primaire.
Une restauration de snapshot ou une création d'index attend des nœuds éligibles.
Une copie de shard obsolète existe, mais Elasticsearch ne la promouvra pas sans acceptation explicite de la perte de données.

Essayez d'abord de récupérer le nœud manquant, de restaurer un snapshot ou de corriger le bloqueur d'allocation. Utilisez l'allocation primaire forcée uniquement lorsque vous comprenez quelle copie est obsolète ou lorsque vous avez accepté la perte de données pour ce shard.

Limites de shards

Les limites de shards par nœud peuvent également bloquer l'allocation. Les paramètres courants incluent index.routing.allocation.total_shards_per_node et cluster.routing.allocation.total_shards_per_node.

Vérifiez ces limites :

GET /_cluster/settings?include_defaults=true&filter_path=**.total_shards_per_node
GET /my_index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

Ajoutez des nœuds, réduisez le nombre de réplicas, consolidez les petits index ou augmentez prudemment la limite pertinente. Trop de shards par nœud peut augmenter la pression sur le tas et ralentir les opérations d'état du cluster.

Diagnostic avec l'API Allocation Explain

L'API Allocation Explain est le meilleur outil pour répondre à la question "pourquoi ce shard ne s'alloue-t-il pas ?"

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

Pour laisser Elasticsearch choisir un shard actuellement non attribué, appelez l'API sans corps :

GET /_cluster/allocation/explain?pretty

Lisez d'abord ces champs :

can_allocate : La réponse de haut niveau.
allocate_explanation : Le résumé en langage clair.
node_allocation_decisions : Décisions par nœud.
deciders : La règle exacte qui a renvoyé NO ou THROTTLE.

Une décision NO est le bloqueur. Une décision THROTTLE signifie généralement qu'Elasticsearch peut allouer le shard mais limite le travail de récupération concurrent.

Séquence de dépannage sécurisée

Commencez large, puis affinez.

1. Vérifier la santé du cluster et les shards non attribués

GET /_cluster/health?pretty
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node

Regardez unassigned.reason. Des valeurs telles que NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED ou ALLOCATION_FAILED vous indiquent où chercher ensuite.

2. Vérifier le disque et l'éligibilité des nœuds

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total
GET /_cat/nodes?v&h=name,roles,heap.percent,ram.percent,cpu,disk.used_percent

Si les nœuds sont proches du seuil haut, corrigez la pression sur le disque avant de modifier les paramètres d'allocation.

3. Exécuter Allocation Explain

Utilisez l'index concerné, le numéro de shard et le drapeau primaire/réplica. La sortie doit nommer le paramètre, la condition du nœud ou le décideur qui bloque l'allocation.

4. Éviter les réacheminements risqués tant que vous ne connaissez pas la cause

Les commandes de réacheminement manuel sont destinées à des cas de récupération spécifiques. Ce ne sont pas une solution générale pour la pression sur le disque, les mauvais filtres ou trop de réplicas.

Si une copie primaire obsolète est la seule voie de récupération pratique, la commande ressemble à ceci :

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_stale_copy",
        "accept_data_loss": true
      }
    }
  ]
}

accept_data_loss: true est requis pour une raison. Utilisez-le uniquement après avoir vérifié les snapshots, essayé de récupérer le nœud manquant et confirmé quel nœud détient la copie obsolète.

5. Gérer la santé jaune séparément

Si seuls les réplicas ne sont pas attribués, le cluster peut toujours servir les données primaires. Corrigez d'abord la contrainte de ressource sous-jacente. L'ajout d'un nœud de données, le nettoyage du disque ou la correction des filtres d'allocation permettent généralement à Elasticsearch d'attribuer les réplicas automatiquement.

Si vous devez fonctionner temporairement sans réplicas, réduisez le nombre de réplicas pour l'index concerné :

PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

Cela peut faire passer la santé au vert car Elasticsearch n'attend plus de copies de réplica pour cet index. Cela réduit également la disponibilité, alors remettez les réplicas à la valeur souhaitée après avoir ajouté de la capacité ou corrigé l'allocation.

Prévenir les problèmes d'allocation

Alertez avant que les nœuds ne franchissent le seuil haut de disque.
Gardez suffisamment de nœuds de données disponibles pour votre nombre de réplicas et vos règles de sensibilisation à l'allocation.
Utilisez des nombres de shards adaptés à votre tas, volume de données et objectifs de récupération.
Révisez les modèles d'index pour que les nouveaux index n'héritent pas de mauvais nombres de réplicas ou de filtres d'allocation.
Testez le remplacement de nœud et les étapes de restauration de snapshot avant un incident.

Conclusion

Votre chemin le plus sûr est simple : identifiez le shard non attribué, exécutez Allocation Explain, corrigez le décideur qui dit NO, et évitez l'allocation forcée à moins d'avoir accepté le compromis de perte de données.