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](#update-troubleshooting-nodes-fail) + [Solicitud de actualización rechazada con ValidationException](#update-troubleshooting-validation-error) + [El clúster permanece en estado de ACTUALIZACIÓN](#update-troubleshooting-stuck-updating) + [El clúster pasa al estado UPDATE\_FAILED tras la actualización](#update-troubleshooting-update-failed) + [Los nodos de cómputo no se inician debido a errores de análisis de la configuración](#update-troubleshooting-config-parse) + [El clúster no está disponible después de la actualización debido a una configuración de QoS no válida](#update-troubleshooting-qos-bootloop) ## 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](monitoring_scheduler-logs.md) **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 instancias](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs) ### 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](working-with_clusters_version_update.md#version_update-cluster-compatibility) 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](working-with_ami.md) ## 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: + La versión de destino está fuera de la [ventana de compatibilidad](https://slurm.schedmd.com/upgrades.html#compatibility_window) de la versión actual. + La versión de destino se denomina End of Life (EOL) y ya no es un destino de actualización válido. + La versión de destino es anterior o igual a la versión actual (no se admiten las versiones anteriores). ### 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ón`ACTIVE`, 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, consulte[Versiones de Slurm en AWS PIEZAS](slurm-versions.md). ## 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](https://slurm.schedmd.com/upgrades.html#compatibility_window), 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: + Scheduler versión 24.05 o posterior + AWS Agente PCS, versión 1.4.0 o posterior 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, consulte[Amazon Machine Images (AMI) para AWS UNIDADES](working-with_ami.md). Para obtener información sobre las versiones del agente de AWS PCS, consulte[AWS Versiones del agente PCS](pcs-agent-versions.md). ## 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 de`DenyQOS`, `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 `AllowQOS``DenyQOS`, o `QOS` antes de actualizar el clúster.