View a markdown version of this page

Solucione problemas de bootstrap e registro do nó de computação em AWS PEÇAS - AWS PEÇAS
Como o Slurm funciona em AWS PEÇASRecupere registros de instânciasRecuperar VPC/Subnet/Security grupos de um ID de instânciaProblemas de registro de nósProblemas de junção do cluster Slurm

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á.

Solucione problemas de bootstrap e registro do nó de computação em AWS PEÇAS

Quando os nós de computação não inicializam ou se registram corretamente em seu cluster AWS PCS, você pode enfrentar os seguintes sintomas:

  • Os empregos não começam

  • Você não pode se conectar a instâncias no AWS Systems Manager

  • Instâncias 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 do usuário do Amazon Elastic Compute Cloud.

As falhas de bootstrap ocorrem quando uma instância do EC2 é iniciada com êxito, mas falha durante o processo de ingresso no cluster AWS PCS. O processo de bootstrap inclui duas fases principais:

Como o Slurm funciona em AWS PEÇAS

Isso pode ajudar você a comparar a forma padrão como o Slurm funciona com a forma como o Slurm funciona no PCS. AWS

Processamento de trabalho padrão do 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.

  2. Quando os recursos se tornam disponíveis, slurmctld aloca os nós existentes.

  3. slurmddaemons executam trabalhos em nós alocados.

Processamento de trabalhos do Slurm em AWS PEÇAS

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.

  2. 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.

  3. Novas instâncias são inicializadas no cluster:

    1. As instâncias são registradas no AWS PCS.

    2. As instâncias se juntam ao cluster Slurm.

  4. Quando os recursos estão prontos, slurmctld aloca nós (incluindo os recém-inicializados).

  5. slurmddaemons executam trabalhos em nós alocados.

Recupere 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-1Substitua pela sua AWS região e i-1234567890abcdef0 pelo seu ID de instância.

AWS Systems Manager

Se você puder se conectar à instância usando o Systems Manager, poderá visualizar diretamente o arquivo de log de bootstrap:

  1. Conecte-se à instância usando o Systems Manager. Para obter mais informações, consulte Iniciando uma sessão no Guia do usuário do Systems Manager.

  2. 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. O Systems Manager e os serviços SSH são iniciados 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 souber seus IDs de instância, consulteEncontrando instâncias de grupos de nós de computação no AWS PCS.

Console de gerenciamento da AWS
Para obter VPC, sub-rede e grupos de segurança

  1. Abra o console do Amazon EC2.

  2. Selecione Instances (Instâncias).

  3. Na tabela Instâncias, escolha o ID da instância.

  4. Encontre o ID da VPC e o ID da sub-rede no resumo da instância exibido.

  5. No resumo da instância, escolha a guia Segurança.

  6. 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 da 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 <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 instância errado

Se o node não conseguir se registrar devido a um perfil de instância errado, 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::<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: }

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, consulteCrie um perfil de instância para AWS PEÇAS.

Não consigo se conectar a AWS Terminais PCS

Se seus nós de computação estiverem em uma sub-rede privada, verifique se você configurou endpoints VPC para PCS. AWS Como alternativa, certifique-se de que sua sub-rede tenha uma rota para um gateway NAT para acesso à Internet. Por padrão, o agente AWS PCS usa o endpoint não FIPS de pilha dupla. pcs.region.api.aws Se você usa DNS personalizado, certifique-se de que ele possa ser resolvido pcs.region.api.aws para o endpoint. Para saber mais, consulte:

Configurado incorretamente AWS Endpoint PCS

Se você receber 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/<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 obter mais informações sobre como configurar endpoints da interface VPC para AWS PCS, consulte. Acesso AWS Parallel Computing Service usando um endpoint de interface (AWS PrivateLink)

Instância em uma sub-rede pública sem IP público

Se sua sub-rede não tiver o IP público de atribuição automática ativado 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 endpoint VPC para AWS PCS à sua VPC de cluster. 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.

Multi-NIC instância 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 endereço IPv4 público durante a execução da instância no Guia do usuário do Amazon EC2 para instâncias Linux.

Multi-NIC os tipos de instância exigem um gateway NAT ou um proxy interno na sub-rede para acessar o endpoint AWS PCS. Como alternativa, você pode adicionar um VPC endpoint para AWS PCS à sua VPC de cluster.

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-<cluster-id>) 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 em AWS PEÇAS.

Se esse segredo for excluído ou marcado para exclusão, novos nós não conseguirão se juntar ao cluster e o controlador ou outros daemons do cluster (como slurmd eslurmdbd) talvez não consigam se unir novamente ao cluster se forem reiniciados.

Para resolver esse problema, você pode restaurar o segredo excluído se ele ainda estiver na janela de recuperação. Para obter instruções detalhadas, consulte Restaurar um segredo do AWS Secrets Manager.

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 para se slurmd comunicar com slurmctld

  • Porta 6818 para dois slurmctld pings slurmd

Para obter mais informações sobre os requisitos do grupo de segurança, consulte os tópicos a seguir:

Importante

O grupo de segurança de cluster que você associou ao 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 forem iniciados e você receber mensagens de erro semelhantes às seguintes nos registros da instância, talvez não haja 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 da NVIDIA em sua AMI personalizada. Para obter mais informações, consulte Etapa 4 — (Opcional) Instale drivers, bibliotecas e software aplicativo adicionais.

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 (sem RegisterComputeNodeGroupInstance chamada para a instância do 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 de bootstrap AWS PCS. Para obter mais informações, consulte Imagens personalizadas da Amazon Machine (AMIs) para AWS PCS.

Slurmctld não consegue fazer 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á definida como DOWN após algum tempo e, em seguida, encerrada.

Isso pode ser causado por grupos de segurança mal configurados. Por exemplo, se a porta 6817 estiver habilitada para permitir slurmd a comunicaçãoslurmctld, 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 emRequisitos e considerações do grupo de segurança.