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á.
# AWS ParallelCluster solução de problemas
As seções a seguir fornecem dicas de solução de problemas que podem ocorrer ao usar o AWS ParallelCluster. A AWS ParallelCluster comunidade mantém uma página Wiki que fornece muitas dicas de solução de problemas na [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/). Para obter uma lista de problemas conhecidos, consulte [Problemas conhecidos](https://github.com/aws/aws-parallelcluster/wiki#known-issues-).
**Topics**
+ [Tentando criar um cluster](troubleshooting-fc-v3-create-cluster.md)
+ [Tentar executar um trabalho](troubleshooting-fc-v3-run-job.md)
+ [Tentando atualizar um cluster](troubleshooting-fc-v3-update-cluster.md)
+ [Tentar acessar o armazenamento](troubleshooting-fc-v3-access-storage.md)
+ [Tentando excluir um cluster](troubleshooting-fc-v3-delete-cluster.md)
+ [Tentando atualizar a pilha de AWS ParallelCluster APIs](troubleshooting-fc-v3-upgrade-stack-v3.md)
+ [Vendo erros nas inicializações dos nós de computação](troubleshooting-fc-v3-compute-node-initialization-v3.md)
+ [Métricas de integridade do cluster para solução de problemas](troubleshooting-v3-cluster-health-metrics.md)
+ [Solução de problemas de implantação de cluster](troubleshooting-v3-cluster-deployment.md)
+ [Solução de problemas de implantação de cluster usando o Terraform](troubleshooting-v3-terraform.md)
+ [Solucionar problemas de escala](troubleshooting-v3-scaling-issues.md)
+ [Grupos de posicionamento e problemas de execução de instâncias](troubleshooting-v3-placemment-groups.md)
+ [Substituição de diretórios](troubleshooting-v3-dirs-must-keep.md)
+ [Solução de problemas no Amazon DCV](troubleshooting-v3-nice-dcv.md)
+ [Solução de problemas em clusters com AWS Batch integração](troubleshooting-v3-batch.md)
+ [Solução de problemas de integração de vários usuários com o Active Directory](troubleshooting-v3-multi-user.md)
+ [Solução de problemas de AMI personalizada](troubleshooting-v3-custom-amis.md)
+ [Solução de problemas de tempo limite de atualização de cluster quando `cfn-hup` não está em execução](troubleshooting-v3-cluster-update-timeout.md)
+ [Solução de problemas de rede](troubleshooting-v3-networking.md)
+ [Falha na atualização do cluster na ação personalizada `onNodeUpdated`](troubleshooting-v3-on-node-updated.md)
+ [Vendo erros com a configuração personalizada Slurm](troubleshooting-v3-custom-slurm-config.md)
+ [Alarmes do cluster](troubleshooting-v3-cluster-alarms.md)
+ [Resolvendo alterações na configuração do sistema operacional que causam erros ou falhas](resolving-os-configuration-changes.md)
# Tentando criar um cluster
Ao usar a AWS ParallelCluster versão 3.5.0 e posterior para criar um cluster, e a criação de um cluster falhar com `--rollback-on-failure` set to`false`, use o comando [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) CLI para obter informações de status e falha. Nesse caso, o `clusterStatus` esperado da saída `pcluster describe-cluster` é `CREATE_FAILED`. Verifique a seção `failures` na saída para encontrar `failureCode` e `failureReason`. Em seguida, na seção a seguir, encontre `failureCode` correspondente para obter ajuda adicional na solução de problemas. Para obter mais informações, consulte [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md).
Nas seções a seguir, recomendamos que você verifique os registros no nó principal, como os arquivos `/var/log/cfn-init.log` e `/var/log/chef-client.log`. Para obter mais informações sobre AWS ParallelCluster registros e como visualizá-los, consulte [Logs principais para depuração](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) [Recuperando e preservando logs](troubleshooting-v3-get-logs.md) e.
Se você não tiver um`failureCode`, navegue até o CloudFormation console para ver a pilha de clusters. Verifique o `Status Reason` para ver se há `HeadNodeWaitCondition` ou falhas em outros recursos para encontrar detalhes adicionais da falha. Para obter mais informações, consulte [Veja CloudFormation os eventos em `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events). Verifique os arquivos `/var/log/cfn-init.log` e `/var/log/chef-client.log` no nó principal. Se a criação do cluster falhar devido à falha na criação do nó principal e os registros do cluster não estiverem disponíveis no grupo de logs do cluster, você deverá reter o cluster em caso de falha, especificar `--rollback-on-failure` = `True` e recuperar os registros de dentro do próprio nó principal.
## `failureCode` é `OnNodeConfiguredExecutionFailure`
+ **Por que falhou?**
Você forneceu um script personalizado na seção `OnNodeConfigured` do nó principal na configuração para criar um cluster. No entanto, o script personalizado falhou ao ser executado.
+ **Como resolver?**
Verifique o arquivo `/var/log/cfn-init.log` para saber mais sobre a falha e como corrigir o problema em seu script personalizado. Perto do final desse log, você pode ver informações de execução relacionadas ao script `OnNodeConfigured` após a mensagem `Running command runpostinstall`.
## `failureCode` é `OnNodeConfiguredDownloadFailure`
+ **Por que falhou?**
Você forneceu um script personalizado na seção `OnNodeConfigured` do nó principal na configuração para criar um cluster. No entanto, o script personalizado falhou ao ser baixado.
+ **Como resolver?**
Verifique se o URL é válido e se o acesso está configurado corretamente. Para obter mais informações sobre a configuração de scripts de bootstrap personalizados, consulte [Ações de bootstrap personalizadas](custom-bootstrap-actions-v3.md).
Verifique o arquivo `/var/log/cfn-init.log`. Perto do final desse log, você pode ver informações de execução relacionadas ao processamento do script `OnNodeConfigured`, incluindo download, após a mensagem `Running command runpostinstall`.
## `failureCode` é `OnNodeConfiguredFailure`
+ **Por que falhou?**
Você forneceu um script personalizado na seção `OnNodeConfigured` do nó principal na configuração para criar um cluster. No entanto, o uso do script personalizado falhou na implantação do cluster. Uma causa imediata não pode ser determinada e é necessária uma investigação adicional.
+ **Como resolver?**
Verifique o arquivo `/var/log/cfn-init.log`. Perto do final desse log, você pode ver informações de execução relacionadas ao processamento do script `OnNodeConfigured` após a mensagem `Running command runpostinstall`.
## `failureCode` é `OnNodeStartExecutionFailure`
+ **Por que falhou?**
Você forneceu um script personalizado na seção `OnNodeStart` do nó principal na configuração para criar um cluster. No entanto, o script personalizado falhou ao ser executado.
+ **Como resolver?**
Verifique o arquivo `/var/log/cfn-init.log` para saber mais sobre a falha e como corrigir o problema em seu script personalizado. Perto do final desse log, você pode ver informações de execução relacionadas ao script `OnNodeStart` após a mensagem `Running command runpreinstall`.
## `failureCode` é `OnNodeStartDownloadFailure`
+ **Por que falhou?**
Você forneceu um script personalizado na seção `OnNodeStart` do nó principal na configuração para criar um cluster. No entanto, o script personalizado falhou ao ser baixado.
+ **Como resolver?**
Verifique se o URL é válido e se o acesso está configurado corretamente. Para obter mais informações sobre a configuração de scripts de bootstrap personalizados, consulte [Ações de bootstrap personalizadas](custom-bootstrap-actions-v3.md).
Verifique o arquivo `/var/log/cfn-init.log`. Perto do final desse log, você pode ver informações de execução relacionadas ao processamento do script `OnNodeStart`, incluindo download, após a mensagem `Running command runpreinstall`.
## `failureCode` é `OnNodeStartFailure`
+ **Por que falhou?**
Você forneceu um script personalizado no `OnNodeStart` da seção do nó principal na configuração para criar um cluster. No entanto, o uso do script personalizado falhou na implantação do cluster. Uma causa imediata não pode ser determinada e é necessária uma investigação adicional.
+ **Como resolver?**
Verifique o arquivo `/var/log/cfn-init.log`. Perto do final desse log, você pode ver informações de execução relacionadas ao processamento do script `OnNodeStart` após a mensagem `Running command runpreinstall`.
## `failureCode` é `EbsMountFailure`
+ **Por que falhou?**
Falha na montagem do volume do EBS definido na configuração do cluster.
+ **Como resolver?**
Verifique o arquivo `/var/log/chef-client.log` para ver os detalhes da falha.
## `failureCode` é `EfsMountFailure`
+ **Por que falhou?**
Falha na montagem do volume do Amazon EFS definido na configuração do cluster.
+ **Como resolver?**
Se você definiu um sistema de arquivos Amazon EFS existente, certifique-se de que o tráfego seja permitido entre o cluster e o sistema de arquivos. Para obter mais informações, consulte [`SharedStorage`](SharedStorage-v3.md) / [`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings) / [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
Verifique o arquivo `/var/log/chef-client.log` para ver os detalhes da falha.
## `failureCode` é `FsxMountFailure`
+ **Por que falhou?**
Falha na montagem do sistema de FSx arquivos da Amazon definido na configuração do cluster.
+ **Como resolver?**
Se você definiu um sistema de FSx arquivos da Amazon existente, certifique-se de que o tráfego seja permitido entre o cluster e o sistema de arquivos. Para obter mais informações, consulte [`SharedStorage`](SharedStorage-v3.md) / [`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings) / [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
Verifique o arquivo `/var/log/chef-client.log` para ver os detalhes da falha.
## `failureCode` é `RaidMountFailure`
+ **Por que falhou?**
Falha na montagem dos volumes RAID definidos na configuração do cluster.
+ **Como resolver?**
Verifique o arquivo `/var/log/chef-client.log` para ver os detalhes da falha.
## `failureCode` é `AmiVersionMismatch`
+ **Por que falhou?**
A AWS ParallelCluster versão usada para criar a AMI personalizada é diferente da AWS ParallelCluster versão usada para configurar o cluster. No CloudFormation console, visualize os detalhes da CloudFormation pilha de clusters e verifique o `Status Reason` `HeadNodeWaitCondition` para obter detalhes adicionais sobre AWS ParallelCluster as versões e a AMI. Para obter mais informações, consulte [Veja CloudFormation os eventos em `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events).
+ **Como resolver?**
Certifique-se de que a AWS ParallelCluster versão usada para criar a AMI personalizada seja a mesma AWS ParallelCluster usada para configurar o cluster. Você pode alterar a versão personalizada da AMI ou a versão da CLI `pcluster` para torná-las iguais.
## `failureCode` é `InvalidAmi`
+ **Por que falhou?**
A AMI personalizada é inválida porque não foi criada usando o. AWS ParallelCluster
+ **Como resolver?**
Use o comando `pcluster build-image` para criar uma AMI transformando sua AMI na imagem principal. Para obter mais informações, consulte [`pcluster build-image`](pcluster.build-image-v3.md).
## `failureCode` é uma `HeadNodeBootstrapFailure` com `failureReason` Falha na configuração do nó principal.
+ **Por que falhou?**
Uma causa imediata não pode ser determinada e é necessária uma investigação adicional. Por exemplo, pode ser que o cluster esteja em status protegido, e isso pode ser causado por uma falha no provisionamento da frota de computação estática.
+ **Como resolver?**
Verifique o arquivo `/var/log/chef-client.log.` para ver os detalhes da falha.
**nota**
Se você vir `RuntimeError` com uma exceção`Cluster state has been set to PROTECTED mode due to failures detected in static node provisioning`, o cluster está no status protegido. Para obter mais informações, consulte [Como depurar o modo protegido](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3).
## `failureCode` é uma `HeadNodeBootstrapFailure` com `failureReason` de tempo limite de criação do cluster.
+ **Por que falhou?**
Por padrão, há um limite de tempo de 30 minutos para a conclusão da criação do cluster. Se a criação do cluster não for concluída dentro desse período, a criação do cluster falhará com um erro de tempo limite. A criação do cluster pode atingir o tempo limite por diferentes motivos. Por exemplo, falhas de tempo limite podem ser causadas por uma falha na criação do nó principal, um problema de rede, scripts personalizados que demoram muito para serem executados no nó principal, um erro em um script personalizado executado nos nós de computação ou longos tempos de espera para o provisionamento do nó de computação. Uma causa imediata não pode ser determinada e é necessária uma investigação adicional.
+ **Como resolver?**
Verifique os arquivos `/var/log/cfn-init.log` e `/var/log/chef-client.log` para ver os detalhes da falha. Para obter mais informações sobre logs AWS ParallelCluster e como obtê-los, consulte [Logs principais para depuração](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) e [Recuperando e preservando logs](troubleshooting-v3-get-logs.md).
Você pode descobrir o seguinte nesses logs.
+ **Vendo `Waiting for static fleet capacity provisioning` perto do final do `chef-client.log`**
Isso indica que a criação do cluster atingiu o tempo limite ao aguardar a inicialização dos nós estáticos. Para obter mais informações, consulte [Vendo erros nas inicializações dos nós de computação](troubleshooting-fc-v3-compute-node-initialization-v3.md).
+ **A visualização do script do nó principal `OnNodeConfigured` ou `OnNodeStart` não foi concluído no final do `cfn-init.log`**
Isso indica que o script personalizado `OnNodeConfigured` ou o `OnNodeStart` demorou muito para ser executado e causou um erro de tempo limite. Verifique se há problemas no script personalizado que podem fazer com que ele seja executado por um longo tempo. Se o script personalizado exigir muito tempo para ser executado, considere alterar o limite de tempo limite adicionando uma seção `DevSettings` ao arquivo de configuração do cluster, conforme mostrado no exemplo a seguir:
```
DevSettings:
Timeouts:
HeadNodeBootstrapTimeout: 1800 # default setting: 1800 seconds
```
+ **Não consigo encontrar os logs ou o nó principal não foi criado com sucesso**
É possível que o nó principal não tenha sido criado com sucesso e que os logs não possam ser encontrados. Nesse caso, você pode obter detalhes adicionais da falha verificando os eventos da CloudFormation pilha e o registro do console do nó principal. Você pode recuperar o log do console do nó principal por meio do console do Amazon EC2 ou executando o seguinte comando da CLI do Amazon EC2:
```
aws ec2 get-console-output --instance-id HEAD_NODE_INSTANCE_ID --output text
```
## `failureCode` é uma `HeadNodeBootstrapFailure` com `failureReason` de Falha no bootstrap do nó principal.
+ **Por que falhou?**
Uma causa imediata não pode ser determinada e é necessária uma investigação adicional.
+ **Como resolver?**
Verifique os arquivos `/var/log/cfn-init.log` e `/var/log/chef-client.log`.
## `failureCode` é `ResourceCreationFailure`
+ **Por que falhou?**
A criação de alguns recursos falhou durante o processo de criação do cluster. A falha pode ocorrer por vários motivos. Por exemplo, falhas na criação de recursos podem ser causadas por problemas de capacidade ou por uma política de IAM mal configurada.
+ **Como resolver?**
No CloudFormation console, visualize a pilha do cluster para verificar detalhes adicionais da falha na criação de recursos.
## `failureCode` é `ClusterCreationFailure`
+ **Por que falhou?**
Uma causa imediata não pode ser determinada e é necessária uma investigação adicional.
+ **Como resolver?**
No CloudFormation console, visualize a pilha do cluster e verifique a `Status Reason` `HeadNodeWaitCondition` para encontrar detalhes adicionais da falha.
Verifique os arquivos `/var/log/cfn-init.log` e `/var/log/chef-client.log`.
## Vendo `WaitCondition timed out...` na CloudFormation pilha
Para obter mais informações, consulte [`failureCode` é uma `HeadNodeBootstrapFailure` com `failureReason` de tempo limite de criação do cluster.](#create-cluster-head-node-bootstrap-timeout-failure-v3).
## Vendo `Resource creation cancelled` na CloudFormation pilha
Para obter mais informações, consulte [`failureCode` é `ResourceCreationFailure`](#create-cluster-resource-creation-failure-v3).
## `Failed to run cfn-init...`Visualização ou outros erros na CloudFormation pilha
Verifique `/var/log/cfn-init.log` e `/var/log/chef-client.log` para ver os detalhes adicionais da falha.
## Visualizando `chef-client.log` que termina com `INFO: Waiting for static fleet capacity provisioning`
Isso está relacionado ao tempo limite de criação do cluster ao aguardar a inicialização dos nós estáticos. Para obter mais informações, consulte [Vendo erros nas inicializações dos nós de computação](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Vendo `Failed to run preinstall or postinstall in cfn-init.log`
Você tem um script `OnNodeConfigured` ou `OnNodeStart` na seção `HeadNode` de configuração do cluster. O script não está funcionando corretamente. Verifique o arquivo `/var/log/cfn-init.log` para ver os detalhes do erro do script personalizado.
## Vendo `This AMI was created with xxx, but is trying to be used with xxx...` na CloudFormation pilha
Para obter mais informações, consulte [`failureCode` é `AmiVersionMismatch`](#create-cluster-ami-version-mismatch-v3).
## Vendo `This AMI was not baked by AWS ParallelCluster...` na CloudFormation pilha
Para obter mais informações, consulte [`failureCode` é `InvalidAmi`](#create-cluster-invalid-ami-v3).
## Vendo que o comando `pcluster create-cluster` falha ao ser executado localmente
Verifique o `~/.parallelcluster/pcluster-cli.log` em seu sistema de arquivos local para ver os detalhes da falha.
## Suporte adicional
Siga as orientações de solução de problemas em [Solução de problemas de implantação de cluster](troubleshooting-v3-cluster-deployment.md).
Verifique se seu cenário está abordado em [Problemas GitHub conhecidos](https://github.com/aws/aws-parallelcluster/wiki) em AWS ParallelCluster on GitHub.
# Tentar executar um trabalho
A seção a seguir fornece possíveis soluções caso você tenha problemas ao tentar executar um trabalho.
## O trabalho interativo do `srun` falha com erro `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **Por que falhou?**
Você executou o comando `srun` para enviar um trabalho e, em seguida, aumentou o tamanho de uma fila usando o comando `pcluster update-cluster`, sem reiniciar os daemons Slurm após a conclusão da atualização.
O Slurm organiza os daemons Slurm em uma hierarquia de árvores para otimizar a comunicação. Essa hierarquia só é atualizada quando os daemons são iniciados.
Suponha que você use `srun` para iniciar um trabalho e, em seguida, executar o comando `pcluster update-cluster` para aumentar o tamanho da fila. Novos nós de computação são lançados como parte da atualização. Em seguida, o Slurm enfileira seu trabalho em um dos novos nós de computação. Nesse caso, tanto os daemons Slurm quanto o `srun` não detectam os novos nós de computação. O `srun` retorna um erro porque não detecta os novos nós.
+ **Como resolver?**
Reinicie os daemons Slurm em todos os nós de computação e use `srun` para enviar seu trabalho. Você pode programar a reinicialização dos daemons Slurm executando o comando `scontrol reboot` que reinicia os nós de computação. Para obter mais informações, consulte [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot) na documentação do Slurm. Você também pode reiniciar manualmente os daemons Slurm nos nós de computação solicitando a reinicialização dos serviços `systemd` correspondentes.
## Trabalho está preso no estado `CF` com o comando `squeue`
Isso pode ser um problema com a inicialização dos nós dinâmicos. Para obter mais informações, consulte [Vendo erros nas inicializações dos nós de computação](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Executando trabalhos em grande escala e vendo `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Com um sistema de arquivos em rede, quando os limites da rede são atingidos, o tempo de I/O espera também aumenta. Isso pode resultar em travamentos leves porque a rede é usada para gravar dados tanto para redes quanto para I/O métricas.
Com instâncias de 5ª geração, usamos o driver ENA para expor os contadores de pacotes. Esses contadores contam os pacotes formados pelo AWS momento em que a rede atinge os limites de largura de banda da instância. Você pode verificar esses contadores para ver se eles são maiores que 0. Se estiverem, você excedeu seus limites de largura de banda. Você pode ver esses contadores executando `ethtool -S eth0 | grep exceeded`.
Exceder os limites da rede geralmente é resultado do suporte a muitas conexões NFS. Essa é uma das primeiras coisas a verificar quando você atinge ou excede os limites da rede.
Por exemplo, a saída a seguir mostra pacotes descartados:
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
Para evitar receber essa mensagem, considere alterar o tipo de instância do nó principal para um tipo de instância com melhor desempenho. Considere transferir seu armazenamento de dados para sistemas de arquivos de armazenamento compartilhado que não são exportados como um compartilhamento NFS, como Amazon EFS ou Amazon. FSx Para obter mais informações, consulte [Armazenamento compartilhado](shared-storage-quotas-integration-v3.md) e as [melhores práticas](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) no AWS ParallelCluster Wiki em GitHub.
## Executando um trabalho de MPI
### Habilitar o modo de depuração
Para ativar o modo de depuração do OpenMPI, consulte [What controls does Open MPI have that aid in debugging (Quais controles o Open MPI tem que auxiliam na depuração)](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls).
Para ativar o modo de depuração do IntelMPI, consulte [Other Environment Variables (Outras variáveis de ambiente)](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html).
### Visualizando `MPI_ERRORS_ARE_FATAL` e `OPAL ERROR` na saída do trabalho
Esses códigos de erro vêm da camada MPI em seu aplicativo. Para saber como obter logs de depuração do MPI do seu aplicativo, consulte [Habilitar o modo de depuração](#run-job-mpi-enable-v3).
Uma possível causa desse erro é que seu aplicativo foi compilado para uma implementação de MPI específica, como o OpenMPI, e você está tentando executá-lo com uma implementação de MPI diferente, como o IntelMPI. Verifique se você está compilando e executando seu aplicativo com a mesma implementação de MPI.
### Usando `mpirun` com o DNS gerenciado desativado
Para clusters criados com [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)e [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) definidos como`true`, o nome do Slurm nó não é resolvido pelo DNS. Slurmpodem inicializar processos MPI quando `nodenames` não estão habilitados e se a tarefa MPI for executada em um contexto. Slurm Recomendamos seguir as orientações do [Guia do Usuário de MPI do Slurm](https://slurm.schedmd.com/mpi_guide.html) para executar trabalhos do MPI com Slurm.
# Tentando atualizar um cluster
A seção a seguir fornece possíveis soluções para problemas que podem ocorrer enquanto você tenta atualizar um cluster.
## O comando `pcluster update-cluster` falha ao ser executado localmente
Verifique o `~/.parallelcluster/pcluster-cli.log` em seu sistema de arquivos local para ver os detalhes da falha.
## Ver `clusterStatus` é `UPDATE_FAILED` com comando `pcluster describe-cluster`
### Causa raiz
Para identificar a causa raiz da falha, o ponto de partida é examinar os eventos da pilha do cluster e o `/var/log/chef-client.log` nó principal.
Uma possível causa é que pelo menos um nó do cluster não aplicou a atualização. Você pode recuperar a lista de nós que falharam na atualização `/var/log/chef-client.log` no nó principal procurando `Check cluster readiness` no registro.
Verifique se seu problema foi mencionado em [Problemas GitHub conhecidos](https://github.com/aws/aws-parallelcluster/wiki) em AWS ParallelCluster em GitHub.
### Prevenindo
Uma atualização de cluster pode falhar se pelo menos um nó no cluster não aplicar a atualização com êxito. Para reduzir o risco de falha na atualização do cluster, recomendamos encerrar os nós quebrados antes de iniciar a atualização. Um exemplo de nós que podem ser quebrados são os nós de computação presos no `COMPLETING` estado por mais tempo do que a duração esperada do epílogo. Para detectar esses nós, você pode executar o comando a seguir, adaptando o `threshold` valor às suas necessidades (o valor deve ser maior do que a duração máxima esperada para seus epílogos).
```
$ scontrol show nodes --json | jq -r --argjson threshold 60 '
.nodes[] | select(.state | index("COMPLETING")) |
select((now - .last_busy.number) > $threshold) |
.name
'
```
### Se recuperando
Se a atualização falhar, a reversão é o mecanismo esperado para recuperar o estado do cluster.
Se a reversão falhar, o estado do cluster não é determinístico. Nesse caso, pode ser que tenha `clustermgtd` sido interrompido para evitar a amplificação de falhas. Recomendamos iniciá-lo executando o seguinte comando no nó principal. Adapte a versão do Python à que vem com sua versão: AWS ParallelCluster
```
$ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
```
## A atualização do cluster atingiu o tempo limite
Isso pode ser um problema relacionado ao `cfn-hup` não sendo executado. Se o daemon `cfn-hup` for encerrado por uma causa externa, ele não será reiniciado automaticamente. Se `cfn-hup` não estiver em execução, durante uma atualização do cluster, a CloudFormation pilha inicia o processo de atualização conforme o esperado, mas o procedimento de atualização não é ativado no nó principal e a implantação da pilha eventualmente expira. Para obter mais informações, consulte [Solução de problemas de tempo limite de atualização de cluster quando `cfn-hup` não está em execução](troubleshooting-v3-cluster-update-timeout.md) para solucionar o problema e corrigir o problema.
# Tentar acessar o armazenamento
Saiba mais sobre dicas de solução de problemas para tentar acessar o armazenamento.
## Usando um sistema de arquivos externo Amazon FSx for Lustre
Certifique-se de que o tráfego seja permitido entre o cluster e o sistema de arquivos. Se estiver usando um sistema de arquivos existente, ele deve ser associado a um grupo de segurança que permite o tráfego de entrada e saída do TCP pelas portas 988, 1021, 1022, e 1023. Para obter mais informações sobre como configurar grupos de segurança, consulte [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
## Usar um sistema de arquivos externo do Amazon Elastic File System
Certifique-se de que o tráfego seja permitido entre o cluster e o sistema de arquivos. Se estiver usando um sistema de arquivos existente, ele deve ser associado a um grupo de segurança que permite o tráfego de entrada e saída do TCP pelas portas 988, 1021, 1022, e 1023. Para obter mais informações sobre como configurar grupos de segurança, consulte [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
# Tentando excluir um cluster
Se você receber um erro ao tentar excluir um cluster, as seções a seguir fornecem dicas de solução de problemas para os cenários comuns.
## O comando `pcluster delete-cluster` falha ao ser executado localmente
Verifique o arquivo `~/.parallelcluster/pcluster-cli.log` em seu sistema de arquivos local.
## A pilha de clusters não consegue ser excluída
Se a pilha do cluster não for excluída, verifique a mensagem de eventos da CloudFormation pilha.
Verifique se seu problema está mencionado em [Problemas GitHub conhecidos](https://github.com/aws/aws-parallelcluster/wiki) em AWS ParallelCluster on GitHub.
# Tentando atualizar a pilha de AWS ParallelCluster APIs
Se você receber um erro, como `UPDATE_FAILED` ao tentar atualizar a pilha de AWS ParallelCluster APIs, recomendamos que você verifique se há uma solução nas seções **Problemas conhecidos** do [AWS ParallelCluster Wiki](https://github.com/aws/aws-parallelcluster/wiki) em GitHub. Por exemplo, consulte [ParallelCluster API Stack Upgrade Fails para recursos de ECR](https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-3.1.4)-ParallelCluster-API-Stack-Upgrade-Fails-for-ECR-resources), que identifica um possível problema e fornece opções de mitigação.
# Vendo erros nas inicializações dos nós de computação
As seções a seguir fornecem dicas de solução de problemas para quando erros nas inicializações de nós de computação. Isso inclui erros de bootstrap, visualização de erros em logs e onde ir se nenhum dos cenários se aplicar à sua situação específica.
**Topics**
+ [Vendo `Node bootstrap error` em `clustermgtd.log`](compute-node-initialization-bootstrap-error-v3.md)
+ [Eu configurei reservas de capacidade sob demanda (ODCRs) ou instâncias reservadas zonais](compute-node-initialization-odcr-v3.md)
+ [Ver `An error occurred (VcpuLimitExceeded)` 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-vpc-limit-v3.md)
+ [Ver `An error occurred (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.md)
+ [Vendo que os nós estão em estado `DOWN` com `Reason (Code:InsufficientInstanceCapacity)...`](compute-node-initialization-down-nodes-v3.md)
+ [Vendo `cannot change locale (en_US.utf-8) because it has an invalid name` em `slurm_resume.log`](compute-node-initialization-locale-v3.md)
+ [Nenhum dos cenários anteriores se aplica à minha situação](compute-node-initialization-not-found-v3.md)
# Vendo `Node bootstrap error` em `clustermgtd.log`
O problema está relacionado à falha na inicialização dos nós de computação. Para obter informações sobre como depurar um problema no modo protegido por cluster, consulte [Como depurar o modo protegido](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3).
# Eu configurei reservas de capacidade sob demanda (ODCRs) ou instâncias reservadas zonais
## ODCRs que incluem instâncias que têm várias interfaces de rede, como P4d, P4de e AWS Trainium (Trn)
No arquivo de configuração do cluster, verifique se o `HeadNode` está em uma sub-rede pública e se os nós de computação estão em uma sub-rede privada.
## ODCRs são ODCRS direcionados
### Vendo, `Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.` embora eu já tenha `/opt/slurm/etc/pcluster/run_instances_overrides.json` instalado, seguindo as instruções dadas em [Iniciar instâncias com Reservas de Capacidade Sob Demanda (ODCR)](launch-instances-odcr-v3.md)
Se você estiver usando AWS ParallelCluster as versões 3.1.1 a 3.2.1 com targeted ODCRs e também estiver usando o arquivo [JSON run instances override, é possível que você não tenha o arquivo](launch-instances-odcr-v3.md) JSON formatado corretamente. Você pode ver um erro em `clustermgtd.log`, como o seguinte:
```
Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.
Using default: {} in /var/log/parallelcluster/clustermgtd.
```
Valide se o formato de arquivo JSON está correto executando o seguinte:
```
$ echo /opt/slurm/etc/pcluster/run_instances_overrides.json | jq
```
### Ver `Found RunInstances parameters override.` em `clustermgtd.log` quando a criação do cluster falhou ou em `slurm_resume.log` quando o trabalho de execução falhou
Se você estiver usando o [arquivo JSON de substituição de instâncias de execução](launch-instances-odcr-v3.md), verifique se definiu corretamente o nome da fila e o nome dos recursos de computação no arquivo `/opt/slurm/etc/pcluster/run_instances_overrides.json`.
### Ver `An error occurred (InsufficientInstanceCapacity)` no `slurm_resume.log` quando não consegui executar um trabalho ou em `clustermgtd.log` quando eu não consigo criar um cluster
#### Usando PG-ODCR (grupo de posicionamento ODCR)
Ao criar um ODCR com um grupo de posicionamento associado, o mesmo nome do grupo de posicionamento deve ser usado no arquivo de configuração. Defina o [nome do grupo de posicionamento](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) correspondente na configuração do cluster.
#### Usar instâncias reservadas zonais
Se você estiver usando instâncias reservadas zonais com `PlacementGroup` / `Enabled` para `true` na configuração do cluster, poderá ver um erro, como o seguinte:
```
We currently do not have sufficient trn1.32xlarge capacity in the Availability Zone you requested (us-east-1d). Our system will be working on provisioning additional capacity.
You can currently get trn1.32xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1e, us-east-1f.
```
Você pode ver isso porque as instâncias reservadas zonais não são colocadas na mesma UC (ou coluna vertebral), o que pode causar erros de capacidade insuficientes (ICEs) ao usar grupos de posicionamento. Você pode verificar esse caso desativando a configuração de Grupo`PlacementGroup` na configuração do cluster para determinar se o cluster pode alocar as instâncias.
# Ver `An error occurred (VcpuLimitExceeded)` no `slurm_resume.log` quando não consegui executar um trabalho ou em `clustermgtd.log` quando eu não consigo criar um cluster
Verifique os limites de vCPU na sua conta para o tipo específico de instância do Amazon EC2 que você está usando. Se você ver zero ou CPUs menos v do que está solicitando, solicite um aumento para seus limites. Para ter informações sobre como visualizar limites atuais e solicitar novos limites, consulte [Service Quotas do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) no *Guia do usuário do Amazon EC2*.
# Ver `An error occurred (InsufficientInstanceCapacity)` no `slurm_resume.log` quando não consegui executar um trabalho ou em `clustermgtd.log` quando eu não consigo criar um cluster
Você está enfrentando um problema de capacidade insuficiente. Siga [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)para solucionar o problema. insufficient-capacity-errors
# Vendo que os nós estão em estado `DOWN` com `Reason (Code:InsufficientInstanceCapacity)...`
Você está enfrentando um problema de capacidade insuficiente. Siga [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)para solucionar o problema. insufficient-capacity-errors Para obter mais informações sobre o modo AWS ParallelCluster de failover rápido de capacidade insuficiente, consulte. [Failover rápido de capacidade insuficiente do cluster Slurm](slurm-short-capacity-fail-mode-v3.md)
# Vendo `cannot change locale (en_US.utf-8) because it has an invalid name` em `slurm_resume.log`
Isso pode ocorrer se você tiver um processo de instalação do `yum` malsucedido que deixou as configurações de localidade em um estado inconsistente. Por exemplo, isso pode ser causado quando um usuário encerra o processo de instalação.
**Para verificar a causa, realize as seguintes ações:**
+ Executar `su - pcluster-admin`.
O shell mostra um erro, como `cannot change locale...no such file or directory`.
+ Executar `localedef --list`.
Retorna uma lista vazia ou não contém a localidade padrão.
+ Verifique o último comando `yum` com `yum history` e `yum history info #ID`. O último ID tem `Return-Code: Success`?
Se a última ID não tiver `Return-Code: Success`, os scripts de pós-instalação podem não ter sido executados com êxito.
Para corrigir o problema, tente reconstruir a localidade com `yum reinstall glibc-all-langpacks`. Após a reconstrução, `su - pcluster-admin` não mostra um erro ou aviso se o problema foi corrigido.
# Nenhum dos cenários anteriores se aplica à minha situação
Para solucionar problemas de inicialização do nó de computação, consulte [Solução de problemas de inicialização do nó](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init).
Verifique se seu cenário está abordado em [Problemas GitHub conhecidos](https://github.com/aws/aws-parallelcluster/wiki) em AWS ParallelCluster on GitHub.
# Métricas de integridade do cluster para solução de problemas
As métricas de integridade do cluster são adicionadas ao CloudWatch painel AWS ParallelCluster da Amazon a partir da AWS ParallelCluster versão 3.6.0. Nas seções a seguir, você vai aprender sobre as métricas de integridade do painel e sobre ações que você pode realizar para solucionar problemas.
**Topics**
+ [Visualizando o gráfico de **Erros de provisionamento de instâncias**](#troubleshooting-v3-cluster-health-metrics-instance-provisioning)
+ [Visualizando o gráfico de **Erros de instância não saudáveis**](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance)
+ [Visualizando o gráfico de **Tempo de inatividade da frota de computadores**](#troubleshooting-v3-cluster-health-metrics-idle-time-errors)
## Visualizando o gráfico de **Erros de provisionamento de instâncias**
Se você vir um valor diferente de zero no gráfico `Instance Provisioning Errors`, isso significará que a instância do Amazon EC2 para suporte de nós Slurm falhou ao iniciar na API `CreateFleet` ou `RunInstance`.
### Vendo `IAMPolicyErrors`
+ **O que aconteceu?**
Várias instâncias falharam na inicialização, o que é causado por permissões insuficientes com código de erro `UnauthorizedOperation`.
+ **Como resolver?**
Se você configurou um [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole) ou [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile) personalizado, verifique suas políticas do IAM e verifique se está usando as credenciais corretas.
Verifique o arquivo `clustermgtd` para ver os detalhes do erro do nó estático. Verifique o arquivo `slurm_resume.log` para ver os detalhes do erro do nó dinâmico. Use os detalhes para saber mais sobre as permissões ausentes que devem ser adicionadas.
### Vendo `VcpuLimitErrors`
+ **O que aconteceu?**
AWS ParallelCluster falhou ao iniciar instâncias porque atingiu o limite de vCPU Conta da AWS para um tipo específico de instância do Amazon EC2 que você configurou para nós de computação de cluster.
+ **Como resolver?**
Verifique o erro `VcpuLimitExceeded` no arquivo `clustermgtd` para nós estáticos e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes adicionais. Para resolver esse problema, é possível solicitar um aumento nos limites da vCPU. Para ter mais informações sobre como visualizar limites atuais e solicitar novos limites, consulte [Service Quotas do Amazon Elastic Compute Cloud](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html) no *Guia do usuário do Amazon Elastic Compute Cloud para instâncias do Linux*.
### Vendo `VolumeLimitErrors`
+ **O que aconteceu?**
Você atingiu o limite de volume do Amazon EBS e AWS ParallelCluster não consegue iniciar instâncias com código de erro `InsufficientVolumeCapacity` ou`VolumeLimitExceeded`. Conta da AWS
+ **Como resolver?**
Verifique o arquivo `clustermgtd` para ver se há nós estáticos, e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes adicionais sobre limite de volume. Para resolver esse problema, você pode usar um outro Região da AWS, limpar os volumes existentes ou entrar em contato com o AWS Support Center para enviar uma solicitação para aumentar seu limite de volume do Amazon EBS.
### Vendo `InsufficientCapacityErrors`
+ **O que aconteceu?**
AWS ParallelCluster não tem capacidade suficiente para iniciar instâncias do Amazon EC2 em nós secundários.
+ **Como resolver?**
Verifique se há nós estáticos no arquivo `clustermgtd` e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes de erro de capacidade insuficientes. Para solucionar o problema, siga as orientações em [https://aws.amazon.com/premiumsupport/knowledge-center/ec2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) -/. insufficient-capacity-errors
### `OtherInstanceLaunchFailures`
+ **O que aconteceu?**
A instância do Amazon EC2 para suportar os nós de computação falhou ao ser iniciada com a API `CreateFleet` ou `RunInstance`.
+ **Como resolver?**
Verifique se há nós estáticos no arquivo `clustermgtd` e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes do erro.
## Visualizando o gráfico de **Erros de instância não saudáveis**
+ **O que aconteceu?**
Várias instâncias de computação foram iniciadas, mas depois encerradas por não serem íntegras.
+ **Como resolver?**
Para obter mais informações sobre solução de problemas de nós não saudáveis, consulte [**Solução de problemas inesperados de substituições e encerramentos de nós**](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations).
### Vendo `InstanceBootstrapTimeoutError`
+ **O que aconteceu?**
Uma instância não pode se juntar ao cluster em `resume_timeout` (para nós dinâmicos) ou `node_replacement_timeout` (para nós estáticos). Isso pode ocorrer se a rede não estiver configurada corretamente para os nós de computação, ou se os scripts personalizados executados no nó de computação demorarem muito para serem concluídos.
+ **Como resolver?**
Para nós dinâmicos, verifique no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) o endereço IP do nó de computação e erros como os seguintes:
```
Node bootstrap error: Resume timeout expires for node
```
Para nós estáticos, verifique no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) o endereço IP do nó de computação e erros como os seguintes:
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
Para obter detalhes adicionais, verifique se há erros no arquivo `/var/log/cloud-init-output.log`. Você pode recuperar endereços IP de nós de computação problemáticos a partir dos arquivos de log `clustermgtd` e `slurm_resume`.
### Vendo `EC2HealthCheckErrors`
+ **O que aconteceu?**
Uma instância falhou em uma verificação de integridade do Amazon EC2.
+ **Como resolver?**
Para obter informações sobre como solucionar esse problema, consulte [Solução de problemas em instâncias com falha nas verificações de status](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
### Vendo `ScheduledEventHealthCheckErrors`
+ **O que aconteceu?**
Uma instância falhou em uma verificação de integridade de um evento agendado pelo Amazon EC2 e não está íntegra.
+ **Como resolver?**
Para obter informações sobre como solucionar esse problema, consulte [Eventos programados para instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).
### Vendo `NoCorrespondingInstanceErrors`
+ **O que aconteceu?**
AWS ParallelCluster não consigo encontrar instâncias de apoio aos nós. Os nós provavelmente terminaram automaticamente durante as operações de bootstrap. scripts [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions) / [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) ou erros de rede podem produzir`NoCorrespondingInstanceErrors`.
+ **Como resolver?**
Para obter detalhes adicionais, consulte `/var/log/cloud-init-output.log` para ver o nó de computação.
## Visualizando o gráfico de **Tempo de inatividade da frota de computadores**
### Observando um `MaxDynamicNodeIdleTime` que é significativamente maior do que o limite de **redução do tempo de inatividade**
+ **O que aconteceu?**
Sua instância não está sendo encerrada corretamente. O `MaxDynamicNodeIdleTime` mostra o tempo máximo em segundos em que um nó dinâmico, apoiado por uma instância do Amazon EC2, fica ocioso. O limite de **redução do tempo de inatividade** é derivado do parâmetro [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) de configuração do cluster. Quando um nó de computação fica ocioso por mais de segundos do **Idle Time Scaledown**, desliga o nó e Slurm AWS ParallelCluster encerra a instância de backup. Nesse caso, algo está impedindo o encerramento da instância.
+ **Como resolver?**
Para obter mais informações sobre esse problema, consulte [**Substituindo, encerrando ou desligando instâncias e nós problemáticos**](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3) em [Solucionar problemas de escala](troubleshooting-v3-scaling-issues.md).
# Solução de problemas de implantação de cluster
Se o cluster não for criado e reverter a criação da pilha, você poderá examinar os arquivos de log para diagnosticar o problema. A mensagem de falha provavelmente se parece com a seguinte saída:
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster describe-cluster --cluster-name mycluster --region eu-west-1
{
"creationTime": "2021-09-06T11:03:47.696Z",
...
"cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS",
"clusterName": "mycluster",
"computeFleetStatus": "UNKNOWN",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"lastUpdatedTime": "2021-09-06T11:03:47.696Z",
"region": "eu-west-1",
"clusterStatus": "CREATE_FAILED"
}
```
**Topics**
+ [Veja CloudFormation os eventos em `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-events)
+ [Use a CLI para visualizar fluxos de log](#troubleshooting-v3-cluster-deployment-cli-logstreams)
+ [Recrie o cluster com falha com `rollback-on-failure`](#troubleshooting-v3-cluster-deployment-cli-fail-rollback)
## Veja CloudFormation os eventos em `CREATE_FAILED`
Você pode usar o console ou a AWS ParallelCluster CLI para visualizar CloudFormation eventos sobre `CREATE_FAILED` erros e ajudar a encontrar a causa raiz.
**Topics**
+ [Exibir eventos no CloudFormation console](#troubleshooting-v3-cluster-deployment-cloudformation)
+ [Use a CLI para visualizar e filtrar CloudFormation eventos em `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-cli-events)
### Exibir eventos no CloudFormation console
Para ver mais informações sobre o que causou o `"CREATE_FAILED"` status, você pode usar o CloudFormation console.
**Veja as mensagens de CloudFormation erro do console.**
1. Faça login no Console de gerenciamento da AWS e navegue até [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Selecione a pilha chamada *cluster\$1name*.
1. Escolha a guia **Eventos**.
1. Verifique o **status** do recurso que não foi criado percorrendo a lista de eventos do recurso por **ID lógico**. Se houver falha na criação de uma subtarefa, retroceda para encontrar o evento de recurso com falha.
1. Por exemplo, se você ver a mensagem de status a seguir, deverá usar tipos de instância que não excedam seu limite atual de vCPU ou solicitar mais capacidade de vCPU.
```
2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED You have requested more vCPU capacity than your current vCPU limit of 0 allows
for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null).
```
### Use a CLI para visualizar e filtrar CloudFormation eventos em `CREATE_FAILED`
Para diagnosticar o problema de criação do cluster, você pode usar o comando [`pcluster get-cluster-stack-events`](pcluster.get-cluster-stack-events-v3.md) filtrando por status `CREATE_FAILED`. Para obter mais informações, consulte [Filtragem AWS CLI de saída](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html) no *Guia do AWS Command Line Interface usuário*.
```
$ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \
--query 'events[?resourceStatus==`CREATE_FAILED`]'
[
{
"eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9",
"physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "mycluster",
"resourceType": "AWS::CloudFormation::Stack",
"timestamp": "2021-09-06T11:11:51.780Z"
},
{
"eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z",
"physicalResourceId": "i-04e91cc1f4ea796fe",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe",
"resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "HeadNode",
"resourceType": "AWS::EC2::Instance",
"timestamp": "2021-09-06T11:11:50.127Z"
}
]
```
No exemplo anterior, a falha estava na configuração do nó principal.
## Use a CLI para visualizar fluxos de log
Para depurar esse tipo de problema, você pode listar os fluxos de log disponíveis no nó principal com o [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md), filtrando `node-type` e analisando o conteúdo dos fluxos de log.
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=node-type,Values=HeadNode'
{
"logStreams": [
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
...
},
...
]
}
```
Os dois fluxos de log principais que você pode usar para encontrar erros de inicialização são os seguintes:
+ `cfn-init` é o log do script `cfn-init`. Primeiro, verifique esse fluxo de logs. É provável que você veja o erro `Command chef failed` nesse log. Veja as linhas imediatamente antes dessa linha para obter mais detalhes relacionados à mensagem de erro. Para mais informações, consulte [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
+ `cloud-init` é o log do [cloud-init](https://cloudinit.readthedocs.io/). Se não vir nada no `cfn-init`, tente verificar esse log a seguir.
Você pode recuperar o conteúdo do fluxo de log usando o [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) (observe a opção `--limit 5` de limitar o número de eventos recuperados):
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \
--limit 5
{
"nextToken": "f/36370880979637159565202782352491087067973952362220945409/s",
"prevToken": "b/36370880752972385367337528725601470541902663176996585497/s",
"events": [
{
"message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in \n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com",
"timestamp": "2021-09-06T11:11:49.212Z"
},
{
"message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE",
"timestamp": "2021-09-06T11:11:49.213Z"
}
]
}
```
No exemplo anterior, a falha é causada por uma falha `runpostinstall`, portanto, está estritamente relacionada ao conteúdo do script de bootstrap personalizado usado no parâmetro de configuração `OnNodeConfigured` do [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions).
## Recrie o cluster com falha com `rollback-on-failure`
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). Se não houver fluxos de log disponíveis, a falha pode ser causada pelo script de bootstrap [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) personalizado ou por um problema relacionado à AMI. Para diagnosticar o problema de criação nesse caso, crie o cluster novamente usando [`pcluster create-cluster`](pcluster.create-cluster-v3.md), incluindo o parâmetro `--rollback-on-failure` definido como `false`. Em seguida, use o SSH para visualizar o cluster, conforme mostrado a seguir:
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml --rollback-on-failure false
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster ssh --cluster-name mycluster
```
Depois de fazer login no nó principal, você deve encontrar três arquivos de log principais que podem ser usados para encontrar o erro.
+ `/var/log/cfn-init.log` é o log do script `cfn-init`. Primeiro, verifique esse log. É provável que você veja o erro como o `Command chef failed` nesse log. Veja as linhas imediatamente antes dessa linha para obter mais detalhes relacionados à mensagem de erro. Para mais informações, consulte [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html).
+ `/var/log/cloud-init.log` é o log do [cloud-init](https://cloudinit.readthedocs.io/). Se não vir nada no `cfn-init.log`, tente verificar esse log a seguir.
+ `/var/log/cloud-init-output.log` é a saída dos comandos que foram executados pelo [cloud-init](https://cloudinit.readthedocs.io/). Isso inclui a saída de `cfn-init`. Na maioria dos casos, não é preciso consultar esse log para solucionar esse tipo de problema.
# Solução de problemas de implantação de cluster usando o Terraform
Esta seção é relevante para clusters que foram implantados usando o Terraform.
## ParallelCluster API não encontrada
O planejamento pode falhar porque a ParallelCluster API não pode ser encontrada. Nesse caso, o erro retornado será algo como:
```
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Unable to retrieve ParallelCluster API cloudformation stack.
│
│ with provider["registry.terraform.io/aws-tf/aws-parallelcluster"],
│ on providers.tf line 6, in provider "aws-parallelcluster":
│ 6: provider "aws-parallelcluster" {
│
│ operation error CloudFormation: DescribeStacks, https response error StatusCode: 400, RequestID: REQUEST_ID, api error ValidationError: Stack with id PCAPI_STACK_NAME does not exist
```
Para resolver esse erro, implante a ParallelCluster API na conta em que os clusters serão criados. Consulte [Criar um cluster como o Terraform](tutorial-create-cluster-terraform.md).
## Usuário não autorizado a chamar a ParallelCluster API
O planejamento pode falhar porque o IAM role/user que você presumiu para implantar seu projeto Terraform não tem permissões para interagir com a ParallelCluster API. Nesse caso, o erro retornado será algo como:
```
Planning failed. Terraform encountered an error while generating this plan.
│ Error: 403 Forbidden
│
│ with module.parallelcluster_clusters.module.clusters[0].pcluster_cluster.managed_configs["DemoCluster01"],
│ on .terraform/modules/parallelcluster_clusters/modules/clusters/main.tf line 35, in resource "pcluster_cluster" "managed_configs":
│ 35: resource "pcluster_cluster" "managed_configs" {
│
│ {{"Message":"User: USER_ARN is not authorized to perform: execute-api:Invoke on resource: PC_API_REST_RESOURCE with an explicit deny"}
│ }
```
Para resolver esse erro, configure o ParallelCluster provedor para que ele use a função da ParallelCluster API para interagir com a API.
```
provider "aws-parallelcluster" {
region = var.region
profile = var.profile
api_stack_name = var.api_stack_name
**use_user_role** **= true**
}
```
# 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.
# Grupos de posicionamento e problemas de execução de instâncias
Para obter a menor latência entre os nós, use um *grupo de posicionamento*. Um grupo de posicionamento garante que suas instâncias estejam no mesmo suporte principal de rede. Se não houver instâncias suficientes disponíveis quando a solicitação é feita, um erro `InsufficientInstanceCapacity` será gerado. Para reduzir a possibilidade de receber um erro ao usar grupos de posicionamento de cluster, defina o parâmetro [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) / [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) / [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Enabled) para `false`.
Para obter controle adicional sobre o acesso à capacidade, considere [lançar instâncias com ODCR (On-Demand Capacity Reservations)](launch-instances-odcr-v3.md).
Para obter mais informações, consulte [Solução de problemas de execução de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) e [Funções e limitações de placement groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) no *Guia do usuário do Amazon EC2 par instâncias do Linux*.
# Substituição de diretórios
Alguns diretórios não podem ser substituídos. Se você estiver enfrentando problemas para substituir o diretório, esse poderá ser o caso. Os diretórios a seguir são compartilhados entre os nós e não podem ser substituídos.
+ `/opt/intel` - Isso inclui Intel MPI, Intel Parallel Studio e arquivos relacionados.
+ `/opt/slurm`: inclui o Slurm Workload Manager e arquivos relacionados. (Condicional, somente se `Scheduler: slurm`.)
# Solução de problemas no Amazon DCV
**Topics**
+ [Logs do Amazon DCV](#troubleshooting-v3-nice-dcv-logs)
+ [Problemas no Ubuntu Amazon DCV](#troubleshooting-v3-nice-dcv-modules)
## Logs do Amazon DCV
Os logs do Amazon DCV são gravados em arquivos no diretório `/var/log/dcv/`. A revisão desses logs pode ajudar a solucionar problemas.
O tipo de instância deve ter pelo menos 1,7 gibibytes (GiB) de RAM para executar o Amazon DCV. Os tipos de instância nano e micro não têm memória suficiente para executar o Amazon DCV.
AWS ParallelCluster cria fluxos de log do Amazon DCV 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).
## Problemas no Ubuntu Amazon DCV
Ao executar o Gnome Terminal em uma sessão do Amazon DCV no Ubuntu, você pode não ter acesso automático ao ambiente do usuário disponibilizado pelo AWS ParallelCluster por meio do shell de login. O ambiente do usuário fornece módulos de ambiente, como openmpi ou intelmpi, e outras configurações do usuário.
As configurações padrão do Gnome Terminal evitam que o shell inicie como um shell de login. Isso significa que os perfis de shell não são fornecidos automaticamente e o ambiente AWS ParallelCluster do usuário não é carregado.
Para obter corretamente o perfil do shell e acessar o ambiente do AWS ParallelCluster usuário, faça o seguinte:
+
**Altere as configurações do terminal padrão:**
1. Escolha o menu **Editar** no terminal Gnome.
1. Selecione **Preferências**, e em seguida, **Perfis**.
1. Escolha **Comando** e selecione **Executar comando como shell de login**.
1. Abrir um novo terminal.
+ **Use a linha de comando para obter os perfis disponíveis:**
```
$ source /etc/profile && source $HOME/.bashrc
```
# Solução de problemas em clusters com AWS Batch integração
Esta seção fornece possíveis dicas de solução de problemas para clusters com integração de AWS Batch agendador, especificamente com problemas de nó principal, problemas de computação, falhas de trabalho e erros de tempo limite.
**Topics**
+ [Problemas no nó principal](#troubleshooting-v3-batch-head-node)
+ [Problemas de computação](#troubleshooting-v3-batch-compute-nodes)
+ [Falhas de trabalhos](#troubleshooting-v3-batch-job-fail)
+ [Erro de tempo limite de conexão no URL do endpoint](#troubleshooting-v3-batch-connect-timeout)
## Problemas no nó principal
Você pode solucionar problemas de configuração do nó principal da mesma forma que um cluster Slurm (exceto para logs Slurm específicos). Para obter mais informações sobre esses problemas, consulte [Nó principal](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init.head-node).
## Problemas de computação
AWS Batch gerencia os aspectos de escalabilidade e computação de seus serviços. Se você encontrar problemas relacionados à computação, consulte a documentação de AWS Batch [solução de problemas](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) para obter ajuda.
## Falhas de trabalhos
Se um trabalho falhar, você poderá executar o comando [`awsbout`](awsbatchcli.awsbout-v3.md) para recuperar a saída do trabalho. Você também pode executar o [`awsbstat`](awsbatchcli.awsbstat-v3.md) comando para obter um link para os registros de trabalhos armazenados pela Amazon CloudWatch.
## Erro de tempo limite de conexão no URL do endpoint
Se trabalhos paralelos de vários nós falharem com um erro: `Connect timeout on endpoint URL`:
+ No log `awsbout` de saída, verifique se o trabalho tem vários nós paralelos à saída: `Detected 3/3 compute nodes. Waiting for all compute nodes to start.`
+ Verifique se a sub-rede dos nós de computação é pública.
Os trabalhos paralelos de vários nós não suportam o uso de sub-redes públicas ao serem usados em. AWS Batch AWS ParallelCluster Use uma sub-rede privada para seus nós e trabalhos de computação. Para obter mais informações, consulte [Considerações sobre o ambiente de computação](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce) no *Guia do usuário do AWS Batch *. Para configurar uma sub-rede privada para seus nós de computação, consulte [AWS ParallelCluster com AWS Batch agendador](network-configuration-v3-batch.md).
# Solução de problemas de integração de vários usuários com o Active Directory
Esta seção é relevante para clusters integrados a um Active Directory.
Se o recurso de integração do Active Directory não estiver funcionando conforme o esperado, os registros do SSSD podem fornecer informações úteis de diagnóstico. Esses logs estão localizados em `/var/log/sssd` nos nós do cluster. Por padrão, eles também são armazenados no grupo de CloudWatch logs da Amazon de um cluster.
**Topics**
+ [Solução de problemas específicos do Active Directory](#troubleshooting-v3-multi-ad-specific)
+ [Habilitar modo de depuração](#troubleshooting-v3-multi-user-debug)
+ [Como passar do LDAPS para o LDAP](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [Como desabilitar a verificação do certificado do servidor LDAPS](#troubleshooting-v3-multi-user-ldaps-verify)
+ [Como fazer login com uma chave SSH em vez de uma senha](#troubleshooting-v3-multi-user-ssh-login)
+ [Como redefinir uma senha de usuário e senhas expiradas](#troubleshooting-v3-multi-user-reset-passwd)
+ [Como verificar o domínio associado](#troubleshooting-v3-multi-user-domain-verify)
+ [Como solucionar problemas com certificados](#troubleshooting-v3-multi-user-certificates)
+ [Como verificar se a integração com o Active Directory está funcionando](#troubleshooting-v3-multi-user-ad-verify)
+ [Como solucionar problemas de login em nós de computação](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [Problemas conhecidos com trabalhos SimCenter StarCCM\$1 em um ambiente multiusuário](#troubleshooting-v3-multi-user-ad-starccm)
+ [Problemas conhecidos com a resolução do nome de usuário](#troubleshooting-v3-multi-user-name-resolution)
+ [Como resolver problemas de criação do diretório inicial](#troubleshooting-v3-multi-home-directory)
## Solução de problemas específicos do Active Directory
Esta seção é relevante para a solução de problemas específicos de um tipo de Active Directory.
### Simple AD
+ O valor `DomainReadOnlyUser` deve corresponder à pesquisa básica do diretório Simple AD para usuários:
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
Anote `cn` para `Users`.
+ O usuário administrador padrão é `Administrator`.
+ `Ldapsearch` requer o nome NetBIOS antes do nome de usuário.
A sintaxe `Ldapsearch` deve ser a seguinte:
```
$ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \
-b "cn=Users,dc=corp,dc=example,dc=com"
```
### AWS Managed Microsoft AD
+ O `DomainReadOnlyUser` valor deve corresponder à pesquisa de base de AWS Managed Microsoft AD diretórios para usuários:
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ O usuário administrador padrão é `Admin`.
+ A sintaxe `Ldapsearch` deve ser a seguinte:
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## Habilitar modo de depuração
Os registros de depuração do SSSD podem ser úteis para solucionar problemas. Para ativar o modo de depuração, você deve atualizar o cluster com as seguintes alterações feitas na configuração do cluster:
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## Como passar do LDAPS para o LDAP
A mudança do LDAPS (LDAP com TLS/SSL) para o LDAP é desencorajada porque o LDAP sozinho não fornece nenhuma criptografia. No entanto, ele pode ser útil para fins de teste e solução de problemas.
Você pode restaurar a configuração anterior do cluster atualizando o cluster com a definição de configuração anterior.
Para migrar do LDAPS para o LDAP, você deve atualizar o cluster com as seguintes alterações na configuração do cluster:
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## Como desabilitar a verificação do certificado do servidor LDAPS
Pode ser útil desativar temporariamente a verificação do certificado do servidor LDAPS no nó principal, para fins de teste ou solução de problemas.
Você pode restaurar a configuração anterior do cluster atualizando o cluster com a definição de configuração anterior.
Para desativar a verificação do certificado do servidor LDAPS, você deve atualizar o cluster com as seguintes alterações na configuração do cluster:
```
DirectoryService:
LdapTlsReqCert: never
```
## Como fazer login com uma chave SSH em vez de uma senha
A chave SSH é criada no `/home/$user/.ssh/id_rsa` após a primeira vez que você efetua login com uma senha. Para fazer login com a chave SSH, você deve fazer login com sua senha, copiar a chave SSH localmente e usá-la para SSH sem senha, como de costume:
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## Como redefinir uma senha de usuário e senhas expiradas
Se um usuário perder o acesso a um cluster, sua [senha AWS Managed Microsoft AD pode ter expirado](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
Para redefinir a senha, execute o seguinte comando com um usuário e uma função que tenham permissão de gravação no diretório:
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
Se você redefinir a senha para o [`DirectoryService`](DirectoryService-v3.md) / [`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser):
1. Certifique-se de atualizar o segredo [`DirectoryService`](DirectoryService-v3.md) / [`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn) com a nova senha.
1. Atualize o cluster para obter o novo valor secreto:
1. Pare a frota de computadores com o comando `pcluster update-compute-fleet`.
1. Execute o comando a seguir de dentro do nó principal do cluster.
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
Após a redefinição da senha e a atualização do cluster, o acesso do usuário ao cluster deve ser restaurado.
Para obter mais informações, consulte [Redefinir uma senha de usuário](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html) no *Guia de administração do Directory Service *.
## Como verificar o domínio associado
O comando a seguir deve ser executado em uma instância associada ao domínio, não no nó principal.
```
$ realm list corp.example.com \
type: kerberos \
realm-name: CORP.EXAMPLE.COM \
domain-name: corp.example.com \
configured: kerberos-member \
server-software: active-directory \
client-software: sssd \
required-package: oddjob \
required-package: oddjob-mkhomedir \
required-package: sssd \
required-package: adcli \
required-package: samba-common-tools \
login-formats: %U \
login-policy: allow-realm-logins
```
## Como solucionar problemas com certificados
Quando a comunicação LDAPS não está funcionando, pode ser devido a erros na comunicação TLS, o que, por sua vez, pode ser devido a problemas com certificados.
**Notas sobre certificados:**
+ O certificado especificado na configuração do cluster `LdapTlsCaCert` deve ser um pacote de certificados PEM contendo os certificados de toda a cadeia de certificados de autoridade (CA) que emitiu certificados para os controladores de domínio.
+ Um pacote de certificados PEM é um arquivo feito da concatenação de certificados PEM.
+ Um certificado no formato PEM (normalmente usado no Linux) é equivalente a um certificado no formato base64 DER (normalmente exportado pelo Windows).
+ Se o certificado para controladores de domínio for emitido por uma CA subordinada, o pacote de certificados deverá conter o certificado da CA subordinada e raiz.
**Etapas de verificação de problemas:**
As etapas de verificação a seguir pressupõem que os comandos sejam executados de dentro do nó principal do cluster e que o controlador de domínio esteja acessível em `SERVER:PORT`.
Para solucionar um problema relacionado aos certificados, siga estas etapas de verificação:
**Etapas de verificação:**
1. **Verifique a conexão com os controladores de domínio do Active Directory:**
Verifique se você pode se conectar a um controlador de domínio. Se essa etapa for bem-sucedida, a conexão SSL com o controlador de domínio será bem-sucedida e o certificado será verificado. Seu problema não está relacionado aos certificados.
Se essa etapa falhar, prossiga com a próxima verificação.
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **Revise a verificação do certificado:**
Verifique se o pacote de certificados CA local pode validar o certificado fornecido pelo controlador de domínio. Se essa etapa for bem-sucedida, seu problema não está relacionado aos certificados, mas a outros problemas de rede.
Se essa etapa falhar, prossiga com a próxima verificação.
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Verifique o certificado fornecido pelos controladores de domínio do Active Directory:**
Verifique se o conteúdo do certificado fornecido pelos controladores de domínio é o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado CA usado para verificar os controladores. Vá para a próxima etapa de solução de problemas.
Se essa etapa falhar, você deverá corrigir o certificado emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Verifique o conteúdo de um certificado:**
Verifique se o conteúdo do certificado fornecido pelos controladores de domínio é o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado CA usado para verificar os controladores. Vá para a próxima etapa de solução de problemas.
Se essa etapa falhar, você deverá corrigir o certificado emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Verifique o conteúdo do pacote de certificados CA local:**
Verifique se o conteúdo do pacote de certificados CA local usado para validar o certificado dos controladores de domínio está conforme o esperado. Se essa etapa for bem-sucedida, você provavelmente terá problemas com o certificado fornecido pelos controladores de domínio.
Se essa etapa falhar, você deverá corrigir o pacote de certificado de CA emitido para os controladores de domínio e reexecutar as etapas de solução de problemas.
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Como verificar se a integração com o Active Directory está funcionando
Se as duas verificações a seguir forem bem-sucedidas, a integração com o Active Directory está funcionando.
**Verificações:**
1. **Você pode descobrir usuários definidos no diretório:**
De dentro do nó principal do cluster, como um `ec2-user`:
```
$ getent passwd $ANY_AD_USER
```
1. **Você pode usar SSH no nó principal fornecendo a senha do usuário:**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
Se a verificação um falhar, esperamos que a verificação dois também falhe.
Verificações adicionais para solução de problemas:
+ Verifique se o usuário existe no diretório.
+ Habilitar [debug logging](#troubleshooting-v3-multi-user-debug).
+ Considere desativar temporariamente a criptografia [migrando do LDAPS para o LDAP](#troubleshooting-v3-multi-user-ldaps-ldap) para descartar problemas de LDAPS.
## Como solucionar problemas de login em nós de computação
Esta seção é relevante para fazer login em nós de computação em clusters integrados ao Active Directory.
Com AWS ParallelCluster, os logins com senha nos nós de computação do cluster são desativados por design.
Todos os usuários devem usar sua própria chave SSH para fazer login nos nós de computação.
Os usuários podem recuperar sua chave SSH no nó principal após a primeira autenticação (por exemplo, login), se [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers) estiver habilitadas na configuração do cluster.
Quando os usuários se autenticam no nó principal pela primeira vez, eles podem recuperar chaves SSH que são geradas automaticamente para eles como usuários do diretório. Também são criados diretórios pessoais para o usuário. Isso também pode acontecer na primeira vez que um sudo-usuário muda para um usuário no nó principal.
Se um usuário não estiver conectado ao nó principal, as chaves SSH não serão geradas e o usuário não poderá fazer login nos nós de computação.
## Problemas conhecidos com trabalhos SimCenter StarCCM\$1 em um ambiente multiusuário
Esta seção é relevante para trabalhos lançados em um ambiente multiusuário pelo software de dinâmica de fluidos computacional Simcenter StarCCM\$1 da Siemens.
Se você executar trabalhos StarCCM\$1 v16 configurados para usar o IntelMPI incorporado, por padrão, os processos MPI serão inicializados usando SSH.
Devido a um [bug do Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385) que causa erro na resolução do nome de usuário, os trabalhos podem falhar com um erro semelhante a `error setting up the bootstrap proxies`. Esse bug afeta apenas AWS ParallelCluster as versões 3.1.1 e 3.1.2.
Para evitar que isso ocorra, force o IntelMPI a usar o Slurm como método de bootstrap do MPI. Exporte a variável de ambiente `I_MPI_HYDRA_BOOTSTRAP=slurm` para o script de trabalho que inicia o StarCCM\$1, conforme descrito na [documentação oficial do IntelMPI](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html).
## Problemas conhecidos com a resolução do nome de usuário
Esta seção é relevante para recuperar nomes de usuário em trabalhos.
Devido a um [bug conhecido no Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), o nome de usuário recuperado em um processo de trabalho pode ser `nobody` se você executar um trabalho sem `srun`. Esse bug afeta apenas AWS ParallelCluster as versões 3.1.1 e 3.1.2.
Por exemplo, se você executar o comando `sbatch --wrap 'srun id'` como usuário do diretório, o nome de usuário correto será retornado. No entanto, se você executar o `sbatch --wrap 'id'` como usuário do diretório, `nobody` poderá ser retornado como nome de usuário.
É possível usar as seguintes soluções alternativas.
1. Inicie seu trabalho com `'srun'` em vez de `'sbatch'`, se possível.
1. Ative a enumeração SSSD definindo a configuração [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)no cluster da seguinte forma.
```
AdditionalSssdConfigs:
enumerate: true
```
## Como resolver problemas de criação do diretório inicial
Esta seção é relevante para problemas de criação de diretórios iniciais.
Se você ver erros como o mostrado no exemplo a seguir, um diretório inicial não foi criado para você quando você fez login pela primeira vez no nó principal. Ou, um diretório inicial não foi criado para você quando você mudou pela primeira vez de um sudoer para um usuário do Active Directory no nó principal.
```
$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
Could not chdir to home directory /home/PclusterUser85: No such file or directory
```
A falha na criação do diretório inicial pode ser causada pelos pacotes `oddjob` e `oddjob-mkhomedir` instalados no nó principal do cluster.
Sem um diretório inicial e uma chave SSH, o usuário não pode enviar trabalhos ou SSH para os nós do cluster.
Se você precisar dos pacotes `oddjob` em seu sistema, verifique se o serviço `oddjobd` está em execução e atualize os arquivos de configuração do PAM para garantir que o diretório inicial seja criado. Para fazer isso, execute os comandos no nó principal, conforme mostrado no exemplo a seguir.
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
Se você não precisar dos pacotes `oddjob` em seu sistema, desinstale-os e atualize os arquivos de configuração do PAM para garantir que o diretório inicial seja criado. Para fazer isso, execute os comandos no nó principal, conforme mostrado no exemplo a seguir.
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```
# Solução de problemas de AMI personalizada
Esta seção fornece possíveis dicas de solução para problemas de AMI personalizada.
Ao usar uma AMI personalizada, você pode ver os seguintes avisos:
```
"validationMessages": [
{
"level": "WARNING",
"type": "CustomAmiTagValidator",
"message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting."
},
{
"level": "WARNING",
"type": "AmiOsCompatibleValidator",
"message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations."
}
]
```
Se tiver certeza de que a AMI correta está sendo usada, você pode ignorar esses avisos.
Se você não quiser ver esses avisos no futuro, marque a AMI personalizada com as seguintes tags, onde `my-os` é uma das`alinux2`,`alinux2023`,`ubuntu2404`, `ubuntu2204``rhel8`, ou `rhel9` e *"3.15.0"* é a `pcluster` versão em uso:
```
$ aws ec2 create-tags \
--resources ami-yourcustomAmi \
--tags Key="parallelcluster:version",Value="3.15.0" Key="parallelcluster:os",Value="my-os"
```
# Solução de problemas de tempo limite de atualização de cluster quando `cfn-hup` não está em execução
O auxiliar `cfn-hup` é um daemon que detecta alterações em metadados de recursos e executa ações especificadas pelo usuário quando uma alteração é detectada. É assim que você faz as atualizações de configuração em suas instâncias do Amazon EC2 em execução pela ação do API `UpdateStack`.
Atualmente, o daemon `cfn-hup` é lançado pelo `supervisord`. Mas após o lançamento, o processo `cfn-hup` é separado do controle `supervisord`. Se o daemon `cfn-hup` for encerrado por uma causa externa, ele não será reiniciado automaticamente. Se `cfn-hup` não estiver em execução, durante uma atualização do cluster, a CloudFormation pilha inicia o processo de atualização conforme o esperado, mas o procedimento de atualização não é ativado no nó principal e a pilha acaba atingindo o tempo limite. Nos logs do cluster `/var/log/chef-client`, você pode ver que a fórmula de atualização nunca é invocada.
**Verifique e reinicie `cfn-hup` em caso de falhas**
1. No nó principal, verifique se `cfn-hup` está em execução:
```
$ ps aux | grep cfn-hup
```
1. Verifique o log `cfn-hup` `/var/log/cfn-hup.log` e `/var/log/supervisord.log` no nó principal.
1. Se `cfn-hup` não estiver em execução, tente reiniciá-lo executando:
```
$ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup
```
# Solução de problemas de rede
Esta seção fornece uma dica de solução de problemas para quando você encontrar problemas de rede, especificamente ao lidar com um cluster em um único problema de sub-rede pública.
## Problemas de cluster em uma única sub-rede pública
Verifique o `cloud-init-output.log` a partir de um dos nós de computação. Se você encontrar algo como o seguinte que indica que o nó está preso na inicialização Slurm, provavelmente é devido à falta de um endpoint da VPC do DynamoDB. Adicione o endpoint do DynamoDB. Para obter mais informações, consulte [AWS ParallelCluster em uma única sub-rede sem acesso à Internet](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md).
```
ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31)
```
# Falha na atualização do cluster na ação personalizada `onNodeUpdated`
Quando um script [`HeadNode`](HeadNode-v3.md) / [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) / [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated) falha, a atualização falha e o script não é executado no momento da reversão. É sua responsabilidade realizar manualmente as limpezas necessárias após a conclusão da reversão. Por exemplo, se o script `OnNodeUpdated` alterar o status de um campo em um arquivo de configuração (por exemplo, de `true` para `false`) e depois falhar, você precisará restaurar manualmente o valor do campo para o estado anterior à atualização (por exemplo, `false` para `true`). Para obter mais informações, consulte [Ações de bootstrap personalizadas](custom-bootstrap-actions-v3.md).
# Vendo erros com a configuração personalizada Slurm
A partir da AWS ParallelCluster versão 3.6.0, você não pode mais direcionar scripts individuais `prolog` ou `epilog` scripts incluindo-os em uma configuração personalizadaSlurm. Na AWS ParallelCluster versão 3.6.0 e versões posteriores, você deve localizar `epilog` scripts personalizados `prolog` e nas respectivas pastas `Prolog` e. `Epilog` Essas pastas são configuradas por padrão para apontar para:
+ `Prolog` aponta para `/opt/slurm/etc/scripts/prolog.d/`.
+ `Epilog` aponta para `/opt/slurm/etc/scripts/epilog.d/`.
Recomendamos que você mantenha o script do prolog `90_plcuster_health_check_manager` e o script do epilog `90_pcluster_noop` à disposição.
Slurm executa os scripts em ordem alfabética inversa. Tanto a pasta `Prolog` quanto a `Epilog` devem ter pelo menos um arquivo. Para obter mais informações, consulte [`prolog` e `epilog` da Slurm](slurm-prolog-epilog-v3.md) e [Slurm personalização de configuração](slurm-configuration-settings-v3.md).
# Alarmes do cluster
O monitoramento da integridade do cluster é essencial para garantir o desempenho ideal. AWS ParallelCluster permite monitorar vários alarmes CloudWatch baseados no nó principal do cluster.
Esta seção fornece detalhes para cada tipo de alarme de cluster do nó principal, incluindo suas convenções de nomenclatura, condições específicas que acionam os alarmes e etapas sugeridas para solução de problemas.
A convenção de nomenclatura para alarmes de cluster é `CLUSTER_NAME-COMPONENT-METRIC`, por exemplo, `mycluster-HeadNode-Cpu`.
+ `CLUSTER_NAME-HeadNode`: sinaliza o status geral do nó principal. Fica vermelho se pelo menos um dos alarmes abaixo estiver ativo.
+ `CLUSTER_NAME-HeadNode-Health`: vermelho se houver pelo menos uma falha na verificação de integridade do Amazon EC2. Em caso de alarme, sugerimos verificar [Solucionar problemas de instâncias com verificações de status com falha](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
+ `CLUSTER_NAME-HeadNode-Cpu`: vermelho se a utilização da CPU for maior que 90%. Em caso de alarme, verifique os processos que mais estão consumindo a CPU com `ps -aux --sort=-%cpu | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Mem`: vermelho se a utilização da memória for maior que 90%. Em caso de alarme, verifique os processos que mais estão consumindo memória com `ps -aux --sort=-%mem | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Disk`: vermelho se o espaço em disco ocupado for maior que 90% no caminho /. Em caso de alarme, verifique as pastas que consomem a maior parte do espaço com `du -h --max-depth=2 / 2> /dev/null | sort -hr`.
# Resolvendo alterações na configuração do sistema operacional que causam erros ou falhas
Ao fazer alterações na configuração do sistema operacional AWS ParallelCluster nos nós, podem surgir vários problemas que podem causar falhas na criação, atualização ou operação do cluster. Esta seção fornece orientação sobre como identificar e resolver problemas comuns relacionados à configuração do sistema operacional.
## Problemas comuns de configuração do sistema operacional
### Problemas de configuração de localidade
Um dos problemas mais comuns de configuração do sistema operacional está relacionado às configurações locais. Se você ver erros como:
```
cannot change locale (en_US.utf-8) because it has an invalid name
```
Isso geralmente ocorre quando:
+ O processo de `yum` instalação não teve êxito e deixou as configurações locais em um estado inconsistente
+ Um usuário encerrou um processo de instalação prematuramente
+ Pacotes locais estão ausentes ou corrompidos
#### Como diagnosticar
1. Verifique se você pode mudar para o usuário pcluster-admin:
```
$ su - pcluster-admin
```
Se você ver um erro como esse`cannot change locale...no such file or directory`, isso confirma o problema.
1. Verifique os locais disponíveis:
```
$ localedef --list
```
Se isso retornar uma lista vazia ou não contiver a localidade padrão, sua configuração de localidade está quebrada.
1. Confira o último `yum` comando:
```
$ yum history
$ yum history info #ID
```
Se a última ID não tiver `Return-Code: Success`, os scripts de pós-instalação podem não ter sido executados com êxito.
#### Como resolver
Reconstrua a localidade reinstalando os pacotes de idiomas:
```
$ sudo yum reinstall glibc-all-langpacks
```
Após a reconstrução, verifique se o problema foi corrigido executando:
```
$ su - pcluster-admin
```
Se nenhum erro ou aviso for exibido, o problema foi resolvido.
### Conflitos de pacotes do SO
Ao instalar pacotes personalizados ou modificar pacotes do sistema, podem surgir conflitos que impedem a operação adequada do cluster.
#### Como diagnosticar
1. Verifique se há erros relacionados ao pacote no log do chef-client:
```
$ less /var/log/chef-client.log
```
1. Procure conflitos de dependência de pacotes no log cfn-init:
```
$ less /var/log/cfn-init.log
```
#### Como resolver
1. Se um pacote específico estiver causando problemas, tente reinstalá-lo:
```
$ sudo yum reinstall package-name
```
1. Para conflitos de dependência, talvez seja necessário remover pacotes conflitantes:
```
$ sudo yum remove conflicting-package
```
1. Se o problema persistir, considere criar uma AMI personalizada com os pacotes necessários pré-instalados usando o `pcluster build-image` comando. Para obter mais informações, consulte [AWS ParallelCluster Personalização da AMI](custom-ami-v3.md).
### Modificações no arquivo de configuração do sistema
A modificação de arquivos críticos de configuração do sistema pode causar falhas no cluster, especialmente se esses arquivos forem gerenciados pelo AWS ParallelCluster.
#### Como diagnosticar
1. Verifique se há erros no log do chef-client que mencionam arquivos de configuração específicos:
```
$ grep -i "config" /var/log/chef-client.log
```
1. Procure erros de permissão ou sintaxe nos arquivos de configuração:
```
$ less /var/log/cfn-init.log
```
#### Como resolver
1. Restaure os arquivos de configuração modificados para seu estado original:
```
$ sudo cp /etc/file.conf.bak /etc/file.conf
```
1. Se você precisar fazer alterações persistentes nos arquivos de configuração do sistema, use ações de bootstrap personalizadas em vez de modificar diretamente os arquivos:
```
HeadNode:
CustomActions:
OnNodeConfigured:
Script: s3://bucket-name/config-script.sh
```
Para obter mais informações, consulte [Ações de bootstrap personalizadas](custom-bootstrap-actions-v3.md).
1. Para alterações de configuração que devem ser feitas diretamente nos arquivos do sistema, considere criar uma AMI personalizada. Para obter mais informações, consulte [AWS ParallelCluster Personalização da AMI](custom-ami-v3.md).
### Atualizações do kernel e problemas de compatibilidade
As atualizações do kernel podem causar problemas de compatibilidade com determinados AWS serviços, especialmente com o Amazon FSx for Lustre.
#### Como diagnosticar
1. Verifique se as atualizações do kernel foram aplicadas:
```
$ uname -r
```
1. Procure falhas de FSx montagem da Amazon nos registros:
```
$ grep -i "fsx" /var/log/chef-client.log
```
#### Como resolver
1. Para o Ubuntu 22.04, evite atualizar para o kernel mais recente, pois não há nenhum FSx cliente Amazon para esse kernel. Para obter mais informações, consulte [Considerações sobre sistemas operacionais](operating-systems-v3.md#OS-Consideration-v3).
1. Se você já atualizou o kernel e está enfrentando problemas, considere fazer o downgrade para uma versão compatível do kernel:
```
$ sudo apt install linux-image-previous-version
```
1. Para personalizações persistentes do kernel, crie uma AMI personalizada com a versão específica do kernel de que você precisa. Para obter mais informações, consulte [AWS ParallelCluster Personalização da AMI](custom-ami-v3.md).
## Práticas recomendadas para alterações na configuração do sistema operacional
Para minimizar os problemas ao fazer alterações na configuração do sistema operacional:
1. **Use ações personalizadas do Bootstrap**: em vez de modificar diretamente os arquivos do sistema, use `OnNodeStart` nossos `OnNodeConfigured` scripts para fazer alterações de maneira controlada. Para obter mais informações, consulte [Ações de bootstrap personalizadas](custom-bootstrap-actions-v3.md).
1. **Crie instâncias personalizadas AMIs**: para modificações significativas no sistema operacional, crie uma AMI personalizada usando, `pcluster build-image` em vez de fazer alterações, nas instâncias em execução. Para obter mais informações, consulte [AWS ParallelCluster Personalização da AMI](custom-ami-v3.md).
1. **Teste as alterações primeiro**: antes de aplicar as alterações em um cluster de produção, teste-as em um pequeno cluster de teste para garantir a compatibilidade.
1. **Alterações no documento**: acompanhe todas as alterações de configuração do sistema operacional feitas para facilitar a solução de problemas.
1. **Arquivos de configuração de backup**: antes de modificar qualquer arquivo de configuração do sistema, crie um backup:
```
$ sudo cp /etc/file.conf /etc/file.conf.bak
```
1. **Verifique os registros após as alterações**: depois de fazer alterações na configuração do sistema operacional, verifique se há erros nos registros:
```
$ less /var/log/cfn-init.log
$ less /var/log/chef-client.log
```
Seguindo essas diretrizes, você pode minimizar o risco de alterações na configuração do sistema operacional causarem falhas no cluster e solucionar com mais eficiência quaisquer problemas que surjam.