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 AWS Atualizações da versão do cluster PCS

Este tópico ajuda você a identificar e resolver problemas comuns que podem ocorrer ao atualizar a versão do agendador em um cluster.

Os nós de computação não conseguem se conectar após a atualização

Causa comum

Depois de atualizar o cluster, os nós de computação recém-lançados não conseguem se registrar no controlador. Os nós iniciam, mas nunca aparecem na sinfo saída, e o grupo de nós de computação pode percorrer as instâncias repetidamente. Isso ocorre quando a AMI do grupo de nós de computação contém uma versão do agendador que está fora da janela de compatibilidade da nova versão do controlador.

Por exemplo, se você atualizar um cluster de 24.11 para 25.11, mas o grupo de nós de computação ainda usa uma AMI com o Slurm 23.11, novas instâncias não podem se conectar porque 23.11 está fora da janela de compatibilidade de 25.11.

Como diagnosticar

Você pode confirmar esse problema verificando os registros em dois lugares:

Registros do agendador

Se você tiver o registro do agendador ativado, verifique se há erros semelhantes aos seguintes nos CloudWatch registros do agendador em Registros:

error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

Esses erros indicam que um nó de computação com uma versão de agendador incompatível está tentando se conectar ao controlador. Para obter informações sobre como configurar o registro do agendador, consulteLogs do agendador no AWS PCS.

Registros de instâncias do nó de computação

Recupere a saída do console da instância ou conecte-se por meio do Systems Manager e verifique se há erros semelhantes aos seguintes no log de bootstrap:

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed

Para obter mais informações sobre como recuperar registros de instâncias, consulteRecuperar registros de instâncias.

Resolução

Atualize o grupo de nós de computação para usar uma AMI que contenha uma versão do agendador na janela de compatibilidade da sua nova versão do cluster:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Para determinar quais versões do agendador são compatíveis com seu cluster, consulteCompatibilidade da versão.

Para obter informações sobre como criar AMIs personalizadas com a versão correta do agendador, consulte. Amazon Machine Images (AMIs) para AWS PCS

Solicitação de atualização rejeitada com ValidationException

Causa comum

A UpdateCluster solicitação retorna imediatamente com um ValidationException erro indicando que a atualização não é suportada. Isso ocorre quando:

Resolução

Se a versão de destino estiver fora da janela de compatibilidade, execute a atualização em várias etapas. Cada etapa deve ter como alvo uma versão compatível dentro da janela de compatibilidade. Por exemplo, para ir de 23.11 para 25.11, primeiro atualize para 25.05, aguarde o retorno do cluster e, em seguidaACTIVE, atualize para 25.11.

Se a versão de destino for EOL, escolha uma versão compatível mais recente. Para obter informações sobre as versões compatíveis, consulteVersões do Slurm em AWS PCS.

O cluster permanece no estado ATUALIZANDO

Causa comum

O cluster permanece no UPDATING estado por mais tempo do que o esperado (mais de 20 minutos). Isso pode ocorrer devido a problemas internos transitórios durante o processo de atualização.

Resolução

AWS O PCS recupera automaticamente os clusters que estão presos no UPDATING estado. Se o cluster não retornar para ACTIVE ou UPDATE_FAILED dentro de 30 minutos, entre em contato com o AWS Support para obter assistência.

O cluster entra no estado UPDATE_FAILED após a atualização

Causa comum

O cluster muda para o UPDATE_FAILED estado durante a atualização. Isso pode ocorrer quando erros transitórios de serviço impedem que a atualização seja concluída com êxito.

Resolução

Tente atualizar novamente enviando a mesma UpdateCluster solicitação. Os clusters no UPDATE_FAILED estado aceitam novas solicitações de atualização. Se a atualização continuar falhando, entre em contato com o AWS Support.

Os nós de computação falham ao iniciar devido a erros de análise de configuração

Causa comum

Depois de atualizar o cluster, os nós de computação falham ao iniciar e nunca aparecem na sinfo saída. Os registros da instância do nó de computação mostram erros semelhantes aos seguintes:

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin
error: Invalid DebugFlag: AuditRPCs
fatal: Unable to process configuration file

Isso ocorre quando os nós de computação que executam a versão 23.11 do agendador recebem a configuração de uma versão mais recente do cluster. As versões do Scheduler após 23.11 introduziram novas diretivas de configuração que a 23.11 não pode analisar. Ao contrário de outras versões na janela de compatibilidade, os nós de computação 23.11 não podem se conectar a um cluster mais novo porque cometem erros fatais em chaves de configuração não reconhecidas.

Esse problema também pode ocorrer se sua AMI personalizada usar uma versão do agente AWS PCS anterior à v1.4.0. As versões mais antigas do agente não oferecem suporte ao fallback automático de versões para o daemon do nó de computação.

Resolução

Reconstrua sua AMI personalizada com os seguintes requisitos:

Em seguida, atualize o grupo de nós de computação para usar a nova AMI:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Para obter informações sobre a criação de AMIs personalizadas, consulteAmazon Machine Images (AMIs) para AWS PCS. Para obter informações sobre as versões do agente AWS PCS, consulteAWS Versões do agente PCS.

Cluster indisponível após a atualização devido à configuração de QoS inválida

Causa comum

Depois de atualizar para a versão 25.11, o cluster entra no UPDATE_FAILED estado ou o agendador fica indisponível. Você não pode enviar trabalhos nem executar comandos do agendador. Os registros do agendador mostram erros semelhantes aos seguintes:

error: Invalid Allow/DenyQOS value: low
fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

Isso ocorre quando uma fila (partição) faz referência a um nome de QoS AllowQOS por meio deDenyQOS, QOS ou configurações que não existem no banco de dados contábil do Slurm. O Slurm 25.11 introduziu uma validação mais rigorosa das referências de QoS na inicialização do agendador. As versões anteriores permitiam referências a nomes de QoS inexistentes sem erros.

Resolução

Antes de atualizar para a versão 25.11, verifique se todos os nomes de QoS referenciados em suas configurações de fila existem no banco de dados contábil. Conecte-se a um nó de login e execute o seguinte comando para verificar se existe um QoS:

sacctmgr show qos where name=low format=name

Se o QoS não existir, crie-o antes de tentar a atualização:

sacctmgr add qos low

Como alternativa, remova a referência de QoS da configuração da fila atualizando as configurações personalizadas do Slurm da fila para remover o parâmetro AllowQOSDenyQOS, ou QOS antes de atualizar o cluster.