View a markdown version of this page

Aggiorna la versione dello scheduler di un AWS Cluster PCS - AWS PEZZI
Opzione 1: aggiornamento continuoOpzione 2: interruzione Full-fleet della manutenzioneEsempio: aggiornamento tra più versioni

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Aggiorna la versione dello scheduler di un AWS Cluster PCS

Usa questi passaggi per aggiornare la versione dello scheduler sul tuo cluster. Sono disponibili due opzioni a seconda che tu possa tollerare l'interruzione del lavoro. Per ulteriori informazioni sulla scelta tra le opzioni, vedere. Aggiornamento della versione dello scheduler di un cluster in AWS 2 PEZZI

Nota

Si consiglia di testare la nuova AMI e la procedura di aggiornamento su un cluster non di produzione prima di applicare le modifiche all'ambiente di produzione.

Opzione 1: aggiornamento continuo

Il controller viene aggiornato mentre la flotta continua a funzionare. I nodi esistenti continuano a utilizzare la versione precedente di Slurm fino a quando non vengono svuotati e sostituiti. I nuovi nodi lanciati dopo l'aggiornamento utilizzano la versione di destinazione. I processi in esecuzione non vengono interrotti.

Quando usare:

  • Il controller del cluster è su Slurm versione 24.05 o successiva.

Fase 0: verifica lo stato iniziale

Il tuo cluster esegue la versione del controller «A» (ad esempio 24.11) e desideri migrare alla versione «B» (ad esempio 25.11). Verifica che tutti i nodi di calcolo della tua flotta eseguano la stessa versione principale, utilizzando questo comando da un nodo del 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

Conferma la versione dell'agente AWS PCS su un nodo di calcolo. Connettiti al nodo con Systems Manager e controlla il log di 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

Gli aggiornamenti continui richiedono la versione 1.4.0 o successiva dell'agente AWS PCS su tutte le AMI dei nodi di calcolo. Per ulteriori informazioni, consulta AWS Versioni dell'agente PCS.

Fase 1: Preparare le AMI di destinazione

Crea o identifica le AMI che includono la versione B di Slurm e l'agente PCS più recente. AWS

  • È possibile utilizzare i DLAMI più recenti. PCS-ready Tali AMI vengono fornite con le ultime tre versioni di Slurm supportate. Per ulteriori informazioni, consulta Utilizzo di PCS-ready DLAMI con AWS 2 PEZZI.

  • È possibile creare un'AMI personalizzata seguendo i passaggi di installazione dei pacchetti Slurm e dell'agente PCS. AWS Per ulteriori informazioni, consulta Immagini di macchine Amazon personalizzate (AMIs) per AWS PCS.

  • Non consigliamo l'AMI di esempio AWS PCS per l'uso in produzione. Queste AMI sono solo a scopo di test.

Nota

La stessa AMI può includere più versioni di Slurm. AWS PCS seleziona automaticamente la versione corrispondente al controller. L'installazione di versioni aggiuntive non causa problemi.

Fase 2: aggiornamento del controller del cluster

Chiama UpdateCluster con scheduler.version set alla versione B.

Console di gestione AWS

  1. Aprire la console AWS PCS all'indirizzo https://console.aws.amazon.com/pcs/.

  2. Nel pannello di navigazione scegliere Cluster.

  3. Seleziona il cluster da aggiornare e scegli Modifica.

  4. In Dettagli del cluster, seleziona la versione dello scheduler di destinazione dal menu a discesa Scheduler.

  5. Scegli Aggiorna per inviare l'aggiornamento della versione.

  6. Monitora lo stato del cluster. Il cluster viene visualizzato come UPDATING durante l'aggiornamento e ritorna al ACTIVE termine. L'aggiornamento viene completato in genere in 5-15 minuti.

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

Attendi che il cluster ritorni a. ACTIVE L'aggiornamento viene in genere completato in 5-15 minuti.

Durante questa operazione il controller non è disponibile per un breve periodo:

  • I job in esecuzione sui nodi di calcolo continuano a essere eseguiti.

  • I nuovi invii di lavori e i comandi dello scheduler non sono disponibili fino al completamento dell'aggiornamento.

  • Il ridimensionamento automatico viene sospeso fino al ripristino del cluster. ACTIVE

