Solucionar problemas de escala

• /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 por meio do 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 Slurm registro do daemon de controle. AWS ParallelCluster não toma decisões de escalabilidade. Em vez disso, ele apenas tenta lançar recursos para satisfazer o Slurm requisitos. É ú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 EC2 console da Amazon ou AWS CLI para recuperar a saída do console da instância.

• /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 Slurm log do daemon de computação. Use-o para solucionar problemas de inicialização e de falhas de computação.

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 obter 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 ODCR (reservas de capacidade sob demanda). Para obter mais informações, consulte Execute instâncias com reservas de capacidade sob demanda () ODCR.

• 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 obter 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.

• /var/log/cfn-init.log

• /var/log/chef-client.log

• /var/log/parallelcluster/clustermgtd

• /var/log/parallelcluster/slurm_resume.log

• /var/log/slurmctld.log

• 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 um personalizado AMI com modificação no Slurm configuração, então pode haver uma Slurmerro relacionado que impede que o nó de computação se junte ao cluster. Para erros relacionados ao programador, verifique o log /var/log/slurmd.log.

• 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 nunca ResumeProgram foi chamado, você pode verificar o slurmctld log (/var/log/slurmctld.log) para determinar se Slurm já tentei ligar ResumeProgram com o nó).

• Observe que permissões incorretas em ResumeProgram podem fazer com que ResumeProgram falhe silenciosamente. Se você estiver usando um personalizado AMI com modificações na ResumeProgram configuração, verifique se ele ResumeProgram é de propriedade do slurm usuário e tem a permissão 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.

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

• 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 Amazon 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 EC2do usuário da Amazon.

• Logs aplicáveis:

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

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

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

• 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 EC2 relacionado à Amazon, deve haver uma mensagem informativa detalhando o problema EC2 relacionado à Amazon que exigiu a substituição.

• Se o nó clustermgtd não foi encerrado, primeiro verifique se essa era uma rescisão esperada pela AmazonEC2, mais especificamente uma rescisão pontual. computemgtd, executado em um nó de computação, também pode encerrar um nó se clustermgtd for determinado como não íntegro. Verifique no log computemgtd (/var/log/parallelcluster/computemgtd) se computemgtd encerrou o nó.

• 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 na 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 alugar Slurm crie um novo nó.

  • Aguarde o início do nó de computação.

  • Modifique o comportamento de desligamento iniciado pela instância para que um nó de computação com falha seja interrompido em vez de encerrado.

    $ aws ec2 modify-instance-attribute \
        --instance-id i-1234567890abcdef0 \
        --instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"

  • Habilitar a proteção contra encerramento.

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

  • Marque o nó para ser facilmente identificável.

    $ aws ec2 create-tags \
        --resources i-1234567890abcdef0 \
        --tags Key=Name,Value=QUARANTINED-Compute

  • Separe o nó do cluster alterando a parallelcluster:cluster-name tag.

    $ aws ec2 create-tags \
        --resources i-1234567890abcdef0 \
        --tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName

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

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

• 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. Slurm coloca os nós de volta em um POWER_SAVING estado posterior 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.