Uso básico de Slurm

¿Qué es Slurm?

Slurm es un sistema de administración de trabajos para servidores y clústeres de cómputo. Su función es organizar el uso de recursos compartidos como CPUs, memoria RAM, GPUs, nodos y tiempo de ejecución.

En un clúster, los análisis pesados no deben ejecutarse directamente en la terminal de acceso. En su lugar, se envían a una cola mediante Slurm. El sistema decide cuándo y en qué nodo se ejecutan, de acuerdo con los recursos solicitados y la disponibilidad del clúster.

Slurm ayuda a:

  • evitar que una sola persona sature el servidor;
  • organizar los análisis de varias personas usuarias;
  • asignar CPUs, memoria y GPUs de manera controlada;
  • registrar los trabajos ejecutados;
  • mejorar la reproducibilidad de los análisis.

Particiones disponibles para usuarios del IB-UNAM

En BEAGLE, las particiones principales para usuarios del Instituto de Biología, UNAM, son:

Partición Nodo(s) Recursos principales Uso recomendado
ib beagle-01, beagle-02 CPUs y memoria RAM Trabajos generales de bioinformática con CPU
gpu_V100 beagle-gpu-01 CPUs, memoria RAM y GPUs NVIDIA V100 Trabajos que requieren GPU o análisis grandes que necesitan muchos CPUs y memoria

Recursos disponibles por nodo:

Nodo CPUs Memoria aproximada GPU Partición
beagle-01 32 94 GB No ib
beagle-02 20 188 GB No ib
beagle-gpu-01 80 754 GB 3 × NVIDIA V100 gpu_V100
NoteUso de la partición gpu_V100

La partición gpu_V100 contiene el nodo con mayor capacidad de CPU y memoria dentro de BEAGLE, pero también contiene las GPUs. No se debe solicitar GPU si el programa no la usa.

Conceptos básicos

Job

Un job es un trabajo enviado a Slurm. Puede ejecutar un programa, un script de Bash, un análisis en R o Python, un contenedor de Apptainer, o una herramienta bioinformática.

Cola

La cola es la lista de trabajos que están esperando, corriendo, terminando o detenidos dentro del sistema.

Nodo

Un nodo es una computadora del clúster. Cada nodo tiene una cantidad específica de CPUs, memoria RAM y, en algunos casos, GPUs.

Partición

Una partición es un grupo lógico de nodos. Al enviar un trabajo se indica la partición donde debe ejecutarse.

Recurso

Un recurso es una parte del clúster que Slurm puede asignar a un trabajo. Los recursos más comunes son CPUs, memoria RAM, tiempo de ejecución, nodos y GPUs.

Flujo general de trabajo

  1. Preparar un script de Bash con directivas de Slurm.
  2. Enviar el script a la cola con sbatch.
  3. Revisar el estado del trabajo con squeue.
  4. Consultar los archivos de salida y error.

Comandos básicos

Acción Comando Para qué sirve
Ver estado del clúster sinfo Muestra particiones, nodos y estados generales
Ver particiones del IB-UNAM sinfo -p ib,gpu_V100 Filtra la información a las particiones principales de BEAGLE
Ver recursos por nodo sinfo -N -p ib,gpu_V100 -o "%N %c CPUs %m MB %G %T" Muestra CPUs, memoria, GPUs y estado de cada nodo
Ver la cola squeue Lista los trabajos activos o pendientes
Ver solo tus trabajos squeue -u $USER Filtra la cola por tu usuario
Enviar un trabajo sbatch <script.sh> Envía un script a Slurm
Cancelar un trabajo scancel <JOBID> Cancela un trabajo específico
Cancelar tus trabajos scancel -u $USER Cancela todos los trabajos de tu usuario

Cómo leer sinfo

Columnas frecuentes:

Columna Significado
PARTITION Nombre de la partición
AVAIL Indica si la partición está disponible
TIMELIMIT Tiempo máximo permitido para trabajos en esa partición
NODES Número de nodos incluidos
STATE Estado de los nodos
NODELIST Nombre de los nodos

