Solucionar problemas de escala

Esta seção é relevante para clusters que foram instalados usando a AWS ParallelCluster versão 3.0.0 e posterior com o agendador de tarefas do Slurm. Para obter mais informações sobre a configuração múltiplas filas, consulte Configuração de várias filas.

Se um de seus clusters em execução estiver enfrentando problemas, coloque o cluster em um estado STOPPED executando o comando a seguir antes de começar a solucionar o problema. Isso evita incorrer em custos inesperados.

$ pcluster update-compute-fleet --cluster-name mycluster \
   --status STOP_REQUESTED

Você pode listar os fluxos de log disponíveis nos nós do cluster usando o comando pcluster list-cluster-log-streams e filtrando por meio do private-dns-name de um dos nós com falha ou o nó principal:

$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
 --filters 'Name=private-dns-name,Values=ip-10-0-0-101'

Em seguida, você pode recuperar o conteúdo do fluxo de logs para analisá-lo usando o comando pcluster get-cluster-log-events e transmitindo o --log-stream-name correspondente a um dos principais logs mencionados na seção a seguir:

$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init

AWS ParallelCluster cria fluxos de CloudWatch log de cluster em grupos de registros. Você pode visualizar esses registros no CloudWatch console Painéis personalizados ou grupos de registros. Para obter mais informações, consulte Integração com Amazon CloudWatch Logs e Painel do Amazon CloudWatch.

Logs principais para depuração

A tabela a seguir fornece uma visão geral dos principais logs do nó principal:

• /var/log/cfn-init.log- Este é o registro AWS CloudFormation inicial. Ele contém todos os comandos que foram executados quando uma instância foi configurada. Use-o para solucionar problemas de inicialização.

• /var/log/chef-client.log - Este é o log do cliente Chef. Ele contém todos os comandos que foram executados pelo Chef/CINC. Use-o para solucionar problemas de inicialização.

• /var/log/parallelcluster/slurm_resume.log - Isso é um log ResumeProgram. Ele lança instâncias para nós dinâmicos. Use-o para solucionar problemas de inicialização de nós dinâmicos.

• /var/log/parallelcluster/slurm_suspend.log - Esse é o log SuspendProgram. É chamado quando as instâncias são encerradas para nós dinâmicos. Use-o para solucionar problemas de encerramento de nós dinâmicos. Ao verificar esse registro, você também deve verificar o log clustermgtd.

• /var/log/parallelcluster/clustermgtd - Esse é o log clustermgtd. Ele é executado como o daemon centralizado que gerencia a maioria das ações de operação do cluster. Use-o para solucionar qualquer problema de inicialização, encerramento ou operação do cluster.

• /var/log/slurmctld.log- Este é o log do daemon de controle do Slurm. AWS ParallelCluster não toma decisões de escalabilidade. Em vez disso, ele apenas tenta lançar recursos para satisfazer os requisitos do Slurm. É útil para problemas de escalab e alocação, problemas relacionados ao trabalho e quaisquer problemas de lançamento e encerramento relacionados ao programador.

• /var/log/parallelcluster/compute_console_output - Esse log registra a saída do console de um subconjunto de amostra de nós de computação estáticos que foram encerrados inesperadamente. Use esse registro se os nós de computação estáticos terminarem e os registros dos nós de computação não estiverem disponíveis em. CloudWatch O compute_console_output log conteúdo que você recebe é o mesmo quando você usa o console do EC2 ou AWS CLI para recuperar a saída do console da instância.

Estes são os principais logs dos nós de computação:

• /var/log/cloud-init-output.log - Esse é o log cloud-init. Ele contém todos os comandos que foram executados quando uma instância foi configurada. Use-o para solucionar problemas de inicialização.

• /var/log/parallelcluster/computemgtd - Esse é o log computemgtd. Ele é executado em cada nó de computação para monitorar o nó no caso incomum de o daemon clustermgtd no nó principal estar off-line. Use-o para solucionar problemas inesperados de encerramento.

• /var/log/slurmd.log- Este é o log do daemon de computação do Slurm. Use-o para solucionar problemas de inicialização e de falhas de computação.

Ver o erro InsufficientInstanceCapacity no slurm_resume.log quando não consegui executar um trabalho ou em clustermgtd.log quando eu não consigo criar um cluster

Se o cluster usa um programador Slurm, você está enfrentando um problema de capacidade insuficiente. Se não houver instâncias suficientes disponíveis quando a solicitação de inicialização de instância é feita, um erro InsufficientInstanceCapacity será gerado.

Para a capacidade estática da instância, você pode encontrar o erro no log clustermgtd em /var/log/parallelcluster/clustermgtd.

Para a capacidade dinâmica da instância, você pode encontrar o erro no log ResumeProgram em /var/log/parallelcluster/slurm_resume.log.

A mensagem é parecida ao seguinte exemplo:

An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...

Com base no seu caso de uso, considere usar um dos seguintes métodos para evitar receber esses tipos de mensagens de erro:

• Desative o grupo de posicionamento se ele estiver ativado. Para ter mais informações, consulte Grupos de posicionamento e problemas de execução de instâncias.

