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](#update-troubleshooting-nodes-fail) + [Solicitação de atualização rejeitada com ValidationException](#update-troubleshooting-validation-error) + [O cluster permanece no estado ATUALIZANDO](#update-troubleshooting-stuck-updating) + [O cluster entra no estado UPDATE\_FAILED após a atualização](#update-troubleshooting-update-failed) + [Os nós de computação falham ao iniciar devido a erros de análise de configuração](#update-troubleshooting-config-parse) + [Cluster indisponível após a atualização devido à configuração de QoS inválida](#update-troubleshooting-qos-bootloop) ## 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, consulte[Logs do agendador no AWS PCS](monitoring_scheduler-logs.md). **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, consulte[Recuperar registros de instâncias](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs). ### 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, consulte[Compatibilidade da versão](working-with_clusters_version_update.md#version_update-cluster-compatibility). Para obter informações sobre como criar AMIs personalizadas com a versão correta do agendador, consulte. [Amazon Machine Images (AMIs) para AWS PCS](working-with_ami.md) ## 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: + A versão de destino está fora da [janela de compatibilidade](https://slurm.schedmd.com/upgrades.html#compatibility_window) da versão atual. + A versão alvo é designada como End of Life (EOL) e não é mais uma meta de atualização válida. + A versão de destino é mais antiga ou igual à versão atual (não há suporte para downgrades). ### 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 seguida`ACTIVE`, 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, consulte[Versões do Slurm em AWS PCS](slurm-versions.md). ## 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](https://slurm.schedmd.com/upgrades.html#compatibility_window), 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: + Scheduler versão 24.05 ou posterior + AWS Agente PCS versão 1.4.0 ou posterior 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, consulte[Amazon Machine Images (AMIs) para AWS PCS](working-with_ami.md). Para obter informações sobre as versões do agente AWS PCS, consulte[AWS Versões do agente PCS](pcs-agent-versions.md). ## 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 de`DenyQOS`, `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 `AllowQOS``DenyQOS`, ou `QOS` antes de atualizar o cluster.