Pourquoi mon domaine Amazon Elasticsearch Service est-il bloqué à l'état « Traitement » ?

Dernière mise à jour : 08/03/2021

Mon cluster Amazon Elasticsearch Service (Amazon ES) est bloqué à l'état « Traitement ». Pourquoi cela se produit-il et comment l'empêcher ?

Brève description

Votre cluster Amazon ES entre à l'état « Traitement » lorsqu'il se trouve au milieu d'une modification de configuration. Il peut être bloqué à l'état « Traitement » si l'une ou l'autre de ces situations se produit :

  • Un nouvel ensemble de nœuds de données n'a pas pu être lancé.
  • La migration de partition vers le nouvel ensemble de nœuds de données échoue.

Si vous initiez une modification de configuration, l'état du domaine passe à « Traitement » tandis qu'Amazon ES crée un nouvel environnement. Dans le nouvel environnement, Amazon ES lance un nouvel ensemble de nœuds applicables (data, master ou UltraWarm). Une fois la migration terminée, les anciens nœuds sont résiliés.

Résolution

Un nouvel ensemble de nœuds de données n'a pas pu être lancé

Lorsque vous apportez des modifications de configuration simultanées à votre cluster avant la fin de la première modification, cela peut entraîner le blocage de votre cluster. Assurez-vous de vérifier si des déploiements bleu/vert sont en cours dans votre cluster Elasticsearch. Pour vérifier s'il y a des déploiements bleu/vert en cours, vérifiez le nombre total de nœuds dans Amazon CloudWatch. Si vous observez un nombre de nœuds plus élevé que prévu, un déploiement bleu/vert est probablement en cours.

Utilisez l'appel API suivant pour récupérer plus d'informations sur les nœuds supplémentaires et le processus de migration de partition :

GET /_cluster/health?pretty and GET /_cat/recovery?pretty

Si vous utilisez un domaine Amazon Virtual Private Cloud (VPC), vérifiez que vous avez suffisamment d'adresses IP libres dans votre sous-réseau. S'il n'y a pas suffisamment d'adresses IP spécifiées dans votre sous-réseau, le lancement de nouveaux nœuds échoue. En conséquence, votre cluster est bloqué à l'état « Traitement ». Pour plus d'informations, consultez Réservation d'adresses IP dans un sous-réseau VPC.

Si vous disposez d'un domaine Amazon ES chiffré, assurez-vous que votre clé KMS existe dans votre compte AWS avant d'effectuer une modification de configuration. Si vous avez accidentellement supprimé la clé KMS, le cluster peut être bloqué à l'état « Traitement ».

Votre cluster Elasticsearch peut également être bloqué pour les raisons suivantes :

  • Nœud principal avec trop de tâches en attente ou une forte sollicitation du CPU et de la mémoire JVM. Utilisez l'API cat pending tasks pour vérifier les tâches en attente. Vous pouvez également vérifier les métriques MasterCPUUtilization et MasterJVMMemoryPressure dans Amazon CloudWatch.
  • Les conditions préalables d'authentification pour Amazon Cognito for Kibana ne sont pas remplies. Si vous avez configuré Amazon Cognito pour l'authentification Kibana, assurez-vous que vous remplissez les conditions préalables d'authentification. Par exemple, Amazon ES doit avoir le groupe d'utilisateurs, le groupe d'identités Amazon Cognito et le rôle AWS Identity Access Management (IAM) configurés avec les autorisations correctes. Le nom par défaut de ce rôle est CognitoAccessforAmazonES (avec la stratégie AmazonESCognitoAccess attachée).
    Remarque : si vous avez créé un rôle IAM personnalisé, assurez-vous que votre rôle dispose des mêmes autorisations que CognitoAccessforAmazonES.

La migration de partition vers le nouvel ensemble de nœuds de données échoue

