Solucione los problemas de arranque y registro de los nodos de cómputo en PCS AWS - AWS PCS
Cómo funciona Slurm en PCS AWSRecupera los registros de las instanciasRecupera VPC/Subnet/Security grupos de un ID de instanciaProblemas de registro de nodosProblemas de unión al clúster de Slurm

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.

Solucione los problemas de arranque y registro de los nodos de cómputo en PCS AWS

Si los nodos de cómputo no se inician o se registran correctamente en el clúster de AWS PCS, es posible que se presenten los siguientes síntomas:

  • Los trabajos no comienzan

  • No puedes conectarte a instancias en AWS Systems Manager

  • Las instancias se cierran inesperadamente

  • Las instancias se sustituyen continuamente

Estos errores pueden deberse a problemas durante el lanzamiento de la instancia EC2 o durante el proceso de arranque del nodo de cómputo de AWS PCS. En este tema se describen los procedimientos que le ayudarán a solucionar problemas durante el proceso de arranque del nodo AWS PCS. Para obtener más información sobre cómo solucionar problemas de lanzamiento de instancias EC2, consulte Solución de problemas de lanzamiento de instancias de Amazon EC2 en la Guía del usuario de Amazon Elastic Compute Cloud.

Los errores de Bootstrap se producen cuando una instancia EC2 se lanza correctamente, pero se produce un error durante el proceso de unión al clúster de PCS. AWS El proceso de arranque incluye dos fases principales:

Cómo funciona Slurm en PCS AWS

Podría ayudarlo a comparar la forma estándar en que Slurm funciona con la forma en que Slurm funciona en PCS. AWS

Procesamiento de trabajos estándar de Slurm

Los siguientes pasos se producen en el procesamiento de trabajos estándar de Slurm:

  1. Al enviar un trabajo, lo slurmctld valida y lo pone en cola.

  2. Cuando los recursos estén disponibles, slurmctld asigna los nodos existentes.

  3. slurmdlos daemons ejecutan tareas en los nodos asignados.

Procesamiento de tareas de Slurm en PCS AWS

Los siguientes pasos se producen en el procesamiento de trabajos de AWS PCS:

  1. Al enviar un trabajo, lo slurmctld valida y lo pone en cola.

  2. Cuando se necesita capacidad adicional, AWS PCS utiliza la plantilla de lanzamiento del grupo de nodos de cómputo para lanzar nuevas instancias de EC2.

  3. Las nuevas instancias se incorporan al clúster:

    1. Las instancias se registran en AWS PCS.

    2. Las instancias se unen al clúster de Slurm.

  4. Cuando los recursos están listos, slurmctld asigna los nodos (incluidos los que se han iniciado recientemente).

  5. slurmdlos demonios ejecutan tareas en los nodos asignados.

Recupera los registros de las instancias

El primer paso para solucionar los problemas de arranque de los nodos de cómputo es recuperar los registros de las instancias. Puede usar uno de los métodos siguientes:

AWS CLI

Recupera la salida de la consola desde el nodo de cómputo mediante el siguiente comando:

aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text

us-east-1Sustitúyala por tu AWS región y i-1234567890abcdef0 por tu ID de instancia.

AWS Systems Manager

Si puedes conectarte a la instancia mediante Systems Manager, puedes ver el archivo de registro de arranque directamente:

  1. Conéctese a la instancia mediante Systems Manager. Para obtener más información, consulte Iniciar una sesión en la Guía del usuario de Systems Manager.

  2. Consulte el archivo de registro de arranque:

    sudo cat /var/log/amazon/pcs/bootstrap.log
nota

Si se produce un problema durante la fase de inicialización, es posible que tengas que esperar unos 20 minutos antes de poder conectarte a la instancia. Los servicios Systems Manager y SSH se inician solo después de que se complete la inicialización o cuando la ejecución del bootstrap agote el tiempo de espera en caso de fallo.

Recupera VPC/Subnet/Security grupos de un ID de instancia

Para solucionar problemas con los nodos de procesamiento, es posible que tengas que recuperar información sobre la VPC, la subred y los grupos de seguridad asociados a tus instancias. Si no conoces tu instancia IDs, consulta. Búsqueda de instancias de grupos de nodos de cómputo en AWS PCS

Consola de administración de AWS
Para obtener grupos de VPC, subred y seguridad

  1. Abra la consola de Amazon EC2.

  2. Elija Instances.

  3. En la tabla de instancias, elija el ID de la instancia.

  4. Busca el ID de VPC y el ID de subred en el resumen de la instancia que se muestra.

  5. En el resumen de la instancia, selecciona la pestaña Seguridad.

  6. Busca los grupos de seguridad en la pestaña Seguridad.

AWS CLI

Usa el siguiente comando para recuperar la información de la VPC, la subred y el grupo de seguridad de la instancia:

aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table

Problemas de registro de nodos

El registro de nodos es la primera acción que ejecuta un nodo de cómputo durante el arranque. El nodo llama al punto final de la API de AWS PCS para registrarse en el AWS PCS. Los errores de registro suelen mostrar mensajes de error similares a los siguientes:

<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster <clusterId>
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.

Perfil de instancia incorrecto

Si el nodo no se puede registrar debido a un perfil de instancia incorrecto, aparecerá el siguiente error:

<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data:   "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data:   "Message": "User: arn:aws:sts::<accountId>:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data:   "nodeID": null
<13>Nov 13 18:43:08 user-data: }

Compruebe que el perfil de instancia asociado al nodo de cómputo tenga el pcs:RegisterComputeNodeGroupInstance permiso. Para obtener más información sobre cómo crear un perfil de instancia válido, consulteCree un perfil de instancia para AWS PCS.

No se puede conectar a los puntos finales de AWS PCS

