View a markdown version of this page

Solucione los problemas de arranque y registro de los nodos de procesamiento en AWS PCS - AWS PIEZAS

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 procesamiento en AWS PCS

Cuando los nodos de procesamiento no arrancan o no 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 reemplazan continuamente

Estos errores pueden deberse a problemas durante el lanzamiento de la instancia EC2 o durante el proceso de arranque del nodo de procesamiento del 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 la solución de problemas de lanzamiento de instancias EC2, consulte Solucionar problemas de lanzamiento de instancias de Amazon EC2 en la guía del usuario de Amazon Elastic Compute Cloud.

Los errores de arranque se producen cuando una instancia EC2 se lanza correctamente, pero falla 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 AWS 2 PIEZAS

Podría serte útil comparar el funcionamiento estándar de Slurm con el modo en que funciona Slurm en PCS. AWS

Procesamiento de trabajos estándar de Slurm

En el procesamiento de trabajos estándar de Slurm se llevan a cabo los siguientes pasos:

  1. Cuando envías un trabajo, lo slurmctld valida y lo pone en cola.

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

  3. slurmdlos demonios ejecutan tareas en los nodos asignados.

El procesamiento de trabajos de Slurm está activado AWS PIEZAS

En el procesamiento de trabajos de AWS PCS se realizan los siguientes pasos:

  1. Cuando envía un trabajo, lo slurmctld valida y lo pone en cola.

  2. Cuando se necesita capacidad adicional, AWS PCS usa la plantilla de lanzamiento para el grupo de nodos de procesamiento a fin de lanzar nuevas instancias de EC2.

  3. Las nuevas instancias se inician en el clúster:

    1. Las instancias se registran con 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 recién arrancados).

  5. slurmdlos demonios ejecutan tareas en los nodos asignados.

Recupera los registros de instancias

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

AWS CLI

Recupera la salida de la consola del nodo de procesamiento con el siguiente comando:

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

us-east-1Sustitúyelo 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. Vea el archivo de registro de arranque:

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

Si hay algún problema durante la fase de inicialización, es posible que tengas que esperar aproximadamente 20 minutos antes de poder conectarte a la instancia. Los servicios de administración de sistemas y SSH solo se inician una vez finalizada la inicialización o, en caso de error, cuando se agota el tiempo de espera de la ejecución del arranque.

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

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

Consola de administración de AWS
Para obtener la VPC, la subred y los grupos de seguridad
  1. Abra la consola de Amazon EC2.

  2. Elija Instances.

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

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

  5. En el resumen de la instancia, elige 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 tu 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 procesamiento durante el arranque. El nodo llama al punto final de la API de AWS PCS para registrarse en 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 puede registrarse 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: }

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

No puedo conectarme a AWS Terminales PCS

Si sus nodos de procesamiento están en una subred privada, asegúrese de haber configurado los puntos de enlace de VPC para PCS. AWS Como alternativa, asegúrate de que tu subred tenga una ruta a una puerta de enlace NAT para acceder a Internet. De forma predeterminada, el agente AWS PCS utiliza un punto final de doble pila que no es FIPS. pcs.region.api.aws Si usa un DNS personalizado, asegúrese de que pueda llegar pcs.region.api.aws al punto final. Para obtener más información, consulte los siguientes temas:

Está mal configurada AWS Punto final PCS

Si aparece un mensaje de error similar al siguiente, verifique la política asociada a su punto de conexión de AWS PCS 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. Acceso AWS Parallel Computing Service mediante un punto final de interfaz (AWS PrivateLink)

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

Si tu subred no tiene habilitada la asignación automática de IP públicas y tu configuración de rutas usa una puerta de enlace a Internet, las instancias no se pueden comunicar con la AWS API de 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:

  • Añada un punto final de VPC para AWS PCS a la VPC de su clúster. Esto permite que las instancias se comuniquen con AWS PCS sin necesidad de que una dirección IP pública pase a través de 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.

  • Habilita la asignación automática de direcciones IP públicas a través de tu subred o plantilla de lanzamiento para que las instancias puedan contactar con la API a través de la puerta de enlace de Internet. Tenga en cuenta que esta opción no es válida para instancias de interfaces multired.

Multi-NIC instancia en una subred pública

Debes usar una subred privada si usas un tipo de instancia que tenga varias interfaces de red (NIC).

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

Multi-NIC Los tipos de instancia 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.

El secreto del clúster se ha eliminado o se ha marcado para su eliminación

Si el secreto compartido de Slurm en AWS Secrets Manager se ha eliminado o marcado para su eliminación, los nodos de procesamiento no se registrarán y tu clúster quedará dañado.

AWS Al crear un clúster, PCS crea automáticamente un secreto compartido de Slurm en AWS Secrets Manager (con el formato de nombre:pcs!slurm-secret-<cluster-id>). Este secreto es necesario para proteger las comunicaciones en el clúster. Para obtener más información, consulte Trabajando con secretos de clústeres en AWS PC.

Si este secreto se elimina o se marca para su eliminación, los nuevos nodos no podrán unirse al clúster y es posible que el controlador u otros demonios del clúster (como slurmd yslurmdbd) no puedan volver a unirse al clúster si se reinicia.

Para resolver este problema, puedes restaurar el secreto eliminado si aún se encuentra en la ventana de recuperación. Para obtener instrucciones detalladas, consulta Restaurar un secreto de AWS Secrets Manager.

Si el período de recuperación caduca, el secreto no se puede restaurar y el clúster de AWS PCS afectado no se puede restaurar. Debe crear un clúster nuevo con la misma configuración. AWS PCS crea automáticamente un nuevo secreto del planificador.

Problemas para unirse al clúster de Slurm

Tras registrarse correctamente el nodo, el nodo de procesamiento intenta unirse al clúster de Slurm. El slurmd demonio del nodo contacta con el controlador de 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

Verifique 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 acerca de los requisitos de los grupos de seguridad, consulte los siguientes temas:

importante

El grupo de seguridad del clúster que asociaste 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 controladores NVIDIA

Si la instancia se inicia correctamente, pero los trabajos no se inician y aparecen mensajes de error similares a los siguientes en los registros de instancias, 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 demonio, 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, instala los controladores de NVIDIA en tu AMI personalizada. Para obtener más información, consulte Paso 4: (opcional) Instalar controladores, bibliotecas y software de aplicación adicionales.

ResumeTimeout alcanzado

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

Si la instancia no arranca correctamente y no está registrada en AWS PCS (no hay ninguna RegisterComputeNodeGroupInstance llamada a la instancia EC2), comprueba si hay mensajes de error similares a los siguientes en los registros de la instancia:

/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 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 procesamiento

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

Esto puede deberse a que los grupos de seguridad están mal configurados. 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 incluyan todas las reglas necesarias tal y como se indica en. Requisitos y consideraciones sobre los grupos de seguridad