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 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** + [Recuperando e preservando logs](#retrieving-and-preserve-logs) + [Solução de problemas de implantação de pilha](#troubleshooting-stack-creation-failures) + [Solução de problemas em clusters em modo de várias filas](#multiple-queue-mode) + [Solução de problemas em clusters em modo de fila única](#troubleshooting-issues-in-single-queue-clusters) + [Grupos de posicionamento e problemas de execução de instâncias](#placement-groups-and-instance-launch-issues) + [Diretórios que não podem ser substituídos](#directories-cannot-be-replaced) + [Solução de problemas no Amazon DCV](#nice-dcv-troubleshooting) + [Solução de problemas em clusters com AWS Batch integração](#clusters-with-aws-batch-integration) + [Solução de problemas quando um recurso não é criado](#troubleshooting-resource-fails-to-create) + [Solução de problemas de tamanho da política do IAM](#troubleshooting-policy-size-issues) + [Suporte adicional](#getting-support) ## Recuperando e preservando logs Os logs são um recurso útil para solucionar problemas. Antes de usar logs para solucionar problemas com seus recursos do AWS ParallelCluster , você deve primeiro criar um arquivo de logs de cluster. Siga as etapas descritas no tópico [Criando um arquivo dos registros de um cluster](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) no [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) para iniciar esse processo. Se um de seus clusters em execução estiver enfrentando problemas, coloque o cluster em um estado `STOPPED` executando o comando ``pcluster stop` ` antes de começar a solucionar o problema. Isso evita incorrer em custos inesperados. Se `pcluster` parar de funcionar ou se você quiser excluir um cluster enquanto ainda preserva seus logs, execute o comando ``pcluster delete` —keep-logs `. A execução desse comando exclui o cluster, mas retém o grupo de registros armazenado na Amazon. CloudWatch Para obter mais informações sobre esse comando, consulte a documentação do [`pcluster delete`](pcluster.delete.md). ## Solução de problemas de implantação de pilha Se o cluster não for criado e reverter a criação da pilha, você poderá examinar os arquivos de log a seguir para diagnosticar o problema. Você deseja procurar a saída de `ROLLBACK_IN_PROGRESS` nesses logs. A mensagem de falha se parecerá com a seguinte: ``` $ pcluster create mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081 ``` Para diagnosticar o problema, crie o cluster novamente usando [`pcluster create`](pluster.create.md), incluindo o sinalizador `--norollback`. Em seguida, execute o SSH no cluster: ``` $ pcluster create mycluster --norollback ... $ pcluster ssh 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 um 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 em clusters em modo de várias filas Esta seção é relevante para clusters que foram instalados usando a AWS ParallelCluster versão 2.9.0 e posterior com o agendador de Slurm tarefas. Para obter mais informações sobre o modo de várias filas, consulte [Modo de fila múltipla](queue-mode.md). **Topics** + [Logs de chaves](#key-logs) + [**Solução de problemas de inicialização do nó**](#troubleshooting-node-initialization-issues) + [**Solução de problemas inesperados de substituições e encerramentos de nós**](#troubleshooting-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) + [**Solucionando outros problemas conhecidos de nós e trabalhos**](#troubleshooting-other-known-node-and-job-issues) ### Logs de chaves A tabela a seguir fornece uma visão geral dos principais logs do nó principal: `/var/log/cfn-init.log` Esse é o log CloudFormation de inicialização. Ele contém todos os comandos que foram executados quando uma instância foi configurada. É útil 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. É útil para solucionar problemas de inicialização. `/var/log/parallelcluster/slurm_resume.log` Esse é um log do `ResumeProgram`. Ele lança instâncias para nós dinâmicos e é útil para solucionar problemas de inicialização de nós dinâmicos. `/var/log/parallelcluster/slurm_suspend.log` Esse é o log do `SuspendProgram`. É chamado quando as instâncias são encerradas para nós dinâmicos e é útil para solucionar problemas de encerramento de nós dinâmicos. Ao verificar esse log, você também deve verificar o log do `clustermgtd`. `/var/log/parallelcluster/clustermgtd` Esse é o log do `clustermgtd`. Ele é executado como o daemon centralizado que gerencia a maioria das ações de operação do cluster. É útil para solucionar qualquer problema de inicialização, encerramento ou operação do cluster. `/var/log/slurmctld.log` Esse é 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. 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. É útil para solucionar problemas de inicialização. `/var/log/parallelcluster/computemgtd` Esse é o log do `computemgtd`. Ele é executado em cada nó de computação para monitorar o nó no raro caso de o daemon `clustermgtd` no nó principal estar off-line. É útil para solucionar problemas inesperados de encerramento. `/var/log/slurmd.log` Este é o log do daemon de computação do Slurm. É útil para solucionar problemas de inicialização e de falhas de computação. ### **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. **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`. Esses logs devem conter 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 pré-instalação ou pós-instalação forem especificados na configuração do cluster, verifique novamente 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. Sendo assim, 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 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:** + **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`. ### **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 ou encerrados inesperadamente** + Verifique no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) se `clustermgtd` realizou a ação de substituir ou encerrar 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 realizar uma ação para 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ó. + Depois que o nó for iniciado, ative a proteção contra encerramento usando esse comando. ``` aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination ``` + Recupere a saída do console do nó com esse comando. ``` aws ec2 get-console-output --instance-id i-xyz --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 [`scaledown_idletime`](scaling-section.md#scaledown-idletime), 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`. ### **Solucionando outros problemas conhecidos de nós e trabalhos** 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, AWS ParallelCluster somente inicia, encerra ou mantém recursos de acordo com Slurm as instruções. Para esses problemas, verifique o log `slurmctld` para solucioná-los. ## Solução de problemas em clusters em modo de fila única **nota** A partir da versão 2.11.5, AWS ParallelCluster não oferece suporte ao uso de agendadores SGE ou Torque agendadores. Esta seção se aplica a clusters que não têm o modo de várias filas com uma das duas configurações a seguir: + Lançado usando uma AWS ParallelCluster versão anterior à 2.9.0 e SGETorque, ou agendadores de Slurm tarefas. + Lançado usando a AWS ParallelCluster versão 2.9.0 ou posterior e/ou agendadores SGE de Torque tarefas. **Topics** + [Logs de chaves](#key-logs-1) + [**Solução de problemas de falha nas operações de inicialização e junção**](#troubleshooting-failed-launch-and-join-operations) + [Solucionar problemas de escala](#troubleshooting-scaling-issues) + [Solução de outros problemas relacionados ao cluster](#troubleshooting-other-cluster-related-issues) ### Logs de chaves Os arquivos de log a seguir são os principais registros do nó principal. Para a AWS ParallelCluster versão 2.9.0 ou posterior: `/var/log/chef-client.log` Este é o log do cliente CINC (chef). Ele contém todos os comandos que foram executados pelo CINC. É útil para solucionar problemas de inicialização. Para todas as AWS ParallelCluster versões: `/var/log/cfn-init.log` Esse é o log do `cfn-init`. Ele contém todos os comandos que foram executados quando uma instância foi configurada e, portanto, é útil para solucionar problemas de inicialização. Para mais informações, consulte [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). `/var/log/clustermgtd.log` Este é o log `clustermgtd` para programadores Slurm. O `clustermgtd` é executado como o daemon centralizado que gerencia a maioria das ações de operação do cluster. É útil para solucionar qualquer problema de inicialização, encerramento ou operação do cluster. `/var/log/jobwatcher` Este é o log `jobwatcher` para programadores SGE e Torque. O `jobwatcher` monitora a fila do programador e atualiza o grupo do Auto Scaling. É útil para solucionar problemas relacionados com aumentar a escala verticalmente dos nós. `/var/log/sqswatcher` Este é o log `sqswatcher` para os programadores SGE e Torque. `sqswatcher` processa o evento de instância pronta enviado por uma instância de computação após a inicialização bem-sucedida. Ele também adiciona nós de computação à configuração do programador. Esse registro é útil para solucionar o motivo pelo qual um nó ou nós falharam em ingressar em um cluster. Estes são os principais logs dos nós de computação. AWS ParallelCluster versão 2.9.0 ou posterior `/var/log/cloud-init-output.log` Esse é o log de inicialização do Cloud. Ele contém todos os comandos que foram executados quando uma instância foi configurada. É útil para solucionar problemas de inicialização. AWS ParallelCluster versões anteriores à 2.9.0 `/var/log/cfn-init.log` Esse é o log CloudFormation de inicialização. Ele contém todos os comandos que foram executados quando uma instância foi configurada. É útil para solucionar problemas de inicialização Todas as versões `/var/log/nodewatcher` Esse é o log `nodewatcher`. Daemons `nodewatcher` que são executados em cada nó de computação ao usar programadores SGE e Torque. Eles reduzem verticalmente a escala de um nó se ele estiver ocioso. Esse log é útil para qualquer problema relacionado à redução vertical da escala dos recursos. ### **Solução de problemas de falha nas operações de inicialização e junção** + **Logs aplicáveis:** + `/var/log/cfn-init-cmd.log` (nó principal e nó de computação) + `/var/log/sqswatcher` (nó principal) + Se os nós falharem na inicialização, verifique o log `/var/log/cfn-init-cmd.log` para ver a mensagem de erro específica. Na maioria dos casos, as falhas de inicialização do nó são causadas por uma falha na configuração. + Se os nós de computação não conseguirem ingressar na configuração do programador, apesar da configuração bem-sucedida, verifique o log `/var/log/sqswatcher` para ver se o evento `sqswatcher` foi processado. Na maioria dos casos, esses problemas ocorrem porque `sqswatcher` não processou o evento. ### Solucionar problemas de escala + **Logs aplicáveis:** + `/var/log/jobwatcher` (nó principal) + `/var/log/nodewatcher` (nó de computação) + **Problemas de aumento de escala:** para o nó principal, verifique o log `/var/log/jobwatcher` para ver se o daemon `jobwatcher` calculou o número adequado de nós necessários e atualizou o Auto Scaling Group. Observe que `jobwatcher` monitora a fila do programador e atualiza o Auto Scaling Group. + **Problemas de redução de escala:** para nós de computação, verifique o log `/var/log/nodewatcher` no nó problemático para ver por que a escala do nó foi reduzida verticalmente. Observe que os daemons `nodewatcher` reduzem verticalmente a escala de um nó de computação se ele estiver ocioso. ### Solução de outros problemas relacionados ao cluster Um problema conhecido é que as notas de computação aleatórias falham em clusters de grande escala, especificamente aqueles com 500 ou mais nós de computação. Esse problema está relacionado a uma limitação da arquitetura de escalabilidade do cluster de fila única. Se você quiser usar um cluster de grande escala, estiver usando a AWS ParallelCluster versão v2.9.0 ou posterior, estiver usando e quiser evitar esse problemaSlurm, você deve atualizar e mudar para um cluster compatível com o modo de várias filas. Para fazer isso, execute [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert). Para ultra-large-scale clusters, talvez seja necessário um ajuste adicional em seu sistema. Para obter mais informações, entre em contato Suporte. ## 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 placement group 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 esse erro ao usar grupos de posicionamento de cluster, defina o parâmetro [`placement_group`](cluster-definition.md#placement-group) para `DYNAMIC` e defina o parâmetro [`placement`](cluster-definition.md#placement) como `compute`. [Se você precisar de um sistema de arquivos compartilhado de alto desempenho, considere usar FSx o Lustre.](https://aws.amazon.com/fsx/lustre/) Se o nó principal precisar estar no grupo de posicionamento, use o mesmo tipo de instância e sub-rede para os nós principais e também para os nós de computação. Ao fazer isso, o parâmetro [`compute_instance_type`](cluster-definition.md#compute-instance-type) terá o mesmo valor que o parâmetro [`master_instance_type`](cluster-definition.md#master-instance-type), o parâmetro [`placement`](cluster-definition.md#placement) é definido como `cluster` e o parâmetro [`compute_subnet_id`](vpc-section.md#compute-subnet-id) não é especificado. Com essa configuração, o valor do parâmetro [`master_subnet_id`](vpc-section.md#master-subnet-id) é usado para os nós de computação. Para ter mais informações, consulte [Solucionar problemas de inicialização de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) e [Perfis e limitações de grupos de posicionamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) no *Guia do usuário do Amazon EC2*. ## Diretórios que não podem ser substituídos Os diretórios a seguir são compartilhados entre os nós e não podem ser substituídos. `/home` Isso inclui a pasta base do usuário padrão (`/home/ec2_user` no Amazon Linux, `/home/centos` no CentOS, e `/home/ubuntu` no Ubuntu). `/opt/intel` Isso inclui Intel MPI, Intel Parallel Studio e arquivos relacionados. `/opt/sge` A partir da versão 2.11.5, AWS ParallelCluster não oferece suporte ao uso de agendadores SGE ou Torque agendadores. Isso inclui Son of Grid Engine e arquivos relacionados. (Condicional, somente se [`scheduler`](cluster-definition.md#scheduler)` = sge`.) `/opt/slurm` Isso inclui Slurm Workload Manager e arquivos relacionados. (Condicional, somente se [`scheduler`](cluster-definition.md#scheduler)` = slurm`.) `/opt/torque` A partir da versão 2.11.5, AWS ParallelCluster não oferece suporte ao uso de agendadores SGE ou Torque agendadores. Isso inclui Torque Resource Manager e arquivos relacionados. (Condicional, somente se [`scheduler`](cluster-definition.md#scheduler)` = torque`.) ## Solução de problemas no Amazon DCV **Topics** + [Logs do Amazon DCV](#nice-dcv-troubleshooting-logs) + [Memória do tipo de instância do Amazon DCV](#nice-dcv-troubleshooting-memory) + [Problemas no Ubuntu Amazon DCV](#nice-dcv-troubleshooting-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. ### Memória do tipo de instância do Amazon DCV 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. ### Problemas no Ubuntu Amazon DCV Ao executar o Gnome Terminal em uma sessão DCV no Ubuntu, você pode não ter acesso automático ao ambiente do usuário AWS ParallelCluster disponibilizado 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 é relevante para clusters com integração com AWS Batch agendadores. ### Problemas no nó principal Os problemas de configuração relacionados ao nó principal podem ser solucionados da mesma forma que um cluster de fila única. Para obter mais informações sobre esses problemas, consulte [Solução de problemas em clusters em modo de fila única](#troubleshooting-issues-in-single-queue-clusters). ### AWS Batch problemas de envio de trabalhos paralelos de vários nós Se você tiver problemas ao enviar trabalhos paralelos de vários nós ao usar AWS Batch como agendador de trabalhos, atualize para a AWS ParallelCluster versão 2.5.0. Se isso não for viável, você pode usar a solução alternativa detalhada no tópico: [Autocorreção de um cluster usado para enviar trabalhos paralelos de vários nós com o AWS Batch](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch). ### 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`` para recuperar a saída do trabalho. Você também pode executar o ``awsbstat` -d` comando para obter um link para os registros de trabalhos armazenados pela Amazon CloudWatch. ## Solução de problemas quando um recurso não é criado Esta seção é relevante para recursos de cluster quando eles não são criados. Quando um recurso falha na criação, ParallelCluster retorna uma mensagem de erro como a seguinte. ``` pcluster create -c config my-cluster Beginning cluster creation for cluster: my-cluster WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). Info: There is a newer version 3.0.3 of AWS ParallelCluster available. Creating stack named: parallelcluster-my-cluster Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::CloudFormation::Stack MasterServerSubstack Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. - AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. - AWS::EC2::Instance MasterServer 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) } ``` Por exemplo, se você ver a mensagem de status exibida na resposta de comando anterior, deverá usar tipos de instância que não excedam seu limite atual de vCPU ou solicitar mais capacidade de vCPU. Você também pode usar o CloudFormation console para ver informações sobre o `"Cluster creation failed"` status. 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 parallelcluster-. *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. Um exemplo de mensagem AWS CloudFormation de erro: ``` 2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. ``` ## Solução de problemas de tamanho da política do IAM Consulte [IAM e AWS STS cotas, requisitos de nome e limites de caracteres](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) para verificar as cotas nas políticas gerenciadas vinculadas às funções. Se o tamanho de uma política gerenciada exceder a cota, divida a política em duas ou mais políticas. Se você exceder a cota do número de políticas anexadas a um perfil do IAM, crie funções adicionais e distribua as políticas entre elas para atingir a cota. ## Suporte adicional Para obter uma lista de problemas conhecidos, consulte a página principal [GitHubdo Wiki](https://github.com/aws/aws-parallelcluster/wiki) ou a página de [problemas](https://github.com/aws/aws-parallelcluster/issues). Para problemas mais urgentes, entre em contato Suporte ou abra um [novo GitHub problema](https://github.com/aws/aws-parallelcluster/issues).