¿Por qué mi dominio de Amazon OpenSearch Service está bloqueado en el estado “Processing” (Procesando)?

Última actualización: 05-08-2021

Mi clúster de Amazon OpenSearch Service (posterior a Amazon Elasticsearch Service) está atascado en el estado “Processing” (Procesando). ¿A qué se debe y cómo puedo evitarlo?

Descripción breve

El clúster de OpenSearch Service entra en el estado “Procesando” cuando se encuentra en medio de un cambio de configuración. El clúster puede quedar atascado en el estado “Processing” (Procesando) si se produce alguna de las siguientes situaciones:

  • No es posible iniciar un conjunto nuevo de nodos de datos.
  • No es posible completar la migración de partición al nuevo conjunto de nodos de datos.

Si inicia un cambio de configuración, el estado del dominio cambia a “Processing” (Procesando), mientras que OpenSearch Service crea un entorno nuevo. En el nuevo entorno, OpenSearch Service lanza un conjunto nuevo de nodos aplicables (como de datos, maestros o UltraWarm). Una vez que finaliza la migración, concluyen los nodos anteriores.

Resolución

No es posible iniciar un conjunto nuevo de nodos de datos

Cuando se realizan cambios de configuración simultáneos en el clúster antes de que se complete el primer cambio, el clúster puede quedarse atascado. Asegúrese de verificar si hay implementaciones azules/verdes en curso en el clúster. Para comprobar si hay implementaciones azules/verdes en curso, verifique la cantidad total de nodos de Amazon CloudWatch. Si observa un recuento de nodos superior al esperado, es probable que haya una implementación azul/verde en curso.

Utilice la siguiente llamada a la API para obtener más información sobre nodos adicionales y el proceso de migración de partición:

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

Si utiliza un dominio de Amazon Virtual Private Cloud (VPC), verifique que tenga suficientes direcciones IP libres en la subred. Si no hay suficientes direcciones IP especificadas en la subred, se producirá un error en el lanzamiento de nodos nuevos. Como resultado, el clúster se queda atascado en el estado “Processing” (Procesando). Para obtener más información, consulte Reserva de direcciones IP en una subred de una VPC.

Si ha cifrado un dominio de OpenSearch Service, asegúrese de que su clave de AWS KMS se encuentre en su cuenta de AWS antes de realizar un cambio de configuración. Si ha eliminado accidentalmente la clave de AWS KMS, el clúster puede quedarse atascado en el estado “Processing” (Procesando).

El clúster también puede quedarse atascado por los siguientes motivos:

  • Nodo maestro sobrecargado con demasiadas tareas pendientes o niveles elevados de presión de memoria de la CPU y la JVM. Utilice la API de tareas pendientes CAT para verificar si hay tareas pendientes. También puede verificar las métricas MasterCPUUtilization y MasterJVMMemoryPressure en Amazon CloudWatch.
  • No se cumplieron los requisitos previos de autenticación de Amazon Cognito para OpenSearch Dashboards. Si ha configurado la autenticación de Amazon Cognito para OpenSearch Dashboards, asegúrese de que cumple con los requisitos previos de autenticación. Por ejemplo, OpenSearch Service debe tener el grupo de usuarios, el grupo de identidades de Amazon Cognito y el rol AWS Identity Access Management (IAM) configurados con los permisos correctos. El nombre predeterminado de este rol es CognitoAccessForAmazonOpenSearch (con la política de AmazonESCognitoAccess adjunta).
    Nota: Si creó un rol de IAM personalizado, asegúrese de que el rol tenga los mismos permisos que CognitoAccessForAmazonOpenSearch.

No es posible realizar la migración de partición al conjunto nuevo de nodos de datos

La migración de partición (del conjunto antiguo al conjunto nuevo de nodos de datos) podría fallar por los siguientes motivos:

  • Actualmente, el clúster de OpenSearch Service se encuentra en estado rojo. Si el clúster está en estado rojo, solucione los problemas del estado del clúster rojo para que este pase a un estado correcto.
    Nota: Se recomienda configurar el clúster cuando está en buen estado.
  • Los nodos están fuera de servicio debido a una gran carga de procesamiento ocasionada por la alta presión de la memoria de la JVM y el uso de la CPU. Para resolver este problema, reduzca el tráfico de red al clúster o detenga el tráfico de red por completo para que el clúster vuelva a su estado correcto. De lo contrario, el proceso de implementación azul/verde podría agotarse y necesitar que se intervenga de forma manual.
  • Debido a errores internos de hardware, las particiones de los nodos de datos antiguos pueden quedarse atascadas durante una migración. (Nota: Según el problema de hardware, es posible que el clúster no se recupere de forma automática). Si el clúster no se recupera de forma automática, OpenSearch Service ejecutará scripts de recuperación automática para devolver los nodos a un estado correcto. La pérdida del volumen raíz de un nodo puede impedir que OpenSearch Service responda y, luego, un grupo de Auto Scaling reemplace los nodos defectuosos de forma automática. Si el volumen de EBS adjunto de un nodo se cae, la intervención manual es necesaria para reemplazar el volumen de EBS. Para poder identificar qué particiones continúan funcionando desde un conjunto antiguo de nodos, utilice los siguientes comandos de la API: API cat allocation, API cat nodes, API cat shards.
  • Reubicación de partición atascada debido a que el almacenamiento es insuficiente en el conjunto nuevo de nodos. Este problema sucede cuando entran nuevos datos en el clúster durante un proceso de implementación azul/verde.
    Nota: No se activa una implementación azul/verde si OpenSearch Service detecta menos espacio del necesario para realizar una migración de datos correcta.
  • Reubicación de fragmentos atascada debido a las particiones que están ancladas a un conjunto de nodos más antiguo. Para asegurarse de que las particiones no estén ancladas a ningún nodo antes de realizar un cambio de configuración, verifique la configuración del índice. De lo contrario, verifique si el clúster tiene un bloque de escritura ocasionado por una alta presión de memoria de la JVM o porque existe poco espacio disponible en el disco.

Para identificar qué particiones de índice están atascadas y la configuración del índice correspondiente, utilice los siguientes comandos:

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

En la configuración del índice, verifique si se presenta alguna de estas opciones:

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

Si observa “index.routing.allocation.require. _name”: “NODE_NAME” en la configuración del índice, quite la configuración de la siguiente forma:

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

Para obtener más información, consulte Index-level shard allocation filtering (Filtrar asignación de partición de índice) en el sitio web de Elasticsearch.

Si observa “index.blocks.write”: true en la configuración del índice, esto significa que el clúster tiene un bloque de escritura. Es probable que el bloque de escritura se deba a una alta presión de memoria de la JVM o al poco espacio disponible en el disco. Asegúrese de solucionar estos problemas antes de implementar cualquier otra sugerencia de resolución de problemas. Para obtener más información sobre la resolución de problemas de esta excepción, consulte ClusterBlockException.

Nota: Si el clúster está atascado en el estado “Processing” (Procesando) durante más de 24 horas, significa que requiere que se intervenga de forma manual. Además, si no ha realizado ningún cambio en la configuración, pero el recuento de nodos es mayor de lo esperado, es posible que haya un parche de software en curso.


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?