Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Intentando actualizar un clúster

En la siguiente sección se proporcionan posibles soluciones a problemas que puedan ocurrir al intentar actualizar un clúster.

El comando pcluster update-cluster no se ejecuta localmente

Consulte el ~/.parallelcluster/pcluster-cli.log en su sistema de archivos local para conocer los detalles del error.

Se agotó el tiempo de espera de la actualización del clúster

Podría deberse a un problema relacionado con la falta de cfn-hup ejecución. Si el daemon de cfn-hup se elimina por una causa externa, no se reinicia automáticamente. Si cfn-hup no se está ejecutando, durante una actualización del clúster, la CloudFormation pila inicia el proceso de actualización según lo previsto, pero el procedimiento de actualización no se activa en el nodo principal y, finalmente, se agota el tiempo de espera para el despliegue de la pila. Para obtener más información, consulte Solución de problemas cuando se agota el tiempo de espera de una actualización del clúster cuando cfn-hup no se está ejecutando para solucionar el problema y recuperarse de él.

ClusterStatus es UPDATE_FAILED

Causa raíz

Para identificar la causa raíz del error, el punto de partida es observar los eventos de la pila de clústeres y /var/log/chef-client.log el nodo principal.

Una posible causa es que al menos un nodo del clúster no aplicó la actualización. Para recuperar la lista de nodos que no se pudieron actualizar /var/log/chef-client.log en el nodo principal, busque Check cluster readiness en el registro.

Comprueba si tu problema aparece en la sección Problemas GitHub conocidos, en la sección AWS ParallelCluster correspondiente GitHub.

Prevenir

La actualización de un clúster puede fallar si al menos un nodo del clúster no la aplicó correctamente. Para reducir el riesgo de que se produzca un error en la actualización del clúster, recomendamos cerrar los nodos dañados antes de iniciar la actualización. Un ejemplo de nodos que podrían romperse son los nodos de cómputo que permanecen inactivos COMPLETING durante más tiempo del esperado en el epílogo. Para detectar esos nodos, puede ejecutar el siguiente comando, adaptando el threshold valor a sus necesidades (el valor debe ser superior a la duración máxima esperada para los epílogos).

$ scontrol show nodes --json | jq -r --argjson threshold 60 '
  .nodes[] | select(.state | index("COMPLETING")) |
  select((now - .last_busy.number) > $threshold) |
  .name
'

¿Recuperando

Si la actualización falló, se espera que la reversión recupere el estado del clúster.

Si la reversión falló, el estado del clúster no es determinista. En este caso, es posible que se haya clustermgtd detenido para evitar la amplificación de las fallas. Recomendamos iniciarlo ejecutando el siguiente comando en el nodo principal. Adapte la versión de Python a la que viene con su AWS ParallelCluster versión:

$ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd

ClusterStatus es UPDATE_FAILED y la nube es UPDATE_ROLLBACK_FAILED FormationStackStatus

Cuando se pcluster describe-cluster informa que eso clusterStatus es UPDATE_FAILED y cloudFormationStackStatus estáUPDATE_ROLLBACK_FAILED, tanto la actualización del clúster como la posterior reversión fallaron. En este estado, la pila de clústeres no puede aceptar más actualizaciones y requiere una intervención manual para desbloquearla.

Para desbloquear la pila de clústeres, complete los siguientes pasos:

La pila de clústeres aparece atascada en UPDATE_IN_PROGRESS o UPDATE_ROLLBACK_IN_PROGRESS

La pila de clústeres podría quedarse atascada UPDATE_ROLLBACK_IN_PROGRESS durante 1 hora como máximo si el Grupo Auto Scaling de los nodos de inicio de sesión no se estabiliza debido a errores de arranque en los nodos de inicio de sesión. UPDATE_IN_PROGRESS

Para comprobar si se encuentra en esta situación debido al Grupo Auto Scaling de los nodos de inicio de sesión, debe realizar las siguientes comprobaciones: En la pila principal, el único recurso que se encuentra es la pila anidada de los nodos de inicio de sesión. UPDATE_IN_PROGRESS En la pila anidada de nodos de inicio de sesión, el único recurso que está atrapado es el Grupo Auto Scaling de los nodos de inicio de sesión. UPDATE_IN_PROGRESS

Si se encuentra en esta situación, puede cancelar la actualización para no tener que esperar 1 hora para que se complete.

$ aws cloudformation cancel-update-stack --region REGION --stack-name CLUSTER_STACK_NAME

Al cancelar la actualización, se activa la reversión. No puedes reducir el tiempo de espera de 1 hora de la reversión, por lo que, en el peor de los casos, tendrás que esperar a que la reversión alcance su estado final.

Si la reversión se realiza correctamente, puede volver a intentar la actualización del clúster original de forma inmediata una vez que haya corregido la causa principal del error. De lo contrario, consulte ClusterStatus es UPDATE_FAILED y la nube es UPDATE_ROLLBACK_FAILED FormationStackStatus.