Solucionar problemas de inicialização e registro de nós de computação no PCS AWS - AWS PCS
Como o Slurm funciona no PCS AWSRecuperar 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á.

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 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:

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.

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

  3. slurmddaemons 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.

  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 os nós (incluindo os recém-inicializados).

  5. slurmddaemons 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-1Substitua 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 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. 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, 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 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 <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 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::<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 PCS.

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:

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/<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 de interface VPC para AWS PCS, consulte. Acesso Serviço de Computação Paralela da AWS 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 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 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.

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:

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.

ResumeTimeoutalcanç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.

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çã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.