Resiliencia de los clústeres

Si te interesan los clústeres de entrenamiento de Vertex AI, ponte en contacto con tu representante de ventas para obtener acceso.

Los clústeres de entrenamiento de Vertex AI integran un sistema de comprobación del estado completo para asegurar la fiabilidad de los nodos de computación y la estabilidad de tus tareas de Slurm. Este sistema ofrece opciones de recuperación automáticas y manuales. Durante la ejecución de los trabajos, se lleva a cabo un proceso automatizado para monitorizar componentes críticos, como el estado de la GPU y el uso del disco, y sustituir automáticamente los nodos que fallen. En las situaciones que requieren la intervención del usuario, tu clúster de entrenamiento proporciona una API reportFaultyNodes que te permite eliminar manualmente un nodo defectuoso específico o informar de un posible fallo de hardware en su host subyacente.

Ejecutar una carga de trabajo de prueba para verificar la funcionalidad de la GPU

Paso 1: Conéctate a los nodos del clúster mediante SSH

Desde Cloud Shell o la consola, conéctate al nodo de inicio de sesión mediante IAP. Google Cloud En el siguiente ejemplo se muestra el comando de Cloud Shell:

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

Paso 2: Ejecuta un comando Slurm estándar

Después de conectarte a un nodo de inicio de sesión, ejecuta algunos comandos estándar de Slurm para verificar que el clúster funciona correctamente.

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

A continuación, envía una tarea por lotes.

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

Deberías ver que se ha creado un archivo slurm-job-id.out en tu directorio principal.

Paso 3: Ejecuta una carga de trabajo de GPU

Guarda el siguiente contenido como un archivo de secuencia de comandos llamado test.sh en tu directorio 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

Define los permisos de la secuencia de comandos en 755 para que se pueda ejecutar y, a continuación, envía el trabajo de Slurm:

~$ sbatch ./test.sh

Slurm guarda la salida de la secuencia de comandos en un archivo llamado 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)

Verificación del estado del clúster

En esta sección se explica cómo probar el clúster de entrenamiento con la herramienta Cluster Health Scanner (CHS), que está preinstalada en la imagen del clúster de entrenamiento. La herramienta CHS comprueba el estado del clúster y ejecuta pruebas, como diagnósticos de DCGM y pruebas de NCCL, para verificar que el clúster está listo para ejecutar tus cargas de trabajo.

Importante: Los nodos de computación deben tener acceso a Internet saliente para que las pruebas de diagnóstico de DCGM y de validación de clúster se completen correctamente. Asegúrate de que las direcciones IP públicas estén habilitadas en los nodos de proceso ("enable_public_ips": "true") o de que se haya desplegado una pasarela Cloud NAT en la red del clúster.

Desde el nodo de inicio de sesión del clúster, puedes ejecutar la siguiente secuencia de comandos para realizar pruebas con la herramienta CHS.

Nota: Esta secuencia de comandos se ha escrito para un clúster con dos nodos A3 Ultra, pero se puede modificar para adaptarla a la configuración de tu clúster.

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

Una prueba realizada correctamente proporciona dos conjuntos de resultados:

• Resumen de la salida: se imprime un breve resumen en la consola, que debería ser similar al siguiente ejemplo.
• Registros detallados: para ver un informe completo, consulta los registros detallados guardados en el directorio ~/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!

Comprobaciones del estado y recuperación automatizadas

Para asegurar la fiabilidad de los nodos, los clústeres de entrenamiento monitorizan continuamente el estado de los nodos mediante el siguiente conjunto de comprobaciones automatizadas. Los clústeres de entrenamiento ejecutan comprobaciones de estado durante el prólogo de Slurm (antes de que empiece una tarea) y el epílogo (después de que se complete una tarea).

Conjunto de comprobaciones del estado

• Estado de la GPU: realiza diagnósticos detallados de cada GPU, incluida la monitorización del código nvidia-smi, dcgmi y xid.
• Uso del disco: comprueba si hay un uso elevado del disco en particiones críticas (/, /mnt/localssd y /mnt/localdisk) para evitar que los trabajos fallen por falta de espacio.
• Estado de la red: comprueba que las interfaces de red principales tengan una dirección IPv4. Si se detecta un problema, se intenta solucionar automáticamente restableciendo la interfaz.
• Carga de CPU: monitoriza la carga media del sistema y registra una advertencia si supera un umbral predefinido.

Proceso de recuperación tras fallos

Si una comprobación detecta un error grave e irrecuperable, los clústeres de entrenamiento de Vertex AI inician automáticamente un proceso de recuperación de errores. El proceso estándar consiste en vaciar los nodos defectuosos, volver a poner en cola el trabajo de Slurm afectado y, a continuación, eliminar y volver a crear los nodos vaciados para restaurarlos a un estado correcto.

Esta recuperación automática está sujeta a las siguientes condiciones:

• Límite de reinicios: el proceso de recuperación se omite si el trabajo de Slurm afectado ya se ha reiniciado un número determinado de veces.

• Uso de GPU: la eliminación y la recreación de nodos también se omiten si el trabajo que se está ejecutando en el nodo no usa todas las GPUs disponibles. En este caso, el nodo solo se vacía para evitar que se programen nuevos trabajos en él.

Gestionar manualmente nodos de computación defectuosos

Los clústeres de entrenamiento proporcionan APIs para informar manualmente y gestionar nodos de cálculo defectuosos, lo que resulta especialmente útil si las comprobaciones de estado automatizadas no resuelven un problema. Solo puedes ejecutar estas operaciones en un nodo a la vez.

