SageMaker HyperPod resilienza del cluster - Amazon SageMaker
Controllo dello stato del clusterRipresa automaticaCome sostituire un nodo difettoso che non viene ripreso automaticamente da HyperPod

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 fornisce le seguenti funzionalità di resilienza del cluster.

Controllo dello stato del cluster

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 (GPUe core Trainium) e rete (). EFA

Categoria Nome dell'utilità Compatibilità del tipo di istanza Descrizione
Accelerator DCGMpolitiche GPU Ogni istanza del cluster monitora continuamente tutte le politiche GPU correlate, inclusi XID gli errori con. NVIDIADCGM
Accelerator NVIDIA SMI GPU L'utilità nvidia-smi è nota per la gestione e il monitoraggio. CLI GPUs L'health checker integrato analizza l'output nvidia-smi per determinare lo stato dell'istanza.
Accelerator Neuron sysfs Trainium Per le istanze alimentate da Trainium, lo stato dei dispositivi Neuron è determinato dalla lettura dei contatori dei sistemi Neuron propagati direttamente dal driver Neuron.
Rete EFA GPUe Trainium Per facilitare la diagnostica dei dispositivi Elastic Fabric Adaptor (EFA), l'EFAhealth checker esegue una serie di test di connettività utilizzando tutte le EFA schede disponibili all'interno dell'istanza.
Stress DCGMDiagnosi GPU DCGMLa diagnostica di livello 2 serve a mettere sotto pressione gli organi del sistema per ottenere una visione approfondita dello stato di salute. GPUs
Stress CPUstress GPUe Trainium CPUlo stato di salute viene determinato utilizzando lo strumento di stress di Linux, che esegue più thread per ottenere il 100% di CPU utilizzo ed eseguire operazioni di I/O.

Ripresa automatica

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 per cluster con più di 16 nodi.

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.

Nota

Quando Generic Resources (GRES) è collegato a un nodo Slurm, Slurm in genere non consente modifiche nell'allocazione dei nodi, come la sostituzione dei nodi, e quindi non consente di riprendere un processo fallito. A meno che non sia esplicitamente vietato, la funzionalità di ripristino HyperPod automatico riposiziona automaticamente in coda qualsiasi lavoro difettoso associato ai nodi -enabled. GRES Questo processo prevede l'arresto del lavoro, il suo reinserimento nella coda dei lavori e il riavvio del lavoro 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, è necessario modificare lo script entrypoint per assicurarsi che tutte le fasi di configurazione vengano eseguite in un unico comando quando si riprende il lavoro. srun Tramite lo script entrypoint, è importante configurare l'ambiente sul nodo sostituito in modo che sia coerente con l'ambiente in cui il job step era in esecuzione prima che venisse interrotto. La seguente precedenza mostra come preparare uno script entrypoint per mantenere l'ambiente coerente ed eseguirlo come un singolo comando. srun

Suggerimento

Se si utilizzasbatch, è possibile semplificare lo script batch creando uno script separato per la configurazione dell'ambiente e utilizzando un singolo comando. srun

  1. Create uno script utilizzando il seguente esempio di codice e salvatelo con nometrain_auto_resume.sh. Questo script implementa le configurazioni dell'ambiente di formazione presupponendo che non sia stata precedentemente effettuata alcuna configurazione manuale sul nodo sostituito. Ciò garantisce che l'ambiente sia indipendente dal nodo, in modo che quando un nodo viene sostituito, lo stesso ambiente venga fornito sul nodo prima di riprendere il lavoro.

    Nota

    Il seguente esempio di codice mostra come scoprire l'elenco dei nodi Slurm associati al job. 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. Il seguente esempio di codice mostra come definire una nuova NODE_LIST variabile da sostituire SLURM_JOB_NODELIST e quindi impostare le variabili e esterne alla MASTER_NODE variabile. MASTER_ADDR 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

    È possibile utilizzare lo script precedente per aggiungere altri comandi per l'installazione di eventuali dipendenze aggiuntive per il lavoro. Tuttavia, si consiglia di mantenere gli script di installazione delle dipendenze nel set di script del ciclo di vita utilizzati durante la creazione del cluster. Se si utilizza un ambiente virtuale ospitato in una directory condivisa, è possibile utilizzare questo script anche per attivare l'ambiente virtuale.

  2. 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 hai impostato un'allocazione di risorse utilizzando sbatch osalloc, puoi eseguire più srun comandi all'interno dell'allocazione. In caso di errore, la funzionalità di SageMaker HyperPod ripristino automatico funziona solo nella fase di lavoro corrente del srun comando con il flag. --auto-resume=1 In altre parole, l'attivazione della ripresa automatica in un srun comando non si applica agli altri srun comandi lanciati all'interno di una sessione di allocazione delle risorse.

    Di seguito sono riportati alcuni esempi di srun comandi con enabled. auto-resume

    Usare sbatch

    Poiché la maggior parte della logica per la configurazione dell'ambiente è già presentetrain_auto_resume.sh, lo script batch dovrebbe essere semplice e simile al seguente esempio di codice. Si supponga che il seguente script batch venga salvato comebatch.sh.

    #!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh

    Eseguite lo script batch precedente utilizzando il comando seguente.

    sbatch batch.sh

    Usare salloc

    Inizia acquisendo un'allocazione esclusiva ed esegui il srun comando con il --auto-resume flag e lo script entrypoint.

    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 HyperPod ripristino automatico monitora se lo stato dei nodi Slurm diventa o. fail down Puoi controllare lo stato dei nodi Slurm eseguendo. sinfo

Se hai un nodo bloccato con un problema che non viene risolto dalla funzionalità di HyperPod ripristino automatico, ti consigliamo di eseguire il seguente comando per modificare lo stato del nodo in. fail

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

Nell'esempio di comando precedente, sostituisci <ip-ipv4> con il nome del nodo Slurm (nome host) dell'istanza difettosa che desideri sostituire.

Dopo aver eseguito questo comando, il nodo dovrebbe entrare fail nello stato, attendere il completamento dei processi attualmente in esecuzione, essere sostituito con un'istanza funzionante e ripristinato con lo stesso nome host. Questo processo richiede tempo a seconda delle istanze disponibili nella zona di disponibilità e del tempo necessario per eseguire gli script del ciclo di vita. Durante i processi di aggiornamento e sostituzione, evita di modificare nuovamente lo stato del nodo manualmente o di riavviare il controller Slurm; ciò può causare un errore di sostituzione. Se il nodo non viene ripristinato né torna allo idle stato dopo molto tempo, contatta AWS Support.

Se il nodo difettoso è continuamente bloccato nello fail stato, l'ultima soluzione che potresti provare è forzare manualmente la modifica dello stato del nodo. down Ciò richiede i privilegi di amministratore (autorizzazioni sudo).

avvertimento

Procedete con cautela prima di eseguire il comando seguente poiché impone l'interruzione di tutti i lavori e potreste perdere tutto il lavoro non salvato.

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