This is an old revision of the document!
Utilización de SLURM
SLURM Workload Manager o formalmente (Simple Linux Utility for Resource Management) es un sistema de gestión de trabajos en clústeres de código abierto, el cual es tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.
Funciones principales
- Asigna a los usuarios acceso exclusivo y/o no exclusivo a recursos de cómputo por un tiempo determinado, permitiéndoles así ejecutar trabajos (jobs) asignados.
- Provee un marco para iniciar, ejecutar y monitorear tareas (normalmente tareas paralelas) en un conjunto de nodos asignados.
- Coordina la solicitud de recursos a través de una cola de trabajos pendientes.
¿Cómo se encarga Slurm de gestionar los trabajos?
- Ejecutando el trabajo
- Asignando recursos de cómputo solicitados por el trabajo
- Reportando la salida de su ejecución al usuario.
Pasos para ejecutar un trabajo
- Preparar un script (el formato del script se encuentra a continuación)
- Enviar trabajo para ejecución.
1. Comandos básicos de Slurm
Comando | Descripción |
---|---|
squeue | Ver estado de los trabajos en la cola |
sinfo | Ver información de los nodos de cómputo |
sbatch | Enviar un trabajo a través de un script, para su posterior ejecución |
srun | Ejecutar un trabajo interactivo |
scancel | Eliminar un trabajo |
scontrol | Ver información más detallada de trabajos, colas y particiones. |
sacct | Ver a nivel de sistema la utilización de recursos de trabajos completados. |
2. Parámetros básicos de comandos
2.1. Envío de Trabajo (srun y sbatch)
Comando SLURM | Descripción |
–mem-per-cpu=<megabytes> | Memoria requerida para el trabajo por CPU asignada (en MegaBytes). El valor predeterminado es 1024 MB. |
-n, –ntasks=<cantidad de tareas> | Número de tareas que serán asignadas para el trabajo. |
-c <cpus> | Número de CPUs (hilos) requeridas por tarea. El valor especificado aquí es el número “mínimo” de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo). |
–constraint=<features> | Características requeridas del nodo |
–cpus-per-task=<count> -c <count> | Número de CPUs (hilos) requeridas por tarea |
–dependency=<state:jobid> | Aplaza trabajo hasta que los trabajos especificados alcancen el estado especificado |
–error= -e | Archivo en el que se desea almacenar mensajes de error de trabajo |
–exclude=<names> | Nombres de host específicos para excluir de la asignación de trabajo |
–exclusive[=user] | Los nodos asignados no se pueden compartir con otros trabajos/usuarios |
–export=<name[=value]> | Exportar variables de entorno identificadas |
–gres=<name[:count]> | Recursos genéricos necesarios por nodo |
–input=<name> | Archivo desde el cual leer los datos de entrada del trabajo |
–job-name=<name> -J <name> | Nombre del trabajo |
–label -l | Antepone el ID de la tarea a la salida. (sólo con comando srun) |
–licenses=<name[:count]> | Recursos de licencia necesarios para todo el trabajo |
–mem=<MB> | Memoria requerida por nodo |
–mem-per-cpu=<MB> | Memoria requerida por CPU asignada |
-N<minnodes[-maxnodes]> | Recuento de nodos necesarios para el trabajo |
–ntasks=<count> -n <count> | Número de tareas (procesos) a iniciar |
–nodelist=<names> -w <names> | Nombres de host específicos para incluir en la asignación de trabajo |
–output=<name> -o <name> | Archivo en el que se desea almacenar la salida del trabajo |
–partition=<names> -p <names> | Partición/cola en la que se desea ejecutar el trabajo |
–qos=<name> | Calidad de servicio |
–signal=[B:]<num>[@time] | Trabajo de señal cuando se acerca el límite de tiempo |
–time=<time> (ej. “–time=08:00:00”) | Permite ajustar el límite de tiempo del trabajo |
–wrap=<command_string> | Envuelva el comando especificado en un shell “sh” simple (sólo con comando sbatch) |
2.2. Gestión de Trabajo
scancel - Manda una señal a trabajos, conjuntos de trabajos y/o pasos de trabajo.
–account=<name> | Opera solamente en trabajos que carguen en la cuenta especificada |
–name=<name> | Opera solamente en trabajos con nombre especificado |
–partition=<names> | Opera solamente en trabajos con partición/cola especificada |
–qos=<name> | Opera solamente en trabajos que utilicen la calidad de servicio especificada |
–reservation=<name> | Opera solamente en trabajos que utilicen la reservación especificada |
–state=<names> | Opera solamente en trabajos en el estado especificado |
–user=<name> | Opera solamente en trabajos del usuario especificado |
–nodelist=<names> | Opera solamente en trabajos que utilicen los nodos informáticos especificados |
squeue - Entrega información sobre trabajos
–account=<name> | Permite ver sólo trabajos con cuentas especificadas |
–clusters=<name> | Permite ver sólo trabajos con clusters especificados |
–format=<spec> (ej. “–format=%i%j”) | Formato de salida para mostrar. Especifica campos, tamaño, orden, etc. |
–jobs=<job_id_list> | Lista separada por comas de IDs de trabajo para mostrar |
–name=<name> | Permite ver sólo trabajos con nombres especificados |
–partition=<names> | Permite ver sólo trabajos con particiones especificadas |
–priority | Ordena trabajos por prioridad |
–qos=<name> | Permite ver sólo trabajos con Calidad de Servicio especificada |
–start | Informa la hora de inicio prevista y los recursos que se asignarán para los trabajos pendientes en orden de tiempo de inicio creciente |
–state=<names> | Permite ver sólo trabajos con estados especificados |
–users=<names> | Permite ver sólo trabajos para usuarios especificados |
sinfo - Entrega información sobre nodos y particiones
–all | Muestra información sobre todas las particiones |
–dead | Si está configurado, sólo reporta información de estado para los nodos que no responden (muertos) |
–format=<spec> | Formato de salida para mostrar |
–iterate=<seconds> | Imprime el estado en el intervalo especificado |
–long | Imprime información más detallada. |
–Node | Imprime información en un formato orientado a nodos |
–partition=<names> | Permite ver sólo las particiones especificadas |
–reservation | Muestra información sobre reservas avanzadas |
-R | Muestra los motivos por los que los nodos están inactivos, agotados, fallidos o en estado fallido. |
–state=<names> | Permite ver sólo los estados especificados de los nodos |
3.1. Ejemplo básico 1 (multi-thread con OpenMP)
Este es un ejemplo de un script (ejemplo1.sh) con los elementos mínimos para ejecutar el programa namd a través de slurm:
#!/bin/bash #Shell a usar durante la simulación, para este caso es bash #SBATCH -J NAMD-NOMBRE-SIMULACION #Nombre de la simulación, reemplazar por nombre apropiado #SBATCH --nodes=1 #Número de nodos donde se ejecutará la simulación, siempre es 1 para Soroban #SBATCH --tasks-per-node=40 #40 es el número de procesos a ejecutar en el servidor Soroban, reemplazar por la cantidad adecuada #SBATCH --mem=100G #Memoria reservada para esta simulación en el servidor #SBATCH --partition=intel #Partición donde se enviarán los trabajos, en este caso la partición general se llama intel. module load namd/Git-2019-11-27_Linux-x86_64-multicore #Programas o módulos necesarios para ejecutar esta simulación, reemplazar por las adecuadas en cada caso
Para enviar este script a slurm, crear un job, y comenzar el procesamiento se requiere lo siguiente:
chmod x ejemplo1.sh
sbatch ejemplo1.sh
3.2. Ejemplo básico 2 (single thread)
Este es un ejemplo de un script (ejemplo2.sh) con los elementos mínimos para ejecutar el programa R-3.6.1 a través de slurm:
#!/bin/bash #Shell usada por el usuario, para este caso es BASH #SBATCH -J R-NOMBRE-SIMULACION #Reemplazar R-nombre-simulación por el nombre correspondiente a la simulación #SBATCH --nodes=1 #Número de nodos a donde se enviará la simulación, para Soroban es 1. #SBATCH --tasks-per-node=1 #Número de tareas por nodo, en este caso es 1 porque es una tarea single-thread #SBATCH --mem=100G #Cantidad de memoria reservada para esta simulación, 100G, reemplazar por valor adecuado #SBATCH --partition=intel #Nombre de la partición slurm donde se enviará las simulaciones, en este caso la partición general se llama "intel" module load R/3.6.1 #Módulos necesarios para ejecutar la simulación, para este ejemplo solamente es necesario 'R/3.6.1' este ejemplo es para single thread.
Para enviar este script a slurm, crear un job, y comenzar el procesamiento se requiere lo siguiente:
chmod x ejemplo2.sh
sbatch ejemplo2.sh
Este ejemplo enviar un trabajo de 1 hilo a slurm con los parámetros del script, y con limitaciones establecidas al usuario y la partición
3.3. Ejemplo básico 3 (Array Jobs)
Este ejemplo muestra como enviar varias tareas utilizando la propiedad de array-jobs en slurm, para más detalles consultar documentación oficial de slurm para ver todas las posibilidades ofrecidas en Array-Jobs.
#!/bin/bash #SBATCH -J R-NOMBRE-SIMULACION #Nombre de la simulación, reemplazar según sea el caso #SBATCH -a 1-11%3 # #SBATCH --nodes=1 #Número de nodos donde se enviará el trabajo, siempre es 1 para Soroban #SBATCH --tasks-per-node=1 #Número de hilos a ejecutar simultáneamente #SBATCH --mem=100G #Memoria reservada para la simulación #SBATCH --partition=intel #Partición general donde se enviará la simulación, llamada 'intel' module load R/3.6.1 #Módulo necesario cargado previamente, necesario para la simulación cmds=( #Comandos a ejecutar en array 'sleep 10;echo 10' 'sleep 20;echo 20' 'sleep 30;echo 30' 'sleep 40;echo 40' 'sleep 50;echo 50' ) eval ${cmds[$SLURM_ARRAY_TASK_ID - 1]} #Desplegar información de los ID de cada elemento de array-job enviado
chmod +x ejemplo3.sh
sbatch ejemplo3.sh