Os clusters de treinamento da Gemini Enterprise Agent Platform integram um sistema abrangente de verificação de integridade para garantir a confiabilidade dos nós de computação e a estabilidade dos jobs do Slurm. Esse sistema oferece opções de recuperação automática e manual. Um processo automatizado é executado durante a execução do job para monitorar componentes críticos, como a integridade da GPU e o uso do disco, substituindo automaticamente os nós com falha. Para situações que exigem intervenção do usuário, o cluster de treinamento fornece uma API reportFaultyNodes, que permite excluir manualmente um nó com falha específico ou informar uma suspeita de falha de hardware no host subjacente.
Executar uma carga de trabalho de teste para verificar a funcionalidade da GPU
Etapa 1: conectar-se aos nós do cluster usando SSH
No Cloud Shell ou no Cloud de Confiance console, conecte-se ao nó de login usando o IAP. O exemplo a seguir mostra o comando para o Cloud Shell:
gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID
Etapa 2: executar um comando padrão do Slurm
Depois de se conectar a um nó de login, execute alguns comandos padrão do Slurm para verificar se o cluster está funcionando corretamente.
~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
partition1* up infinite 2 idle hcsa3m1236-a3mnodeset-[0-1]
Em seguida, envie um job em lote.
~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"
Você verá que um arquivo slurm-job-id.out é criado no seu diretório principal.
Etapa 3: executar uma carga de trabalho da GPU
Salve o conteúdo a seguir como um arquivo de script chamado test.sh no seu diretório principal.
#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi
srun nvidia-smi -L
Defina as permissões do script como 755 para torná-lo executável e envie o job do Slurm:
~$ sbatch ./test.sh
O Slurm salva a saída do script em um arquivo chamado slurm-job-id.out.
Saída esperada:
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)
Verificações de integridade e recuperação automatizadas
Para garantir a confiabilidade do nó, os clusters de treinamento monitoram continuamente a integridade do nó usando o conjunto de verificações automatizadas a seguir. Os clusters de treinamento executam verificações de integridade durante o prólogo do Slurm (antes do início de um job) e o epílogo (após a conclusão de um job).
Conjunto de verificação de integridade
- Integridade da GPU: realiza diagnósticos detalhados e individuais da GPU, incluindo monitoramento de código
nvidia-smi,dcgmiexid. - Uso do disco: verifica o uso alto do disco em partições críticas
(
/,/mnt/localssd,/mnt/localdisk) para evitar que os jobs falhem devido à falta de espaço. - Integridade da rede: verifica se as interfaces de rede principais têm um endereço IPv4. Se um problema for encontrado, ele tentará se recuperar redefinindo a interface.
- Carga da CPU: monitora a média de carga do sistema e registra um aviso se ela exceder um limite predefinido.
Processo de recuperação de falhas
Se uma verificação detectar um erro grave e irrecuperável, os clusters de treinamento da Gemini Enterprise Agent Platform iniciam automaticamente um processo de recuperação de falhas. O processo padrão envolve a drenagem dos nós com falha, o reenvio do job do Slurm afetado e a exclusão e recriação dos nós drenados para restaurá-los a um estado íntegro.
Essa recuperação automatizada está sujeita às seguintes condições:
Limite de reinicialização: o processo de recuperação é ignorado se o job do Slurm afetado já tiver sido reiniciado um número definido de vezes.
Utilização da GPU: a exclusão e a recriação do nó também são ignoradas se o job em execução no nó não usar todas as GPUs disponíveis. Nesse caso, o nó é drenado apenas para evitar que novos jobs sejam programados nele.
Cada ação de recuperação é registrada nos registros do projeto como um evento de resiliência. Para representar esses eventos em relação ao estado do Slurm dos nós, consulte Monitorar eventos de resiliência com um painel.
Gerenciar manualmente nós de computação com falha
Os clusters de treinamento fornecem APIs para informar e gerenciar manualmente nós de computação com falha, o que é particularmente útil se as verificações de integridade automatizadas não resolverem um problema. Só é possível executar essas operações em um nó por vez.
| Ação | Descrição | Ideal para |
|---|---|---|
| Excluir nó | Remove um nó com falha especificado do cluster. Essa é a ação padrão. | Erros gerais ou quando um nó não responde e precisa ser reciclado. |
| Informar host com falha | Informa o host físico subjacente como com falha, acionando um processo de reparo ou migração. | Suspeita de falhas de hardware na máquina física que hospeda o nó da GPU. |
Ação 1: excluir um nó com falha
Essa ação exclui o nó especificado. O resultado dessa operação depende de o nó ser classificado como "estático" ou "dinâmico" pelo Slurm:
Nós estáticos: se o índice de um nó excluído for menor que a contagem mínima de nós do pool de nós, um novo nó de computação será recriado com o mesmo nome e especificações.
Nós dinâmicos: se o índice de um nó excluído for maior que a contagem mínima de nós, ele só será recriado se houver uma carga de trabalho pendente programada para ele. Caso contrário, ela será removida.
Esses exemplos usam um alias gcurl, que é um atalho conveniente e autenticado para interagir com os endpoints da API. O comando a seguir cria um alias para curl que inclui os cabeçalhos de autorização necessários.
alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'
Solicitação de API para excluir um nó
Para excluir um nó com falha, execute a seguinte solicitação POST. O NODE_ID
precisa estar no formato CLUSTER_ID-NODEPOOL_ID-INDEX.
gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'
Verificar o status da operação
É possível monitorar o resultado da açãoreportFaultyNodes verificando o status da operação.
gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID
Ação 2: informar um host com falha
É possível informar o host físico de um nó da GPU como com falha se você suspeitar de uma falha de hardware.
VMs compatíveis: A3 Ultra e A4 High-GPU
Estado do nó: o nó de destino precisa estar no estado
RUNNINGantes de você chamar a API. Ele fará a transição paraREPAIRINGapós uma chamada bem-sucedida e retornará paraRUNNINGdepois que o host for reparado ou o nó for recriado em um novo host. Essa é uma operação de melhor esforço.
Pré-requisito: conceder o papel do IAM
Para usar esse recurso, conceda o papel Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1) ao agente de serviço da plataforma de agentes.
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") gcloud projects add-iam-policy-binding PROJECT_ID\ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.s3ns-system.iam.gserviceaccount.com" \ --role="roles/compute.instanceAdmin.v1"
Solicitação de API para informar um host
Execute a seguinte solicitação POST para informar o host subjacente como com falha. Ao fazer isso,
você deve fornecer um ou mais comportamentos e descrições observados para o faultReasons.
Para o campo behavior, use um dos seguintes valores:
| Comportamento | Descrição |
|---|---|
PERFORMANCE |
As GPUs anexadas à VM têm problemas de desempenho em comparação com outras GPUs no cluster, não há erros XID nos registros e o Compute Engine não detecta outros padrões de falha comuns, como corrupção de dados silenciosa. |
SILENT_DATA_CORRUPTION |
Você vê corrupção de dados na VM, mas ela continua em execução. Isso pode ocorrer devido a problemas como defeitos de vCPU, bugs de software ou problemas de kernel. |
UNRECOVERABLE_GPU_ERROR |
Você identificou um erro irrecuperável da GPU com um XID. |
BEHAVIOR_UNSPECIFIED |
Você não tem certeza do problema com a VM. |
Confira um exemplo da solicitação de API.
gcurl -X POST \
https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
-d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'
Como tudo funciona em conjunto
Ao aproveitar as verificações de integridade automatizadas e os controles manuais detalhados nesta página, você pode manter um ambiente de treinamento altamente resiliente. O gerenciamento proativo da integridade do cluster excluindo nós com falha ou informando problemas de hardware garante o tempo de atividade máximo e a conclusão bem-sucedida dos jobs de treinamento. Para problemas persistentes ou complexos, sempre considere consultar a Cloud de Confiance by S3NS equipe de suporte para diagnósticos e assistência detalhados.
A seguir
A configuração do cluster de treinamento para tolerância a falhas é uma etapa fundamental na criação de um fluxo de trabalho completo de MLOps pronto para produção.
- Monitorar e depurar jobs de treinamento: acompanhe o progresso, a utilização de recursos e a integridade dos jobs de treinamento, incluindo como identificar quando um nó foi recuperado ou um job foi reiniciado devido a uma falha.
- Orquestrar jobs resilientes com os pipelines da Gemini Enterprise Agent Platform: para ambientes de produção, use os pipelines da Gemini Enterprise Agent Platform para criar um fluxo de trabalho automatizado e repetível que envia seus jobs de treinamento resilientes ao cluster.
- Gerenciar e implantar o modelo: depois que o job de treinamento resiliente for concluído, use o Model Registry da Gemini Enterprise Agent Platform para controlar a versão do artefato do modelo antes de implantá-lo em um endpoint para disponibilizar solicitações de inferência on-line.