Resiliência do cluster

Se tiver interesse em clusters de preparação do Vertex AI, contacte o seu representante de vendas para aceder.

Os clusters de preparação do Vertex AI integram um sistema de verificação de estado abrangente para garantir a fiabilidade dos nós de computação e a estabilidade dos seus trabalhos do Slurm. Este sistema inclui opções de recuperação automáticas e manuais. É executado um processo automático durante a execução do trabalho para monitorizar componentes críticos, como o estado da GPU e a utilização do disco, substituindo automaticamente os nós com falhas. Para situações que requerem intervenção do utilizador, o cluster de preparação fornece uma reportFaultyNodesAPI, que lhe permite eliminar manualmente um nó com falhas específico ou comunicar uma suspeita de falha de hardware no respetivo anfitrião subjacente.

Execute uma carga de trabalho de teste para verificar a funcionalidade da GPU

Passo 1: ligue-se aos nós do cluster através de SSH

A partir do Cloud Shell ou da Google Cloud consola, ligue-se ao nó de início de sessão através do IAP. O exemplo seguinte mostra o comando para o Cloud Shell:

gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID

Passo 2: execute um comando Slurm padrão

Depois de se ligar a um nó de início de sessão, execute alguns comandos Slurm padrão para verificar se o cluster está a funcionar corretamente.

~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
partition1*    up   infinite      2   idle hcsa3m1236-a3mnodeset-[0-1]

Em seguida, envie uma tarefa em lote.

~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"

Deverá ver que é criado um ficheiro slurm-job-id.out no seu diretório inicial.

Passo 3: execute uma carga de trabalho da GPU

Guarde o seguinte conteúdo como um ficheiro de script denominado 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 autorizações do script como 755 para o tornar executável e, em seguida, envie a tarefa do Slurm:

~$ sbatch ./test.sh

O Slurm guarda a saída do script num ficheiro denominado slurm-job-id.out.

Resultado esperado:

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)

Validação do estado do cluster

Esta secção mostra como testar o cluster de preparação usando a ferramenta Cluster Health Scanner (CHS), que está pré-instalada na imagem do cluster de preparação. A ferramenta CHS verifica o estado do cluster, executando testes como diagnósticos DCGM e testes NCCL para verificar se o cluster está pronto para executar as suas cargas de trabalho.

Importante: os nós de computação têm de ter acesso à Internet de saída para que os testes de diagnóstico e validação de clusters do DCGM sejam bem-sucedidos. Certifique-se de que os endereços IP públicos estão ativados para os nós de computação ("enable_public_ips": "true") ou que um gateway Cloud NAT está implementado na rede do cluster.

No nó de início de sessão do cluster, pode executar o seguinte script para executar testes com a ferramenta CHS.

Nota: este script foi escrito para um cluster com dois nós A3 Ultra, mas pode ser modificado para se adequar à configuração do seu cluster.

export CLUSTER_ID=<your_cluster_id>
export PARTITION=a3u
export MACHINE_TYPE=a3-ultragpu-8g
cd ~
/opt/cluster-health-scanner/deploy/slurm/cluster-validation.sh \
--nodelist=${CLUSTER_ID}-${PARTITION}-[0-1] \
--nodes=2 \
--partition=${PARTITION} \
--machine-type=${MACHINE_TYPE} \
--relative-exec-path=../../opt/cluster-health-scanner/deploy/slurm \
--results-dir=results

Uma execução de teste bem-sucedida fornece dois conjuntos de resultados:

• Saída de resumo: é impresso um breve resumo na consola, que deve ser semelhante ao exemplo seguinte.
• Registos detalhados: para um relatório completo, consulte os registos detalhados guardados no diretório ~/results.

Starting DCGM Diagnostics...
DCGM diagnostics passing on all nodes!
Starting NCCL all_reduce_perf...
CURR_NODES:  cluster-id-0
cluster-id-1
NCCL test passing on all nodes!

Verificações de saúde e recuperação automáticas

Para garantir a fiabilidade dos nós, os clusters de preparação monitorizam continuamente o estado dos nós através do seguinte conjunto de verificações automáticas. Os clusters de preparação executam verificações de estado durante o prólogo do Slurm (antes de uma tarefa começar) e o epílogo (após a conclusão de uma tarefa).

Conjunto de verificações de funcionamento

• Estado da GPU: executa diagnósticos detalhados e individuais da GPU, incluindo a monitorização dos códigos nvidia-smi, dcgmi e xid.
• Utilização do disco: verifica a utilização elevada do disco em partições críticas (/, /mnt/localssd, /mnt/localdisk) para evitar a falha de tarefas devido à falta de espaço.
• Estado da rede: verifica se as interfaces de rede principais têm um endereço IPv4. Se for encontrado um problema, o sistema tenta corrigir-se automaticamente repondo a interface.
• Carga da CPU: monitoriza a média de carga do sistema e regista um aviso se exceder um limite predefinido.

Processo de recuperação de falhas

Se uma verificação detetar um erro grave e irrecuperável, os clusters de preparação do Vertex AI iniciam automaticamente um processo de recuperação de falhas. O processo padrão envolve esvaziar os nós com falhas, voltar a colocar na fila o trabalho do Slurm afetado e, em seguida, eliminar e recriar os nós esvaziados para os restaurar a um estado normal.

Esta recuperação automática está sujeita às seguintes condições:

• Limite de reinícios: o processo de recuperação é ignorado se a tarefa do Slurm afetada já tiver sido reiniciada um determinado número de vezes.

• Utilização da GPU: a eliminação e a recriação do nó também são ignoradas se a tarefa em execução no nó não usar todas as GPUs disponíveis. Neste caso, o nó é apenas esgotado para impedir que sejam agendados novos trabalhos no mesmo.

