Resiliência do cluster SageMaker HyperPod

O SageMaker HyperPod fornece os seguintes atributos de resiliência de cluster:

Verificação de integridade do cluster

Esta seção descreve o conjunto de verificações de integridade que o SageMaker HyperPod usa para monitorar regularmente a integridade da instância de cluster em busca de problemas com dispositivos como aceleradores (núcleos de GPU e Trainium) e redes (EFA).

Categoria	Nome do utilitário	Compatibilidade de tipo de instância	Descrição
Accelerator	Políticas do DCGM	GPU	Cada instância no cluster monitora continuamente todas as políticas relacionadas à GPU, incluindo erros de XID com o NVIDIA DCGM.
Accelerator	NVIDIA SMI	GPU	A utilidade nvidia-smi é uma CLI bem conhecida para gerenciar e monitorar GPUs. O verificador de integridade integrado analisa a saída de nvidia-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	GPU e Trainium	Para auxiliar no diagnóstico dos dispositivos Elastic Fabric Adaptor (EFA), o verificador de integridade do EFA executa uma série de testes de conectividade usando todas as placas EFA disponíveis na instância.
Stress	Diagnóstico DCGM de nível 2	GPU	O diagnóstico DCGM de nível 2 é usado para exercitar as GPUs no sistema e colocá-las sob pressão para obter uma visão completa da saúde.
Stress	Stress da CPU	GPU e Trainium	A integridade da CPU é determinada usando a ferramenta de stress Linux, que executa vários threads para atingir 100% de utilização da CPU e realizar operações de E/S.

Retomada automática

Esta seção descreve como executar um trabalho de treinamento com a funcionalidade de retomada automática do SageMaker HyperPod, 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 reinício automático do SageMaker HyperPod 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 recursos genéricos (GRES) são anexados a um nó do Slurm, o Slurm normalmente não permite alterações na alocação do nó, como a substituição de nós, e, portanto, não permite a retomada de um trabalho com falha. A menos que seja explicitamente proibida, a funcionalidade de retomada automática do HyperPod enfileira automaticamente qualquer trabalho com defeito associado aos nós habilitados para GRES. Esse processo envolve interromper o trabalho, colocá-lo de volta na fila de trabalhos e reiniciar o trabalho desde o início.

Usando a funcionalidade de retomada automática do SageMaker HyperPod com o Slurm

Ao usar a retomada automática do SageMaker HyperPod com o Slurm, você deve executar o trabalho dentro de uma alocação exclusiva adquirida usando ou salloc ou 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 comando srun 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ê usar sbatch, poderá manter o script em lote simples criando um script separado para configurar o ambiente e usando um único comando srun.

1. 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 ambiente $SLURM_JOB_NODELIST fornecida pelo Slurm, pois seu valor pode ficar desatualizado após o SageMaker HyperPod retomar automaticamente o trabalho. O exemplo de código a seguir mostra como definir uma nova variável NODE_LIST para substituir SLURM_JOB_NODELIST, em seguida, configurar as variáveis MASTER_NODE e MASTER_ADDR e fora da variável 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

   dica

   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 que são 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.

2. Inicie o trabalho com a retomada automática do SageMaker HyperPod ativada adicionando a sinalização --auto-resume=1 para indicar que o comando srun deve ser repetido automaticamente em caso de falha de hardware.

   nota

   Se você configurou uma alocação de recursos usando sbatch ou salloc, você pode executar vários comandos srun dentro da alocação. No caso de uma falha, a funcionalidade de retomada automática do SageMaker HyperPod opera somente na etapa de trabalho atual do comando srun com a sinalização --auto-resume=1. Em outras palavras, ativar a retomada automática em um comando srun não se aplica a outros comandos srun iniciados em uma sessão de alocação de recursos.

   A seguir, exemplos de comando srun com auto-resume habilitado.

   Usando sbatch

   Como a maior parte da lógica de configuração do ambiente já está estabelecida em 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 como batch.sh.

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

   Execute o script em lote anterior usando o seguinte comando:

   sbatch batch.sh

   Usando salloc

   Comece adquirindo uma alocação exclusiva e execute o comando srun com a sinalização --auto-resume e o sinalizador e o script do ponto de entrada.

   salloc -N 2 --exclusive
   srun --auto-resume=1 train_auto_resume.sh

Como substituir um nó defeituoso que não está sendo retomado automaticamente pelo HyperPod

A funcionalidade de retomada automática do HyperPod monitora se o estado dos nós do Slurm muda para fail ou down. Você pode verificar o estado dos nós do Slurm executando sinfo.

Se você tiver um nó preso com um problema, mas não estiver sendo corrigido pela funcionalidade de retomada automática do HyperPod, recomendamos que você execute o comando a seguir para alterar o estado do nó para fail.

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

No exemplo de comando anterior, substitua <ip-ipv4> pelo nome do nó Slurm (nome do host) da instância com defeito que você deseja substituir.

Depois de executar esse comando, o nó deve entrar no estado fail, 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 estado idle após um longo período, entre em contato com a Ajuda da AWS.

Se o nó com defeito estiver continuamente preso no estado fail, o último recurso que você pode tentar é forçar manualmente a alteração do estado do nó para down. 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"