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
Tópicos
- Recuperando e preservando logs
- Solução de problemas de implantação de pilha
- Solução de problemas em clusters em modo de várias filas
- Solução de problemas em clusters em modo de fila única
- Grupos de posicionamento e problemas de execução de instâncias
- Diretórios que não podem ser substituídos
- Solução de problemas no Amazon DCV
- Solução de problemas em clusters com integração AWS Batch
- Solução de problemas quando um recurso não é criado
- Solução de problemas de tamanho da política do IAM
- Suporte adicional
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
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.cluster_name
>
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 logs armazenado no Amazon CloudWatch. Para obter mais informações sobre esse comando, consulte a documentação do pcluster delete.cluster_name
>
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 scriptcfn-init
. Primeiro, verifique esse log. É provável que você veja um erro como oCommand 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.
Tópicos
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 doclustermgtd
. /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 daemonclustermgtd
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 oResumeProgram
foi chamado com o nó. (Se oResumeProgram
nunca foi chamado, você pode verificar o logslurmctld
(/var/log/slurmctld.log
) para determinar se o Slurm já tentou chamarResumeProgram
com o nó). -
Observe que permissões incorretas em
ResumeProgram
podem fazer com queResumeProgram
falhe silenciosamente. Se você estiver usando uma AMI personalizada com modificações na configuraçãoResumeProgram
, verifique se aResumeProgram
é de propriedade do usuárioslurm
e tem a permissão de744
(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
) seclustermgtd
realizou a ação de substituir ou encerrar um nó. Observe queclustermgtd
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 emDOWN
), verifique o logslurmctld
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. Ocomputemgtd
, executado em um nó de computação, também pode realizar ações para encerrar um nó seclustermgtd
for determinado como não saudável. Verifique no logcomputemgtd
(/var/log/parallelcluster/computemgtd
) secomputemgtd
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 eclustermgtd
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 logclustermgtd
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 oSuspendProgram
foi chamado peloslurmctld
com o nó específico como argumento. Observe que oSuspendProgram
não executa nenhuma ação. Em vez disso, ele só cria logs quando é chamado. Todos encerramentos de instância e redefinições deNodeAddr
são feitos porclustermgtd
. O Slurm coloca automaticamente os nós de volta em um estadoPOWER_SAVING
depois deSuspendTimeout
.
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.
Tópicos
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. Oclustermgtd
é 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. Ojobwatcher
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
. Daemonsnodewatcher
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 eventosqswatcher
foi processado. Na maioria dos casos, esses problemas ocorrem porquesqswatcher
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 daemonjobwatcher
calculou o número adequado de nós necessários e atualizou o Auto Scaling Group. Observe quejobwatcher
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 daemonsnodewatcher
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 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:
-
Escolha o menu Editar no terminal Gnome.
-
Selecione Preferências, e em seguida, Perfis.
-
Escolha Comando e selecione Executar comando como shell de login.
-
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.
-
Faça login no AWS Management Console, e acesse https://console.aws.amazon.com/cloudformation
. -
Selecione a pilha denominada parallelcluster-
nome_do_cluster
. -
Escolha a guia Eventos.
-
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.
-
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