Módulo 1
¿Qué es Slurm?
Slurm (Simple Linux Utility for Resource Management) es el gestor de recursos y cola de trabajos más utilizado en clústeres de HPC en todo el mundo. Permite distribuir trabajos de cómputo entre los nodos disponibles de forma eficiente y equitativa.
Gestor de colas
Organiza y prioriza los trabajos enviados por múltiples usuarios para optimizar el uso del clúster.
Asignación de recursos
Asigna CPUs, memoria, GPUs y tiempo de pared según lo solicitado por cada trabajo.
Contabilidad
Registra el uso de recursos por usuario, proyecto y grupo para facturación y monitoreo.
Código abierto
Licencia GPLv2, mantenido activamente por SchedMD y una comunidad global de centros HPC.
¿Por qué usar un gestor de recursos?
En un clúster compartido, múltiples usuarios compiten por los mismos nodos de cómputo. Sin un gestor de recursos, los usuarios tendrían que coordinarse manualmente para no solapar trabajos, lo que sería caótico e ineficiente. Slurm resuelve esto de forma automática:
- Equidad: aplica políticas de prioridad para que ningún usuario monopolice el sistema.
- Eficiencia: empaqueta trabajos para maximizar la utilización de los nodos.
- Reproducibilidad: los scripts de trabajo documentan el entorno de ejecución exacto.
- Escalabilidad: funciona igual en clústeres de 10 nodos que en sistemas con decenas de miles.
Dato histórico
Slurm nació en el Lawrence Livermore National Laboratory (LLNL) a principios de la década de 2000. Hoy está presente en más del 60 % de los supercomputadores del Top500.
Flujo de trabajo típico con Slurm
Flujo desde el envío de un trabajo hasta su ejecución en los nodos
Comandos principales de Slurm
| Comando | Función | Cuándo usarlo |
|---|---|---|
sbatch | Enviar un trabajo batch a la cola | Siempre que ejecutes un script |
srun | Ejecutar un comando de forma interactiva | Pruebas rápidas en nodo de cómputo |
squeue | Ver trabajos en cola y corriendo | Monitorear el estado de tus jobs |
scancel | Cancelar un trabajo | Cuando necesitas detener un job |
sinfo | Ver estado de particiones y nodos | Antes de enviar un trabajo |
sacct | Ver historial y contabilidad de trabajos | Diagnosticar trabajos pasados |
scontrol | Ver/modificar detalles de trabajos | Diagnóstico avanzado |
Módulo 2
Arquitectura de Slurm
Slurm tiene una arquitectura cliente-servidor distribuida compuesta por un demonio controlador central y daemons en cada nodo de cómputo. Entender esta arquitectura te ayudará a interpretar los mensajes de error y a depurar problemas.
Arquitectura de Slurm: slurmctld (controlador), slurmd (nodos), slurmdbd (base de datos de contabilidad)
Componentes principales
slurmctld
Demonio controlador central. Toma decisiones de scheduling, mantiene el estado global del clúster y gestiona colas y prioridades. Corre en el nodo maestro.
slurmd
Demonio que corre en cada nodo de cómputo. Recibe trabajos del controlador, los ejecuta y reporta estado y recursos disponibles.
slurmdbd
Demonio de base de datos. Registra toda la contabilidad: trabajos enviados, recursos usados, tiempos de ejecución, por usuario y proyecto.
FS compartido
Sistema de archivos paralelo BeeGFS (1.5 PB, 200 GB/s) montado en todos los nodos. Permite que tus scripts y datos sean visibles desde cualquier nodo de forma inmediata.
Particiones
Una partición (o cola) en Slurm es un grupo de nodos con una política común de acceso, tiempo máximo de trabajo y límites de recursos. Los clústeres HPC suelen tener varias particiones según el tipo de trabajo:
| Partición típica | Descripción | Límite tiempo |
|---|---|---|
debug | Pruebas rápidas, prioridad alta, recursos limitados | 1-4 horas |
normal | Trabajos generales de producción | 24-72 horas |
long | Simulaciones largas, menor prioridad | 7-30 días |
gpu | Nodos con GPUs para deep learning y visualización | Variable |
highmem | Nodos con mucha RAM para análisis de datos masivos | Variable |
Módulo 3
Explorar el clúster con sinfo
Antes de enviar un trabajo, debes conocer el estado de las particiones y nodos disponibles. El comando sinfo es tu ventana al estado del clúster en tiempo real.
Uso básico
user@login01:~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
debug* up 4:00:00 2 idle node[01-02]
normal up 3-00:00:00 8 idle node[03-10]
normal up 3-00:00:00 2 alloc node[11-12]
gpu up 1-00:00:00 4 idle gpu[01-04]
highmem up 7-00:00:00 1 idle bigmem01
user@login01:~$ # Ver nodos con sus recursos detallados
user@login01:~$ sinfo -o "%20N %10c %10m %25f %10G"
NODELIST CPUS MEMORY AVAIL_FEATURES GRES
node[01-02] 32 128000 compute,debug (null)
node[03-12] 64 256000 compute,normal (null)
gpu[01-04] 32 192000 compute,gpu gpu:tesla:4
bigmem01 128 2048000 compute,highmem (null)
Filtrar por partición
user@login01:~$ # Ver solo la partición GPU
user@login01:~$ sinfo -p gpu
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
gpu up 1-00:00:00 2 idle gpu[01-02]
gpu up 1-00:00:00 1 alloc gpu03
gpu up 1-00:00:00 1 down gpu04
user@login01:~$ # Ver nodos con estado IDLE (disponibles)
user@login01:~$ sinfo -t idle
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
debug* up 4:00:00 2 idle node[01-02]
normal up 3-00:00:00 8 idle node[03-10]
gpu up 1-00:00:00 2 idle gpu[01-02]
Estados de los nodos
| Estado | Significado |
|---|---|
| idle | Nodo disponible y listo para recibir trabajos |
| alloc | Nodo completamente asignado a trabajos en ejecución |
| mix | Nodo parcialmente asignado (algunos CPUs libres) |
| down | Nodo fuera de servicio o no responde |
| drain | Nodo en mantenimiento, no acepta nuevos trabajos |
Consejo práctico
Usa sinfo -N -l para ver una lista completa de nodos con todos los detalles de recursos. Esto te ayuda a elegir la partición correcta según los requisitos de tu trabajo.
Módulo 4
Scripts de trabajo con sbatch
sbatch es el comando para enviar trabajos en modo batch a la cola de Slurm. Los trabajos se definen en un script de shell que combina directivas #SBATCH con los comandos de tu programa.
Anatomía de un script Slurm
mi_trabajo.sh
Bash + Slurm
#!/bin/bash
#SBATCH --job-name=mi_trabajo # Nombre del trabajo en la cola
#SBATCH --partition=normal # Partición (cola) a usar
#SBATCH --nodes=1 # Número de nodos
#SBATCH --ntasks=1 # Número de tareas (procesos MPI)
#SBATCH --cpus-per-task=8 # CPUs por tarea (hilos OpenMP)
#SBATCH --mem=16G # Memoria total por nodo
#SBATCH --time=02:00:00 # Tiempo máximo (HH:MM:SS)
#SBATCH --output=trabajo_%j.out # Salida estándar (%j = job ID)
#SBATCH --error=trabajo_%j.err # Salida de errores
#SBATCH --mail-type=END,FAIL # Notificaciones por email
#SBATCH [email protected]
## ─── Entorno ──────────────────────────────────────────────────
module purge
module load python/3.11 cuda/12.2
## ─── Directorio de trabajo ────────────────────────────────────
echo "Trabajo iniciado: $(date)"
echo "Nodo: $SLURM_NODELIST"
echo "CPUs: $SLURM_CPUS_PER_TASK"
cd $SLURM_SUBMIT_DIR
## ─── Tu programa ──────────────────────────────────────────────
python mi_script.py --epochs 100 --batch-size 64
echo "Trabajo terminado: $(date)"
Directivas #SBATCH explicadas
| Directiva | Ejemplo | Descripción |
|---|---|---|
--job-name | mi_sim | Nombre del trabajo visible en squeue |
--partition | gpu | Partición donde se ejecutará |
--nodes | 2 | Número de nodos físicos a reservar |
--ntasks | 16 | Número de procesos MPI |
--ntasks-per-node | 8 | Procesos MPI por nodo |
--cpus-per-task | 4 | Hilos OpenMP por proceso |
--mem | 32G | Memoria total por nodo (no por CPU) |
--mem-per-cpu | 4G | Memoria por CPU (alternativa a --mem) |
--time | 1-12:00:00 | Límite de tiempo: D-HH:MM:SS |
--gres | gpu:2 | Recursos genéricos (GPUs, etc.) |
--output | job_%j.out | Archivo de salida (%j = JobID) |
--array | 1-100 | Job array: 100 trabajos idénticos |
--dependency | afterok:12345 | Ejecutar solo si otro job terminó bien |
Enviar y verificar el trabajo
user@login01:~$ # Enviar el script a la cola
user@login01:~$ sbatch mi_trabajo.sh
Submitted batch job 142857
user@login01:~$ # Ver el estado del trabajo recién enviado
user@login01:~$ squeue -j 142857
JOBID PARTITION NAME USER ST TIME NODES NODELIST
142857 normal mi_trabajo user PD 0:00 1 (Priority)
user@login01:~$ # Unos minutos después...
user@login01:~$ squeue -j 142857
JOBID PARTITION NAME USER ST TIME NODES NODELIST
142857 normal mi_trabajo user R 2:14 1 node05
user@login01:~$ # Ver la salida en tiempo real
user@login01:~$ tail -f trabajo_142857.out
Plantillas de scripts por caso de uso
serial_python.shPython / Serial
#!/bin/bash
#SBATCH --job-name=python_serial
#SBATCH --partition=normal
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=8G
#SBATCH --time=04:00:00
#SBATCH --output=slurm_%j.out
module purge
module load python/3.11 anaconda/2024
cd $SLURM_SUBMIT_DIR
python analisis.py --input datos.csv --output resultados/
openmp.shOpenMP (multihilo)
#!/bin/bash
#SBATCH --job-name=omp_sim
#SBATCH --partition=normal
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=32 # Un proceso, 32 hilos
#SBATCH --mem=64G
#SBATCH --time=08:00:00
#SBATCH --output=slurm_%j.out
module purge
module load gcc/13.2 intel-oneapi/2024
# Configurar número de hilos OpenMP
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
cd $SLURM_SUBMIT_DIR
./mi_programa_omp input.dat
mpi.shMPI (multiproceso)
#!/bin/bash
#SBATCH --job-name=mpi_cfd
#SBATCH --partition=normal
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=16 # 4 nodos × 16 = 64 procesos MPI
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=4G
#SBATCH --time=1-00:00:00
#SBATCH --output=slurm_%j.out
module purge
module load gcc/13.2 openmpi/4.1
cd $SLURM_SUBMIT_DIR
mpirun -np $SLURM_NTASKS ./solver --config cfd.conf
gpu.shGPU / CUDA / Deep Learning
#!/bin/bash
#SBATCH --job-name=train_dl
#SBATCH --partition=gpu
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --gres=gpu:2 # Solicitar 2 GPUs
#SBATCH --time=12:00:00
#SBATCH --output=slurm_%j.out
module purge
module load cuda/12.2 cudnn/8.9 python/3.11
export CUDA_VISIBLE_DEVICES=$SLURM_JOB_GPUS
cd $SLURM_SUBMIT_DIR
python train.py --gpus 2 --epochs 200 --model resnet50
array.shJob Array (múltiples parámetros)
#!/bin/bash
#SBATCH --job-name=parametrico
#SBATCH --partition=normal
#SBATCH --array=1-20 # 20 trabajos idénticos, IDs 1-20
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=02:00:00
#SBATCH --output=array_%A_%a.out # %A=JobID, %a=índice del array
module purge
module load python/3.11
# Cada tarea lee su índice para elegir parámetros distintos
SEED=$SLURM_ARRAY_TASK_ID
LEARNING_RATE=$(awk "NR==$SEED" lr_values.txt)
cd $SLURM_SUBMIT_DIR
python train.py --seed $SEED --lr $LEARNING_RATE
Evita sobreestimar recursos
Pedir más CPUs, memoria o tiempo del necesario retrasa tu trabajo en la cola y reduce el tiempo de turnaround de todos los usuarios. Empieza con estimaciones conservadoras y ajusta según los resultados de sacct.
Variables de entorno útiles de Slurm
| Variable | Valor típico | Descripción |
|---|---|---|
$SLURM_JOB_ID | 142857 | ID único del trabajo |
$SLURM_NODELIST | node[05-06] | Lista de nodos asignados |
$SLURM_NTASKS | 16 | Número total de tareas |
$SLURM_CPUS_PER_TASK | 8 | CPUs por tarea (para OMP_NUM_THREADS) |
$SLURM_SUBMIT_DIR | /home/user/sim/ | Directorio desde donde se envió el job |
$SLURM_ARRAY_TASK_ID | 5 | Índice en un job array |
$SLURM_JOB_GPUS | 0,1 | GPUs asignadas al trabajo |
Módulo 5
Monitorear y cancelar trabajos
Una vez enviado tu trabajo, necesitas monitorearlo con squeue y, si algo sale mal, cancelarlo con scancel. También veremos scontrol para diagnóstico detallado.
Monitorear con squeue
user@login01:~$ # Ver todos tus trabajos
user@login01:~$ squeue -u $USER
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
142857 normal mi_trabajo user R 1:23:47 1 node05
142858 gpu train_dl user PD 0:00 1 (Priority)
142859 normal array_job user PD 0:00 1 (Resources)
user@login01:~$ # Formato personalizado con más detalles
user@login01:~$ squeue -u $USER -o "%.10i %.12j %.4t %.10M %.6D %.4C %.8m %R"
JOBID NAME ST TIME NODES CPUS MIN_M NODELIST
142857 mi_trabajo R 1:23:47 1 8 16G node05
142858 train_dl PD 0:00 1 8 32G (Priority)
user@login01:~$ # Actualización automática cada 30 segundos
user@login01:~$ watch -n 30 squeue -u $USER
Estados de los trabajos
| Estado | Código | Significado |
|---|---|---|
| PENDING | PD | En cola, esperando recursos disponibles |
| RUNNING | R | Ejecutándose en nodos de cómputo |
| COMPLETING | CG | Terminando, liberando recursos |
| COMPLETED | CD | Finalizó correctamente |
| CANCELLED | CA | Cancelado por el usuario o admin |
| FAILED | F | Terminó con código de error ≠ 0 |
| TIMEOUT | TO | Superó el tiempo máximo (--time) |
| OUT_OF_MEMORY | OOM | Superó la memoria solicitada |
Razones comunes de espera (PENDING)
| Razón | Causa |
|---|---|
(Priority) | Otros trabajos tienen mayor prioridad en la cola |
(Resources) | No hay suficientes recursos disponibles ahora |
(QOSMaxCpuPerUserLimit) | Has alcanzado el límite de CPUs por usuario |
(Dependency) | Esperando que termine otro trabajo (--dependency) |
(ReqNodeNotAvail) | El nodo solicitado está en mantenimiento |
Cancelar trabajos con scancel
user@login01:~$ # Cancelar un trabajo por ID
user@login01:~$ scancel 142858
user@login01:~$ # Cancelar todos tus trabajos de una partición
user@login01:~$ scancel -u $USER -p gpu
user@login01:~$ # Cancelar un job array (todos los elementos)
user@login01:~$ scancel 142859
user@login01:~$ # Cancelar solo el elemento 5 de un array
user@login01:~$ scancel 142859_5
user@login01:~$ ## ── scontrol: diagnóstico detallado ──
user@login01:~$ scontrol show job 142857
JobId=142857 JobName=mi_trabajo
UserId=user(1001) GroupId=users(1001) MCS_label=N/A
Priority=2345 Nice=0 Account=cihh QOS=normal
JobState=RUNNING Reason=None Dependency=(null)
RunTime=01:23:47 TimeLimit=02:00:00 SubmitTime=2024-11-15T10:00:00
NumNodes=1 NumCPUs=8 NumTasks=1
TRES=cpu=8,mem=16G,node=1
NodeList=node05
BatchHost=node05
Command=/home/user/mi_trabajo.sh
WorkDir=/home/user/sim
StdOut=/home/user/trabajo_142857.out
Monitoreo eficiente
Crea un alias en tu ~/.bashrc para ver tus trabajos rápidamente: alias myjobs='squeue -u $USER -o "%.10i %.12j %.4t %.10M %.6D %.4C %R"'
Módulo 6
Contabilidad con sacct
sacct te permite consultar el historial de trabajos pasados, incluyendo recursos usados, tiempo real de ejecución y causa de finalización. Es esencial para optimizar tus solicitudes de recursos.
Uso básico de sacct
user@login01:~$ # Ver trabajos de hoy
user@login01:~$ sacct -u $USER --starttime=today
JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
142855 python_sim normal cihh 8 COMPLETED 0:0
142855.ba+ batch 8 COMPLETED 0:0
142856 train_gpu gpu cihh 8 FAILED 1:0
142857 mi_trabajo normal cihh 8 RUNNING 0:0
user@login01:~$ # Ver recursos consumidos (muy útil para optimizar)
user@login01:~$ sacct -j 142855 --format=JobID,JobName,Elapsed,CPUTime,MaxRSS,MaxVMSize,ExitCode
JobID JobName Elapsed CPUTime MaxRSS MaxVMSize ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
142855 python_sim 01:14:23 09:54:04 12456776K 18764320K 0:0
142855.ba+ batch 01:14:23 09:54:04 12456776K 18764320K 0:0
user@login01:~$ # Ver trabajos de la última semana
user@login01:~$ sacct -u $USER --starttime=$(date -d '7 days ago' +%Y-%m-%d) \
--format=JobID,JobName,Partition,State,Elapsed,MaxRSS
Campos útiles de sacct
| Campo | Descripción |
|---|---|
JobID | Identificador del trabajo |
JobName | Nombre dado con --job-name |
Elapsed | Tiempo real de ejecución (wall time) |
CPUTime | CPUs × Elapsed (tiempo de CPU total) |
MaxRSS | Máximo de memoria RAM usada (muy útil) |
MaxVMSize | Máximo de memoria virtual |
ExitCode | Código de salida (0:0 = éxito) |
State | Estado final: COMPLETED, FAILED, TIMEOUT… |
AllocCPUS | CPUs asignados al trabajo |
NodeList | Nodos donde se ejecutó |
Optimizar solicitudes de recursos con sacct
user@login01:~$ # Comparar memoria solicitada vs. usada
user@login01:~$ sacct -j 142855 --format=JobName,ReqMem,MaxRSS,Elapsed,State
JobName ReqMem MaxRSS Elapsed State
---------- ---------- ---------- ---------- ----------
python_sim 16G 12456776K 01:14:23 COMPLETED
batch 16G 12456776K 01:14:23 COMPLETED
## MaxRSS = 12456776K ≈ 12.4 GB → Pediste 16 GB, usaste 12.4 GB (OK)
## Si MaxRSS fuera 500 MB con 16 GB solicitados, reduce la solicitud
user@login01:~$ # Ver la eficiencia del CPU
user@login01:~$ seff 142855
Job ID: 142855
Cluster: blackhole
User/Group: user/users
State: COMPLETED (exit code 0)
Nodes: 1
Cores per node: 8
CPU Utilized: 09:48:12
CPU Efficiency: 98.65% of 09:54:24 core-walltime
Job Wall-clock time: 01:14:18
Memory Utilized: 11.88 GB
Memory Efficiency: 74.24% of 16.00 GB
Usa seff habitualmente
El comando seff <JobID> (disponible en la mayoría de clústeres) muestra la eficiencia de CPU y memoria de un trabajo completado. Un trabajo eficiente usa >80% de los recursos solicitados.
Módulo 7
Slurm + Open OnDemand
Open OnDemand ofrece una interfaz web que simplifica el envío de trabajos Slurm sin necesidad de línea de comandos. El Job Composer te permite crear, editar y enviar scripts directamente desde el navegador.
Job Composer: envío visual de trabajos
El Job Composer de Open OnDemand es una herramienta que te permite:
- Crear scripts Slurm con editor de texto integrado
- Seleccionar plantillas predefinidas para casos comunes
- Enviar trabajos con un clic y ver el resultado en tiempo real
- Acceder al historial de trabajos y sus archivos de salida
📋 Nuevo trabajo Slurm
Nombre del trabajo
Partición
Nodos
CPUs por tarea
Memoria
Tiempo (h:m:s)
📄 Vista previa del script generado
#!/bin/bash
#SBATCH --job-name=mi_simulacion
#SBATCH --partition=normal
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=16G
#SBATCH --time=2:00:00
#SBATCH --output=slurm_%j.out
module purge
module load python/3.11
python mi_script.py
Monitorear trabajos desde OnDemand
La sección Jobs → Active Jobs de OnDemand muestra todos los trabajos en cola en tiempo real, con la misma información que squeue pero en formato visual:
Flujo de trabajo completo en OnDemand
Flujo de trabajo completo usando solo la interfaz web de Open OnDemand
CLI vs. OnDemand: ¿cuándo usar cada uno?
Línea de comandos (SSH)
- Flujos automatizados y scripts
- Depuración avanzada con scontrol
- Job arrays complejos
- Integración con pipelines (Make, Snakemake…)
- Usuarios avanzados y sysadmins
Open OnDemand (web)
- Usuarios nuevos en HPC
- Trabajos interactivos (Jupyter, RStudio)
- Acceso a archivos sin cliente SFTP
- Visualización de resultados en el navegador
- Acceso desde cualquier dispositivo
¡Felicidades!
Has completado el curso de Slurm. Ahora conoces la arquitectura del scheduler, puedes enviar trabajos con sbatch, monitorearlos con squeue, analizarlos con sacct y usar la interfaz web de Open OnDemand. El siguiente paso es practicar con tus propios datos y programas en el clúster.
Referencia rápida de comandos
## ── Exploración ──────────────────────────────────────────────
sinfo # Estado de particiones y nodos
sinfo -p gpu # Solo partición GPU
sinfo -N -l # Nodos con todos los detalles
## ── Enviar trabajos ──────────────────────────────────────────
sbatch script.sh # Enviar script batch
srun --pty bash # Sesión interactiva
## ── Monitorear ───────────────────────────────────────────────
squeue -u $USER # Mis trabajos en cola
squeue -j 12345 # Trabajo específico
scontrol show job 12345 # Detalle completo
## ── Cancelar ─────────────────────────────────────────────────
scancel 12345 # Cancelar un job
scancel -u $USER # Cancelar todos mis jobs
## ── Contabilidad ─────────────────────────────────────────────
sacct -u $USER --starttime=today # Trabajos de hoy
seff 12345 # Eficiencia de un job
sacct -j 12345 --format=MaxRSS,Elapsed,State