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.

Resolución de problemas AWS Actualizaciones de la versión del clúster PCS

Este tema le ayuda a identificar y resolver problemas comunes que se pueden producir al actualizar la versión del programador en un clúster.

Los nodos de cómputo no se conectan después de la actualización

Causa habitual

Tras actualizar el clúster, los nodos de cómputo recién lanzados no se registran en la controladora. Los nodos se inician pero nunca aparecen en la sinfo salida, y es posible que el grupo de nodos de cómputo recorra las instancias repetidamente. Esto ocurre cuando la AMI del grupo de nodos de cómputo contiene una versión del programador que queda fuera de la ventana de compatibilidad de la nueva versión del controlador.

Por ejemplo, si actualizas un clúster de 24.11 a 25.11 pero el grupo de nodos de cómputo sigue usando una AMI con Slurm 23.11, las nuevas instancias no se pueden conectar porque 23.11 está fuera de la ventana de compatibilidad de 25.11.

¿Cómo diagnosticar

Puede confirmar este problema consultando los registros en dos lugares:

Registros del programador

Si tiene activado el registro del planificador, compruebe si hay errores similares a los siguientes en los CloudWatch registros del planificador en los registros:

error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

Estos errores indican que un nodo de cómputo con una versión de programador incompatible está intentando conectarse al controlador. Para obtener información sobre cómo configurar el registro del programador, consulte. El planificador inicia sesión en AWS PCS

Calcule los registros de instancias de nodos

Recupera la salida de la consola de la instancia o conéctate a través de Systems Manager y comprueba el registro de arranque para ver si hay errores similares a los siguientes:

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed

Para obtener más información sobre la recuperación de los registros de instancias, consulte. Recupera los registros de las instancias

Resolución

Actualice el grupo de nodos de cómputo para usar una AMI que contenga una versión del programador dentro de la ventana de compatibilidad de la nueva versión del clúster:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Para determinar qué versiones del programador son compatibles con su clúster, consulte. Compatibilidad de versiones

Para obtener información sobre cómo crear AMI personalizadas con la versión correcta del programador, consulte. Amazon Machine Images (AMI) para AWS UNIDADES

Solicitud de actualización rechazada con ValidationException

Causa habitual

La UpdateCluster solicitud se devuelve inmediatamente con un ValidationException error que indica que la actualización no es compatible. Esto ocurre cuando:

Resolución

Si la versión de destino está fuera de la ventana de compatibilidad, realice la actualización en varios pasos. Cada paso debe dirigirse a una versión compatible dentro de la ventana de compatibilidad. Por ejemplo, para pasar del 23.11 al 25.11, actualice primero a la 25.05, espere a que el clúster vuelva a la 25.11 y, a continuaciónACTIVE, actualice a la 25.11.

Si la versión de destino es EOL, elija en su lugar una versión compatible más reciente. Para obtener información sobre las versiones compatibles, consulteLas versiones de Slurm están disponibles AWS UNIDADES.

El clúster permanece en estado de ACTUALIZACIÓN

Causa habitual

El clúster permanece en UPDATING estado durante más tiempo del esperado (más de 20 minutos). Esto puede ocurrir debido a problemas internos transitorios durante el proceso de actualización.

Resolución

AWS El PCS recupera automáticamente los clústeres que están atascados en UPDATING ese estado. Si el clúster no regresa a los 30 minutos ACTIVE o UPDATE_FAILED en un plazo de 30 minutos, póngase en contacto con AWS Support para obtener ayuda.

El clúster pasa al estado UPDATE_FAILED tras la actualización

Causa habitual

El clúster pasa al UPDATE_FAILED estado durante la actualización. Esto puede ocurrir cuando errores transitorios del servicio impiden que la actualización se complete correctamente.

Resolución

Vuelva a intentar la actualización enviando la misma UpdateCluster solicitud. Los clústeres en UPDATE_FAILED estado aceptan nuevas solicitudes de actualización. Si la actualización sigue fallando, ponte en contacto con AWS Support.

Los nodos de cómputo no se inician debido a errores de análisis de la configuración

Causa habitual

Tras actualizar el clúster, los nodos de cómputo no se inician y nunca aparecen en la sinfo salida. Los registros de instancias del nodo de cómputo muestran errores similares a los siguientes:

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin
error: Invalid DebugFlag: AuditRPCs
fatal: Unable to process configuration file

Esto ocurre cuando los nodos de cómputo que ejecutan la versión 23.11 del programador reciben la configuración de una versión de clúster más reciente. Las versiones del programador posteriores a la 23.11 introdujeron nuevas directivas de configuración que la 23.11 no puede analizar. A diferencia de otras versiones incluidas en la ventana de compatibilidad, los nodos de cómputo de la versión 23.11 no pueden conectarse a un clúster más nuevo porque producen un error grave en claves de configuración no reconocidas.

Este problema también puede producirse si la AMI personalizada utiliza una versión del agente AWS PCS anterior a la v1.4.0. Las versiones anteriores del agente no admiten el respaldo automático de versiones para el daemon de nodos de cómputo.

Resolución

Reconstruya su AMI personalizada con los siguientes requisitos:

A continuación, actualice el grupo de nodos de procesamiento para usar la nueva AMI:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Para obtener información sobre la creación de AMI personalizadas, consulteAmazon Machine Images (AMI) para AWS UNIDADES. Para obtener información sobre las versiones del agente de AWS PCS, consulteAWS Versiones del agente PCS.

El clúster no está disponible después de la actualización debido a una configuración de QoS no válida

Causa habitual

Tras actualizarse a la versión 25.11, el clúster entra en UPDATE_FAILED estado o el programador deja de estar disponible. No puede enviar trabajos ni ejecutar comandos del programador. Los registros del planificador muestran errores similares a los siguientes:

error: Invalid Allow/DenyQOS value: low
fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

Esto ocurre cuando una cola (partición) hace referencia a un nombre de QoS AllowQOS a través deDenyQOS, QOS o a una configuración que no existe en la base de datos de cuentas de Slurm. Slurm 25.11 introdujo una validación más estricta de las referencias de QoS al iniciar el programador. Las versiones anteriores permitían hacer referencias a nombres de QoS inexistentes sin errores.

Resolución

Antes de actualizar a la versión 25.11, compruebe que todos los nombres de QoS a los que se hace referencia en las configuraciones de cola estén en la base de datos de cuentas. Conéctese a un nodo de inicio de sesión y ejecute el siguiente comando para comprobar si existe una QoS:

sacctmgr show qos where name=low format=name

Si la QoS no existe, créela antes de intentar la actualización:

sacctmgr add qos low

Como alternativa, elimine la referencia de QoS de la configuración de la cola actualizando la configuración personalizada de Slurm de la cola para eliminar el parámetro AllowQOSDenyQOS, o QOS antes de actualizar el clúster.