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

Atualizar 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 PEÇAS.

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. Os 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 a versão 1.4.0 ou posterior do agente AWS PCS em todas as AMIs dos nós de computação. 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 — Atualizar o controlador de cluster

Ligue UpdateCluster com scheduler.version o set 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 do Agendador.

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

6. Monitore o status do cluster. O cluster é exibido como UPDATING durante a atualização e retorna ACTIVE quando concluído. A atualização normalmente é concluída em 5 a 15 minutos.

AWS CLI

aws pcs update-cluster \
  --cluster-identifier cluster-id \
  --scheduler version=25.11

Aguarde até que o cluster retorne aoACTIVE. A atualização normalmente é concluída em 5 a 15 minutos.

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

Se o cluster não retornar em 30 minutos ACTIVE ou UPDATE_FAILED dentro de 30 minutos, entre em contato com o AWS Suporte para obter assistência.

Etapa 3 — Atualizar grupos de nós de computação

Para cada grupo de nós de computação, defina a nova AMI com a versão de destino do Slurm:

aws pcs update-compute-node-group \
  --cluster-identifier cluster-id \
  --compute-node-group-identifier cng-id \
  --ami-id new-ami-id

AWS O PCS define os nós que executam a versão anterior como DRAIN estado. Depois que os nós drenados terminam seus trabalhos atuais, o AWS PCS encerra os nós e os substitui por novos nós executando o Slurm versão B.

Etapa 4 — Verificar a frota consistente na versão B do Slurm

Monitore a transição da frota. Em um nó de cluster, verifique o resumo da versão em todos os nós:

scontrol show nodes | grep "Version=" | awk -F'=' '{print $NF}' | sort | uniq -c

Verifique o DRAIN estado dos nós e sua versão:

scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=.*DRAIN/{print name, ver}'

Verifique a versão para todos os nós ativos:

scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=/{if (ver) print name, ver}'

A atualização é concluída quando o resumo da versão mostra somente a versão de destino e nenhum nó permanece em DRAIN nosso DRAINING estado. Os nós no POWERED_DOWN estado não relatam uma versão até que o AWS PCS os inicie.

Opção 2: parada Full-fleet de manutenção

Você encerra toda a frota antes de atualizar o controlador e depois o redimensiona a partir de uma nova AMI com a versão Slurm de destino. Esse procedimento é mais simples, mas encerra todos os nós e trabalhos em execução.

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 — Reduzir 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 marcada 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 do Agendador.

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

6. Monitore o status do cluster. O cluster é exibido como UPDATING durante a atualização e retorna ACTIVE quando concluído. A atualização normalmente é concluída em 5 a 15 minutos.

AWS CLI

aws pcs update-cluster \
  --cluster-identifier cluster-id \
  --scheduler version=25.11

Aguarde até que o cluster retorne aoACTIVE. A atualização normalmente é concluída em 5 a 15 minutos.

Se o cluster não retornar em 30 minutos ACTIVE ou UPDATE_FAILED dentro de 30 minutos, entre em contato com o AWS Suporte 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: parada Full-fleet de manutenção escala 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 para 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 depois 25.05 a 25.11). Siga as etapas da Opção 2, com a Etapa 3 dividida em uma atualização por salto: