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, consulteAtualizando a versão do agendador de um cluster no AWS PCS.

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:

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.

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 .

Quando as AMIs estiverem prontas:

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/.

2. No painel de navegação, escolha Clusters.

3. Selecione o cluster a ser atualizado e escolha Editar.

4. Em Detalhes do cluster, selecione a versão do agendador de destino no menu suspenso Agendador.

5. Escolha Atualizar para enviar a atualização da versão.

6. 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 clusterACTIVE. A atualização geralmente é concluída em 5 a 15 minutos.

Durante essa operação, o controlador fica brevemente indisponível:

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 Slurmslurmd; os novos nós usam a versão B. Isso é esperado.

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:

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.

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 .

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

maxNodeCountDefina 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/.

2. No painel de navegação, escolha Clusters.

3. Selecione o cluster a ser atualizado e escolha Editar.

4. Em Detalhes do cluster, selecione a versão do agendador de destino no menu suspenso Agendador.

5. Escolha Atualizar para enviar a atualização da versão.

6. 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 clusterACTIVE. 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 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: