Los clústeres de entrenamiento de Gemini Enterprise Agent Platform integran un sistema integral de verificación de estado para garantizar la confiabilidad de los nodos de procesamiento y la estabilidad de tus trabajos de Slurm. Este sistema incluye opciones de recuperación automáticas y manuales. Se ejecuta un proceso automatizado durante la ejecución del trabajo para supervisar componentes fundamentales, como el estado de la GPU y el uso del disco, y reemplazar automáticamente los nodos que fallan. Para las situaciones que requieren la intervención del usuario, tu clúster de entrenamiento proporciona una API de reportFaultyNodes, que te permite borrar manualmente un nodo defectuoso específico o informar una falla de hardware sospechada en su host subyacente.
Ejecuta una carga de trabajo de prueba para verificar la funcionalidad de la GPU
Paso 1: Conéctate a los nodos del clúster con SSH
Desde Cloud Shell o la Google Cloud console, conéctate al nodo de acceso con IAP. En el siguiente ejemplo, se muestra el comando para Cloud Shell:
gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID
Paso 2: Ejecuta un comando estándar de Slurm
Después de conectarte a un nodo de acceso, ejecuta algunos comandos estándar de Slurm para verificar que el clúster funcione correctamente.
~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
partition1* up infinite 2 idle hcsa3m1236-a3mnodeset-[0-1]
A continuación, envía un trabajo por lotes.
~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"
Deberías ver que se crea 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
Establece los permisos de la secuencia de comandos en 755 para que se pueda ejecutar y, luego, envía el trabajo de Slurm:
~$ sbatch ./test.sh
Slurm guarda el resultado 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)
Verificaciones de estado y recuperación automatizadas
Para garantizar la confiabilidad de los nodos, los clústeres de entrenamiento supervisan continuamente el estado de los nodos con el siguiente conjunto de verificaciones automatizadas. Los clústeres de entrenamiento ejecutan verificaciones de estado durante el prólogo de Slurm (antes de que comience un trabajo) y el epílogo (después de que se completa un trabajo).
Conjunto de verificaciones de estado
- Estado de la GPU: Realiza diagnósticos detallados e individuales de la GPU, incluida la supervisión del código
nvidia-smi,dcgmiyxid. - Uso del disco: Verifica el uso elevado del disco en particiones fundamentales
(
/,/mnt/localssd,/mnt/localdisk) para evitar que los trabajos fallen debido a falta de espacio. - Estado de la red: Verifica que las interfaces de red principales tengan una dirección IPv4. Si se encuentra un problema, intenta repararse automáticamente restableciendo la interfaz.
- Carga de CPU: Supervisa el promedio de carga del sistema y registra una advertencia si supera un umbral predefinido.
Proceso de recuperación de fallas
Si una verificación detecta un error grave e irrecuperable, los clústeres de entrenamiento de Gemini Enterprise Agent Platform inician automáticamente un proceso de recuperación de fallas. El proceso estándar implica desviar los nodos defectuosos, volver a poner en cola el trabajo de Slurm afectado y, luego, borrar y volver a crear los nodos desviados para restablecerlos a un estado correcto.
Esta recuperación automatizada está sujeta a las siguientes condiciones:
Límite de reinicio: Se omite el proceso de recuperación si el trabajo de Slurm afectado ya se reinició una cantidad determinada de veces.
Uso de la GPU: También se omite el borrado y la recreación de nodos si el trabajo que se ejecuta en el nodo no usa todas las GPU disponibles. En este caso, solo se desvía el nodo para evitar que se programen trabajos nuevos en él.
Cada acción de recuperación se registra en los registros de tu proyecto como un evento de resiliencia. Para graficar estos eventos en relación con el estado de Slurm de tus nodos, consulta Supervisa eventos de resiliencia con un panel.
Administra manualmente los nodos de procesamiento defectuosos
Los clústeres de entrenamiento proporcionan APIs para informar y administrar manualmente los nodos de procesamiento defectuosos, lo que es particularmente útil si las verificaciones de estado automatizadas no resuelven un problema. Solo puedes ejecutar estas operaciones en un nodo a la vez.
| Acción | Descripción | Clientes ideales |
|---|---|---|
| Borrar nodo | Quita un nodo defectuoso especificado del clúster. Esta es la acción predeterminada. | Errores generales o cuando un nodo no responde y debe reciclarse. |
| Informar que el host está defectuoso | Informa que el host físico subyacente está defectuoso, lo que activa un proceso de reparación o migración. | Sospecha de fallas de hardware en la máquina física que aloja el nodo de GPU. |
Acción 1: Borra un nodo defectuoso
Esta acción borra 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 borrado es menor que el recuento mínimo de nodos del grupo de nodos, se vuelve a crear un nodo de procesamiento nuevo con el mismo nombre y las mismas especificaciones.
Nodos dinámicos: Si el índice de un nodo borrado es mayor que el recuento mínimo de nodos, solo se vuelve a crear si hay una carga de trabajo pendiente programada para él. De lo contrario, se quita.
En estos ejemplos, se usa un alias gcurl, que es un acceso directo autenticado y conveniente para interactuar con los extremos 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 borrar un nodo
Para borrar 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"}]}'
Verifica el estado de la operación
Puedes supervisar el resultado de la acciónreportFaultyNodes verificando el estado de la operación.
gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID
Acción 2: Informa que un host está defectuoso
Puedes informar que el host físico de un nodo de GPU está defectuoso si sospechas que hay una falla de hardware.
VMs compatibles: A3 Ultra y A4 High-GPU
Estado del nodo: El nodo de destino debe estar en estado
RUNNINGantes de llamar a la API. Pasará aREPAIRINGcuando la llamada se realice correctamente y volverá aRUNNINGdespués de que se repare el host o se vuelva a crear el nodo en un host nuevo. Esta es una operación de mejor esfuerzo.
Requisito previo: Otorga el rol de IAM
Para usar esta función, debes otorgar el rol de administrador de instancias de Compute (v1) (roles/compute.instanceAdmin.v1) al agente de servicio de Agent Platform.
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.iam.gserviceaccount.com" \ --role="roles/compute.instanceAdmin.v1"
Solicitud a la API para informar un host
Ejecuta la siguiente solicitud POST para informar que el host subyacente está defectuoso. Cuando lo hagas,
debes proporcionar uno o más comportamientos y descripciones observados para el faultReasons.
Para el campo behavior, debes 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 de XID en los registros y Compute Engine no detecta otros patrones de falla habituales, como la corrupción silenciosa de datos. |
SILENT_DATA_CORRUPTION |
Ves corrupción de datos en tu VM, 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 |
Identificaste un error de GPU irrecuperable con un XID. |
BEHAVIOR_UNSPECIFIED |
No estás seguro de cuál es el problema con tu VM. |
Aquí encontrarás un ejemplo de la solicitud a 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"}]}}]}'
Revisión general
Si aprovechas las verificaciones de estado automatizadas y los controles manuales que se detallan en esta página, puedes mantener un entorno de entrenamiento altamente resistente. La administración proactiva del estado de tu clúster mediante el borrado de nodos defectuosos o la notificación de problemas de hardware garantiza el máximo tiempo de actividad y la finalización correcta de tus trabajos de entrenamiento. Si tienes problemas persistentes o complejos, siempre considera consultar al Google Cloud equipo de asistencia para obtener diagnósticos y asistencia detallados.
¿Qué sigue?
Configurar tu clúster de entrenamiento para la tolerancia a fallas es un paso clave para compilar un flujo de trabajo de MLOps completo y listo para la producción.
- Supervisa y depura tus trabajos de entrenamiento: Haz un seguimiento del progreso, el uso de recursos y el estado de tus trabajos de entrenamiento, incluido cómo identificar cuándo se recuperó un nodo o se reinició un trabajo debido a una falla.
- Organiza tus trabajos resistentes con canalizaciones de Gemini Enterprise Agent Platform: Para los entornos de producción, usa canalizaciones de Gemini Enterprise Agent Platform para crear un flujo de trabajo automatizado y repetible que envíe tus trabajos de entrenamiento resistentes a tu clúster.
- Administra e implementa tu modelo: Una vez que se complete tu trabajo de entrenamiento resistente, usa Gemini Enterprise Agent Platform Model Registry para crear versiones de tu artefacto de modelo antes de implementar el modelo en un extremo para entregar solicitudes de inferencia en línea.