Aplicá Chaos Engineering en clusters de GPU para infraestructura de IA robusta

Introducción

Los clusters de GPU son el backbone de la infraestructura de IA moderna, pero su complejidad supera por órdenes de magnitud a los sistemas tradicionales. Hardware heterogéneo, topologías de red como NVLink/NVSwitch, nodos NUMA y protocolos como RDMA introducen una superficie de fallos que no puede detectarse con pruebas convencionales. La ingeniería de caos es la única metodología que permite validar la resiliencia de estos sistemas antes de que un fallo en producción cueste millones en tiempo de entrenamiento de modelos.

En esta guía, implementarás experimentos de caos específicos para clusters de GPU, cubriendo desde la inyección de fallos en nodos NUMA hasta la simulación de saturación en enlaces NVLink. Usarás herramientas como DCGM (Data Center GPU Manager), Chaos Mesh en Kubernetes y scripts en Rust para automatizar la validación de tu infraestructura.

Qué es y para qué sirve

La ingeniería de caos en clusters de GPU no consiste en «romper cosas al azar», sino en diseñar experimentos controlados que revelen:

1. Fallas en la topología de red: NVLink y NVSwitch son críticos para la comunicación entre GPUs. Un fallo en estos enlaces puede degradar el rendimiento de un cluster entero.
2. Problemas de afinidad NUMA: Los GPUs suelen estar conectados a sockets específicos. Una mala asignación de procesos puede generar latencias de acceso a memoria de hasta 10x.
3. Errores de hardware ocultos: ECC corrige errores de memoria, pero fallos en streaming multiprocessors (SM) o en los sensores de temperatura pueden generar XID errors no detectados.
4. Fallas en la gestión de energía: La throttling térmica es silenciosa pero devastadora para cargas de trabajo de larga duración.

Estos fallos suelen aparecer bajo condiciones específicas de carga (ej: entrenamiento de modelos con sharding de datos). La ingeniería de caos te permite exponerlos en entornos controlados antes de que impacten en producción.

Prerequisitos

Software y versiones

• Kubernetes: 1.25+ (con soporte para dispositivos GPU vía NVIDIA Device Plugin)
• NVIDIA DCGM: 3.2+ (dcgmi y DCGM-Exporter instalados)
• Chaos Mesh: 2.6+ (para orquestar experimentos de caos)
• Rust: 1.70+ (para scripts de validación personalizados)
• Containerd/NVIDIA Container Toolkit: Versiones compatibles con tu distribución de Kubernetes
• Prometheus + Grafana: Para métricas de rendimiento (opcional pero recomendado)

Accesos y permisos

• Acceso de cluster-admin en tu cluster de Kubernetes.
• Permisos para ejecutar dcgmi en nodos con GPUs (ej: usuario nvidia o sudoers).
• Acceso a logs del kernel (/var/log/kern.log o /var/log/messages) en nodos GPU.
• Cuenta con privilegios para modificar ResourceQuotas y PodSecurityPolicies (o PodSecurityAdmission en K8s 1.25+).

Hardware mínimo recomendado (para pruebas)

• Un cluster con 2 nodos, cada uno con 1 GPU NVIDIA H100 o A100.
• Topología de red con al menos 2 enlaces NVLink entre GPUs (verificar con nvidia-smi topo -m).
• Nodos con soporte NUMA (verificar con lscpu | grep NUMA).

Guía paso a paso

1. Validar la topología del cluster GPU

Antes de inyectar fallos, documentá la topología de tu cluster. Ejecutá en un nodo con GPU:

# Instalar herramientas de NVIDIA (si no están)
sudo apt-get install -y nvidia-utils-535 nvidia-driver-535

# Verificar topología de GPUs
nvidia-smi topo -m

# Ejemplo de salida esperada:
# GPU0    GPU1    CPU Affinity    NUMA Affinity
# GPU0    NV12     0-19           N/A
# GPU1    NV12     20-39          N/A

