As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
SageMaker HyperPod resiliência de clusters
SageMaker HyperPod fornece os seguintes recursos de resiliência de cluster.
Tópicos
Verificação de integridade do cluster
Esta seção descreve o conjunto de verificações de integridade SageMaker HyperPod usado para monitorar regularmente a integridade da instância do cluster em busca de problemas com dispositivos como aceleradores (GPUe núcleos Trainium) e redes (EFA).
Categoria | Nome do utilitário | Compatibilidade de tipo de instância | Descrição |
---|---|---|---|
Accelerator | DCGMpolíticas | GPU | Cada instância no cluster monitora continuamente todas as políticas GPU relacionadas, incluindo XID erros com NVIDIADCGM |
Accelerator | NVIDIA SMI | GPU | O utilitário nvidia-sminvidia-smi para determinar a integridade da instância. |
Accelerator | Sistemas de neurônios | Trainium | Para instâncias alimentadas por Trainium, a integridade dos dispositivos Neuron é determinada pela leitura de contadores do Neuron sysfs propagados diretamente pelo driver Neuron |
Rede | EFA | GPUe Trainium | Para auxiliar no diagnóstico dos dispositivos Elastic Fabric Adaptor (EFA), o verificador de EFA integridade executa uma série de testes de conectividade usando todas as EFA placas disponíveis na instância. |
Estresse | DCGMdiagnóstico de |
GPU | DCGMo nível de diagnóstico |
Estresse | CPUstress | GPUe Trainium | CPUa integridade é determinada usando a ferramenta de estresse Linux |
Retoma automático
Esta seção descreve como executar um trabalho de treinamento com a funcionalidade de SageMaker HyperPod retomada automática, que fornece uma infraestrutura de resiliência sem toque para recuperar automaticamente um trabalho de treinamento do último ponto de verificação salvo no caso de uma falha de hardware em clusters com mais de 16 nós.
Com a funcionalidade de retomada automática, se um trabalho falhar devido a uma falha de hardware ou a qualquer problema transitório entre o treinamento, o SageMaker HyperPod reinício automático inicia o fluxo de trabalho de substituição do nó e reinicia o trabalho após a substituição dos nós defeituosos.
nota
Quando Generic Resources (GRES)
Usando a funcionalidade de SageMaker HyperPod retomada automática com o Slurm
Ao usar a SageMaker HyperPod retomada automática com o Slurm, você deve executar o trabalho dentro de uma alocação exclusiva adquirida usando ou. salloc
sbatch
De qualquer forma, você precisa modificar o script do ponto de entrada para garantir que todas as etapas de configuração sejam executadas em um único srun
comando ao retomar o trabalho. Por meio do script de ponto de entrada, é importante configurar o ambiente no nó substituído para ser consistente com o ambiente em que a etapa do trabalho estava executando antes de ser interrompida. O procedimento a seguir mostra como preparar um script de ponto de entrada para manter o ambiente consistente e executá-lo como um único comando. srun
dica
Se você usarsbatch
, você pode manter o script em lote simples criando um script separado para configurar o ambiente e usando um único srun
comando.
-
Crie um script usando o exemplo de código a seguir e salve-o como
train_auto_resume.sh
. Esse script implanta configurações do ambiente de treinamento, supondo que não haja nenhuma configuração manual feita anteriormente no nó substituído. Isso garante que o ambiente seja independente de nós, de modo que, quando um nó for substituído, o mesmo ambiente seja provisionado no nó antes de retomar o trabalho.nota
O exemplo de código a seguir mostra como descobrir a lista de nós do Slurm associada ao trabalho. Não use a variável de
$SLURM_JOB_NODELIST
ambiente fornecida pelo Slurm, pois seu valor pode ficar desatualizado após a SageMaker HyperPod retomada automática do trabalho. O exemplo de código a seguir mostra como definir uma novaNODE_LIST
variável para substituir eSLURM_JOB_NODELIST
, em seguida, configurar asMASTER_ADDR
variáveisMASTER_NODE
e fora daNODE_LIST
variável.#!/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_cmddica
Você pode usar o script anterior para adicionar mais comandos para instalar quaisquer dependências adicionais para seu trabalho. No entanto, recomendamos que você mantenha os scripts de instalação de dependências no conjunto de scripts de ciclo de vida usados durante a criação do cluster. Se você usa um ambiente virtual hospedado em um diretório compartilhado, também pode utilizar esse script para ativar o ambiente virtual.
-
Inicie o trabalho com a SageMaker HyperPod retomada automática ativada adicionando o sinalizador
--auto-resume=1
para indicar que osrun
comando deve ser repetido automaticamente em caso de falha de hardware.nota
Se você configurou uma alocação de recursos usando
sbatch
ousalloc
, você pode executar váriossrun
comandos dentro da alocação. No caso de uma falha, a funcionalidade de SageMaker HyperPod retomada automática opera somente na etapa de trabalhoatual do srun
comando com o sinalizador--auto-resume=1
. Em outras palavras, ativar a retomada automática em umsrun
comando não se aplica a outrossrun
comandos iniciados em uma sessão de alocação de recursos.A seguir estão exemplos de
srun
comandos comauto-resume
habilitado.Usando sbatch
Como a maior parte da lógica de configuração do ambiente já está estabelecida
train_auto_resume.sh
, o script em lote deve ser simples e semelhante ao exemplo de código a seguir. Suponha que o script em lote a seguir seja salvo comobatch.sh
.#!/bin/bash #SBATCH --nodes 2 #SBATCH --exclusive srun --auto-resume=1
train_auto_resume.sh
Execute o script em lote anterior usando o comando a seguir.
sbatch
batch.sh
Usando salloc
Comece adquirindo uma alocação exclusiva e execute o
srun
comando com o--auto-resume
sinalizador e o script do ponto de entrada.salloc -N 2 --exclusive srun --auto-resume=1
train_auto_resume.sh
Como substituir um nó com defeito que não está sendo retomado automaticamente pelo HyperPod
A funcionalidade de HyperPod retomada automática monitora se o estado dos seus nós do Slurm muda para ou. fail
down
Você pode verificar o estado dos nós do Slurm executando. sinfo
Se você tem um nó preso com um problema, mas não está sendo corrigido pela funcionalidade de HyperPod retomada automática, recomendamos que você execute o comando a seguir para alterar o estado do nó parafail
.
scontrol update node=
<ip-ipv4>
state=fail
reason="Action:Replace"
No exemplo de comando anterior,
substitua pelo nome do nó Slurm (nome do host) da instância com defeito que você deseja substituir.<ip-ipv4>
Depois de executar esse comando, o nó deve entrar no fail
estado, aguardar a conclusão dos trabalhos atualmente em execução, ser substituído por uma instância íntegra e recuperado com o mesmo nome de host. Esse processo leva tempo, dependendo das instâncias disponíveis em sua zona de disponibilidade e do tempo necessário para executar seus scripts de ciclo de vida. Durante os processos de atualização e substituição, evite alterar o estado do nó manualmente novamente ou reiniciar o controlador Slurm; isso pode causar uma falha na substituição. Se o nó não for recuperado nem voltar ao idle
estado após um longo período, entre em contato com o AWS
Support
Se o nó com defeito estiver continuamente preso no fail
estado, o último recurso que você pode tentar é forçar manualmente a alteração do estado do nó paradown
. Isso requer privilégios de administrador (permissões sudo).
Atenção
Prossiga com cuidado antes de executar o comando a seguir, pois ele força o encerramento de todas as tarefas e você poderá perder todo o trabalho não salvo.
scontrol update node=
<ip-ipv4>
state=down
reason="Action:Replace"