

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
<a name="troubleshooting-compute-node-bootstrap"></a>

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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) 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:
+ **Registro de nodos**: la instancia EC2 invoca la acción de la API de [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS para registrarse en el servicio AWS PCS. Se pueden producir errores debido a los siguientes problemas:
  + Permisos
    + [Perfil de instancia incorrecto](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
  + Red
    + [No se puede conectar a los puntos finales de AWS PCS](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
    + [Punto final de PCS mal configurado AWS](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
    + [Instancia en una subred pública sin IP pública](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
    + [Instancia de varias NIC en una subred pública](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
  + Secreto del clúster
    + [El secreto del clúster se ha eliminado o marcado para su eliminación](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Integración con Slurm**: la instancia se ejecuta `slurmd` y se une al clúster de Slurm. Se pueden producir errores debido a los siguientes problemas:
  + Permisos
    + [Configuración del grupo de seguridad](#troubleshooting-compute-node-bootstrap-security-groups)
    + [Slurmctld no puede hacer ping al nodo de cómputo](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
  + Configuración de AMI personalizada
    + [Faltan los controladores NVIDIA](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
    + [ResumeTimeout alcanzado](#troubleshooting-compute-node-bootstrap-resume-timeout)

## Cómo funciona Slurm en PCS AWS
<a name="troubleshooting-compute-node-bootstrap-how-slurm-works"></a>

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.

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

1. `slurmd`los 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.

1. **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.**

1. **Las nuevas instancias se incorporan al clúster:**

   1. **Las instancias se registran en AWS PCS.**

   1. **Las instancias se unen al clúster de Slurm.**

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

1. `slurmd`los daemons ejecutan tareas en los nodos asignados.

## Recupera los registros de las instancias
<a name="troubleshooting-compute-node-bootstrap-retrieve-logs"></a>

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-1*Sustitú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](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) en la *Guía del usuario de Systems Manager*.

1. 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
<a name="troubleshooting-compute-node-bootstrap-retrieve-vpc-info"></a>

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](working-with_compute-instances.md)

------
#### [ Consola de administración de AWS ]

**Para obtener grupos de VPC, subred y seguridad**

1. Abra la [consola de Amazon EC2](https://console.aws.amazon.com/ec2).

1. Elija **Instances**.

1. En la tabla de **instancias**, elija el ID de la instancia.

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

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

1. 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
<a name="troubleshooting-compute-node-bootstrap-registration-issues"></a>

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
<a name="troubleshooting-compute-node-bootstrap-wrong-instance-profile"></a>

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, consulte[Crear un perfil de instancia para AWS PCS](getting-started_create-cng_instance-profile.md).

### No se puede conectar a los puntos finales de AWS PCS
<a name="troubleshooting-compute-node-bootstrap-connect-to-endpoints"></a>

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:
+ [Acceda a un AWS servicio mediante un punto final de VPC de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) en la guía *Amazon Virtual Private Cloud AWS PrivateLink*.
+ [Puntos finales y cuotas de servicio para PCS AWS](service-endpoints-quotas.md).
+ [Conecta tu VPC a otras redes](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) en la Guía del usuario de *Amazon Virtual Private Cloud*
+ [AWS Redes PCS](working-with_networking.md)

### Punto final de PCS mal configurado AWS
<a name="troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint"></a>

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](vpc-interface-endpoints.md)

### Instancia en una subred pública sin IP pública
<a name="troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip"></a>

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
<a name="troubleshooting-compute-node-bootstrap-multi-nic-public-subnet"></a>

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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) 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.

### El secreto del clúster se ha eliminado o marcado para su eliminación
<a name="troubleshooting-compute-node-bootstrap-cluster-secret-deleted"></a>

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 el clúster se verá afectado.

AWS PCS crea automáticamente un secreto compartido de Slurm en AWS Secrets Manager (con el formato de nombre:`pcs!slurm-secret-<cluster-id>`) al crear un clúster. Este secreto es necesario para garantizar la seguridad de las comunicaciones en el clúster. Para obtener más información, consulte [Trabajar con secretos de clústeres en AWS PCS](working-with_clusters_secrets.md).

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

Para resolver este problema, puedes restaurar el secreto eliminado si aún se encuentra dentro del período de recuperación. Para obtener instrucciones detalladas, consulte [Restaurar un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html).

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

## Problemas de unión al clúster de Slurm
<a name="troubleshooting-compute-node-bootstrap-slurm-issues"></a>

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
<a name="troubleshooting-compute-node-bootstrap-security-groups"></a>

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:
+ [Crear grupos de seguridad para AWS PCS](getting-started_create-sg.md)
+ [Cree plantillas de lanzamiento para AWS PCS](getting-started_create-cng_launch-templates.md)
+ [Requisitos y consideraciones sobre los grupos de seguridad](working-with_networking_sg.md#working-with_networking_sg-requirements)

**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
<a name="troubleshooting-compute-node-bootstrap-missing-nvidia-drivers"></a>

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](working-with_ami_custom_install-software.md).

### ResumeTimeout alcanzado
<a name="troubleshooting-compute-node-bootstrap-resume-timeout"></a>

Si un nodo de procesamiento y su instancia EC2 se cierran porque el nodo está en mal estado, es posible que el 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](working-with_ami_custom.md).

### Slurmctld no puede hacer ping al nodo de cómputo
<a name="troubleshooting-compute-node-bootstrap-slurmctld-ping-issue"></a>

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 él`slurmctld`, 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](working-with_networking_sg.md#working-with_networking_sg-requirements)