Solução de problemas do AWS ParallelCluster - AWS ParallelCluster
Recuperando e preservando logsSolução de problemas de implantação de pilhaSolução de problemas em clusters em modo de várias filasSolução de problemas em clusters em modo de fila únicaGrupos de posicionamento e problemas de execução de instânciasDiretórios que não podem ser substituídosSolução de problemas no Amazon DCVSolução de problemas em clusters com integração AWS BatchSolução de problemas quando um recurso não é criadoSolução de problemas de tamanho da política do IAMSuporte adicional

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

Solução de problemas do AWS ParallelCluster

A comunidade AWS ParallelCluster mantém uma página Wiki que fornece muitas dicas de solução de problemas na Wiki do GitHub do AWS ParallelCluster. Para obter uma lista de problemas conhecidos, consulte Problemas conhecidos.

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 Criar um arquivo dos logs de um cluster na Wiki do GitHub do AWS ParallelCluster 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 <cluster_name> 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 <cluster_name>. A execução desse comando exclui o cluster, mas retém o grupo de logs armazenado no Amazon CloudWatch. Para obter mais informações sobre esse comando, consulte a documentação do pcluster delete.

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

  • /var/log/cloud-init.log é o log do cloud-init. 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. 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 o AWS ParallelCluster versão 2.9.0 e posterior com o programador de trabalhos do Slurm. Para obter mais informações sobre o modo de várias filas, consulte Modo de fila múltipla.

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 init do AWS CloudFormation. 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

Este é o log do daemon de controle do Slurm. O AWS ParallelCluster não toma decisões de escala. 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. 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 o ResumeProgram nunca foi chamado, você pode verificar o log slurmctld (/var/log/slurmctld.log) para determinar se o Slurm já tentou chamar ResumeProgram com o nó).

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

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

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

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

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

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

  • Nós de computação:

    • 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 clustermgtd não encerrou o nó, primeiro verifique se esse era um encerramento esperado pelo Amazon EC2, mais especificamente um encerramento pontual. O computemgtd, executado em um nó de computação, também pode realizar ações para encerrar um nó se clustermgtd for determinado como não saudável. Verifique no log computemgtd (/var/log/parallelcluster/computemgtd) se computemgtd encerrou o nó.

  • Falha nos nós

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

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

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

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

        aws ec2 modify-instance-attribute --instance-id i-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, consulte o log SuspendProgram para ver se o SuspendProgram foi chamado pelo slurmctldcom o nó específico como argumento. Observe que o SuspendProgram não executa nenhuma ação. Em vez disso, ele só cria logs quando é chamado. 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, 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.

Solução de problemas em clusters em modo de fila única

nota

A partir da versão 2.11.5, AWS ParallelCluster não suporta o uso de programadores SGE ou Torque.

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 um AWS ParallelCluster versão anterior à 2.9.0 e programadores de trabalhos SGE, Torque, ou Slurm.

  • Lançado usando um AWS ParallelCluster versão anterior à 2.9.0 e programadores de trabalhos SGE ou Torque.

Logs de chaves

Os arquivos de log a seguir são os principais registros do nó principal.

Para o 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 versões do AWS ParallelCluster:

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

/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 de inicialização do CloudFormation. 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.

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 o AWS ParallelCluster versão v2.9.0 ou posterior, estiver usando Slurm e quiser evitar esse problema, você deve atualizar e mudar para um cluster compatível com o modo de várias filas. Para fazer isso, execute pcluster-config convert.

Para clusters de escala ultralarga, talvez seja necessário um ajuste adicional em seu sistema. Para obter mais informações, entre em contato com o 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 para DYNAMIC e defina o parâmetro placement como compute.

Se você precisar de um sistema de arquivos compartilhado de alto desempenho, considere usar o FSx para 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 terá o mesmo valor que o parâmetro master_instance_type, o parâmetro placement é definido como cluster e o parâmetro compute_subnet_id não é especificado. Com essa configuração, o valor do parâmetro 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 e Perfis e limitações de grupos de posicionamento 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
nota

A partir da versão 2.11.5, AWS ParallelCluster não suporta o uso de programadores SGE ou Torque.

Isso inclui Son of Grid Engine e arquivos relacionados. (Condicional, somente se scheduler = sge.)

/opt/slurm

Isso inclui Slurm Workload Manager e arquivos relacionados. (Condicional, somente se scheduler = slurm.)

/opt/torque
nota

A partir da versão 2.11.5, AWS ParallelCluster não suporta o uso de programadores SGE ou Torque.

Isso inclui Torque Resource Manager e arquivos relacionados. (Condicional, somente se scheduler = torque.)

Solução de problemas no Amazon DCV

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 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 do usuário AWS ParallelCluster não é carregado.

Para obter o perfil do shell corretamente e acessar o ambiente do usuário do AWS ParallelCluster, realize um dos seguintes procedimentos:

  • Altere as configurações do terminal padrão:

    1. Escolha o menu Editar no terminal Gnome.

    2. Selecione Preferências, e em seguida, Perfis.

    3. Escolha Comando e selecione Executar comando como shell de login.

    4. 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 integração AWS Batch

Esta seção é relevante para clusters com integração com programadores AWS Batch.

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.

Problemas de envio de trabalhos paralelos de vários nós AWS Batch

Se você tiver problemas ao enviar trabalhos paralelos de vários nós ao usar o AWS Batch como programador de trabalhos, você deve atualizar para o AWS ParallelCluster 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.

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 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 comando awsbstat -d para obter um link para os logs de trabalho armazenados pelo 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 não é criado, o ParallelCluster retorna uma mensagem de erro semelhante à mostrada a seguir.

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ê pode usar o console do CloudFormation para ver mais informações sobre o status "Cluster creation failed".

Veja as mensagens de erro do CloudFormation no console.

  1. Faça login no AWS Management Console, e acesse https://console.aws.amazon.com/cloudformation.

  2. Selecione a pilha denominada parallelcluster-nome_do_cluster.

  3. Escolha a guia Eventos.

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

  5. Um exemplo de mensagem de erro AWS CloudFormation:

    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 o IAM e cotas do AWS STS, requisitos de nome e limites de caracteres para verificar as cotas de políticas gerenciadas associadas à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 do GitHub Wiki ou a página de problemas. Para problemas mais urgentes, entre em contato com Suporte ou abra um novo problema no GitHub.