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à.
# SageMaker HyperPod resilienza del cluster
SageMaker HyperPod tramite l'orchestrazione Slurm fornisce le seguenti funzionalità di resilienza del cluster.
**Topics**
+ [Agente di monitoraggio della salute](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Sostituisci o riavvia manualmente un nodo usando Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agente di monitoraggio della salute
Questa sezione descrive l'insieme di controlli di integrità SageMaker HyperPod utilizzati per monitorare regolarmente lo stato delle istanze del cluster per individuare problemi relativi a dispositivi come acceleratori (core GPU e Trainium) e rete (EFA). SageMaker HyperPod Health-Monitoring Agent (HMA) monitora continuamente lo stato di salute di ogni istanza basata su GPU o Trainium. Quando rileva un errore dell’istanza o della GPU, l’agente contrassegna l’istanza come non integra.
SageMaker HyperPod HMA esegue gli stessi controlli di integrità per gli orchestratori EKS e Slurm. Per ulteriori informazioni su HMA, vedere. [Sistema di monitoraggio della salute](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
# Ripristino automatico dei nodi e ripristino automatico
**Nota**
A partire dall'11 settembre 2025, HyperPod con Slurm orchestration ora supporta gli agenti di monitoraggio dello stato di salute. Esegui [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)e aggiorna l'AMI alla versione più recente per utilizzare questa funzionalità.
Questa sezione parla delle due funzionalità SageMaker HyperPod di resilienza complementari di Amazon: il ripristino automatico dei nodi che sostituisce l'infrastruttura difettosa senza l'intervento manuale e la funzionalità di ripristino automatico che riavvia i lavori di formazione dall'ultimo checkpoint dopo i guasti hardware.
## Come funziona il ripristino automatico dei nodi
Durante la creazione o l’aggiornamento del cluster, gli utenti amministratori del cluster possono selezionare l’opzione di ripristino del nodo (istanza) scegliendo tra `Automatic` (consigliato) e `None` a livello di cluster. Se impostato su`Automatic`, SageMaker HyperPod riavvia o sostituisce automaticamente i nodi difettosi.
**Importante**
Consigliamo di impostare l’opzione `Automatic`. Per impostazione predefinita, i cluster sono configurati con il ripristino automatico dei nodi.
Il ripristino automatico dei nodi viene eseguito quando vengono rilevati problemi dall’agente di monitoraggio dell’integrità, dai controlli dell’integrità di base e dai controlli dell’integrità approfonditi. Se è impostato `None`, l’agente di monitoraggio dell’integrità etichetta le istanze in cui viene rilevato un guasto, ma non avvia automaticamente alcuna azione di correzione o ripristino sui nodi interessati. Questa opzione non è consigliata.
## Esecuzione di un processo di formazione con la funzionalità di SageMaker HyperPod ripristino automatico di Amazon
Questa sezione descrive come eseguire un processo di formazione con la funzionalità di SageMaker HyperPod ripristino automatico, che fornisce un'infrastruttura di resilienza zero-touch per ripristinare automaticamente un processo di formazione dall'ultimo checkpoint salvato in caso di guasto hardware.
Con la funzionalità di ripristino automatico, se un processo fallisce a causa di un guasto hardware o di problemi transitori tra un training e l'altro, la ripresa SageMaker HyperPod automatica avvia il flusso di lavoro di sostituzione dei nodi e riavvia il lavoro dopo la sostituzione dei nodi difettosi. I seguenti controlli hardware vengono eseguiti ogni volta che un processo fallisce durante l'utilizzo della ripresa automatica:
| Categoria | Nome dell’utilità | Compatibilità del tipo di istanza | Description |
| --- | --- | --- | --- |
| Accelerator | NVIDIA SMI | GPU | [L'utilità nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) è una nota CLI per la gestione e il monitoraggio. GPUs Lo strumento integrato di controllo dell’integrità analizza l’output da nvidia-smi per determinare l’integrità dell’istanza. |
| Accelerator | Neuron Sysfs | Trainium | Per le istanze basate su Trainium, l’integrità dei dispositivi Neuron viene determinato dalla lettura dei contatori di [Neuron Sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) propagati direttamente dal driver Neuron. |
| Rete | EFA | GPU e Trainium | Per facilitare la diagnostica dei dispositivi Elastic Fabric Adaptor (EFA), lo strumento di controllo dell’integrità di EFA esegue una serie di test di connettività utilizzando tutte le schede EFA disponibili all’interno dell’istanza. |
**Nota**
Quando le [Generic RESources (GRES)](https://slurm.schedmd.com/gres.html) sono collegate a un nodo Slurm, Slurm in genere non consente modifiche all’allocazione dei nodi, ad esempio la sostituzione dei nodi, e quindi non consente di riprendere un processo non riuscito. A meno che non sia esplicitamente vietato, la funzionalità di ripristino HyperPod automatico rimette automaticamente in coda qualsiasi lavoro difettoso associato ai nodi abilitati per GRES. Questa procedura prevede l’arresto del processo, il suo reinserimento nella coda dei processi e il suo riavvio dall’inizio.
**Utilizzo della funzionalità di SageMaker HyperPod ripristino automatico con Slurm**
Quando si utilizza il SageMaker HyperPod ripristino automatico con Slurm, è necessario eseguire il lavoro all'interno di un'allocazione esclusiva acquisita utilizzando o. `salloc` `sbatch` In ogni caso, devi modificare lo script del punto di ingresso per assicurarti che tutte le fasi della configurazione vengano eseguite in un unico comando `srun` quando riprendi il processo. Utilizzando lo script del punto di ingresso, è importante configurare l’ambiente sul nodo sostituito in modo che sia coerente con l’ambiente in cui era in esecuzione la fase del processo prima che venisse interrotta. La procedura seguente mostra come preparare uno script entrypoint per mantenere l'ambiente coerente ed eseguirlo come un singolo comando. `srun`
**Suggerimento**
Se utilizzi `sbatch`, puoi semplificare lo script batch creando uno script separato per la configurazione dell’ambiente e l’uso di un singolo comando `srun`.
1. Crea uno script utilizzando l’esempio di codice seguente e salvalo come `train_auto_resume.sh`. Questo script implementa le configurazioni dell’ambiente di addestramento presupponendo che non sia stata precedentemente effettuata alcuna configurazione manuale sul nodo sostituito. Questo garantisce che l’ambiente sia indipendente dal nodo in modo che, quando un nodo viene sostituito, lo stesso ambiente venga allocato sul nodo prima di riprendere il processo.
**Nota**
L’esempio di codice seguente mostra come rilevare l’elenco dei nodi Slurm associati al processo. Non utilizzare la variabile di `$SLURM_JOB_NODELIST` ambiente fornita da Slurm, poiché il suo valore potrebbe essere obsoleto dopo la ripresa SageMaker HyperPod automatica del lavoro. L’esempio di codice seguente mostra come definire una nuova variabile `NODE_LIST` per sostituire `SLURM_JOB_NODELIST` e quindi impostare le variabili `MASTER_NODE` e `MASTER_ADDR` al di fuori della variabile `NODE_LIST`.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**Suggerimento**
Puoi utilizzare lo script precedente per aggiungere altri comandi per l’installazione di eventuali dipendenze aggiuntive per il processo. Tuttavia, consigliamo di mantenere gli script di installazione delle dipendenze nel [set di script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) utilizzati durante la creazione del cluster. Se utilizzi un ambiente virtuale ospitato in una directory condivisa, puoi utilizzare questo script anche per attivare l’ambiente virtuale.
1. Avvia il processo con la SageMaker HyperPod ripresa automatica abilitata aggiungendo il flag `--auto-resume=1` per indicare che il `srun` comando deve essere riprovato automaticamente in caso di guasto hardware.
**Nota**
Se è stata impostata un’allocazione di risorse con `sbatch` o `salloc`, puoi eseguire più comandi `srun` all’interno dell’allocazione. In caso di errore, la funzionalità di SageMaker HyperPod ripristino automatico funziona solo nella [fase di lavoro](https://slurm.schedmd.com/job_launch.html#step_allocation) corrente del `srun` comando con il flag. `--auto-resume=1` In altre parole, l’attivazione della ripresa automatica in un comando `srun` non si applica agli altri comandi `srun` avviati all’interno di una sessione di allocazione delle risorse.
Di seguito sono riportati esempi del comando `srun` con `auto-resume` abilitato.
**Utilizzo di sbatch**
Poiché la maggior parte della logica per la configurazione dell’ambiente è già presente in `train_auto_resume.sh`, lo script batch dovrebbe essere semplice e simile al codice di esempio seguente. Supponiamo che il seguente script batch venga salvato come `batch.sh`.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
Esegui lo script batch utilizzando il comando seguente.
```
sbatch batch.sh
```
**Utilizzo di salloc**
Inizia acquisendo un’allocazione esclusiva ed esegui il comando `srun` con il flag `--auto-resume` e lo script del punto di ingresso.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## Come interagiscono il ripristino automatico dei nodi e il ripristino automatico
Quando i sistemi di ripristino automatico dei nodi e di ripristino automatico sono attivi, seguono un approccio coordinato alla gestione dei guasti. Se l'HMA rileva un guasto hardware, il nodo viene contrassegnato per il drenaggio indipendentemente dallo stato a livello di processo. Con il ripristino automatico dei nodi abilitato, i nodi vengono sostituiti automaticamente una volta terminati tutti i processi in esecuzione nei nodi. In questo scenario, per i lavori con ripristino automatico abilitato, se nella fase è presente uno stato di uscita diverso da zero, viene attivata la ripresa automatica (i lavori riprendono una volta sostituiti i nodi). I lavori senza il ripristino automatico verranno semplicemente chiusi e richiederanno un nuovo invio manuale da parte degli amministratori o degli utenti.
**Nota**
Se si utilizza la ripresa automatica, i nodi vengono sempre sostituiti (nessun riavvio) quando vengono rilevati guasti hardware.
# Sostituisci o riavvia manualmente un nodo usando Slurm
Questa sezione spiega quando è necessario riavviare o sostituire manualmente un nodo, con istruzioni su come eseguire entrambe le operazioni.
## Quando riavviare o sostituire manualmente un nodo
La funzionalità di HyperPod ripristino automatico monitora se lo stato dei nodi Slurm diventa o. `fail` `down` Puoi controllare lo stato dei nodi Slurm eseguendo `sinfo`.
Se un nodo rimane bloccato o non risponde e il processo di ripristino automatico non lo ripristina, puoi avviare il ripristino manualmente. La scelta tra il riavvio e la sostituzione di un nodo dipende dalla natura del problema. Prendi in considerazione la possibilità di riavviare il sistema in caso di problemi temporanei o legati al software, come blocchi del sistema, perdite di memoria, problemi relativi ai driver della GPU, aggiornamenti del kernel o blocchi dei processi. Tuttavia, se si verificano problemi persistenti o legati all'hardware come guasti, errori di memoria o di rete GPUs, ripetuti errori nei controlli di integrità o nodi che non rispondono dopo più tentativi di riavvio, la sostituzione dei nodi è la soluzione più appropriata.
## Metodi per riavviare o sostituire manualmente i nodi
SageMaker HyperPod offre due metodi per il ripristino manuale dei nodi. L'approccio preferito consiste nell'utilizzare SageMaker HyperPod Reboot and Replace APIs, che fornisce un processo di ripristino più rapido e trasparente che funziona con tutti gli orchestratori. In alternativa, è possibile utilizzare i comandi Slurm tradizionali come`scontrol update`, sebbene questo metodo legacy richieda l'accesso diretto al nodo controller di Slurm. Entrambi i metodi attivano gli stessi processi di ripristino. SageMaker HyperPod
## Riavvia manualmente un nodo utilizzando l'API di riavvio
È possibile utilizzare il **BatchRebootClusterNodes**per riavviare manualmente un nodo difettoso nel cluster. SageMaker HyperPod
Ecco un esempio di esecuzione dell'operazione di riavvio su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Sostituisci manualmente un nodo utilizzando l'API di sostituzione
È possibile utilizzare il **BatchReplaceClusterNodes**per sostituire manualmente un nodo difettoso nel SageMaker HyperPod cluster.
Ecco un esempio di esecuzione dell'operazione di sostituzione su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Riavviare manualmente un nodo utilizzando Slurm
Puoi anche usare i comandi scontrol Slurm per attivare il ripristino del nodo. Questi comandi interagiscono direttamente con il piano di controllo Slurm e richiamano gli stessi meccanismi di ripristino sottostanti. SageMaker HyperPod
Nel comando seguente, sostituite con il nome del nodo Slurm (nome host) dell'istanza difettosa che desiderate riavviare.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Questo contrassegna il nodo come FAIL per il motivo specificato. SageMaker HyperPod lo rileva e riavvia l'istanza. Evita di modificare lo stato del nodo o di riavviare il controller Slurm durante l'operazione.
## Sostituisci manualmente un nodo usando Slurm
È possibile utilizzare il comando scontrol update come segue per sostituire un nodo.
Nel comando seguente, sostituisci `` con il nome del nodo Slurm (nome host) dell'istanza difettosa che desideri sostituire.
```
scontrol update node= state=fail reason="Action:Replace"
```
Dopo aver eseguito questo comando, il nodo entrerà `fail` nello stato, attenderà il completamento dei processi attualmente in esecuzione, verrà sostituito con un'istanza integra e verrà ripristinato con lo stesso nome host. Questo processo richiede tempo e dipende dalle istanze disponibili nella zona di disponibilità e dal tempo necessario per eseguire gli script del ciclo di vita. Durante i processi di aggiornamento e sostituzione, evita nuove modifiche manuali allo stato del nodo o il riavvio del controller Slurm, perché queste operazioni potrebbero comportare errori di sostituzione. Se il nodo non viene ripristinato o non torna allo stato `idle` dopo molto tempo, contatta il [Supporto AWS](https://console.aws.amazon.com/support/).
## Forza la modifica manuale di un nodo
Se il nodo difettoso resta sempre bloccato in stato `fail`, l’ultima soluzione che potresti provare è forzare manualmente la modifica dello stato del nodo su `down`. Questa operazione richiede privilegi di amministratore (autorizzazioni sudo).
**avvertimento**
Procedi con cautela prima di utilizzare il comando seguente, perché impone l’interruzione di tutti i processi che potrebbe comportare la perdita di tutto il lavoro non salvato.
```
scontrol update node= state=down reason="Action:Replace"
```