Resilienza del cluster SageMaker HyperPod - Amazon SageMaker AI
Controllo dell’integrità del clusterRipresa automaticaCome sostituire un nodo difettoso che non viene ripreso automaticamente da HyperPod

Resilienza del cluster SageMaker HyperPod

SageMaker HyperPod offre le seguenti funzionalità di resilienza del cluster.

Controllo dell’integrità del cluster

Questa sezione descrive il set di controlli dell’integrità che SageMaker HyperPod utilizza per monitorare regolarmente l’integrità delle istanze del cluster alla ricerca di problemi con dispositivi quali gli acceleratori (core GPU e Trainium) e le reti (EFA).

Categoria Nome dell’utilità Compatibilità del tipo di istanza Descrizione
Accelerator Policy DCGM GPU Ogni istanza del cluster monitora continuamente tutte le policy relative alla GPU, inclusi gli errori XID con NVIDIA DCGM.
Accelerator NVIDIA SMI GPU L’utilità nvidia-smi è una CLI molto nota per gestire e monitorare le GPU. 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 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.
Stress Diagnostica DCGM di livello 2 GPU La diagnostica DCGM di livello 2 viene utilizzata per mettere in esercizio le GPU del sistema e metterle sotto pressione per ottenere una visione approfondita dell’integrità.
Stress Stress della CPU GPU e Trainium L’integrità della CPU viene determinato utilizzando lo strumento di stress Linux, che esegue più thread per ottenere il 100% di utilizzo della CPU ed eseguire operazioni di I/O.

Ripresa automatica

Questa sezione descrive come eseguire un job di addestramento con la funzionalità di ripresa automatica di SageMaker HyperPod, che fornisce un’infrastruttura di resilienza zero-touch per ripristinare automaticamente un job di addestramento dall’ultimo checkpoint salvato in caso di guasto hardware.

Con la funzionalità di ripresa automatica, se un processo non riesce a causa di un guasto hardware o di problemi transitori tra un addestramento e l’altro, questa funzionalità di SageMaker HyperPod avvia il flusso di lavoro di sostituzione dei nodi e riavvia il processo dopo la sostituzione dei nodi difettosi.

Nota

Quando le Generic RESources (GRES) 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 ripresa automatica di HyperPod rimette automaticamente in coda qualsiasi processo 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 ripresa automatica di SageMaker HyperPod con Slurm

Quando utilizzi la funzionalità di ripresa automatica di SageMaker HyperPod con Slurm, devi eseguire il processo all’interno di un’allocazione esclusiva acquisita utilizzando salloc o 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 seguente procedura mostra come preparare uno script del punto di ingresso 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 ambiente $SLURM_JOB_NODELIST fornita da Slurm, perché il suo valore potrebbe essere obsoleto dopo la ripresa automatica del processo con SageMaker HyperPod. 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 \
                       <your_training_script.py>"

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

  2. Avvia il processo con la ripresa automatica di SageMaker HyperPod abilitata aggiungendo il flag --auto-resume=1 per indicare che il comando srun 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 ripresa automatica di SageMaker HyperPod funziona solo nella fase del processo corrente del comando srun 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 sostituire un nodo difettoso che non viene ripreso automaticamente da HyperPod

La funzionalità di ripresa automatica di HyperPod monitora se lo stato dei nodi Slurm diventa fail o down. Puoi controllare lo stato dei nodi Slurm eseguendo sinfo.

Se hai un nodo bloccato da un problema che non è stato risolto dalla funzionalità di ripresa automatica di HyperPod, ti consigliamo di utilizzare il comando seguente per modificare lo stato del nodo su fail.

scontrol update node=<ip-ipv4> state=fail reason="Action:Replace"

Nel comando precedente di esempio, sostituisci <ip-ipv4> con il nome del nodo Slurm (nome host) dell’istanza difettosa da sostituire.

Dopo aver eseguito questo comando, dovrebbe verificarsi quanto segue: il nodo entra in stato fail, attende il completamento dei processi attualmente in esecuzione, viene sostituito da un’istanza integra e viene 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.

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=<ip-ipv4> state=down reason="Action:Replace"