AWS ParallelCluster solução de problemas - 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 na Amazon DCVSolução de problemas em clusters com integração AWS BatchSolução de problemas quando um recurso não é criadoSolução de problemas IAM de tamanho da políticaSuporte 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á.

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. 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 Criando um arquivo dos registros de um cluster no AWS ParallelCluster GitHub 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 <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 registros armazenado na 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, 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 a AWS ParallelCluster versão 2.9.0 e posterior com o Slurm agendador de tarefas. 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 AWS 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 por meio do 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 Slurm registro do daemon de controle. AWS ParallelCluster não toma decisões de escalabilidade. Em vez disso, ele apenas tenta lançar recursos para satisfazer o Slurm requisitos. É útil para problemas de 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 Slurm log do daemon de computação. É ú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á tentei ligar ResumeProgram com o nó.)

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

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

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

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

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

    • Se o nó clustermgtd não foi encerrado, primeiro verifique se essa era uma rescisão esperada pela AmazonEC2, mais especificamente uma rescisão pontual. computemgtd, executado em um nó de computação, também pode 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 na Amazon EC2 para esse nó, o nó pode falhar durante a configuração. Para recuperar o log de um computador (/var/log/cloud-init-output.log), execute as seguintes etapas:

      • Envie um trabalho para alugar Slurm crie um novo nó.

      • 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. Todo encerramento da instância e restauração de NodeAddr são feitos por clustermgtd. Slurm coloca os nós de volta em um POWER_SAVING estado posterior SuspendTimeout automaticamente.

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 apenas inicia, encerra ou mantém recursos de acordo com Slurm 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 suporta o uso de 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 SGE, Torque, ou Slurm agendadores de trabalho.

  • Lançado usando a AWS ParallelCluster versão 2.9.0 ou posterior e SGE ou Torque agendadores de trabalho.

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 registro do cliente CINC (chef). Ele contém todos os comandos que foram executadosCINC. É ú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.

/var/log/clustermgtd.log

Este é o clustermgtd registro para Slurm agendadores. 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 jobwatcher registro para SGE e Torque agendadores. jobwatchermonitora a fila do agendador e atualiza o Auto Scaling Group. É útil para solucionar problemas relacionados com aumentar a escala verticalmente dos nós.

/var/log/sqswatcher

Este é o sqswatcher registro para SGE e Torque agendadores. sqswatcherprocessa o evento Instance Ready 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 nodewatcher registro. nodewatcherdaemons que são executados em cada nó de computação ao usar SGE e Torque agendadores. 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, está usando a AWS ParallelCluster versão v2.9.0 ou posterior, está usando Slurme, para 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 AWS Support.

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 FSx o 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 obter mais informações, consulte Solução de problemas de lançamento de instâncias e funções e limitações de grupos de posicionamento no Guia EC2 do usuário da Amazon

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 inicial padrão do usuário (/home/ec2_userno Amazon Linux, /home/centos em CentOS, e assim /home/ubuntu por diante Ubuntu).

/opt/intel

Isso inclui IntelMPI, 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 SGE ou Torque agendadores.

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 SGE ou Torque agendadores.

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

Solução de problemas na Amazon DCV

Registros para a Amazon DCV

Os registros da Amazon DCV são gravados em arquivos no /var/log/dcv/ diretório. A revisão desses logs pode ajudar a solucionar problemas.

Memória do tipo de DCV instância Amazon

O tipo de instância deve ter pelo menos 1,7 gibibyte (GiB) de para executar a Amazon. RAM DCV Nano e micro os tipos de instância não têm memória suficiente para executar a AmazonDCV.

DCVProblemas com o Ubuntu Amazon

Ao executar o Gnome Terminal em uma DCV sessão no Ubuntu, você pode não ter acesso automático ao ambiente do usuário que o AWS ParallelCluster disponibiliza 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.

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

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.

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 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 mostrada na resposta do comando anterior, deverá usar tipos de instância que não excedam seu CPU limite atual de v ou solicitar mais CPU capacidade v.

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 AWS Management Console e navegue até https://console.aws.amazon.com/cloudformation.

  2. Selecione a pilha chamada parallelcluster-cluster_name.

  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 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 IAM de tamanho da política

Consulte AWS STS cotas, requisitos de nome e limites de caracteres para verificar as cotas nas políticas gerenciadas associadas às funções. IAM 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 uma IAM função, crie funções adicionais e distribua as políticas entre elas para atender à cota.

Suporte adicional

Para obter uma lista de problemas conhecidos, consulte a página principal GitHubdo Wiki ou a página de problemas. Para problemas mais urgentes, entre em contato AWS Support ou abra um novo GitHub problema.