As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solucionar problemas de inicialização e registro de nós de computação no PCS AWS
Quando os nós de computação não conseguem inicializar ou se registrar adequadamente no cluster AWS PCS, você pode enfrentar os seguintes sintomas:
+ Os trabalhos não começam
+ Você não pode se conectar às instâncias no AWS Systems Manager
+ As instâncias foram encerradas inesperadamente
+ As instâncias são substituídas continuamente
Essas falhas podem ser causadas por problemas durante a inicialização da instância EC2 ou durante o processo de inicialização do nó de computação do AWS PCS. Este tópico descreve procedimentos para ajudá-lo a solucionar problemas durante o processo de inicialização do nó AWS PCS. Para obter mais informações sobre como solucionar problemas de inicialização de instâncias do EC2, consulte [Solucionar problemas de inicialização de instâncias do Amazon EC2 no Guia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) do usuário do *Amazon Elastic Compute Cloud*.
Falhas de bootstrap ocorrem quando uma instância do EC2 é iniciada com sucesso, mas falham durante o processo de ingresso no cluster AWS PCS. O processo de bootstrap inclui duas fases principais:
+ **Registro de nós** — A instância do EC2 chama a ação da API [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS para se registrar no serviço AWS PCS. Falhas podem ocorrer devido a problemas no seguinte:
+ Permissões
+ [Perfil de instância errado](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
+ Redes
+ [Não é possível conectar-se aos endpoints AWS PCS](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
+ [Endpoint AWS PCS configurado incorretamente](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
+ [Instância em uma sub-rede pública sem IP público](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
+ [Instância multi-NIC em uma sub-rede pública](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
+ Segredo do cluster
+ [O segredo do cluster foi excluído ou marcado para exclusão](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Integração do Slurm** — A instância é executada `slurmd` e se junta ao cluster do Slurm. Falhas podem ocorrer devido a problemas no seguinte:
+ Permissões
+ [Configuração do security group](#troubleshooting-compute-node-bootstrap-security-groups)
+ [Slurmctld não consegue executar ping no nó de computação](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
+ Configuração personalizada de AMI
+ [Drivers NVIDIA ausentes](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
+ [ResumeTimeout alcançado](#troubleshooting-compute-node-bootstrap-resume-timeout)
## Como o Slurm funciona no PCS AWS
Isso pode ajudá-lo a comparar a forma padrão de funcionamento do Slurm com a forma como o Slurm funciona no PCS. AWS
**Processamento de trabalhos do Standard Slurm**
As etapas a seguir ocorrem no processamento de tarefas padrão do Slurm:
1. Quando você envia um trabalho, `slurmctld` valida e coloca o trabalho em fila.
1. Quando os recursos se tornam disponíveis, `slurmctld` aloca os nós existentes.
1. `slurmd`daemons executam trabalhos em nós alocados.
**Processamento de tarefas do Slurm no PCS AWS**
As etapas a seguir ocorrem no processamento de tarefas do AWS PCS:
1. Quando você envia um trabalho, `slurmctld` valida e coloca o trabalho em fila.
1. **Quando é necessária capacidade adicional, o AWS PCS usa o modelo de execução do grupo de nós de computação para iniciar novas instâncias do EC2.**
1. **Novas instâncias são inicializadas no cluster:**
1. **As instâncias são registradas no AWS PCS.**
1. **As instâncias se juntam ao cluster Slurm.**
1. Quando os recursos estão prontos, `slurmctld` aloca os nós (incluindo os recém-inicializados).
1. `slurmd`daemons executam trabalhos em nós alocados.
## Recuperar registros de instâncias
A primeira etapa para solucionar problemas de bootstrap do nó de computação é recuperar os registros da instância. É possível usar um dos seguintes métodos:
------
#### [ AWS CLI ]
Recupere a saída do console do nó de computação usando o seguinte comando:
```
aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text
```
*us-east-1*Substitua pela sua AWS região e *i-1234567890abcdef0* pelo ID da sua instância.
------
#### [ AWS Systems Manager ]
Se você puder se conectar à instância usando o Systems Manager, poderá visualizar diretamente o arquivo de log do bootstrap:
1. Conecte-se à instância usando o Systems Manager. Para obter mais informações, consulte [Iniciando uma sessão](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) no *Guia do Usuário do Systems Manager*.
1. Veja o arquivo de log do bootstrap:
```
sudo cat /var/log/amazon/pcs/bootstrap.log
```
**nota**
Se houver um problema durante a fase de inicialização, talvez seja necessário esperar aproximadamente 20 minutos antes de se conectar à instância. Os serviços Systems Manager e SSH iniciam somente após a conclusão da inicialização ou quando a execução do bootstrap atinge um tempo limite em caso de falha.
------
## Recuperar VPC/Subnet/Security grupos de um ID de instância
Para solucionar problemas com seus nós de computação, talvez seja necessário recuperar informações sobre a VPC, a sub-rede e os grupos de segurança associados às suas instâncias. Se você não conhece sua instância IDs, consulte[Encontrando instâncias de grupos de nós de computação no AWS PCS](working-with_compute-instances.md).
------
#### [ Console de gerenciamento da AWS ]
**Para obter VPC, sub-rede e grupos de segurança**
1. Abra o [console do Amazon EC2](https://console.aws.amazon.com/ec2).
1. Selecione **Instances (Instâncias)**.
1. Na tabela **Instâncias**, escolha o ID da instância.
1. Encontre o ID da **VPC e o ID** da **sub-rede** no resumo da instância exibido.
1. No resumo da instância, escolha a guia **Segurança**.
1. Encontre os **grupos de segurança** na guia **Segurança**.
------
#### [ AWS CLI ]
Use o comando a seguir para recuperar informações de VPC, sub-rede e grupo de segurança para sua instância:
```
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 nós
O registro do nó é a primeira ação executada por um nó de computação durante o bootstrap. O nó chama o endpoint da API AWS PCS para se registrar no AWS PCS. As falhas de registro geralmente mostram mensagens de erro semelhantes às seguintes:
```
<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
<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 instância errado
Se o nó não conseguir se registrar devido a um perfil de instância incorreto, você verá o seguinte erro:
```
<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:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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: }
```
Verifique se o perfil da instância associado ao nó de computação tem a `pcs:RegisterComputeNodeGroupInstance` permissão. Para obter mais informações sobre como criar um perfil de instância válido, consulte[Crie um perfil de instância para AWS PCS](getting-started_create-cng_instance-profile.md).
### Não é possível conectar-se aos endpoints AWS PCS
Se seus nós de computação estiverem em uma sub-rede privada, verifique se você configurou endpoints VPC para AWS PCS ou se sua sub-rede tem uma rota para um gateway NAT para acesso à Internet. Para saber mais, consulte:
+ [Acesse um AWS serviço usando uma interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) no guia da *Amazon Virtual Private Cloud*. AWS PrivateLink
+ [Endpoints e cotas de serviço para PCS AWS](service-endpoints-quotas.md).
+ [Conecte sua VPC a outras redes](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) no Guia do usuário da *Amazon Virtual Private Cloud*
+ [AWS Rede PCS](working-with_networking.md)
### Endpoint AWS PCS configurado incorretamente
Se você ver uma mensagem de erro semelhante à seguinte, verifique a política associada ao seu endpoint AWS PCS VPC:
```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access
```
Para obter mais informações sobre como configurar endpoints de interface VPC para AWS PCS, consulte. [Acesso Serviço de Computação Paralela da AWS usando um endpoint de interface ()AWS PrivateLink](vpc-interface-endpoints.md)
### Instância em uma sub-rede pública sem IP público
Se sua sub-rede não tiver a **atribuição automática de IP público** habilitada e sua configuração de rota usar um gateway de internet, as instâncias não poderão se comunicar com a API AWS PCS.
As instâncias em uma sub-rede com um gateway de internet devem ter um endereço IP público. Para resolver esse problema, escolha uma das seguintes opções:
+ Adicione um VPC endpoint para AWS PCS ao seu cluster VPC. Isso permite que as instâncias se comuniquem com o AWS PCS sem a necessidade de um endereço IP público passar pelo gateway da Internet.
+ Use uma sub-rede privada com um gateway NAT, para que não seja necessário um endereço IP público.
+ Ative a atribuição automática de endereços IP públicos por meio de sua sub-rede ou modelo de execução para que as instâncias possam entrar em contato com a API por meio do gateway da Internet. Observe que essa opção não é válida para instâncias de interface de várias redes.
### Instância multi-NIC em uma sub-rede pública
Você deve usar uma sub-rede privada se usar um tipo de instância que tenha várias interfaces de rede (NICs).
AWS endereços IP públicos só podem ser atribuídos a instâncias iniciadas com uma única interface de rede. Para obter mais informações sobre endereços IP, consulte [Atribuir um IPv4 endereço público durante a execução da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) no *Guia do usuário do Amazon EC2 para instâncias Linux.*
Os tipos de instância de várias NIC exigem um gateway NAT ou um proxy interno na sub-rede para acessar o AWS endpoint PCS. Como alternativa, você pode adicionar um VPC endpoint para AWS PCS ao seu cluster VPC.
### O segredo do cluster foi excluído ou marcado para exclusão
Se o segredo compartilhado do Slurm no AWS Secrets Manager tiver sido excluído ou marcado para exclusão, os nós de computação não conseguirão se registrar e seu cluster ficará comprometido.
AWS O PCS cria automaticamente um segredo compartilhado do Slurm no AWS Secrets Manager (com formato de nome:`pcs!slurm-secret-`) quando você cria um cluster. Esse segredo é necessário para comunicações seguras no cluster. Para obter mais informações, consulte [Trabalhando com segredos de cluster no AWS PCS](working-with_clusters_secrets.md).
Se esse segredo for excluído ou marcado para exclusão, novos nós não poderão ingressar no cluster e o controlador ou outros daemons do cluster (como `slurmd` e`slurmdbd`) talvez não consigam se juntar novamente ao cluster se forem reiniciados.
Para resolver esse problema, você pode restaurar o segredo excluído se ele ainda estiver dentro da janela de recuperação. Para obter instruções detalhadas, consulte [Restaurar um segredo do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html).
Se a janela de recuperação expirar, o segredo não poderá ser restaurado e o cluster AWS PCS afetado não poderá ser restaurado. Você precisa criar um novo cluster com a mesma configuração. AWS O PCS cria automaticamente um novo segredo do agendador.
## Problemas de junção do cluster Slurm
Após o registro bem-sucedido do nó, o nó de computação tenta se juntar ao cluster Slurm. O `slurmd` daemon no nó entra em contato com o controlador Slurm para se registrar no cluster. As falhas de junção do Slurm geralmente mostram mensagens de erro semelhantes às seguintes:
```
<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"] ----
```
### Configuração do security group
Verifique se seus grupos de segurança estão configurados corretamente para permitir a comunicação entre os nós de computação e o controlador Slurm. Os grupos de segurança devem permitir o seguinte tráfego:
+ Porta 6817 `slurmd` para comunicação com `slurmctld`
+ Porta 6818 para `slurmctld` fazer ping `slurmd`
Para obter mais informações sobre os requisitos do grupo de segurança, consulte os tópicos a seguir:
+ [Crie grupos de segurança para AWS PCS](getting-started_create-sg.md)
+ [Crie modelos de lançamento para AWS PCS](getting-started_create-cng_launch-templates.md)
+ [Requisitos e considerações do grupo de segurança](working-with_networking_sg.md#working-with_networking_sg-requirements)
**Importante**
O grupo de segurança do cluster que você associou ao seu cluster durante a criação do cluster também deve ser configurado nos grupos de segurança do grupo de nós de computação para permitir que os nós de computação se comuniquem com o controlador.
### Drivers NVIDIA ausentes
Se a instância for inicializada corretamente, mas os trabalhos não iniciarem e você ver mensagens de erro semelhantes às seguintes nos registros da instância, talvez você não tenha drivers da 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!
```
Se você se conectar à instância e verificar o status do `slurmd` daemon, poderá ver um erro semelhante ao seguinte:
```
$ systemctl status slurmd
...
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory
```
Para resolver esse problema, instale os drivers NVIDIA em sua AMI personalizada. Para obter mais informações, consulte [Etapa 4 — (Opcional) Instale drivers, bibliotecas e software aplicativo adicionais](working-with_ami_custom_install-software.md).
### ResumeTimeout alcançado
Se um nó de computação e sua instância do EC2 forem encerrados porque o nó não está íntegro, o AWS PCS pode não oferecer suporte à AMI ou pode haver problemas de rede. A instância do EC2 é executada por aproximadamente 30 minutos até que a do Slurm ResumeTimeout seja alcançada e marque o nó como. `DOWN`
Se a instância não inicializar corretamente e não estiver registrada no AWS PCS (nenhuma `RegisterComputeNodeGroupInstance` chamada para a instância EC2), verifique se há mensagens de erro semelhantes às seguintes nos registros da instância:
```
/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory
```
Esse erro indica que o software AWS PCS bootstrap não faz parte da AMI. Para resolver esse problema, certifique-se de que sua AMI personalizada inclua o software AWS PCS bootstrap. Para obter mais informações, consulte [Imagens personalizadas da Amazon Machine (AMIs) para AWS PCS](working-with_ami_custom.md).
### Slurmctld não consegue executar ping no nó de computação
Se a instância executar corretamente o procedimento de bootstrap e estiver registrada no AWS PCS, mas `slurmctld` não conseguir vê-la e enviar trabalhos para ela, a instância será configurada para `DOWN` depois de algum tempo e, em seguida, encerrada.
Isso pode ser causado por grupos de segurança configurados incorretamente. Por exemplo, se a porta 6817 estiver habilitada para permitir `slurmd` a comunicação`slurmctld`, mas a porta 6818 estiver ausente `slurmctld` para permitir o ping. `slurmd`
Verifique se seus grupos de segurança incluem todas as regras necessárias, conforme documentado em[Requisitos e considerações do grupo de segurança](working-with_networking_sg.md#working-with_networking_sg-requirements).