Estados comunes de nodos:

Estado Significado
idle El nodo está libre
alloc El nodo está ocupado
mix El nodo tiene algunos recursos ocupados y otros libres
down El nodo no está disponible
drain El nodo no acepta nuevos trabajos

Cómo leer squeue

Columnas frecuentes:

Columna Significado
JOBID Identificador único del trabajo
PARTITION Partición donde está programado el trabajo
NAME Nombre del trabajo
USER Usuario que envió el trabajo
ST Estado del trabajo
TIME Tiempo que lleva corriendo
NODES Número de nodos asignados
NODELIST(REASON) Nodo asignado o razón por la que sigue pendiente

Estados comunes de trabajos:

Estado Significado
R Running: el trabajo está corriendo
PD Pending: el trabajo está esperando
CG Completing: el trabajo está terminando
CD Completed: el trabajo terminó correctamente
F Failed: el trabajo falló
CA Cancelled: el trabajo fue cancelado
TO Timeout: el trabajo terminó por límite de tiempo

Estructura de un script de Slurm

Un script de Slurm es un archivo de Bash con instrucciones especiales para solicitar recursos. Tiene tres partes principales:

Parte Qué significa
Línea de intérprete Define qué programa interpretará el script, normalmente Bash
Directivas #SBATCH Indican a Slurm qué recursos se solicitan
Cuerpo del script Contiene los comandos que se ejecutarán dentro del trabajo

Línea de intérprete

La línea de intérprete indica que el archivo debe ejecutarse con Bash.

Línea Significado
#!/bin/bash Usa Bash como intérprete del script

Directivas #SBATCH

Las líneas que empiezan con #SBATCH son leídas por Slurm antes de ejecutar el cuerpo del script. Aunque parecen comentarios para Bash, Slurm las interpreta como instrucciones de planificación.

Directiva Significado
#SBATCH -J <nombre> Nombre del trabajo
#SBATCH --job-name=<nombre> Nombre del trabajo usando la forma larga
#SBATCH -p <partición> Partición donde se ejecutará
#SBATCH --partition=<partición> Partición usando la forma larga
#SBATCH -N <nodos> Número de nodos solicitados
#SBATCH -n <tareas> Número total de tareas
#SBATCH -c <cpus> CPUs por tarea
#SBATCH --cpus-per-task=<cpus> CPUs por tarea usando la forma larga
#SBATCH --mem=<memoria> Memoria RAM solicitada
#SBATCH --time=<tiempo> Tiempo máximo de ejecución
#SBATCH -o <archivo> Archivo de salida estándar
#SBATCH -e <archivo> Archivo de error estándar
#SBATCH --gres=gpu:<n> Número de GPUs solicitadas

CPUs, tareas y nodos

En Slurm, -N, -n y -c no significan lo mismo.

Opción Significado Uso típico
-N Número de nodos Trabajos que necesitan uno o varios nodos
-n Número de tareas Programas paralelos por procesos, como MPI
-c CPUs por tarea Programas multihilo, como muchas herramientas bioinformáticas

Para la mayoría de análisis bioinformáticos comunes en BEAGLE, suele usarse un nodo, una tarea y varias CPUs por tarea. El número de CPUs solicitado debe coincidir con el número de hilos que usará el programa.

Memoria RAM

La memoria se solicita con --mem. Slurm reserva esa cantidad de RAM para el trabajo. Si el análisis usa más memoria de la solicitada, puede fallar por falta de memoria.

Formatos comunes:

Formato Significado
--mem=4G Solicita 4 GB de RAM
--mem=16000M Solicita 16000 MB de RAM
--mem=0 Solicita toda la memoria disponible del nodo, si la configuración lo permite

Tiempo máximo

El tiempo se solicita con --time. Cuando el trabajo supera ese límite, Slurm puede cancelarlo automáticamente.

Formatos comunes:

Formato Significado
--time=30:00 30 minutos
--time=02:00:00 2 horas
--time=1-00:00:00 1 día
--time=5-00:00:00 5 días

