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á.
Tentando atualizar um cluster
A seção a seguir fornece possíveis soluções para problemas que podem ocorrer enquanto você tenta atualizar um cluster.
O comando pcluster update-cluster falha ao ser executado localmente
Verifique o ~/.parallelcluster/pcluster-cli.log em seu sistema de arquivos local para ver os detalhes da falha.
A atualização do cluster atingiu o tempo limite
Isso pode ser um problema relacionado ao cfn-hup não sendo executado. Se o daemon cfn-hup for encerrado por uma causa externa, ele não será reiniciado automaticamente. Se cfn-hup não estiver em execução, durante uma atualização do cluster, a CloudFormation pilha inicia o processo de atualização conforme o esperado, mas o procedimento de atualização não é ativado no nó principal e a implantação da pilha eventualmente expira. Para obter mais informações, consulte Solução de problemas de tempo limite de atualização do cluster quando o cfn-hup não está em execução para solucionar o problema e corrigir o problema.
ClusterStatus é UPDATE_FAILED
Causa raiz
Para identificar a causa raiz da falha, o ponto de partida é examinar os eventos da pilha do cluster e o /var/log/chef-client.log nó principal.
Uma possível causa é que pelo menos um nó do cluster não aplicou a atualização. Você pode recuperar a lista de nós que falharam na atualização /var/log/chef-client.log no nó principal procurando Check cluster readiness no registro.
Verifique se seu problema foi mencionado em Problemas GitHub conhecidos
Prevenindo
Uma atualização de cluster pode falhar se pelo menos um nó no cluster não aplicar a atualização com êxito. Para reduzir o risco de falha na atualização do cluster, recomendamos encerrar os nós quebrados antes de iniciar a atualização. Um exemplo de nós que podem ser quebrados são os nós de computação presos no COMPLETING estado por mais tempo do que a duração esperada do epílogo. Para detectar esses nós, você pode executar o comando a seguir, adaptando o threshold valor às suas necessidades (o valor deve ser maior do que a duração máxima esperada para seus epílogos).
$scontrol show nodes --json | jq -r --argjson threshold 60 ' .nodes[] | select(.state | index("COMPLETING")) | select((now - .last_busy.number) > $threshold) | .name '
Se recuperando
Se a atualização falhar, a reversão é o mecanismo esperado para recuperar o estado do cluster.
Se a reversão falhar, o estado do cluster não é determinístico. Nesse caso, pode ser que tenha clustermgtd sido interrompido para evitar a amplificação de falhas. Recomendamos iniciá-lo executando o seguinte comando no nó principal. Adapte a versão do Python à que vem com sua versão: AWS ParallelCluster
$/opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
ClusterStatus é UPDATE_FAILED e a nuvem é UPDATE_ROLLBACK_FAILED FormationStackStatus
é UPDATE_FAILED e a nuvem é UPDATE_ROLLBACK_FAILED FormationStackStatus Quando pcluster describe-cluster relata que clusterStatus é UPDATE_FAILED e cloudFormationStackStatus éUPDATE_ROLLBACK_FAILED, tanto a atualização do cluster quanto a reversão subsequente falharam. Nesse estado, a pilha de clusters não pode aceitar nenhuma atualização adicional e requer intervenção manual para ser desbloqueada.
Para desbloquear a pilha de clusters, conclua as seguintes etapas:
-
Corrija a causa raiz da falha.
-
Forçar a continuação da reversão.
$aws cloudformation continue-update-rollback --regionREGION--stack-nameCLUSTER_STACK_NAME -
Aguarde até que a pilha alcance o
UPDATE_ROLLBACK_COMPLETEstatus. -
Tente novamente a atualização original com o
pcluster update-clustercomando.
A pilha do cluster parece travada em UPDATE_IN_PROGRESS ou UPDATE_ROLLBACK_IN_PROGRESS
UPDATE_ROLLBACK_IN_PROGRESS A pilha de clusters pode ficar presa UPDATE_IN_PROGRESS ou UPDATE_ROLLBACK_IN_PROGRESS por no máximo 1 hora, se o Auto Scaling Group dos nós de login não conseguir se estabilizar devido a falhas de bootstrap nos nós de login.
Para verificar se você está nessa situação devido ao Auto Scaling Group dos nós de login, você precisa fazer as seguintes verificações: Na pilha principal, o único recurso que está dentro é a pilha aninhada UPDATE_IN_PROGRESS dos nós de login. Na pilha aninhada dos nós de login, o único recurso que está preso é o Auto Scaling Group dos nós de login. UPDATE_IN_PROGRESS
Se você estiver nesse cenário, poderá cancelar a atualização para não precisar esperar 1 hora para que a atualização seja concluída.
$aws cloudformation cancel-update-stack --regionREGION--stack-nameCLUSTER_STACK_NAME
O cancelamento da atualização aciona a reversão. Você não pode reduzir o tempo limite de 1 hora na reversão; portanto, na pior das hipóteses, você precisa esperar que a reversão atinja seu estado final.
Se a reversão for bem-sucedida, você poderá repetir imediatamente a atualização original do cluster depois de corrigir a causa raiz da falha. Caso contrário, consulte ClusterStatus é UPDATE_FAILED e a nuvem é UPDATE_ROLLBACK_FAILED FormationStackStatus.