• Las GPUs sean modelos compatibles (H100, A100, RTX 6000 Ada).
• El driver NVIDIA esté actualizado (nvidia-smi -q | grep "Driver Version").
• El BIOS del servidor tenga SR-IOV y NVLink habilitados.

2. Configurar DCGM para monitoreo y control

DCGM es la herramienta oficial de NVIDIA para monitorear y gestionar clusters GPU. Instalá el DCGM-Exporter y habilitá el modo de control:

# Descargar e instalar DCGM (versión 3.2.0 o superior)
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get install -y datacenter-gpu-manager

# Verificar que dcgmi funcione
sudo dcgmi discovery -l

# Ejemplo de salida:
# Found 2 GPUs on this node
# GPU 00000000:01:00.0 [H100-PCIe]
# GPU 00000000:02:00.0 [H100-PCIe]

# Habilitar el modo de control (requiere reinicio del servicio)
sudo systemctl stop nvidia-dcgm
sudo dcgmi config --enable-dcgm-exporter
sudo systemctl start nvidia-dcgm

sudo systemctl status nvidia-dcgm
dcgmi test --gpuid 0 --test memory

3. Desplegar Chaos Mesh en Kubernetes

Chaos Mesh es un framework de ingeniería de caos para Kubernetes. Desplegá la versión estable:

# Instalar Helm (si no está)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Añadir el repo de Chaos Mesh
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

# Instalar Chaos Mesh (namespace dedicado)
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --version 2.6.0

# Verificar instalación
kubectl get pods -n chaos-mesh

• Que tu cluster tenga CNI instalado (Calico, Cilium).
• Que no haya PodSecurityPolicies o NetworkPolicies bloqueando la comunicación entre namespaces.

4. Inyectar fallos en nodos NUMA

Los fallos de afinidad NUMA ocurren cuando un proceso se ejecuta en un socket CPU que no está conectado a la GPU asignada. Creamos un experimento de caos para simularlo:

# archivo: numa-affinity-failure.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: numa-affinity-failure
spec:
  action: pod-failure
  mode: one
  duration: "1h"
  selector:
    namespaces:
      - default
    labelSelectors:
      app: training-job  # Etiqueta de tus pods de entrenamiento
  scheduler:
    cron: "@hourly"

Aplicá el experimento:

kubectl apply -f numa-affinity-failure.yaml

1. Observá la métrica nvidia_gpu_utilization en Prometheus (debería caer a 0% durante el fallo).
2. Verificá en los logs del kernel (journalctl -u kubelet | grep "NUMA") si hay warnings de afinidad.

// archivo: numa-affinity-test.rs
use std::process::Command;

fn main() {
    // Forzar afinidad a socket 0 (aunque la GPU esté en socket 1)
    Command::new("numactl")
        .args(&["--cpubind=0", "--membind=0", "nvidia-smi"])
        .status()
        .expect("Failed to execute numactl");
}

Compilalo y ejecutalo dentro de un pod de entrenamiento para ver la degradación de rendimiento.

5. Simular fallos en enlaces NVLink

Los enlaces NVLink son críticos para la comunicación entre GPUs. Simulá un fallo de enlace con Chaos Mesh:

# archivo: nvlink-failure.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: nvlink-failure
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: distributed-training  # Etiqueta de pods que usan múltiples GPUs
  delay:
    latency: "100ms"
    jitter: "10ms"
  duration: "30m"
  scheduler:
    cron: "*/30 * * * *"

Aplicá el experimento:

kubectl apply -f nvlink-failure.yaml

1. Verificá métricas de rendimiento en DCGM:

   dcgmi stats --gpuid 0 --type sm_util
   

El sm_util debería caer un 30-50%.

1. Revisá logs de tus pods de entrenamiento para errores como:

   NCCL WARN : [Rank 0] [nvlink] NCCL watchdog caught exception NCCL_ERROR_NET_TIMEOUT
   

• Que tus pods estén usando más de 1 GPU (ej: nvidia.com/gpu: 2).
• Que el driver NVIDIA esté configurado para usar NVLink (nvidia-smi -q | grep "NVLink").

