Opzione 1: aggiornamento continuo Opzione 2: riciclare Full-fleet Esempio: aggiornamento tra più versioni

Aggiornare la versione dello scheduler di un AWS Cluster PCS

Utilizza questi passaggi per aggiornare la versione dello scheduler sul tuo cluster. Sono disponibili due opzioni a seconda che sia possibile tollerare o meno l'interruzione del lavoro. Per ulteriori informazioni sulla scelta tra le opzioni, vedere. Aggiornamento della versione dello scheduler di un cluster in AWS PZ

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 è installato sulla versione Slurm 24.05 o successiva.
Puoi fornire AMI che includono sia la versione attuale che quella di destinazione di Slurm.

Fase 0 — Verificare lo stato di partenza

Il cluster utilizza la versione del controller «A» (ad esempio 24.11) e desideri migrare alla versione «B» (ad esempio 25.11). Conferma che tutti i nodi di elaborazione 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. Connect al nodo con Systems Manager e controllate 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 e implementare le AMI a doppia versione

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

Puoi 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 PZ.
Puoi creare un'AMI personalizzata, seguendo i passaggi di installazione per i pacchetti Slurm e l'agente AWS PCS. Per ulteriori informazioni, consulta Immagini di macchine Amazon personalizzate (AMIs) per AWS PCS.
Non è possibile utilizzare un'AMI di esempio AWS PCS. Tali AMI non sono progettate per la produzione e attualmente includono solo una singola versione Slurm.

Nota

Se l'AMI include più di due versioni di Slurm, AWS PCS seleziona automaticamente la versione che corrisponde al controller. L'installazione di versioni aggiuntive non causa problemi.

Una volta che le AMI sono pronte:

Chiama UpdateComputeNodeGroup ogni gruppo di nodi di calcolo per impostare la nuova AMI a doppia versione. I nodi verranno impostati in DRAIN da AWS PCS e migreranno alla nuova AMI.
Attendi che i nodi esauriti completino i loro processi, terminino e vengano sostituiti da nodi che utilizzano la nuova AMI a doppia versione. Verifica che tutte le istanze EC2 nel cluster utilizzino la nuova AMI con:
```
aws ec2 describe-instances \
    --filters "Name=tag:aws:pcs:cluster-id,Values=cluster-id" \
    --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \
    --output table
```

Fase 2: Aggiornare il controller del cluster

Chiama UpdateCluster con la versione scheduler.version impostata B.

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

I lavori in esecuzione sui nodi di calcolo continuano a essere eseguiti.
I nuovi incarichi di lavoro e i comandi di pianificazione non sono disponibili fino al completamento dell'aggiornamento.
Il ridimensionamento automatico viene sospeso fino al ripristino del cluster. ACTIVE

Dopo l'aggiornamento, la flotta di elaborazione si trova in uno stato misto: i nodi in esecuzione prima dell'aggiornamento continuano a utilizzare la versione A di Slurmslurmd; i nuovi nodi utilizzano la versione Slurm B. Questo è previsto.

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; la vecchia potrebbe non riconoscere i nuovi parametri. slurmd

Se il cluster non torna ACTIVE o non torna UPDATE_FAILED entro 30 minuti, contatta AWS Support per ricevere assistenza.

Fase 3 — Drenare i nodi che ancora eseguono la versione A di Slurm

Identifica e svuota i nodi ancora presenti nella versione precedente. Da un nodo del cluster, esegui:


scontrol show nodes | grep "Version="
scontrol update NodeName=node State=DRAIN Reason="Slurm version update"

Una volta che i nodi svuotati terminano i loro lavori correnti, terminano e vengono sostituiti dai nodi nella versione Slurm B.

Fase 4: verifica una flotta coerente sulla versione B di Slurm

Conferma che tutti i nodi riportano la versione B. Da un nodo del cluster, esegui:


scontrol show nodes | grep "Version="

Tutti i nodi dovrebbero ora riportare la versione B. Slurm. L'aggiornamento è completo.

Opzione 2: riciclare Full-fleet

L'intera flotta viene interrotta prima che il controller venga aggiornato, quindi ridimensionato da una nuova AMI con la versione Slurm di destinazione. Questa procedura è più semplice, ma richiede che tutti i nodi e i job in esecuzione vengano terminati.

Quando usare:

Non è possibile fornire AMI con entrambe le versioni di Slurm installate.
Il controller del cluster è nella versione 23.11 (l'opzione 1 non è disponibile per i cluster 23.11).

Nota

L'interruzione immediata dell'intero parco macchine aumenta la probabilità di errori di capacità insufficiente durante il backup. Prendi in considerazione l'utilizzo della capacità riservata o la pianificazione durante le ore non di punta.

Passaggio 0: verifica lo stato di partenza


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. Connect al nodo con Systems Manager e controllate 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

Utilizza 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 AMI che includono la versione B di Slurm e l'ultimo agente PCS. AWS

Puoi 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 PZ.
Puoi creare un'AMI personalizzata, seguendo i passaggi di installazione per i pacchetti Slurm e l'agente AWS PCS. Per ulteriori informazioni, consulta Immagini di macchine Amazon personalizzate (AMIs) per AWS PCS.
L'uso dell'AMI di esempio AWS PCS non è consigliato. Tali AMI non sono progettate per la produzione.

Fase 2: Ridimensionamento dell'intera flotta

Registra l'attuale gruppo di nodi di calcolo minNodeCount e maxNodeCount per ogni gruppo di nodi di calcolo: li ripristinerai nella Fase 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

L'operazione seguente interrompe tutti i nodi in esecuzione e i processi 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 etichettata come 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: Aggiornare il controller del cluster

Fase 4: Aggiornamento dei gruppi di nodi di elaborazione e ripristino della capacità

Per ogni gruppo di nodi di calcolo, imposta la nuova AMI e ripristina i limiti di capacità minima e massima 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 si ridimensiona di nuovo. 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, è necessario spostare il controller tra una o più versioni intermedie, aggiornandola un passaggio alla volta. Ogni hop deve avere come target una versione supportata all'interno della finestra di compatibilità della versione corrente del controller.

Poiché Opzione 2: riciclare Full-fleet ridimensiona la flotta 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 di destinazione finale: 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 hop (da 23.11 a 25.05, quindi da 25.05 a 25.11). Segui i passaggi dell'Opzione 2, con il Passaggio 3 suddiviso in un unico aggiornamento per hop:

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

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


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

Fase 3a — Aggiornare il controller dal 23.11 al 25.05. Attendi che il cluster ritorni a. ACTIVE
```
aws pcs update-cluster --cluster-identifier my-cluster \
--scheduler version=25.05
```
Fase 3b — Aggiornare il controller dal 25.05 al 25.11. Attendi che il cluster ritorni a. ACTIVE
```
aws pcs update-cluster --cluster-identifier my-cluster \
--scheduler version=25.11
```
Fase 4: Aggiornare i gruppi di nodi di calcolo e ripristinare la capacità. Imposta l'AMI 25.11 su ogni gruppo di nodi di calcolo e ripristina i limiti di capacità originali (vediFase 4: Aggiornamento dei gruppi di nodi di elaborazione 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à della precedente. Per trovare versioni intermedie valide, consultaCompatibilità delle versioni. La flotta rimane a zero durante le fasi 3a e 3b, quindi non sono necessari aggiornamenti intermedi dell'AMI.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Aggiornamento della versione dello scheduler

Risoluzione dei problemi di aggiornamento delle versioni