Nota

Non aggiungete impostazioni Slurm specifiche per la versione B mentre la flotta contiene ancora nodi nella versione A. La configurazione è distribuita a tutti i nodi; i vecchi slurmd potrebbero non riconoscere nuovi parametri.

Se il cluster non torna alla normalità ACTIVE o UPDATE_FAILED entro 30 minuti, contatta l' AWS assistenza per ricevere assistenza.

Fase 3: aggiornamento dei gruppi di nodi di calcolo

Per ogni gruppo di nodi di calcolo, imposta la nuova AMI con la versione di Slurm di destinazione:

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

AWS PCS imposta lo stato dei nodi che eseguono la versione precedente. DRAIN Dopo che i nodi esauriti hanno terminato i lavori correnti, AWS PCS li interrompe e li sostituisce con nuovi nodi che eseguono Slurm versione B.

Fase 4: verifica della consistenza della flotta sulla versione B di Slurm

Monitora la transizione della flotta. Da un nodo del cluster, controlla il riepilogo della versione in tutti i nodi:

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

Controlla DRAIN lo stato dei nodi e la loro versione:

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

Controlla la versione per tutti i nodi attivi:

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

L'aggiornamento è completo quando il riepilogo della versione mostra solo la versione di destinazione e nessun nodo rimane attivo DRAIN o in DRAINING stato. I nodi nello POWERED_DOWN stato non segnalano una versione finché AWS PCS non li avvia.

Opzione 2: interruzione Full-fleet della manutenzione

Si interrompe l'intero parco macchine prima di aggiornare il controller, per poi passare da una nuova AMI alla versione Slurm di destinazione. Questa procedura è più semplice, ma termina tutti i nodi e i job in esecuzione.

Quando usare:

  • Il controller del cluster è nella versione 23.11 (l'opzione 1 non è disponibile per i cluster 23.11).

Nota

L'interruzione immediata dell'intera flotta aumenta la probabilità di errori di capacità insufficienti durante il backup. Valuta la possibilità di utilizzare la capacità riservata o di programmare durante le ore non di punta.

Passaggio 0: verifica lo stato di partenza

Il tuo cluster esegue la versione del controller «A» (ad esempio 24.11) e desideri migrare alla versione «B» (ad esempio 25.11). Verifica che tutti i nodi di calcolo della tua flotta eseguano la stessa versione principale, utilizzando questo comando da un nodo del 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

Conferma la versione dell'agente AWS PCS su un nodo di calcolo. Connettiti al nodo con Systems Manager e controlla il log di 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

Usa l'agente AWS PCS più recente sulle AMI di destinazione. Per ulteriori informazioni, consulta AWS Versioni dell'agente PCS.

Fase 1: preparare le AMI di destinazione

Crea o identifica le AMI che includono la versione B di Slurm e l'agente PCS più recente. AWS

  • È possibile utilizzare i DLAMI più recenti. PCS-ready Tali AMI vengono fornite con le ultime tre versioni di Slurm supportate. Per ulteriori informazioni, consulta Utilizzo di PCS-ready DLAMI con AWS 2 PEZZI.

  • È possibile creare un'AMI personalizzata seguendo i passaggi di installazione dei pacchetti Slurm e dell'agente PCS. AWS Per ulteriori informazioni, consulta Immagini di macchine Amazon personalizzate (AMIs) per AWS PCS.

  • Non consigliamo l'AMI di esempio AWS PCS per l'uso in produzione. Queste AMI sono solo a scopo di test.

Fase 2: Ridimensionare l'intera flotta

Registra i dati correnti minNodeCount e maxNodeCount relativi a ciascun gruppo di nodi di calcolo: li ripristinerai nel passaggio 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
avvertimento

La seguente operazione interrompe tutti i nodi in esecuzione e i lavori su di essi.

Imposta minNodeCount e attiva maxNodeCount 0 su ogni gruppo di nodi di calcolo:

aws pcs update-compute-node-group \
  --cluster-identifier cluster-id \
  --compute-node-group-identifier cng-id \
  --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'

Verifica che nessuna istanza contrassegnata aws:pcs:cluster-id corrispondente al tuo cluster sia in esecuzione prima di continuare:

aws ec2 describe-instances \
    --filters "Name=tag:aws:pcs:cluster-id,Values=cluster-id" \
    --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \
    --output table

Fase 3: aggiornamento del controller del cluster

Console di gestione AWS

  1. Aprire la console AWS PCS all'indirizzo https://console.aws.amazon.com/pcs/.

  2. Nel pannello di navigazione scegliere Cluster.

  3. Seleziona il cluster da aggiornare e scegli Modifica.

  4. In Dettagli del cluster, seleziona la versione dello scheduler di destinazione dal menu a discesa Scheduler.

  5. Scegli Aggiorna per inviare l'aggiornamento della versione.

  6. Monitora lo stato del cluster. Il cluster viene visualizzato come UPDATING durante l'aggiornamento e ritorna al ACTIVE termine. L'aggiornamento viene completato in genere in 5-15 minuti.

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

Attendi che il cluster ritorni a. ACTIVE L'aggiornamento viene in genere completato in 5-15 minuti.

Se il cluster non ritorna ACTIVE o non viene ripristinato UPDATE_FAILED entro 30 minuti, contatta il AWS supporto per ricevere assistenza.

Fase 4: aggiornamento dei gruppi di nodi di calcolo e ripristino della capacità

Per ogni gruppo di nodi di calcolo, imposta la nuova AMI e ripristina i limiti di capacità minimi e massimi originali:

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}'