• Reserve capacidade para as instâncias e inicie-as com o ODCR (On-Demand Capacity Reservations). Para ter mais informações, consulte Iniciar instâncias com ODCR (On-Demand Capacity Reservations).

• Configure diversos recursos computacionais com diferentes tipos de instância. Se sua workload não exigir um tipo de instância específico, você pode aproveitar o failover rápido de capacidade insuficiente com vários recursos computacionais. Para ter mais informações, consulte Failover rápido de capacidade insuficiente do cluster Slurm.

• Configure vários tipos de instância no mesmo recurso computacional e aproveite a alocação de vários tipos de instância. Para obter mais informações sobre como configurar várias instâncias, consulte Alocação a vários tipos de instância com o Slurm e Scheduling / SlurmQueues / ComputeResources / Instances.

• Mova a fila para uma zona de disponibilidade diferente alterando o ID da sub-rede na configuração do cluster Scheduling / SlurmQueues / Networking / SubnetIds.

• Se sua workload não estiver fortemente acoplada, divida a fila em diferentes zonas de disponibilidade. Para obter mais informações sobre como configurar várias sub-redes, consulte Scheduling / SlurmQueues / Networking / SubnetIds.

Solução de problemas de inicialização do nó

Esta seção aborda como você pode solucionar problemas de inicialização do nó. Isso inclui problemas em que o nó falha ao iniciar, ligar ou ingressar em um cluster.

Tópicos

• Nó principal
• Nós de computação

Nó principal

Logs aplicáveis:

• /var/log/cfn-init.log

• /var/log/chef-client.log

• /var/log/parallelcluster/clustermgtd

• /var/log/parallelcluster/slurm_resume.log

• /var/log/slurmctld.log

Verifique os logs /var/log/cfn-init.log e /var/log/chef-client.log ou os fluxos de log correspondentes. Esses logs contêm todas as ações que foram executadas quando o nó principal foi configurado. A maioria dos erros que ocorrem durante a configuração deve ter mensagens de erro localizadas no log /var/log/chef-client.log. Se os scripts OnNodeStart ou OnNodeConfigured forem especificados na configuração do cluster, verifique duas vezes se o script é executado com êxito por meio de mensagens de log.

Quando um cluster é criado, o nó principal precisa esperar que os nós de computação se juntem ao cluster antes que ele possa se juntar ao cluster. Por esse motivo, se os nós de computação não conseguirem se juntar ao cluster, o nó principal também falhará. É possível seguir um desses conjuntos de procedimentos, dependendo do tipo de nós computacionais usados, para solucionar esse tipo de problema:

Nós de computação

• Logs aplicáveis:

  • /var/log/cloud-init-output.log

  • /var/log/slurmd.log

• Se um nó de computação for iniciado, primeiro verifique o /var/log/cloud-init-output.log, que deve conter os logs de configuração semelhantes ao log /var/log/chef-client.log do nó principal. A maioria dos erros que ocorrem durante a configuração deve ter mensagens de erro localizadas no log /var/log/cloud-init-output.log. Se scripts de pré-instalação ou pós-instalação forem especificados na configuração do cluster, verifique se eles foram executados com êxito.

• Se você estiver usando uma AMI personalizada com modificação na configuração Slurm, talvez haja um erro relacionado ao Slurm que impeça o nó de computação de se juntar ao cluster. Para erros relacionados ao programador, verifique o log /var/log/slurmd.log.

Nós de computação dinâmicos:

• Pesquise no log ResumeProgram (/var/log/parallelcluster/slurm_resume.log) o nome do seu nó de computação para ver se alguma vez o ResumeProgram foi chamado com o nó. (Se o ResumeProgram nunca foi chamado, você pode verificar o log slurmctld (/var/log/slurmctld.log) para determinar se o Slurm já tentou chamar ResumeProgram com o nó).

• Observe que permissões incorretas em ResumeProgram podem fazer com que ResumeProgram falhe silenciosamente. Se você estiver usando uma AMI personalizada com modificações na configuração ResumeProgram, verifique se a ResumeProgram é de propriedade do usuário slurm e tem a permissão de 744 (rwxr--r--).

• Se ResumeProgram for chamado, verifique se uma instância foi executada para o nó. Se nenhuma instância foi iniciada, você pode ver uma mensagem de erro que descreve a falha na inicialização.

• Se a instância for executada, é possível que um problema tenha ocorrido durante o processo de configuração. Você deve ver o endereço IP privado e o ID da instância correspondentes no log ResumeProgram. Além disso, você pode ver os logs de configuração correspondentes para a instância específica. Para ter mais informações sobre como solucionar um erro de configuração com um nó de computação, consulte a próxima seção.

Nós de computação estáticos:

• Verifique o log clustermgtd (/var/log/parallelcluster/clustermgtd) para ver se foram iniciadas instâncias para o nó. Se elas não foram iniciadas, deve haver uma mensagem de erro clara detalhando a falha na inicialização.

