Pourquoi mon domaine Amazon OpenSearch Service est-il bloqué dans l'état « Traitement en cours » ?

Date de la dernière mise à jour : 05/08/2021

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

Brève description

Votre cluster OpenSearch Service passe au statut « Traitement en cours » lorsqu'il fait l'objet d'une modification de configuration. Il peut être bloqué à l'état de « Traitement en cours » si l'une ou l'autre de ces événements suivants 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 en cours » tandis qu'OpenSearch Service crée un nouvel environnement. Dans le nouvel environnement, OpenSearch Service lance un nouvel ensemble de nœuds applicables (notamment, principal 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. Vérifiez s'il y a des déploiements bleu/vert en cours dans votre cluster. Pour vérifier s'il y a des déploiements bleu/vert en cours, examinez 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 disposez de suffisamment d'adresses IP gratuites 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, veuillez consulter la rubrique Réservation d'adresses IP dans un sous-réseau VPC.

Si vous avez chiffré un domaine OpenSearch Service, assurez-vous que votre clé AWS KMS existe dans votre compte AWS avant de modifier la configuration. Si vous avez accidentellement supprimé la clé AWS KMS, le cluster peut rester bloqué dans l'état « Traitement en cours ».

Votre cluster 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 à l'authentification Amazon Cognito pour OpenSearch Dashboards n'ont pas été remplies. Si vous avez configuré l'authentification Amazon Cognito for OpenSearch Dashboards, assurez-vous que vous avez satisfait aux conditions préalables à l'authentification. Par exemple, OpenSearch Service doit disposer du groupe d'utilisateurs, du groupe d'identités Amazon Cognito et d'AWS Identity Access Management (IAM) avec les autorisations adéquates. Le nom par défaut de ce rôle est CognitoAccessForAmazonOpenSearch (avec la politique AmazonESCognitoAccess associée).
    Remarque : si vous avez créé un rôle IAM personnalisé, assurez-vous que votre rôle dispose des mêmes autorisations que CognitoAccessForAmazonOpenSearch.

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 OpenSearch Service est actuellement à l'état rouge. Si votre cluster est au statut rouge, dépannez le problème afin qu'il soit à nouveau sain.
    Remarque : il est recommandé de configurer votre cluster lorsqu'il est dans un état sain.
  • 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. (Remarque : en fonction de votre problème matériel, votre cluster peut également ne pas se rétablir automatiquement.) Si votre cluster ne se rétablit pas automatiquement, OpenSearch Service exécute des scripts d'autoréparation pour rétablir l'état de santé des nœuds. La perte du volume racine d'un nœud peut empêcher OpenSearch Service de répondre, et un groupe Auto Scaling remplace ensuite automatiquement les nœuds défectueux. Si le volume EBS attaché à un nœud tombe en panne, une intervention manuelle est nécessaire pour remplacer le volume EBS. Pour vous aider à identifier les partitions qui fonctionnent encore à partir d'un ensemble de nœuds plus anciens, utilisez les commandes API suivantes : cat allocation API, cat nodes API ou cat shards API.
  • 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 OpenSearch Service détecte moins d'espace que nécessaire à une migration de données réussie.
  • Un déplacement de partition bloqué en raison de l'épinglage d'une partition à 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, veuillez consulter 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, il se peut qu'un correctif logiciel soit en cours.


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


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