Une migration de partition (de l'ancien ensemble vers le nouvel ensemble de nœuds de données) peut échouer pour les raisons suivantes :

  • Votre cluster Elasticsearch est actuellement en état d'intégrité rouge. Si votre cluster est en état d'intégrité rouge, dépannez l'état rouge de votre cluster et ramenez-le à un état normal avant d'apporter une modification de configuration.
  • Les nœuds sont hors service en raison d'une forte charge de traitement causée par la forte sollicitation de la mémoire JVM et l'utilisation élevée du CPU. Pour résoudre ce problème, réduisez votre trafic réseau vers le cluster ou arrêtez entièrement le trafic réseau, ramenant le cluster à un état normal. Sinon, votre processus de déploiement bleu/vert peut expirer, nécessitant une intervention manuelle.
  • En raison de pannes matérielles internes, les partitions des anciens nœuds de données peuvent être bloquées pendant une migration. Si vous rencontrez une panne matérielle interne, remplacez les nœuds du matériel défectueux. La perte de volume racine sur vos nœuds de données peut empêcher Amazon ES de répondre, et un groupe Auto Scaling remplace alors automatiquement les nœuds. Si le volume EBS attaché à un nœud tombe en panne, une intervention manuelle est nécessaire pour remplacer le volume EBS. Pour remplacer le volume EBS, remplacez le nœud entier lui-même. Pour vous aider à identifier les partitions qui fonctionnent encore à partir d'un ensemble de nœuds plus anciens, utilisez les commandes API suivantes : API cat allocation, API cat nodesou API cat shards.
  • Déplacement de partition bloqué causé par un stockage libre insuffisant dans le nouvel ensemble de nœuds. Ce problème se produit lorsqu'il y a de nouvelles données entrant dans le cluster au cours d'un processus de déploiement bleu/vert.
    Remarque : un déploiement bleu/vert n'est pas déclenché si Amazon ES détecte moins d'espace qu'il n'est nécessaire pour une migration de données réussie.
  • Déplacement de partition bloqué causé par des partitions qui sont épinglées à un ensemble de nœuds plus anciens. Pour vous assurer que les partitions ne sont épinglées à aucun nœud avant qu'une modification de la configuration ne soit effectuée, vérifiez le paramètre d'index. Vous pouvez également vérifier si votre cluster présente un bloc d'écriture causé par une forte sollicitation de la mémoire JVM ou un faible espace disque.

Pour identifier les partitions d'index qui sont bloquées et les paramètres d'index correspondants, utilisez les commandes suivantes :

curl -X GET "ENDPOINT/_cluster/allocation/explain?pretty"
curl -X GET "ENDPOINT/INDEX_NAME/_settings?pretty"

Dans les paramètres de votre index, vérifiez si l'un ou l'autre de ces paramètres apparaît :

{
    "index.routing.allocation.require._name": "NODE_NAME" (OR)
    "index.blocks.write": true
    }

Si vous observez "index.routing.allocation.require._name": "NODE_NAME" dans les paramètres de votre index, supprimez le paramètre comme ceci :

curl -X PUT "ENDPOINT/INDEX_NAME/_settings?pretty" H 'Content-Type: application/json' -d '
{
"index.routing.allocation.require._name": null
}'

Pour plus d'informations, consultez Filtrage de l'allocation de partitions au niveau de l'index sur le site web Elasticsearch.

Si vous observez "index.blocks.write": true dans les paramètres de votre index, alors votre cluster a un bloc d'écriture. Le bloc d'écriture est probablement causé par une forte sollicitation de la mémoire JVM ou un faible espace disque. Veillez à résoudre ces problèmes avant d'implémenter d'autres conseils de dépannage. Pour plus d'informations sur le dépannage de cette exception, consultez ClusterBlockException.

Remarque : si votre cluster est bloqué à l'état « Traitement » pendant plus de 24 heures, il nécessite une intervention manuelle. De plus, si vous n'avez apporté aucune modification de configuration mais que le nombre de nœuds est plus élevé que prévu, un correctif logiciel peut être en cours.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?