Slurm es un sistema de gestión de clústeres y programación de trabajos de código abierto para Linux. Este sistema gestiona la programación de trabajos en más del 65% de los sistemas TOP500. Muchas organizaciones que realizan entrenamiento de IA a gran escala han invertido años en scripts de trabajos de Slurm, políticas de uso equitativo y flujos de trabajo contables. El desafío consiste en integrar las capacidades de programación de Slurm en Kubernetes, la plataforma estándar para gestionar infraestructuras de GPU a gran escala, sin mantener dos entornos separados.
Slinky, un proyecto de código abierto desarrollado por SchedMD (ahora parte de NVIDIA), aborda esta integración de dos maneras:
- slurm-bridge permite que Slurm actúe como programador de Kubernetes para pods.
- slurm-operator gestiona clústeres completos de Slurm en la infraestructura de Kubernetes, controlando el ciclo de vida de los demonios de Slurm como pods.
Esta publicación se centra en el slurm-operator, que es cómo NVIDIA ejecuta Slurm en Kubernetes para clústeres de entrenamiento de GPU a gran escala. Se describe la arquitectura del operador y cómo se relaciona con los elementos primitivos de Kubernetes, seguido de la implementación, incluyendo cómo Slinky se integra con la infraestructura existente. También se abordan las integraciones del ecosistema de Kubernetes que hacen posible este modelo. Finalmente, compartimos lecciones aprendidas de la ejecución de Slinky en producción en clústeres con más de 1,000 nodos de GPU y más de 8,000 GPUs.
¿Cómo funciona Slinky slurm-operator?
El slurm-operator de Slinky representa cada componente de Slurm (slurmctld para programación, slurmdbd para contabilidad, slurmd para trabajadores de cómputo, slurmrestd para acceso API) como una Definición de Recurso Personalizado (CRD) de Kubernetes. Un clúster de Slurm se define utilizando Recursos Personalizados, y Slinky crea demonios de Slurm en contenedores que se ejecutan en sus propios pods, configurados para pertenecer a su respectivo clúster.
Slinky garantiza la alta disponibilidad (HA) del plano de control de Slurm (slurmctld) mediante la regeneración de pods, sin necesidad del mecanismo de HA nativo de Slurm. Los cambios de configuración se propagan automáticamente: Kubernetes sincroniza la configuración montada (ConfigMaps y Secrets) en el pod de control, que detecta los cambios y propaga la nueva configuración a sus trabajadores (slurmd) sin tiempo de inactividad del programador.
¿Cómo implementar Slinky slurm-operator?
Los clústeres de Slurm implementados con Slinky en Kubernetes funcionan de manera similar a las implementaciones de Slurm no containerizadas. El slurm-operator de Slinky habilita automáticamente las características de Slurm necesarias para la operación en contenedores:
- Modo sin configuración para la distribución de configuración sin sistemas de archivos compartidos.
- Nodos dinámicos para que los trabajadores se registren al iniciar sin ser predefinidos en
slurm.conf. - Autenticación/Slurm con uso de client IDs para autenticación de usuario en todo el clúster sin servicios de identidad por nodo.
Slinky opera con su infraestructura de base de datos e identidad existente. La contabilidad de Slurm (slurmdbd) se conecta a cualquier base de datos compatible con MySQL o MariaDB, ya sea que se ejecute dentro del clúster o como un servicio gestionado externo. La gestión de identidad para los pods de inicio de sesión se realiza a través de SSSD, por lo que Active Directory, LDAP o cualquier otro backend soportado se integra sin cambios. Slurm 25.11 permite que slurmd haga cumplir el aislamiento de recursos (cgroups v2) dentro de su contenedor, lo que significa que los trabajos concurrentes de múltiples usuarios en el mismo trabajador están completamente aislados.
Slinky proporciona imágenes de contenedor de referencia y archivos Docker para cada componente de Slurm. Puede usarlas directamente, extenderlas con sus propias bibliotecas y dependencias, o construir imágenes personalizadas siempre que incluyan una instalación funcional de Slurm.
¿Cuál es el beneficio de ejecutar Slurm en Kubernetes?
El beneficio operativo de ejecutar Slurm en Kubernetes proviene del ecosistema. En lugar de construir y mantener cadenas de herramientas separadas para la gestión de GPU, monitorización, redes y ciclo de vida de nodos, puede utilizar las herramientas de Kubernetes que ya existen para estos problemas. Los equipos de plataforma gestionan clústeres con YAML declarativo, implementaciones Helm, actualizaciones continuas y Prometheus o Grafana para la observabilidad.
Automatizar la gestión de GPU con el NVIDIA GPU Operator
El NVIDIA GPU Operator automatiza la instalación de controladores de GPU, la configuración del entorno de ejecución de contenedores y la implementación de plugins de dispositivo, otorgando a los pods de trabajo acceso automático a las GPUs.
El NVIDIA GPU Operator también despliega DCGM Exporter, un recolector de telemetría de GPU. Con la integración de DCGM y soporte para mapeo de trabajos HPC, puede habilitar métricas de GPU por trabajo etiquetadas con IDs de trabajos de Slurm, proporcionando monitorización a nivel de carga de trabajo en su clúster.
Para habilitar esto, agregue lo siguiente a los valores del Helm del NVIDIA GPU Operator:
dcgmExporter: hpcJobMapping: enabled: true directory: /var/lib/dcgm-exporter/job-mapping
Los pods de trabajo montan el mismo directorio, permitiendo que los scripts prolog/epilog de Slurm (que se ejecutan al inicio y finalización de los trabajos) escriban archivos de mapeo de trabajos que DCGM Exporter recoge automáticamente.
NVIDIA NVLink multinodo con ComputeDomains
Para arquitecturas de GPU como NVIDIA GB200 NVL72, donde las GPUs se comunican a través de nodos mediante NVIDIA NVLink, Slinky permite el acceso a ComputeDomains. Esta es una abstracción de Kubernetes proporcionada por el controlador DRA de NVIDIA que gestiona dinámicamente los dominios de Intercambio de Memoria entre Nodos (IMEX) para una conectividad GPU a GPU de alta capacidad.
En las implementaciones de NVIDIA, Slinky utiliza un ComputeDomain a nivel de clúster (numNodes: 0) que agrega y elimina nodos del dominio IMEX automáticamente a medida que se unen o abandonan el clúster. Esto proporciona:
- Conciencia de la topología de bloques: Slinky se integra con Topograph, que descubre automáticamente la topología de bloques de GPU de su clúster utilizando Asignación de Recursos Dinámicos (DRA) y etiquetas publicadas por el NVIDIA GPU Operator.
- Plugin IMEX: Slurm está configurado con
SwitchType = switch/nvidia_imexpara utilizar NVIDIA IMEX para la comunicación de GPU entre nodos. - Programación consciente de la topología: Slurm 25.11 admite
TopologyParam=BlockAsNodeRankconTopologyPlugin=topology/block, asegurando que las asignaciones se ordenen para que las aplicaciones puedan descubrir segmentos por rango de nodo.
Los trabajos de entrenamiento distribuidos logran el ancho de banda completo de NVLink a través de los límites de los nodos mientras ComputeDomains crea y desmantela automáticamente los dominios IMEX a medida que los trabajos se completan.
Sincronización de estado bidireccional
Slinky sincroniza el estado entre Kubernetes y Slurm en ambas direcciones. Los estados de los nodos de Slurm (Inactivo, Asignado, Mixto, Apagado, Drenado, Completando, No Responde) se reflejan como condiciones de pods, brindando a los operadores visibilidad del estado de Slurm a través de herramientas estándar de Kubernetes.
Cuando se retira un nodo para mantenimiento usando kubectl drain, el estado de drenado y la razón se sincronizan automáticamente con Slurm. Los pods que ejecutan cargas de trabajo activas están protegidos por PodDisruptionBudgets, de modo que los trabajos en curso no se desalojan accidentalmente.
Slinky slurm-operator a gran escala
NVIDIA ejecuta Slinky slurm-operator en producción en múltiples clústeres, con algunas implementaciones escalando hasta más de 8,000 GPUs. Estos clústeres ejecutan trabajos de entrenamiento LLM a gran escala y cargas de trabajo de inferencia multinodo a diario. Las pruebas de comunicación de GPU (NCCL all-reduce y all-gather) igualan el rendimiento de las implementaciones de Slurm no containerizadas, sin impacto medible de la capa de Kubernetes en la que se ejecuta Slinky. Los nuevos clústeres pasan de cero a ejecutar trabajos en horas utilizando gráficos Helm y configuración declarativa, sin aprovisionamiento manual. A esta escala, los beneficios operativos de ejecutar Slurm en Kubernetes se acumulan con:
- Monitoreo unificado: Prometheus recoge métricas de Slurm (trabajos, nodos, particiones, latencia del programador) junto con métricas estándar de Kubernetes, con paneles de Grafana que muestran ambos en una sola vista. No hay necesidad de una pila de monitoreo separada para HPC.
- Remediación automatizada: Cuando las verificaciones de salud marcan un nodo como no saludable, el estado se sincroniza automáticamente de Kubernetes a Slurm, con la misma razón visible en ambos sistemas. Slurm drena el nodo, los trabajos se reprograman en hardware sano, y los equipos ya no necesitan coordinar entre las herramientas de K8s y Slurm por separado.
- Actualizaciones continuas no disruptivas: Actualizar cientos de imágenes de pods de trabajo solía requerir tiempo de inactividad. Con
PodDisruptionBudgetsprotegiendo trabajos en ejecución, ahora implementamos actualizaciones de versión de Slurm y parches de SO mientras los trabajos de entrenamiento continúan sin interrupciones en la capacidad restante. - Coordinación de mantenimiento: El drenaje estándar de nodos de Kubernetes se sincroniza con Slurm. Los trabajos se completan de forma ordenada, se procede al mantenimiento y, al volver a poner el nodo en línea, se restaura automáticamente al clúster de Slurm.
- Herramientas familiares: Los equipos de plataforma utilizan kubectl para operaciones diarias. Las condiciones de los pods exponen estados de Slurm (Inactivo, Asignado, Drenado) sin necesidad de acceso a la CLI de Slurm, lo que significa que los ingenieros de guardia pueden gestionar problemas de Slurm con las mismas herramientas que utilizan para todo lo demás.
Una limitación a tener en cuenta: El slurm-operator de Slinky actualmente asume un pod de trabajo por nodo. Si sus cargas de trabajo son exclusivamente trabajos de Slurm de un solo nodo, esto puede resultar en una sobreprovisión relativa a lo que necesita, y una integración más ligera (o slurm-bridge) puede ser una mejor opción. El modelo de implementación de Slinky resulta beneficioso en la programación de trabajos multinodo.
Aspectos destacados de la versión 1.1.0 de Slinky slurm-operator
La recientemente lanzada versión 1.1.0 del slurm-operator aborda varias brechas que son importantes para las implementaciones en producción:
- Soporte para topología dinámica: Antes de la versión 1.1.0, la conciencia de topología de Slurm requería configuración estática. En la versión 1.1.0, los nodos dinámicos se registrarán con su topología en función del nodo de Kubernetes en el que se ejecute el pod de trabajo, lo que significa que la programación consciente de la topología funcionará correctamente a medida que los pods se muevan por el clúster.
- Escalado de pods de trabajo estilo DaemonSet: Antes de la versión 1.1.0, los pods de trabajo se escalaban a través del recuento de réplicas. El escalado estilo DaemonSet vincula los pods a su
nodeSelector, haciendo que el mapeo de nodos de Slurm a Kubernetes sea estáticamente 1:1. Esto simplifica las operaciones para clústeres donde cada nodo de GPU debería ejecutar siempre un trabajador de Slurm. - Remediación de pods de trabajo no registrados: Los pods de trabajo que son saludables pero no están registrados en su clúster de Slurm se recrean automáticamente, cerrando una brecha en el comportamiento de auto-reparación.
En el largo plazo, el equipo trabaja en actualizaciones de clústeres de Slurm de manera ordenada, flujos de trabajo de interrupciones planificadas, reversión de configuraciones y registro estructurado de demonios. El objetivo es hacer que el modelo operativo de Slinky coincida con lo que los equipos de plataforma esperan de cualquier carga de trabajo de Kubernetes en producción: declarativa, auto-reparable y observable.
Comience con el Slinky slurm-operator
Slinky es de código abierto y está disponible hoy. Instale el slurm-operator a través de Helm, defina su clúster de Slurm como un Recurso Personalizado, y podrá tener trabajos ejecutándose en Kubernetes en menos de una hora. La Guía de inicio rápido del slurm-operator lo guía a través de la configuración completa.
Kubernetes es la infraestructura adecuada para la computación con GPU, y Slurm es una capa de programación de trabajos extremadamente poderosa para las cargas de trabajo que se ejecutan sobre ella. Slinky hace que esta combinación funcione sin problemas en producción. Planeamos seguir invirtiendo en facilitar la ejecución de infraestructura de entrenamiento de IA a gran escala. Si tiene preguntas o desea compartir lo que está construyendo, visite SlinkyProject en GitHub.
