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 profundas 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 integridade profundas podem ser executadas automaticamente quando as instâncias são criadas ou adicionadas a um cluster (no início), ou você pode acioná-las manualmente a qualquer momento (sob demanda) usando a StartClusterHealthCheck API. Essa abordagem proativa ajuda a identificar e mitigar possíveis problemas em todo o ciclo de vida do cluster.

Durante verificações profundas de integridade, 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 forem aprovadas, os nós serão liberados da reserva e ficarão disponíveis para cargas de trabalho.

Tipos de verificação profunda de saúde

SageMaker HyperPod oferece suporte a duas categorias de verificações profundas de integridade para clusters Slurm:

Lista de verificações profundas de saúde feitas por SageMaker HyperPod

SageMaker HyperPod executa as seguintes verificações de integridade profundas.

Instance-level verificações de saúde profundas (InstanceStress)

Cluster-level verificações de saúde profundas (InstanceConnectivity)

On-start verificações de saúde profundas

On-start verificações de integridade profundas 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 Isso garante que cada nó passe pela validação de hardware antes de aceitar cargas de trabalho.

Permitindo verificações de integridade profundas no início

Para ativar verificações de integridade profundas no início, 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 integridade profundas 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 verificações de saúde profundas no início

Quando as verificações profundas de integridade no início são ativadas, ocorre o seguinte processo:

O cluster faz a transição para pelo menos InService uma vez em que o nó do controlador está em execução. Os nós de trabalho mostram DeepHealthCheckInProgress o status durante o teste e fazem a transição para Running após a aprovação.

Monitoramento de verificações de integridade profundas 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 comoDeepHealthCheckInProgress.

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 integridade profundas no início ativadas

Quando você expande um cluster OnStartDeepHealthChecks configurado, os novos nós passam automaticamente por verificações profundas de integridade antes de aceitar cargas de trabalho. Os nós existentes e as tarefas 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 enquanto as verificações profundas de integridade são executadas. Os trabalhos que exigem a capacidade adicional dos novos nós aguardam até que esses nós passem por verificações de integridade profundas e se tornem disponíveis. Os trabalhos que podem ser satisfeitos com os nós existentes disponíveis não são afetados.

On-demand verificações de saúde profundas

On-demand verificações de integridade profundas permitem que você acione a validação de hardware em nós de cluster existentes a qualquer momento usando a StartClusterHealthCheck API. Isso é útil para validação periódica da integridade ou após suspeitas de problemas de hardware.

Executando verificações de integridade profundas sob demanda a partir do console

Você pode executar verificações profundas de integridade em instâncias de HyperPod cluster diretamente do console de SageMaker IA.

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 a 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 defeituosas.

Acionando verificações de integridade 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:

Logs das verificações de integridade profundas

A seguir estão exemplos de registros das verificações SageMaker HyperPod profundas de integridade.

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/<cluster_name>/<cluster_id>

Os fluxos de log estão registrados em DeepHealthCheckResults/<log_stream_id>.

Instance-level logs

Em cada nó, os registros profundos de verificação 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:<cluster_id>_<instance_group>-<instance_id>"

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 profundas

Sem as verificações de integridade profundas ativadas, 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 imediatamente.

Com as verificações de integridade profundas ativadas, o nó substituto deve passar por todas as verificações de integridade profundas configuradas antes de ficar disponível. No entanto, o trabalho retomado automaticamente não precisa esperar pelo nó substituto — ele pode ser agendado em qualquer outro nó disponível no cluster. O trabalho só aguardará se nenhum outro nó estiver disponível.

Considerações adicionais