GPUs

Las GPUs se solicitan con --gres=gpu:<n>. Esta directiva solo debe usarse cuando el programa realmente puede usar GPU.

Directiva Significado
#SBATCH -p gpu_V100 Envía el trabajo a la partición con nodo GPU
#SBATCH --gres=gpu:1 Solicita una GPU
#SBATCH --gres=gpu:2 Solicita dos GPUs

Cuando se usan contenedores de Apptainer con GPU NVIDIA, normalmente se agrega la opción --nv al comando apptainer exec. La explicación detallada de Apptainer está en la sección correspondiente.

Archivos de salida y error

Slurm puede separar la salida normal y los mensajes de error en archivos diferentes.

Directiva Significado
#SBATCH -o logs/%x_%j.out Guarda la salida estándar en logs/
#SBATCH -e logs/%x_%j.err Guarda los errores en logs/

Códigos útiles en nombres de archivo:

Código Significado
%x Nombre del trabajo
%j ID del trabajo
%u Nombre del usuario
%N Nombre del nodo

Variables útiles de Slurm

Slurm crea variables automáticamente dentro de cada trabajo.

Variable Significado
$SLURM_JOB_ID ID del trabajo
$SLURM_JOB_NAME Nombre del trabajo
$SLURM_CPUS_PER_TASK CPUs asignadas por tarea
$SLURM_SUBMIT_DIR Carpeta desde donde se envió el trabajo
$SLURM_JOB_NODELIST Nodo o nodos asignados
$SLURM_GPUS GPUs asignadas, si aplica
$SLURM_MEM_PER_NODE Memoria asignada por nodo, si está disponible
$SLURM_NTASKS Número de tareas asignadas

Solicitar menos recursos de los necesarios

Solicitar menos recursos puede provocar fallas o ejecuciones muy lentas.

Recurso insuficiente Consecuencia posible
Pocas CPUs El análisis tarda más o el programa intenta usar más hilos de los asignados
Poca memoria El trabajo puede terminar con error de memoria
Poco tiempo Slurm puede cancelar el trabajo por límite de tiempo
No solicitar GPU Un programa que requiere GPU puede no detectar aceleración

Solicitar más recursos de los necesarios

Pedir recursos de más no hace que el programa corra más rápido automáticamente. Si un programa solo usa pocas CPUs, las CPUs extra quedan reservadas pero sin uso.

Consecuencias frecuentes:

  • el trabajo puede tardar más en iniciar;
  • otros usuarios no pueden usar los recursos reservados;
  • se desperdicia capacidad del clúster;
  • baja la eficiencia general del sistema.

Buenas prácticas

No correr análisis pesados en la terminal de acceso

La terminal de acceso debe usarse para preparar archivos, revisar resultados, editar scripts y enviar trabajos. Los análisis pesados deben enviarse a Slurm.

Solicitar recursos razonables

Pide CPUs, memoria y tiempo de acuerdo con el programa y el tamaño de tus datos. Si no conoces el consumo, empieza con una prueba pequeña y revisa los resultados.

Usar la partición correcta

Usa ib para trabajos generales con CPU. Usa gpu_V100 cuando necesites GPU o cuando el análisis requiera más CPU y memoria de la que ofrecen los nodos de ib.

Hacer coincidir CPUs e hilos

El número de CPUs solicitado debe coincidir con los hilos configurados dentro del programa. Para scripts, es recomendable usar $SLURM_CPUS_PER_TASK cuando el programa permita definir hilos.

Guardar salidas y errores

Usa una carpeta logs/ para archivos .out y .err. Esto facilita revisar si el trabajo terminó correctamente o si falló.

No solicitar GPU sin necesidad

Una GPU reservada queda bloqueada para otros usuarios. Solo solicita GPU cuando el programa esté preparado para usarla.

Revisar el historial de trabajos

Después de terminar un análisis, consulta el estado final, el tiempo usado y posibles errores. Esto ayuda a ajustar recursos para futuros trabajos.