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 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 Slurm tarefas. Para obter mais informações sobre a configuração múltiplas filas, consulte [Configuração de várias filas](configuration-of-multiple-queues-v3.md).
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`](pcluster.list-cluster-log-streams-v3.md) 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`](pcluster.get-cluster-log-events-v3.md) 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](cloudwatch-logs-v3.md) e [CloudWatch Painel da Amazon](cloudwatch-dashboard-v3.md).
**Topics**
+ [Logs principais para depuração](#troubleshooting-v3-key-logs)
+ [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](#compute-node-initialization-ice-failure-v3-c2)
+ [Solução de problemas de inicialização do nó](#troubleshooting-v3-node-init)
+ [**Solução de problemas inesperados de substituições e encerramentos de nós**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**Substituindo, encerrando ou desligando instâncias e nós problemáticos**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [Status `Inactive` da fila (partição)](#troubleshooting-v3-queues)
+ [Solucionando outros problemas conhecidos de nós e tarefas](#troubleshooting-v3-other-node-job-issues)
## 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 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 Slurm controle. 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 escala e alocação, problemas relacionados ao trabalho e quaisquer problemas de inicialização 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 Amazon 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](https://cloudinit.readthedocs.io/). 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 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 obter mais informações, consulte [Grupos de posicionamento e problemas de execução de instâncias](troubleshooting-v3-placemment-groups.md).
+ Reserve capacidade para as instâncias e inicie-as com o ODCR (On-Demand Capacity Reservations). Para obter mais informações, consulte [Iniciar instâncias com Reservas de Capacidade Sob Demanda (ODCR)](launch-instances-odcr-v3.md).
+ 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](slurm-short-capacity-fail-mode-v3.md).
+ 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](slurm-multiple-instance-allocation-v3.md) e [`Scheduling`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) / [`Instances`](Scheduling-v3.md#yaml-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`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) / [`SubnetIds`](Scheduling-v3.md#yaml-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`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) / [`SubnetIds`](Scheduling-v3.md#yaml-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.
**Topics**
+ [Nó principal](#troubleshooting-v3-node-init.head-node)
+ [Nós de computação](#troubleshooting-v3-node-init.compute-node)
### 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 nunca `ResumeProgram` foi chamado, você pode verificar o `slurmctld` log (`/var/log/slurmctld.log`) para determinar se 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 eles não foram lançados, deve haver uma mensagem de erro clara detalhando a falha no lançamento.
+ 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 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](spot-v3.md) o Guia do AWS ParallelCluster usuário e a [função vinculada ao serviço para solicitações de instância spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) 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 nó `clustermgtd` não foi encerrado, primeiro verifique se esse era um encerramento esperado pelo Amazon EC2, mais especificamente um encerramento 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ó.
**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ó.
+ 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 fácil de identificar.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ Separe o nó do cluster alterando a etiqueta `parallelcluster:cluster-name`.
```
$ 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
```
## **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`](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties), consulte o log `SuspendProgram` para ver se o `SuspendProgram` foi chamado pelo `slurmctld`com 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. Todos encerramentos de instância e redefinições de `NodeAddr` são feitos por `clustermgtd`. O Slurm coloca automaticamente os nós de volta em um estado `POWER_SAVING` depois de `SuspendTimeout`.
+ 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 [Slurm modo protegido por cluster](slurm-protected-mode-v3.md) 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 [Slurm modo protegido por cluster](slurm-protected-mode-v3.md) 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.