Gerir manualmente nós de computação com falhas

Os clusters de preparação fornecem APIs para comunicar e gerir manualmente nós de computação com falhas, o que é particularmente útil se as verificações de estado automatizadas não resolverem um problema. Só pode executar estas operações num nó de cada vez.

Ação	Descrição	Ideal para
Eliminar nó	Remove um nó com falhas especificado do cluster. Esta é a ação predefinida.	Erros gerais ou quando um nó não responde e precisa de ser reciclado.
Comunique que o anfitrião está com problemas	Comunica o anfitrião físico subjacente como defeituoso, acionando um processo de reparação ou migração.	Falhas de hardware suspeitas na máquina física que aloja o nó da GPU.

Ação 1: elimine um nó com falhas

Esta ação elimina o nó especificado. O resultado desta 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ó eliminado for inferior à contagem mínima de nós do conjunto de nós, é recriado um novo nó de computação com o mesmo nome e especificações.

• Nós dinâmicos: se o índice de um nó eliminado for superior à quantidade mínima de nós, só é recriado se houver uma carga de trabalho pendente agendada para o mesmo. Caso contrário, é removido.

Estes exemplos usam um alias gcurl, que é um atalho autenticado conveniente para interagir com os pontos finais da API. O comando seguinte 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"'

Pedido de API para eliminar um nó

Para eliminar um nó com falhas, execute o seguinte pedido POST. O elemento NODE_ID deve 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"}]}'
  

Verifique o estado da operação

Pode monitorizar o resultado da ação reportFaultyNodes verificando o estado da operação.

  gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID
  

Ação 2: denuncie um anfitrião como defeituoso

Aviso: esta é uma funcionalidade pré-GA. Antes de denunciar um anfitrião, investigue exaustivamente o problema para identificar a causa principal. Use esta ação apenas se não tiver outras alternativas. Consulte o relatório de documentação de anfitrião com falhas e a Google Cloud equipa de apoio técnico antes de continuar.

Pode comunicar o anfitrião físico de um nó de GPU como defeituoso se suspeitar de uma falha de hardware.

• VMs suportadas: A3 Ultra e A4 High-GPU

• Estado do nó: o nó de destino tem de estar num estado RUNNING antes de chamar a API. Passa para REPAIRING após uma chamada bem-sucedida e regressa a RUNNING depois de o anfitrião ser reparado ou o nó ser recriado num novo anfitrião. Esta é uma operação de melhor esforço.

Pré-requisito: conceda a função de IAM

Para usar esta funcionalidade, tem de conceder a função Administrador de instâncias do Compute (v1) (roles/compute.instanceAdmin.v1) ao agente de serviço do Vertex AI.

  PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

  gcloud projects add-iam-policy-binding PROJECT_ID\
  --member="serviceAccount:[e-mail]" \
  --role="roles/compute.instanceAdmin.v1"
  

Pedido de API para denunciar um anfitrião

Execute o seguinte pedido POST para comunicar que o anfitrião subjacente está com defeito. Ao fazê-lo, tem de fornecer um ou mais comportamentos observados e descrições para o faultReasons.
Para o campo behavior, deve usar um dos seguintes valores:

Comportamento	Descrição
PERFORMANCE	As GPUs associadas à VM têm problemas de desempenho em comparação com outras GPUs no cluster, não vê erros XID nos registos e o Compute Engine não deteta outros padrões de falhas habituais, como a corrupção de dados silenciosa.
SILENT_DATA_CORRUPTION	Ver corrupção de dados na VM, mas a VM continua a ser executada. Isto pode dever-se a problemas como defeitos de vCPU, erros de software ou problemas de kernel.
UNRECOVERABLE_GPU_ERROR	Identificou um erro de GPU irrecuperável com um XID.
BEHAVIOR_UNSPECIFIED	Não tem a certeza do problema com a sua VM.

Segue-se um exemplo do pedido da 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"}]}}]}'
  

Juntar tudo

Ao tirar partido das verificações de saúde automáticas e dos controlos manuais detalhados nesta página, pode manter um ambiente de preparação altamente resiliente. A gestão proativa do estado do cluster através da eliminação de nós com falhas ou da comunicação de problemas de hardware garante o tempo de atividade máximo e a conclusão bem-sucedida das tarefas de preparação. Para problemas persistentes ou complexos, considere sempre consultar a Google Cloud equipa de apoio técnico para receber diagnósticos detalhados e assistência.

O que se segue?

A configuração do cluster de preparação para tolerância a falhas é um passo fundamental na criação de um fluxo de trabalho de MLOps completo e pronto para produção.

• Monitorize e depure as suas tarefas de preparação: acompanhe o progresso, a utilização de recursos e o estado das suas tarefas de preparação, incluindo como identificar quando um nó foi recuperado ou uma tarefa foi reiniciada devido a uma falha.
  • Monitorize tarefas de preparação no Vertex AI
• Orquestre as suas tarefas resilientes com o Vertex AI Pipelines: para ambientes de produção, use o Vertex AI Pipelines para criar um fluxo de trabalho automatizado e repetível que envia as suas tarefas de preparação resilientes para o cluster.
  • Saiba como orquestrar tarefas num cluster de preparação
• Faça a gestão e a implementação do seu modelo: quando a tarefa de preparação resiliente estiver concluída, use o Registo de modelos do Vertex AI para criar versões do artefacto do modelo antes de implementar o modelo num ponto final para processar pedidos de inferência online.
  • Introdução ao Registo de modelos do Vertex AI
  • Implemente um modelo num ponto final