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á. # Verificações de integridade profundas SageMaker HyperPod realiza *verificações detalhadas de integridade* em instâncias de Slurm-orchestrated cluster para garantir a confiabilidade e a estabilidade do hardware e da infraestrutura subjacentes. As verificações de saúde detalhadas podem ser executadas automaticamente quando as instâncias são criadas ou adicionadas a um cluster (na *inicialização*), ou você pode acioná-las manualmente a qualquer momento (*sob demanda*) usando a [StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html)API. Essa abordagem proativa ajuda a identificar e mitigar possíveis problemas em todo o ciclo de vida do cluster. Durante verificações de integridade detalhadas, os nós afetados são colocados em uma reserva de manutenção do Slurm para evitar que trabalhos sejam agendados neles. Depois que todas as verificações são aprovadas, os nós são liberados da reserva e ficam disponíveis para cargas de trabalho. **Importante** Para usar verificações de saúde detalhadas, você deve atualizar para a versão mais recente da AMI. Execute [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)para atualizar para a versão mais recente da AMI. Se você estiver executando uma versão mais antiga da AMI, as verificações profundas de integridade podem não funcionar conforme o esperado. ## Tipos de verificação profunda de saúde SageMaker HyperPod oferece suporte a duas categorias de verificações profundas de integridade para clusters do Slurm: + **InstanceStress**— Executa testes em nível de instância, incluindo testes de estresse de hardware (CPU, memória, disco, GPU/PCI verificação), diagnósticos de GPU DCGM e conectividade de loopback EFA. Isso valida a integridade do hardware de nós individuais. + **InstanceConnectivity**— Executa testes NCCL (NVIDIA Collective Communications Library) em nível de cluster em vários nós para verificar o desempenho da comunicação entre as GPUs. Essa verificação só é compatível com instâncias com recursos de comunicação de GPU de vários nós. ## Lista de verificações de saúde detalhadas feitas por SageMaker HyperPod SageMaker HyperPod executa as seguintes verificações de saúde detalhadas. **Instance-level verificações de saúde profundas (InstanceStress)** | Categoria | Nome do utilitário | Compatibilidade de tipo de instância | Description | | --- | --- | --- | --- | | Acelerador | GPU/NVLink count | GPU | Verifica as GPU/NVLink contagens. | | Acelerador | [Diagnóstico DCGM](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) de nível 4 | GPU | Avalia a integridade e a funcionalidade das GPUs NVIDIA executando o diagnóstico DCGM (NVIDIA Data Center GPU Manager) no nível 4, incluindo testes adicionais de memória. Duração típica: cerca de 45 a 90 minutos, dependendo da contagem de GPU. | | Rede | EFA | GPU | Executa testes de latência e largura de banda de loopback do EFA no dispositivo EFA conectado. Duração típica: \~2-5 minutos. | **Cluster-level verificações de saúde profundas (InstanceConnectivity)** | Categoria | Nome do utilitário | Compatibilidade de tipo de instância | Description | | --- | --- | --- | --- | | Acelerador | Teste NCCL | GPU | Executa testes de all\_reduce desempenho da NCCL em vários nós para verificar a largura de banda de comunicação entre nós da GPU. Duração típica: cerca de 5 a 15 minutos, dependendo da contagem de nós. | ## On-start verificações de saúde aprofundadas On-start verificações profundas de integridade são executadas automaticamente quando as instâncias são provisionadas pela primeira vez — durante a criação do cluster ou quando novas instâncias são adicionadas via. [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) Isso garante que cada nó passe pela validação do hardware antes de aceitar cargas de trabalho. ### Habilitando verificações de saúde detalhadas na inicialização Para ativar verificações de saúde detalhadas na inicialização, especifique o `OnStartDeepHealthChecks` parâmetro na configuração do grupo de instâncias ao criar ou atualizar um cluster. **Exemplo: criar um cluster com verificações de saúde detalhadas no início** ``` aws sagemaker create-cluster \ --cluster-name {{my-slurm-cluster}} \ --instance-groups '[ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 4, "LifeCycleConfig": { "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}", "ThreadsPerCore": 1, "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"] } ]' \ --vpc-config '{"SecurityGroupIds":["{{sg-12345678}}"],"Subnets":["{{subnet-12345678}}"]}' ``` ### O que acontece durante as verificações de saúde aprofundadas na inicialização Quando as verificações profundas de integridade na inicialização estão habilitadas, ocorre o seguinte processo: 1. **Provisionamento de nós**: novas instâncias são lançadas e scripts de ciclo de vida são executados. 1. **Isolamento** de nós: o agente de HyperPod cluster coloca novos nós em uma reserva de manutenção do Slurm (`hyperpod-deep-health-check`) e os adiciona à `hyperpod-system-maintenance` partição. Os nós são marcados com o recurso Slurm. `SageMakerDeepHealthCheck:InProgress` Isso evita que trabalhos sejam agendados nesses nós durante o teste. 1. **Execução do teste**: os testes a seguir são executados em cada nó como parte da `InstanceStress` verificação: + **HARDWARE\_CHECK**: executa testes `stress-ng` de estresse de CPU, memória e disco, seguidos pela verificação da contagem de dispositivos de GPU e PCI. Duração típica: \~1-2 minutos. + **DCGM**: executa diagnósticos NVIDIA DCGM no nível 4, incluindo testes de memória de GPU. Duração típica: cerca de 45 a 90 minutos, dependendo da contagem de GPU. + **EFA: executa** testes de latência e largura de banda de loopback do EFA. Duração típica: \~2-5 minutos. Se também `InstanceConnectivity` estiver ativado, o seguinte teste adicional será executado: + **NCCL**: executa testes de `all_reduce` desempenho de NCCL em vários nós para verificar a largura de banda de comunicação entre nós da GPU. Duração típica: cerca de 5 a 15 minutos, dependendo da contagem de nós. 1. **Manipulação de resultados**: + **Passe**: o nó é removido da reserva de manutenção, o recurso de verificação profunda de integridade é eliminado e o nó fica disponível para trabalhos na partição atribuída. + **Falha**: o nó permanece isolado. SageMaker HyperPod substitui automaticamente o nó com falha e executa verificações detalhadas de integridade na substituição. O cluster faz a transição para `InService` uma vez em que pelo menos o nó do controlador esteja em execução. Os nós de trabalho mostram `DeepHealthCheckInProgress` o status durante o teste e a transição para `Running` após a aprovação. ### Monitorando verificações de saúde detalhadas no início Você pode monitorar o status das verificações de saúde profundas no início usando a API Amazon SageMaker AI ou os comandos Slurm. **Verifique o status do nó usando o AWS Command Line Interface** ``` aws sagemaker list-cluster-nodes \ --cluster-name {{my-slurm-cluster}} ``` Os nós submetidos a verificações de integridade profundas são exibidos `InstanceStatus.Status` como`DeepHealthCheckInProgress`. **Verifique o estado do Slurm via SSM no nó do controlador** ``` # View node states sinfo -a -N -l # View maintenance reservation scontrol show reservations # View running DHC jobs squeue -a ``` Os nós sob verificação profunda de integridade aparecem na `hyperpod-deep-health-check` reserva e na `hyperpod-system-maintenance` partição. ### Adicionar nós a um cluster com verificações de saúde profundas na inicialização ativadas Quando você expande um cluster `OnStartDeepHealthChecks` configurado, os novos nós passam automaticamente por verificações de integridade detalhadas antes de aceitar cargas de trabalho. Os nós existentes e os trabalhos em execução não são afetados. ``` aws sagemaker update-cluster \ --cluster-name {{my-slurm-cluster}} \ --instance-groups '[ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "LifeCycleConfig": { "SourceS3Uri": "s3://{{my-bucket}}/lifecycle-scripts/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/{{my-role}}", "ThreadsPerCore": 1, "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"] } ]' ``` Os novos nós são isolados na reserva de manutenção durante a execução de verificações detalhadas de integridade. Os trabalhos que exigem a capacidade adicional dos novos nós aguardam até que esses nós passem por verificações de integridade detalhadas e estejam disponíveis. Os trabalhos que podem ser satisfeitos pelos nós disponíveis existentes não são afetados. ## On-demand verificações de saúde aprofundadas On-demand verificações profundas de integridade permitem que você acione a validação de hardware nos nós de cluster existentes a qualquer momento usando a [StartClusterHealthCheck](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_StartClusterHealthCheck.html)API. Isso é útil para validação periódica de integridade ou após suspeitas de problemas de hardware. **nota** On-demand verificações de integridade profundas não são suportadas em clusters com `NodeProvisioningMode` definido como`Continuous`. ### Executando verificações de integridade detalhadas sob demanda a partir do console Você pode executar verificações de saúde detalhadas em instâncias de HyperPod cluster diretamente do console de SageMaker IA. **Para executar verificações de saúde detalhadas sob demanda a partir do console** 1. Abra o console de SageMaker IA no [console de SageMaker IA](https://console.aws.amazon.com/sagemaker). 1. No painel de navegação, em **HyperPod**, escolha **Clusters**. 1. Escolha o nome do seu cluster para abrir a página de detalhes do cluster. 1. Na tabela **Instâncias**, selecione uma ou mais instâncias nas quais você deseja executar verificações de saúde detalhadas. **nota** As famílias de instâncias compatíveis incluem g5, p4 e p5. Non-accelerated as instâncias são automaticamente ignoradas. 1. Escolha **Ações** e, em seguida, escolha **Executar verificações de saúde detalhadas**. 1. Selecione **Verificação de estresse**, **Verificação de conectividade** ou ambas: + **Verificação de estresse** — valida o hardware do acelerador sob carga (corresponde a`InstanceStress`). + **Verificação de conectividade** — Valida a comunicação de rede entre nós (corresponde a`InstanceConnectivity`). 1. Escolha **Executar verificações de saúde**. Um banner de sucesso confirma que as verificações foram iniciadas. As instâncias não estão disponíveis para cargas de trabalho durante as verificações, que podem levar mais de uma hora. Monitore o status da instância na tabela **Instâncias** — ela mostra **uma verificação profunda de integridade em andamento** durante a execução. Quando problemas são encontrados e a recuperação automática é ativada, reinicializa ou substitui SageMaker HyperPod automaticamente as instâncias com defeito. ### Acionando verificações de saúde profundas sob demanda usando o AWS Command Line Interface Você pode especificar quais grupos de instâncias e quais verificações executar. Somente uma solicitação de verificação profunda de integridade sob demanda pode estar ativa por cluster por vez. ``` aws sagemaker start-cluster-health-check \ --cluster-name {{my-slurm-cluster}} \ --deep-health-check-configurations '[ { "InstanceGroupName": "worker-group", "DeepHealthChecks": ["InstanceStress", "InstanceConnectivity"] } ]' ``` ### Comportamento com cargas de trabalho em execução Quando verificações de integridade profundas sob demanda são acionadas em nós que estão executando trabalhos: + Os trabalhos em execução **não** são interrompidos nem encerrados. + A verificação profunda de integridade está na fila e aguarda a conclusão do trabalho atual. Se o trabalho em execução não for concluído em 10 minutos, o nó será ignorado da verificação profunda de integridade. + Os nós são colocados na reserva de manutenção para evitar que novos trabalhos sejam agendados durante o teste. ## Logs das verificações de integridade profundas Veja a seguir exemplos de registros das verificações de saúde SageMaker HyperPod detalhadas. **Cluster-level logs** Os registros de verificação profunda de integridade em nível de cluster são armazenados em seu CloudWatch grupo de registros em. `/aws/sagemaker/Clusters//` Os fluxos de log estão registrados em `DeepHealthCheckResults/`. **Instance-level logs** Em cada nó, registros de verificação profunda de integridade são armazenados em`/var/log/aws/clusters/sagemaker-deep-health-check.log`. Você pode acessar o registro via SSM: ``` aws ssm start-session \ --target "sagemaker-cluster:{{}}_{{}}-{{}}" ``` Em seguida, veja o registro: ``` cat /var/log/aws/clusters/sagemaker-deep-health-check.log ``` **Exemplo de saída HARDWARE\_CHECK** ``` 2026-03-29T18:03:14Z info Executing Hardware stress check with command: stress-ng 2026-03-29T18:04:20Z info stress-ng success 2026-03-29T18:04:20Z info GpuPci Count check success ``` **Exemplo de saída DCGM** ``` 2026-03-29T18:35:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 4 dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01 gpuDeviceIds: [2237] replacementRequired: false rebootRequired: false ``` **Exemplo de saída EFA** ``` 2026-03-29T18:36:28Z info EFA Loopback check passed for device: rdmap0s29 MaxBw: 58.59, AvgBw: 32.42, MaxTypicalLat: 30.87, AvgLat: 21.63 ``` **Exemplo de saída de falha de verificação profunda de integridade** ``` { "level": "error", "ts": "2026-03-29T19:15:22Z", "msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: ml.g5.8xlarge. ERROR: Bandwidth has less than threshold: Expected minimum threshold: 80, NCCL Test output Bw: 30" } ``` ## Auto-resume comportamento com verificações de saúde aprofundadas Sem a ativação de verificações de integridade aprofundadas, quando um nó é substituído durante a retomada automática, o nó substituto é imediatamente adicionado ao cluster e o trabalho retomado automaticamente pode ser agendado nele imediatamente. Com as verificações de saúde profundas ativadas, o nó substituto deve passar por todas as verificações de saúde profundas configuradas antes de ficar disponível. No entanto, o trabalho retomado automaticamente não precisa esperar pelo nó de substituição — ele pode ser agendado em qualquer outro nó disponível no cluster. O trabalho só espera se nenhum outro nó estiver disponível. ## Considerações adicionais + As verificações de saúde aprofundadas exigem a versão mais recente da AMI. Execute [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)para atualizar seu cluster antes de ativar verificações de saúde detalhadas. + On-demand verificações de integridade profundas não são suportadas em clusters com `NodeProvisioningMode` definido como`Continuous`. + Verificações de saúde detalhadas são executadas somente em nós de trabalho. Os nós de controle e login não estão sujeitos a verificações de integridade detalhadas. + Somente uma solicitação de verificação profunda de integridade sob demanda pode estar ativa por cluster por vez. + Se uma verificação sob demanda acionar a reinicialização ou substituição de um nó, o nó substituto só executará verificações profundas de integridade se `OnStartDeepHealthChecks` estiver habilitado no grupo de instâncias. Caso contrário, o nó se juntará novamente sem executar verificações profundas de integridade.