Si sus nodos de cómputo están en una subred privada, asegúrese de haber configurado puntos de enlace de VPC AWS para PCS o de que su subred tenga una ruta a una puerta de enlace NAT para el acceso a Internet. Para obtener más información, consulte los siguientes temas:

Punto final de PCS mal configurado AWS

Si aparece un mensaje de error similar al siguiente, compruebe la política asociada a su punto final de AWS VPC:

com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access

Para obtener más información sobre cómo configurar los puntos finales de la interfaz de VPC para AWS PCS, consulte. Acceda AWS Parallel Computing Service mediante un punto final de interfaz ()AWS PrivateLink

Instancia en una subred pública sin IP pública

Si la subred no tiene habilitada la asignación automática de IP pública y la configuración de la ruta usa una puerta de enlace a Internet, las instancias no se pueden comunicar con la API de AWS PCS.

Las instancias de una subred con una puerta de enlace a Internet deben tener una dirección IP pública. Para resolver este problema, elige una de las siguientes opciones:

  • Agregue un punto de enlace de VPC para AWS PCS a la VPC de su clúster. Esto permite que las instancias se comuniquen con el AWS PCS sin necesidad de que una dirección IP pública pase por la puerta de enlace de Internet.

  • Utilice una subred privada con una puerta de enlace NAT, de modo que no sea necesaria una dirección IP pública.

  • Habilite la asignación automática de direcciones IP públicas a través de su subred o plantilla de lanzamiento para que las instancias puedan contactar con la API a través de la puerta de enlace de Internet. Ten en cuenta que esta opción no es válida para instancias de interfaz de varias redes.

Instancia de varias NIC en una subred pública

Debe usar una subred privada si usa un tipo de instancia que tiene varias interfaces de red (). NICs

AWS Las direcciones IP públicas solo se pueden asignar a instancias lanzadas con una única interfaz de red. Para obtener más información sobre las direcciones IP, consulte Asignar una IPv4 dirección pública durante el lanzamiento de una instancia en la Guía del usuario de Amazon EC2 para instancias de Linux.

Los tipos de instancias con varias NIC requieren una puerta de enlace NAT o un proxy interno en la subred para acceder al punto final del AWS PCS. Como alternativa, puede añadir un punto de enlace de VPC para AWS PCS a la VPC de su clúster.

Problemas de unión al clúster de Slurm

Tras el registro correcto del nodo, el nodo de cómputo intenta unirse al clúster de Slurm. El slurmd daemon del nodo contacta con el controlador Slurm para registrarse en el clúster. Los errores de unión a Slurm suelen mostrar mensajes de error similares a los siguientes:

<13>Nov  5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'  
<13>Nov  5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----  
<13>Nov  5 17:20:29 user-data: STDOUT:   
<13>Nov  5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Nov  5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----

Configuración del grupo de seguridad

Compruebe que sus grupos de seguridad estén configurados correctamente para permitir la comunicación entre los nodos de procesamiento y el controlador Slurm. Los grupos de seguridad deben permitir el siguiente tráfico:

  • Puerto 6817 para slurmd comunicarse con slurmctld

  • Puerto 6818 para hacer ping slurmctld slurmd

Para obtener más información sobre los requisitos de los grupos de seguridad, consulte los temas siguientes:

importante

El grupo de seguridad de clúster que asoció al clúster durante la creación del clúster también debe configurarse en los grupos de seguridad del grupo de nodos de procesamiento para permitir que los nodos de procesamiento se comuniquen con el controlador.

Faltan los controladores NVIDIA

Si la instancia se inicia correctamente, pero los trabajos no se inician y ves mensajes de error similares a los siguientes en los registros de la instancia, es posible que te falten los controladores de NVIDIA:

<13>Dec  2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!  
...  
<13>Dec  2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Dec  2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!

Si te conectas a la instancia y compruebas el estado del slurmd daemon, es posible que aparezca un error similar al siguiente:

$ systemctl status slurmd  
...  
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory

Para resolver este problema, instale los controladores NVIDIA en la AMI personalizada. Para obtener más información, consulte Paso 4: (opcional) Instalar controladores, bibliotecas y software de aplicación adicionales.

ResumeTimeoutalcanzado

Si un nodo de procesamiento y su instancia EC2 se cierran porque el nodo está en mal estado, es posible que AWS PCS no admita la AMI o que haya problemas de red. La instancia EC2 se ejecuta durante aproximadamente 30 minutos hasta que se llega a la de Slurm y ResumeTimeout se marca el nodo como. DOWN

Si la instancia no se inicia correctamente y no está registrada en AWS PCS (no RegisterComputeNodeGroupInstance se requiere la instancia EC2), compruebe los registros de la instancia para ver si hay mensajes de error similares a los siguientes:

/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory

Este error indica que el software de arranque del AWS PCS no forma parte de la AMI. Para resolver este problema, asegúrese de que la AMI personalizada incluya el software de arranque de AWS PCS. Para obtener más información, consulte Imágenes personalizadas de Amazon Machine (AMIs) para AWS PCS.

Slurmctld no puede hacer ping al nodo de cómputo

Si la instancia ejecuta correctamente el procedimiento de arranque y está registrada en AWS PCS, pero slurmctld no puede verla ni enviarle trabajos, la instancia se configura DOWN después de un tiempo y, a continuación, se cierra.

Esto puede deberse a una mala configuración de los grupos de seguridad. Por ejemplo, si el puerto 6817 está habilitado slurmd para permitir la comunicación con élslurmctld, pero falta el puerto 6818 para permitir slurmctld el ping. slurmd

Compruebe que sus grupos de seguridad incluyen todas las reglas obligatorias, tal como se indica en. Requisitos y consideraciones sobre los grupos de seguridad