• Se a instância for iniciada, haverá algum problema durante o processo de configuração. Você deve ver o endereço IP privado e o ID da instância correspondentes no log ResumeProgram. Além disso, você pode ver os logs de configuração correspondentes para a instância específica.

Nós de computação apoiados por instâncias spot:

• Se for a primeira vez que você usa instâncias spot e o trabalho permanece em um PD (estado pendente), verifique novamente o arquivo /var/log/parallelcluster/slurm_resume.log. É provável que você encontre um erro semelhante ao seguinte:

  2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.

  Ao usar instâncias Spot, uma função vinculada ao serviço AWSServiceRoleForEC2Spot deve existir na sua conta. Para criar essa função na sua conta usando o AWS CLI, execute o seguinte comando:

  $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

  Para obter mais informações, consulte Trabalho com Instâncias spot o Guia do AWS ParallelCluster usuário e a função vinculada ao serviço para solicitações de instância spot no Guia do usuário do Amazon EC2.

Solução de problemas inesperados de substituições e encerramentos de nós

Esta seção continua explorando como você pode solucionar problemas relacionados ao nó, especificamente quando um nó é substituído ou encerrado inesperadamente.

• Logs aplicáveis:

  • /var/log/parallelcluster/clustermgtd (nó principal)

  • /var/log/slurmctld.log (nó principal)

  • /var/log/parallelcluster/computemgtd (nó de computação)

Nós substituídos/encerrados inesperadamente

• Verifique no log clustermgtd (/var/log/parallelcluster/clustermgtd) se um clustermgtd substituiu ou encerrou um nó. Observe que clustermgtd trata de todas as ações normais de manutenção do nó.

• Se o clustermgtd substituiu ou encerrou um nó, deverá haver uma mensagem detalhando por que essa ação foi tomada no nó. Se o motivo estiver relacionado com o programador (por exemplo, o nó estiver em DOWN), verifique o log slurmctld para mais informações. Se o motivo for relacionado ao Amazon EC2, deve haver uma mensagem informativa detalhando o problema relacionado ao Amazon EC2 que exigiu a substituição.

• Se o clustermgtd não encerrou o nó, primeiro verifique se esse era um encerramento esperado pelo Amazon EC2, mais especificamente um encerramento pontual. O computemgtd, executado em um nó de computação, também pode encerrar um nó se clustermgtd for determinado como não saudável. Verifique no log computemgtd (/var/log/parallelcluster/computemgtd) se computemgtd encerrou o nó.

Falha nos nós

• Verifique no log slurmctld (/var/log/slurmctld.log) para ver por que um trabalho ou um nó falhou. Observe que os trabalhos são automaticamente enfileirados novamente se um nó falhar.

• Se slurm_resume relatar que o nó foi iniciado e clustermgtd relatar após alguns minutos que não há nenhuma instância correspondente no Amazon EC2 para esse nó, o nó pode falhar durante a configuração. Para recuperar o log de um computador (/var/log/cloud-init-output.log), execute as seguintes etapas:

  • Envie um trabalho para permitir que o Slurm gere um novo nó.

  • Depois que o nó for iniciado, ative a proteção contra encerramento usando esse comando.

    $ aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --disable-api-termination

  • Recupere a saída do console do nó com esse comando.

    $ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text

Substituindo, encerrando ou desligando instâncias e nós problemáticos

• Logs aplicáveis:

  • /var/log/parallelcluster/clustermgtd (nó principal)

  • /var/log/parallelcluster/slurm_suspend.log (nó principal)

• Na maioria dos casos, clustermgtd processa todas as ações esperadas de encerramento da instância. Examine o log clustermgtd para ver por que ele não conseguiu substituir ou encerrar um nó.

• Se os nós dinâmicos falharem no Propriedades do SlurmSettings, consulte o log SuspendProgram para ver se o SuspendProgram foi chamado pelo slurmctldcom o nó específico como argumento. Observe que o SuspendProgram não executa nenhuma ação. Em vez disso, ele só cria logs quando é chamado. Todo encerramento da instância e restauração de NodeAddr são feitos por clustermgtd. O Slurm coloca os nós de volta em um estado POWER_SAVING depois do SuspendTimeout automaticamente.

• Se os nós de computação falharem continuamente devido a falhas de bootstrap, verifique se eles estão sendo iniciados com a opção Modo protegido por cluster do Slurm habilitada. Se o modo protegido não estiver ativado, modifique as configurações do modo protegido para ativar o modo protegido. Solucione problemas e corrija o script de bootstrap.

Status Inactive da fila (partição)

Se você executar sinfo e a saída mostrar filas com status AVAIL de inact, seu cluster pode ter o Modo protegido por cluster do Slurm ativado e a fila foi definida para o estado INACTIVE por um período de tempo predefinido.

Solucionando outros problemas conhecidos de nós e tarefas

Outro tipo de problema conhecido é que AWS ParallelCluster pode falhar na alocação de trabalhos ou na tomada de decisões de escalabilidade. Com esse tipo de problema, o AWS ParallelCluster apenas inicia, encerra ou mantém recursos de acordo com as instruções do Slurm. Para esses problemas, verifique o log slurmctld para solucioná-los.