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:
-
Registro de nodos: la instancia EC2 invoca la acción de la API de RegisterComputeNodeGroupInstance AWS PCS para registrarse en el servicio de AWS PCS. Se pueden producir errores debido a los siguientes problemas:
-
Permisos
-
Red
-
Secreto del clúster
-
-
Integración con Slurm: la instancia se ejecuta
slurmdy se une al clúster de Slurm. Se pueden producir errores debido a los siguientes problemas:-
Permisos
-
Configuración de AMI personalizada
-
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:
-
Cuando envías un trabajo, lo
slurmctldvalida y lo pone en cola. -
Cuando los recursos están disponibles,
slurmctldasigna los nodos existentes. -
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:
-
Cuando envía un trabajo, lo
slurmctldvalida y lo pone en cola. -
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.
-
Las nuevas instancias se inician en el clúster:
-
Las instancias se registran con AWS PCS.
-
Las instancias se unen al clúster de Slurm.
-
-
Cuando los recursos están listos,
slurmctldasigna los nodos (incluidos los recién arrancados). -
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:
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
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. Si usa un DNS personalizado, asegúrese de que pueda llegar region.api.awspcs. al punto final. Para obtener más información, consulte los siguientes temas:region.api.aws
-
Acceda a un AWS servicio mediante un punto final de VPC de interfaz en la AWS PrivateLink guía de Amazon Virtual Private Cloud.
-
Conecta tu VPC a otras redes en la guía del usuario de Amazon Virtual Private Cloud
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
slurmdcomunicarse conslurmctld -
Puerto 6818 para hacer ping
slurmctldslurmd
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