Trabajos con SLURM¶

SLURM es el planificador del clúster: recibe tus solicitudes de recursos, las pone en cola y ejecuta cada job en los nodos de cómputo cuando hay espacio. El ciclo completo quedó demostrado en el paso 5; aquí está el detalle.

Tres formas de ejecutar: `sbatch`, `srun` y `salloc`¶

SLURM te deja lanzar el mismo trabajo de tres maneras. Empieza por sbatch, que es el camino normal del clúster, y usa las otras dos cuando las necesites:

Comando	Qué hace	Cuándo usarlo
`sbatch`	Apunta tu script en la cola y devuelve el turno al instante; se ejecuta cuando haya recursos	Todo lo que quieras reproducir o repetir: es tu flujo de trabajo
`srun`	Pide la asignación y ejecuta un comando ahora, en tu terminal, bloqueándote hasta que termina	Comandos cortos y sueltos, o para lanzar MPI
`salloc`	Reserva los recursos y te deja trabajar dentro de la reserva	Probar, depurar, instalar: el modo "a mano"

sbatch y srun aceptan prácticamente las mismas opciones (-p, -n, -c, --mem, --time), así que lo que aprendes con uno te sirve con el otro.

Un script de trabajo, pieza por pieza¶

#!/bin/bash
#SBATCH -J test_job              # Nombre del job
#SBATCH -p cpu                   # Partición
#SBATCH -n 1                     # Número de tareas
#SBATCH -c 4                     # CPUs por tarea
#SBATCH --mem=8G                 # Memoria
#SBATCH --time=01:00:00          # Tiempo máximo
#SBATCH -o output_%j.log         # Salida estándar
#SBATCH -e error_%j.log          # Error estándar

echo "==============================="
echo "Inicio del job"
echo "Fecha: $(date)"
echo "Usuario: $(whoami)"
echo "==============================="

# Cargar módulos (ejemplo). Si en tu cuenta aún no activaste el árbol de
# módulos del clúster, añade antes esta línea:
#   module use --append /sw/modulefiles /sw/modules/all
module load python/3.11

# Ejecutar algo simple
python -c "print('Hola desde el HPC')"

echo "==============================="
echo "Fin del job"
echo "Fecha: $(date)"
echo "==============================="

Guárdalo como job.sh y envíalo con:

sbatch job.sh

Colas (particiones) disponibles¶

Partición	Tiempo máx.	Recursos por job	Uso pensado
`cpu-dev`	5 días	hasta 16 cores / 32 GB	desarrollo y pruebas en CPU
`cpu`	2 días	hasta 64 cores / 128 GB	producción en CPU
`cpu-max`	1 día	hasta 128 cores / 256 GB	jobs grandes de CPU
`gpu-dev`	4 días	1 GPU	desarrollo en GPU
`gpu`	2 días	2 GPU	producción en GPU
`gpu-max`	1 día	4 GPU	jobs grandes de GPU
`multinodo`	1 día	varios nodos	jobs que cruzan más de un nodo
`interactive`	1 día	lo que pida el portal	sesiones del portal visual

Las GPU (con sus tipos y perfiles) se detallan en la guía de GPU. Los límites son por job; el clúster es compartido: solicita SOLO los recursos que necesitas.

Vigilar tus jobs¶

squeue -u $USER                # qué hay en cola ahora mismo

             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
             31417       cpu hola_mun     <tú>  R       0:01      1        <nodo>

sacct -j 31417 -X --format=JobID,JobName,Partition,State,ExitCode,Elapsed

JobID           JobName  Partition      State ExitCode    Elapsed 
------------ ---------- ---------- ---------- -------- ---------- 
31417        hola_mundo        cpu  COMPLETED      0:0   00:00:04

scancel <JOBID>                # detener un job propio (el número que te dio sbatch)

Cómo leer los estados¶

`State`	Significado
`PENDING`	en espera de recursos (mira la columna `NODELIST(REASON)` de `squeue`)
`RUNNING`	ejecutándose
`COMPLETED` + `ExitCode 0:0`	terminó bien
`FAILED`	falló: revisa el archivo de error (`-e`) y `ExitCode`
`CANCELLED`	cancelado (tú, o el sistema por exceder límites)
`TIMEOUT`	excedió `--time`

Buenas prácticas¶

Pide --mem siempre: omitirla puede hacer que el envío sea rechazado con QOSMaxMemoryPerJob.
Pide tiempo de sobra pero realista; --time es el techo, no la duración.
Escribe salidas a $HOME o a /work/$USER con ruta absoluta (esta última solo existe dentro del job: el nodo de acceso no monta /work). /tmp no es compartido con los nodos de cómputo y no verás tu archivo de salida.
Lee el mensaje de error de sbatch: casi siempre dice exactamente qué falta.

Ejecutar en línea con `srun`¶

srun hace el mismo viaje que sbatch pero sin script: pide los recursos, ejecuta el comando y te devuelve la salida en la propia terminal. Es conveniente para comprobaciones rápidas; recuerda que mientras dura, tu sesión está bloqueada.

srun --partition=cpu --nodes=1 --ntasks=1 --cpus-per-task=1 --mem=1G \
     --time=00:02:00 --job-name=srun_hola echo "Hola mundo desde srun"

Hola mundo desde srun

Mientras srun trabaja, tu job está en la cola igual que uno de sbatch y lo ves con squeue:

squeue -u $USER

             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
             31386       cpu   dormir     <tú>  R       0:08      1        <nodo>

(Salida real con squeue -u: se sustituyeron el usuario y el nodo reales por <tú> y <nodo>.)

Dos cosas que la gente espera de srun y no ocurren:

No reparte tu trabajo entre nodos solo con pedirlo: para parallelizar de verdad usa srun -n <tareas> con un ejecutable compilado con MPI (guía de MPI).
No es una sesión: cuando el comando termina, la asignación se libera. Si quieres quedarte dentro trabajando, usa salloc.