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á. # Atualize a versão do agendador de um AWS Cluster PCS Use essas etapas para atualizar a versão do agendador em seu cluster. Há duas opções, dependendo se você pode tolerar a interrupção do trabalho. Para obter mais informações sobre como escolher entre as opções, consulte[Atualizando a versão do agendador de um cluster no AWS PCS](working-with_clusters_version_update.md). ## Opção 1: atualização contínua O controlador é atualizado enquanto a frota continua funcionando. Os nós existentes continuam usando a versão anterior do Slurm até serem drenados e substituídos. Novos nós lançados após a atualização usam a versão de destino. Os trabalhos em execução não são interrompidos. **Quando usar:** + O controlador de cluster está no Slurm versão 24.05 ou posterior. + Você pode fornecer AMIs que incluam as versões atual e de destino do Slurm. ### Etapa 0 — Verifique o estado inicial Seu cluster está executando a versão “A” do controlador (por exemplo, 24.11) e você deseja migrar para a versão “B” (por exemplo, 25.11). Confirme se todos os nós de computação da sua frota executam a mesma versão principal, usando este comando de um nó de cluster: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Confirme a versão do agente AWS PCS em um nó de computação. Conecte-se ao nó com o Systems Manager e verifique o log de bootstrap: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` As atualizações contínuas exigem o agente AWS PCS versão 1.4.0 ou posterior em todas as AMIs de nós de computação. Para obter mais informações, consulte [AWS Versões do agente PCS](pcs-agent-versions.md). ### Etapa 1 — Preparar e implantar as AMIs de versão dupla Crie ou identifique AMIs que incluam **as versões A e B do Slurm e o agente PCS mais recente AWS **. + Você pode usar os **PCS-ready DLAMis** mais recentes. Essas AMIs são fornecidas com as três versões mais recentes do Slurm suportadas. Para obter mais informações, consulte [Usando o PCS-ready DLAMI com AWS PCS](working-with_ami_pcs-ready-dlami.md). + Você pode criar uma **AMI personalizada** seguindo as etapas de instalação dos pacotes Slurm e do agente AWS PCS. Para obter mais informações, consulte [Imagens personalizadas da Amazon Machine (AMIs) para AWS PCS](working-with_ami_custom.md). + Você **não pode** usar uma **amostra de AMI do AWS PCS**. Essas AMIs não foram projetadas para produção e atualmente incluem apenas uma única versão do Slurm. **nota** Se sua AMI incluir mais de duas versões do Slurm, o AWS PCS selecionará automaticamente a versão que corresponde ao controlador. Ter versões adicionais instaladas não causa problemas. Quando as AMIs estiverem prontas: 1. Chame `UpdateComputeNodeGroup` cada grupo de nós de computação para definir a nova AMI de versão dupla. Os nós serão configurados no DRAIN pelo AWS PCS e migrarão para a nova AMI. 1. Aguarde até que os nós esgotados concluam suas tarefas, sejam encerrados e substituídos por nós usando a nova AMI de versão dupla. Verifique se todas as instâncias do EC2 no cluster estão usando a nova AMI com: ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### Etapa 2 — Atualizar o controlador de cluster Ligue `UpdateCluster` com a versão `scheduler.version` configurada para a versão B. ------ #### [ Console de gerenciamento da AWS ] 1. Abra o console AWS PCS em [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. No painel de navegação, escolha **Clusters**. 1. Selecione o cluster a ser atualizado e escolha **Editar**. 1. Em **Detalhes do cluster**, selecione a versão do agendador de destino no menu suspenso **Agendador.** 1. Escolha **Atualizar** para enviar a atualização da versão. 1. Monitore o status do cluster. O cluster aparece `UPDATING` durante a atualização e retorna `ACTIVE` quando concluído. A atualização geralmente é concluída em 5 a 15 minutos. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Aguarde o retorno do cluster`ACTIVE`. A atualização geralmente é concluída em 5 a 15 minutos. ------ Durante essa operação, o controlador fica brevemente indisponível: + Os trabalhos em execução nos nós de computação **continuam sendo executados**. + Novos envios de trabalhos e comandos do agendador não estarão disponíveis até que a atualização seja concluída. + O escalonamento automático é pausado até que o cluster retorne a. `ACTIVE` Após a atualização, a frota computacional está em um **estado misto**: os nós executados antes da atualização continuam usando a versão A do Slurm`slurmd`; os novos nós usam a versão B. Isso é esperado. **nota** Não adicione configurações do Slurm específicas para a versão B enquanto a frota ainda contiver nós na versão A. A configuração é distribuída para todos os nós; a antiga `slurmd` pode não reconhecer novos parâmetros. 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. ### Passo 3 — Drenar nós que ainda executam a versão A do Slurm Identifique e drene os nós que ainda estão na versão anterior. Em um nó do cluster, execute: ``` scontrol show nodes | grep "Version=" scontrol update NodeName={{node}} State=DRAIN Reason="Slurm version update" ``` Depois que os nós drenados terminam seus trabalhos atuais, eles são encerrados e substituídos por nós na versão B do Slurm. ### Etapa 4 — Verifique a consistência da frota na versão B do Slurm Confirme se todos os nós relatam a versão B. Em um nó do cluster, execute: ``` scontrol show nodes | grep "Version=" ``` Agora, todos os nós devem relatar a versão B. O Slurm está concluído. ## Opção 2: Full-fleet reciclar Toda a frota é encerrada antes que o controlador seja atualizado e, em seguida, ampliada a partir de uma nova AMI com a versão de destino do Slurm. Esse procedimento é mais simples, mas exige que todos os nós e trabalhos em execução sejam encerrados. **Quando usar:** + Você não pode fornecer AMIs com as duas versões do Slurm instaladas. + O controlador de cluster está na versão 23.11 (a opção 1 não está disponível para clusters 23.11). **nota** Encerrar toda a frota de uma só vez aumenta a probabilidade de erros de capacidade insuficientes ao aumentar a escala. Considere usar a capacidade reservada ou a programação fora do horário de pico. ### Etapa 0 — Verifique o estado inicial Seu cluster está executando a versão “A” do controlador (por exemplo, 24.11) e você deseja migrar para a versão “B” (por exemplo, 25.11). Confirme se todos os nós de computação da sua frota executam a mesma versão principal, usando este comando de um nó de cluster: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Confirme a versão do agente AWS PCS em um nó de computação. Conecte-se ao nó com o Systems Manager e verifique o log de bootstrap: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` Use o agente AWS PCS mais recente em suas AMIs de destino. Para obter mais informações, consulte [AWS Versões do agente PCS](pcs-agent-versions.md). ### Etapa 1 — Preparar as AMIs de destino Crie ou identifique AMIs que incluam a **versão B do Slurm e o agente PCS mais recente AWS **. + Você pode usar os **PCS-ready DLAMis** mais recentes. Essas AMIs são fornecidas com as três versões mais recentes do Slurm suportadas. Para obter mais informações, consulte [Usando o PCS-ready DLAMI com AWS PCS](working-with_ami_pcs-ready-dlami.md). + Você pode criar uma **AMI personalizada** seguindo as etapas de instalação dos pacotes Slurm e do agente AWS PCS. Para obter mais informações, consulte [Imagens personalizadas da Amazon Machine (AMIs) para AWS PCS](working-with_ami_custom.md). + **Não é recomendável usar o AMI de amostra do AWS PCS**. Essas AMIs não foram projetadas para produção. ### Etapa 2 — Reduza a escala de toda a frota Registre o atual `minNodeCount` e `maxNodeCount` para cada grupo de nós de computação — você os restaurará na Etapa 4. ``` for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do aws pcs get-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier "$cng" \ --query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \ --output table done ``` **Atenção** A operação a seguir encerra todos os nós em execução e os trabalhos neles. `maxNodeCount`Defina `minNodeCount` e para `0` em cada grupo de nós de computação: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` Verifique se nenhuma instância com a tag `aws:pcs:cluster-id` correspondente ao seu cluster está em execução antes de continuar: ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### Etapa 3 — Atualizar o controlador de cluster ------ #### [ Console de gerenciamento da AWS ] 1. Abra o console AWS PCS em [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. No painel de navegação, escolha **Clusters**. 1. Selecione o cluster a ser atualizado e escolha **Editar**. 1. Em **Detalhes do cluster**, selecione a versão do agendador de destino no menu suspenso **Agendador.** 1. Escolha **Atualizar** para enviar a atualização da versão. 1. Monitore o status do cluster. O cluster aparece `UPDATING` durante a atualização e retorna `ACTIVE` quando concluído. A atualização geralmente é concluída em 5 a 15 minutos. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Aguarde o retorno do cluster`ACTIVE`. A atualização geralmente é concluída em 5 a 15 minutos. 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. ------ ### Etapa 4 — Atualizar grupos de nós de computação e restaurar a capacidade Para cada grupo de nós de computação, defina a nova AMI e restaure os limites originais de capacidade mínima e máxima: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --ami-id {{new-ami-id}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` O cluster volta a crescer. Todos os novos nós executam o Slurm versão B com o agente AWS PCS mais recente. ## Exemplo: atualização em várias versões Se a versão de destino estiver fora da janela de compatibilidade da sua versão atual, você deverá mover o controlador por uma ou mais versões intermediárias, atualizando-o um salto por vez. Cada salto deve ter como alvo uma versão compatível dentro da janela de compatibilidade da versão atual do controlador. Como [Opção 2: Full-fleet reciclar](#version_update-procedure-option2) dimensiona a frota para zero antes de atualizar o controlador, nenhum nó de computação está em execução enquanto o controlador se move entre as versões. Como resultado, suas AMIs podem usar diretamente a versão **final** de destino — somente a atualização do controlador (Etapa 3) é repetida em cada salto. O exemplo a seguir atualiza um cluster de **23.11 para 25.11** usando o procedimento da Opção 2. 23.11 está fora da janela de compatibilidade de 25.11, portanto, o controlador é atualizado em dois saltos (23.11 a 25.05 e, em seguida, 25.05 a 25.11). Siga as etapas da Opção 2, com a Etapa 3 dividida em uma atualização por salto: 1. **Etapa 1 — Prepare as AMIs de destino.** Crie ou identifique AMIs com a versão **final** (25.11) e o agente AWS PCS mais recente. Consulte [Etapa 1 — Preparar as AMIs de destino](#version_update-procedure-option2-step1). 1. **Etapa 2 — Reduza a escala de toda a frota.** Registre a capacidade atual (consulte[Etapa 2 — Reduza a escala de toda a frota](#version_update-procedure-option2-step2)) e defina cada grupo de nós de computação como zero. ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` 1. **Etapa 3a — Atualize o controlador de 23.11 para 25.05.** Aguarde o retorno do cluster`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.05 ``` 1. **Etapa 3b — Atualize o controlador de 25.05 para 25.11.** Aguarde o retorno do cluster`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.11 ``` 1. **Etapa 4 — Atualize os grupos de nós de computação e restaure a capacidade.** Defina a AMI 25.11 em cada grupo de nós de computação e restaure os limites de capacidade originais (consulte[Etapa 4 — Atualizar grupos de nós de computação e restaurar a capacidade](#version_update-procedure-option2-step4)). ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` **nota** Cada salto do controlador deve chegar a uma versão dentro da janela de compatibilidade da anterior. Para encontrar versões intermediárias válidas, consulte[Compatibilidade da versão](working-with_clusters_version_update.md#version_update-cluster-compatibility). A frota permanece em zero nas etapas 3a e 3b, portanto, nenhuma atualização intermediária da AMI é necessária.