

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
<a name="sagemaker-hyperpod-resiliency-slurm"></a>

SageMaker HyperPod por meio da orquestração do Slurm, fornece os seguintes recursos de resiliência de cluster.

**Topics**
+ [Agente de monitoramento de saúde](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Recuperação automática de nós e retomada automática](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Substitua ou reinicialize manualmente um nó usando o Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)

# Agente de monitoramento de saúde
<a name="sagemaker-hyperpod-resiliency-slurm-cluster-health-check"></a>

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 (núcleos de GPU e Trainium) e redes (EFA). SageMaker HyperPod o agente de monitoramento de saúde (HMA) monitora continuamente o status de saúde de cada instância baseada em GPU ou Trainium. Ao detectar qualquer falha na instância ou na GPU, o agente marca a instância como não íntegra.

SageMaker HyperPod O HMA realiza as mesmas verificações de integridade para os orquestradores EKS e Slurm. Para obter mais informações sobre o HMA, consulte[Sistema de monitoramento de saúde](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).

# Recuperação automática de nós e retomada automática
<a name="sagemaker-hyperpod-resiliency-slurm-auto-resume"></a>

**nota**  
A partir de 11 de setembro de 2025, HyperPod com o Slurm, a orquestração agora suporta agentes de monitoramento de saúde. Execute [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)e atualize para a versão mais recente da AMI para usar essa funcionalidade.

Esta seção fala sobre os dois recursos de resiliência complementares SageMaker HyperPod da Amazon: recuperação automática de nós, que substitui a infraestrutura defeituosa sem intervenção manual, e a funcionalidade de retomada automática, que reinicia as tarefas de treinamento a partir do último ponto de verificação após falhas de hardware.

## Como funciona a recuperação automática de nós
<a name="sagemaker-hyperpod-resiliency-slurm-auto-resume-how"></a>

Durante a criação ou atualização do cluster, os usuários administradores do cluster podem selecionar a opção de recuperação do nó (instância) entre `Automatic` (Recomendado) e `None` no nível do cluster. Se definido como`Automatic`, SageMaker HyperPod reinicializa ou substitui automaticamente os nós defeituosos. 

**Importante**  
Recomendamos definir a opção `Automatic`. Por padrão, os clusters são configurados com a recuperação automática de nós.

A recuperação automática de nós é executada quando problemas são encontrados no agente de monitoramento de integridade, nas verificações básicas de integridade e nas verificações profundas de integridade. Se definido como `None`, o agente de monitoramento de integridade rotulará as instâncias quando uma falha for detectada, mas não iniciará automaticamente nenhuma ação de reparo ou recuperação nos nós afetados. Não recomendamos essa opção.

## Executando um trabalho de treinamento com a funcionalidade de SageMaker HyperPod retomada automática da Amazon
<a name="sagemaker-hyperpod-resiliency-slurm-auto-resume-job"></a>

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.

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. As seguintes verificações de hardware são executadas sempre que um trabalho falha ao usar a retomada automática:


| Categoria | Nome do utilitário | Compatibilidade de tipo de instância | Description | 
| --- | --- | --- | --- | 
| Acelerador | NVIDIA SMI | GPU | [O utilitário nvidia-smi é uma CLI](https://developer.nvidia.com/nvidia-system-management-interface) 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. | 
| Acelerador | Sistemas de neurônios | Trainium | Para instâncias alimentadas por Trainium, a integridade dos dispositivos Neuron é determinada pela leitura de contadores do [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) 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. | 

**nota**  
Quando [recursos genéricos (GRES)](https://slurm.schedmd.com/gres.html) 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 HyperPod retomada automática coloca automaticamente em fila novamente 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 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 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 `srun` comando.

**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 `$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 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](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 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.

1. Inicie o trabalho com a SageMaker HyperPod retomada automática ativada adicionando o sinalizador `--auto-resume=1` para indicar que o `srun` comando 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 SageMaker HyperPod retomada automática opera somente na [etapa de trabalho](https://slurm.schedmd.com/job_launch.html#step_allocation) atual do `srun` comando com o sinalizador`--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 a recuperação automática de nós e a retomada automática funcionam juntas
<a name="sagemaker-hyperpod-resiliency-slurm-auto-resume-node-recovery"></a>

Quando os sistemas de recuperação automática de nós e de retomada automática estão ativos, eles seguem uma abordagem coordenada para lidar com falhas. Se o HMA detectar uma falha de hardware, o nó será marcado para drenagem, independentemente do status do nível do trabalho. Com a recuperação automática de nós ativada, os nós são substituídos automaticamente quando todas as tarefas em execução nos nós são encerradas. Nesse cenário, para trabalhos com a retomada automática ativada, se houver um status de saída diferente de zero na etapa, a retomada automática entra em ação (os trabalhos são retomados quando os nós são substituídos). Os trabalhos sem a retomada automática simplesmente serão encerrados, exigindo o reenvio manual por administradores ou usuários.

**nota**  
Se você usar a retomada automática, os nós sempre serão substituídos (sem reinicializações) quando forem detectadas falhas de hardware.

# Substitua ou reinicialize manualmente um nó usando o Slurm
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance"></a>

Esta seção fala sobre quando você deve reinicializar ou substituir manualmente um nó, com instruções sobre como fazer as duas coisas.

## Quando reinicializar ou substituir manualmente um nó
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-when"></a>

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 um nó permanecer preso ou sem resposta e o processo de retomada automática não o recuperar, você poderá iniciar a recuperação manualmente. A escolha entre reinicializar e substituir um nó depende da natureza do problema. Considere a reinicialização ao enfrentar problemas temporários ou relacionados ao software, como travamentos do sistema, vazamentos de memória, problemas no driver da GPU, atualizações do kernel ou processos interrompidos. No entanto, se você encontrar problemas persistentes ou relacionados ao hardware, como falhas, falhas de memória ou de rede GPUs, falhas repetidas na verificação de integridade ou nós que permanecem sem resposta após várias tentativas de reinicialização, a substituição do nó é a solução mais apropriada.

## Formas de reinicializar ou substituir manualmente os nós
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-ways"></a>

SageMaker HyperPod oferece dois métodos para recuperação manual de nós. A abordagem preferida é usar o SageMaker HyperPod Reboot and Replace APIs, que fornece um processo de recuperação mais rápido e transparente que funciona em todos os orquestradores. Como alternativa, você pode usar comandos tradicionais do Slurm`scontrol update`, como, embora esse método legado exija acesso direto ao nó controlador do Slurm. Ambos os métodos ativam os mesmos processos SageMaker HyperPod de recuperação.

## Reinicialize manualmente um nó usando a API de reinicialização
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-reboot-api"></a>

 Você pode usar o **BatchRebootClusterNodes**para reinicializar manualmente um nó com defeito no seu SageMaker HyperPod cluster.

 Aqui está um exemplo de como executar a operação de reinicialização em duas instâncias de um cluster usando o 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
```

## Substituir manualmente um nó usando a API de substituição
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace-api"></a>

 Você pode usar o **BatchReplaceClusterNodes**para substituir manualmente um nó com defeito no seu SageMaker HyperPod cluster.

 Aqui está um exemplo de execução da operação de substituição em duas instâncias de um cluster usando o 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
```

## Reinicialize manualmente um nó usando o Slurm
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-reboot"></a>

Você também pode usar os comandos scontrol Slurm para acionar a recuperação do nó. Esses comandos interagem diretamente com o plano de controle do Slurm e invocam os mesmos mecanismos de recuperação subjacentes SageMaker HyperPod . 

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

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

Isso marca o nó como FAIL com o motivo especificado. SageMaker HyperPod detecta isso e reinicia a instância. Evite alterar o estado do nó ou reiniciar o controlador Slurm durante a operação.

## Substituir manualmente um nó usando o Slurm
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace"></a>

Você pode usar o comando scontrol update da seguinte forma para substituir um nó.

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

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

Depois de executar esse comando, o nó entrará no `fail` estado, aguardará a conclusão dos trabalhos atualmente em execução, será substituído por uma instância íntegra e será 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](https://console.aws.amazon.com/support/).

## Forçar manualmente a mudança de um nó
<a name="sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-force"></a>

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"
```