Acción	Descripción	Recomendado para
Eliminar nodo	Elimina un nodo defectuoso específico del clúster. Esta es la acción predeterminada.	Errores generales o cuando un nodo no responde y debe reciclarse.
Informar de que el anfitrión no funciona	Informa de que el host físico subyacente está defectuoso, lo que activa un proceso de reparación o migración.	Sospecha de fallos de hardware en la máquina física que aloja el nodo de GPU.

Acción 1: Eliminar un nodo defectuoso

Esta acción elimina el nodo especificado. El resultado de esta operación depende de si Slurm clasifica el nodo como "estático" o "dinámico":

• Nodos estáticos: si el índice de un nodo eliminado es inferior al número mínimo de nodos del grupo de nodos, se vuelve a crear un nodo de computación con el mismo nombre y las mismas especificaciones.

• Nodos dinámicos: si el índice de un nodo eliminado es mayor que el número mínimo de nodos, solo se vuelve a crear si hay una carga de trabajo pendiente programada para él. De lo contrario, se elimina.

En estos ejemplos se usa un alias de gcurl, que es un acceso directo autenticado y práctico para interactuar con los endpoints de la API. El siguiente comando crea un alias para curl que incluye los encabezados de autorización necesarios.

alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'

Solicitud a la API para eliminar un nodo

Para eliminar un nodo defectuoso, ejecuta la siguiente solicitud POST. El NODE_ID debe tener el 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"}]}'
  

Comprobar el estado de la operación

Para monitorizar el resultado de la acción reportFaultyNodes, comprueba el estado de la operación.

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

Acción 2: Informar de que un anfitrión está defectuoso

Precaución: Esta es una función previa a la disponibilidad general. Antes de denunciar a un anfitrión, investiga a fondo el problema para identificar la causa principal. Solo debes usar esta acción si no tienes otras alternativas. Consulta el informe de documentación de host defectuoso y el Google Cloud equipo de Asistencia

antes de continuar.

Puedes informar de que el host físico de un nodo de GPU está defectuoso si sospechas que hay un fallo de hardware.

• Máquinas virtuales compatibles: A3 Ultra y A4 High-GPU

• Estado del nodo: el nodo de destino debe estar en estado RUNNING para poder llamar a la API. Pasará a REPAIRING cuando la llamada se realice correctamente y volverá a RUNNING cuando se repare el host o se vuelva a crear el nodo en un nuevo host. Esta operación se realiza en función de la máxima capacidad.

Requisito previo: asignar un rol de gestión de identidades y accesos

Para usar esta función, debes conceder el rol Administrador de instancias de Compute (v1) (roles/compute.instanceAdmin.v1) al agente de servicio de 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"
  

Solicitud a la API para denunciar un host

Ejecuta la siguiente solicitud POST para informar de que el host subyacente tiene un fallo. Al hacerlo, debes proporcionar uno o varios comportamientos y descripciones observados para el faultReasons.
En el campo behavior, debe usar uno de los siguientes valores:

Comportamiento	Descripción
PERFORMANCE	Las GPUs conectadas a la VM tienen problemas de rendimiento en comparación con otras GPUs del clúster, no ves errores XID en los registros y Compute Engine no detecta otros patrones de fallos habituales, como la corrupción de datos silenciosa.
SILENT_DATA_CORRUPTION	Los datos de tu VM están dañados, pero la VM sigue ejecutándose. Esto puede deberse a problemas como defectos de vCPU, errores de software o problemas del kernel.
UNRECOVERABLE_GPU_ERROR	Has identificado un error irrecuperable de la GPU con un XID.
BEHAVIOR_UNSPECIFIED	No sabes cuál es el problema de tu VM.

Aquí tienes un ejemplo de la solicitud de la 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"}]}}]}'
  

Visión de conjunto

Si aprovechas tanto las comprobaciones de estado automatizadas como los controles manuales que se detallan en esta página, podrás mantener un entorno de entrenamiento muy resistente. Si gestionas de forma proactiva el estado de tu clúster eliminando los nodos defectuosos o notificando los problemas de hardware, te asegurarás de que el tiempo de actividad sea máximo y de que los trabajos de entrenamiento se completen correctamente. Si tienes problemas persistentes o complejos, siempre debes consultar al Google Cloud equipo de Asistencia para obtener diagnósticos y ayuda detallados.

Siguientes pasos

Configurar tu clúster de entrenamiento para que sea tolerante a fallos es un paso clave para crear un flujo de trabajo de MLOps completo y listo para producción.

• Monitorizar y depurar los trabajos de entrenamiento: haz un seguimiento del progreso, la utilización de recursos y el estado de tus trabajos de entrenamiento, incluido cómo identificar cuándo se ha recuperado un nodo o se ha reiniciado un trabajo debido a un fallo.
  • Monitorizar tareas de entrenamiento en Vertex AI
• Orquesta tus trabajos resistentes con Vertex AI Pipelines: en entornos de producción, usa Vertex AI Pipelines para crear un flujo de trabajo automatizado y repetible que envíe tus trabajos de entrenamiento resistentes a tu clúster.
  • Información sobre la orquestación de trabajos en un clúster de entrenamiento
• Gestiona y despliega tu modelo: una vez que se haya completado tu tarea de entrenamiento resistente, usa Vertex AI Model Registry para crear una versión de tu artefacto de modelo antes de desplegar el modelo en un endpoint para atender solicitudes de inferencia online.
  • Introducción al registro de modelos de Vertex AI
  • Desplegar un modelo en un endpoint