Il cluster viene ridimensionato. Tutti i nuovi nodi eseguono Slurm versione B con l'agente PCS più recente AWS .

Esempio: aggiornamento tra più versioni

Se la versione di destinazione non rientra nella finestra di compatibilità della versione corrente, devi spostare il controller tra una o più versioni intermedie, aggiornandolo un hop alla volta. Ogni hop deve avere come destinazione una versione supportata all'interno della finestra di compatibilità della versione corrente del controller.

Poiché Opzione 2: interruzione Full-fleet della manutenzione ridimensiona il parco macchine a zero prima di aggiornare il controller, nessun nodo di calcolo è in esecuzione mentre il controller passa da una versione all'altra. Di conseguenza, le tue AMI possono utilizzare direttamente la versione finale di destinazione: solo l'aggiornamento del controller (Fase 3) viene ripetuto per ogni hop.

L'esempio seguente aggiorna un cluster dal 23.11 al 25.11 utilizzando la procedura Option 2. 23.11 non rientra nella finestra di compatibilità del 25.11, quindi il controller viene aggiornato in due passaggi (dal 23.11 al 25.05, quindi dal 25.05 al 25.11). Segui i passaggi dell'opzione 2, suddividendo il passaggio 3 in un aggiornamento per hop:

  1. Fase 1: preparare le AMI di destinazione. Crea o identifica le AMI con la versione finale (25.11) e l'agente AWS PCS più recente. Per informazioni, consulta Fase 1: preparare le AMI di destinazione.

  2. Fase 2: Ridimensionare l'intera flotta. Registra la capacità attuale (vediFase 2: Ridimensionare l'intera flotta), quindi imposta ogni gruppo di nodi di calcolo a zero.

    aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'

  3. Fase 3a — Aggiornare il controller dal 23.11 al 25.05. Attendi che il cluster ritorni aACTIVE.

    aws pcs update-cluster --cluster-identifier my-cluster \
--scheduler version=25.05

  4. Fase 3b — Aggiornare il controller dal 25.05 al 25.11. Attendi che il cluster ritorni aACTIVE.

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

  5. Fase 4: aggiornamento dei gruppi di nodi di calcolo e ripristino della capacità. Imposta l'AMI 25.11 su ciascun gruppo di nodi di calcolo e ripristina i limiti di capacità originali (vediFase 4: aggiornamento dei gruppi di nodi di calcolo e ripristino della capacità).

    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

Ogni controller hop deve arrivare a una versione all'interno della finestra di compatibilità di quella precedente. Per trovare versioni intermedie valide, vedereCompatibilità delle versioni. La flotta rimane a zero durante le fasi 3a e 3b, quindi non sono necessari aggiornamenti AMI intermedi.