6. Inyectar fallos térmicos (throttling)

Simulá condiciones de alta temperatura para forzar throttling:

# archivo: thermal-throttling.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: thermal-stress
spec:
  mode: one
  stressors:
    cpu:
      workers: 4
      load: 90
  selector:
    namespaces:
      - default
    labelSelectors:
      app: training-job
  duration: "15m"
  scheduler:
    cron: "*/15 * * * *"

1. Observá la métrica nvidia_gpu_temperature en Prometheus. Debería subir a >80°C.
2. Verificá en DCGM:

   dcgmi test --gpuid 0 --test performance
   

El power_usage debería mostrar throttling (throttle_reasons).

# Forzar throttling en GPU 0
sudo dcgmi test --gpuid 0 --test performance --throttle 1 --duration 300

7. Validar resiliencia de ECC

Los errores de memoria en GPUs (ECC) suelen ser silenciosos hasta que generan XID errors. Simulá un fallo de memoria:

# archivo: ecc-failure.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: IoChaos
metadata:
  name: ecc-simulated-failure
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - default
    labelSelectors:
      app: inference-service  # Pods que usan GPUs para inferencia
  delay:
    latency: "5ms"
    jitter: "1ms"
  duration: "10m"
  scheduler:
    cron: "@daily"

1. Observá logs del kernel en nodos GPU:

   journalctl -u nvidia-dcgm | grep "XID"
   

1. Verificá que tus pods no fallen con errores como:

   CUDA error: an illegal memory access was encountered
   

Consideraciones y buenas prácticas

Limitaciones conocidas

• Chaos Mesh no soporta inyección de fallos en NVLink directamente: Los enlaces NVLink son hardware específico y requieren herramientas como NVIDIA NCCL o Mellanox OFED para simular fallos. Usá NetworkChaos con delay o loss como workaround.
• Rendimiento vs. estabilidad: Algunos experimentos (ej: throttling) pueden degradar el rendimiento de tu cluster. Ejecutalos en horarios de baja carga.
• Costos ocultos: Un experimento que inyecte fallos en un cluster con GB200 Grace Blackwell (U$S 3M por rack) puede generar costos en minutos. Usá ResourceQuotas para limitar el impacto.

Alertas recomendadas

Configurá alertas en Prometheus para detectar fallos inyectados:

# archivo: gpu-alerts.yaml
groups:
- name: gpu-failures
  rules:
  - alert: GPUThrottlingDetected
    expr: increase(nvidia_gpu_temperature{job="dcgm-exporter"}[5m]) > 5
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Throttling detectado en GPU {{ $labels.gpu }}"
      description: "La temperatura de la GPU {{ $labels.gpu }} subió un 5°C en 5 minutos"

Alternativas a Chaos Mesh

• Gremlin: Herramienta comercial con soporte para GPUs (requiere licencia).
• LitmusChaos: Open-source, pero con menos soporte para GPU-specific experiments.
• Scripts personalizados: Usá Rust o Go para inyectar fallos directamente via DCGM (ej: dcgmi test --gpuid 0 --test memory --errors 10).

Conclusión

Aplicar ingeniería de caos en clusters de GPU no es un lujo, es una necesidad. Los fallos en topologías de red, afinidad NUMA, throttling térmico y errores de memoria pueden degradar el rendimiento de tu infraestructura de IA en minutos, generando costos millonarios en tiempo de entrenamiento.

En esta guía, implementaste:

1. Monitoreo de topología GPU con DCGM.
2. Experimentos de caos para NUMA, NVLink y throttling.
3. Validación de métricas con Prometheus y logs del kernel.

• Automatizá la ejecución de experimentos con Argo Workflows.
• Integra los resultados con tus pipelines de CI/CD para validar resiliencia en cada despliegue.
• Explorá herramientas como NVIDIA NCCL Tests para simular fallos en comunicaciones entre GPUs.

La resiliencia de tu infraestructura de IA no se construye con pruebas tradicionales, sino con experimentos controlados que expongan los límites del sistema antes de que lo haga un usuario real.

FIN