Cuando los usuarios inician sesión en el sistema, lo hacen en los frontend que dan acceso a los recursos del sistema, los usuarios no deben ejecutar ningún trabajo sobre estos equipos ya que todos los usuarios trabajan sobre estas máquinas y la ejecución de procesos en ellas, ralentiza el trabajo del resto de usuarios.
Todos los trabajos HPC que se ejecuten en el sistema deben ser ejecutados en los nodos de cálculo mediante el envío de un script al gestor de trabajos de SCAYLE.
Es fundamental que los usuarios optimicen el uso de los recursos del sistema para garantizar un rendimiento eficiente y equitativo. Además, el uso adecuado del gestor de trabajos de SCAYLE no solo facilita la distribución de las tareas, sino que también maximiza la utilización de los recursos disponibles, minimizando los tiempos de espera y evitando la sobrecarga de los nodos frontales.
Al seguir estas directrices, se asegura un entorno de trabajo colaborativo y eficiente, beneficiando a todos los usuarios del sistema.
El gestor de trabajos o gestor de colas es un sistema que se encarga de enviar los trabajos a los nodos de cálculo a los que cada usuario tiene acceso, controla su ejecución y evita que varios trabajos compartan los mismos recursos, viendo así incrementados sus tiempos de ejecución. El gestor usado por SCAYLE es SLURM.
En el caso del gestor de trabajos SLURM, los comandos más utilizados en su uso habitual son:
Compila trabajos en los nodos con las mismas características que en los que va a ser ejecutado posteriormente, creando una sesión interactiva con los nodos de cálculo.
Por ejemplo, ejecutando el siguiente comando:
[usuario@frontend11 ~]$ salloc --ntasks=16 --time=60 --partition=genoaEl gestor de trabajos asignará un acceso a uno de los nodos de cálculo de la partición llamada "genoa" (--partition=cascadelake), durante un máximo de 60 minutos (--time=60) y nos permitirá usar 16 cores para nuestras tareas de compilación o test de nuestro código.
Este comando de SLURM se utiliza para enviar al gestor de trabajos el script del trabajo que querramos ejecutar.
Por ejemplo:
[usuario@frontend11 ~]$ sbatch run_openfoam.shEnviará el script de ejecución del software de "dinámica de fluidos OpenFOAM" al gestor de trabajos.
Muestra información y estado de todos los trabajos en ejecución.
[usuario@frontend11 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
94631 genoa JOB_OF usuario R 3:47:29 2 cn[7026-7027]En el ejemplo anterior, el usuario tiene un único trabajo en ejecución con un valor de "JOBID" de 94631:
JOBID: Es un número único que el gestor de trabajos asigna a cada uno de los trabajos que gestiona.
PARTITION: Informa de en qué grupo de servidores está siendo ejecutado el trabajo.
NAME: Informa del nombre del trabajo que fue definido en el script de envío.
USER: Indica el propietario del trabajo.
ST: Informa del estado del trabajo, en este caso "R (running)" en ejecución. Existe otro estado "PD (pendiente)", que indica que el trabajo está en espera para ser ejecutado.
TIME: Informa del tiempo que lleva el trabajo siendo ejecutado.
Finalmente, el número de servidores utilizados y el nombre de los mismos se detallan en las columnas "NODES" y "NODELIST".
Por razones de seguridad y privacidad, los usuarios solo pueden tener acceso a la información de sus propios trabajos, no pudiendo acceder a ningún tipo de información del resto de usuarios.
Cancela la ejecución de un trabajo que está en funcionamiento.
Según el ejemplo anterior si deseamos cancelar el trabajo con "JOBID 94631", pasaríamos el comando:
[usuario@frontend11 ~]$ scancel 94631
El primer paso para poder enviar un trabajo al gestor de trabajos es escribir un script de envío (submission script) que contenga dos tipos de líneas: directivas para el gestor de trabajos y comandos Linux.
“#SBATCH” seguida de las distintas opciones disponibles. Estas directivas son procesadas por el gestor cuando el script se envía con el comando sbatch, que sirven para proporcionar información al gestor y permitir así que los nodos de ejecución realicen el trabajo de la forma deseada por el usuario. Por ejemplo, el siguiente batch script:
#!/bin/bash
#SBATCH --ntasks=32
#SBATCH --job-name=hello_world
#SBATCH --mail-user=email@scayle.es
#SBATCH --mail-type=ALL
#SBATCH --output=hello_world_%A_%a.out
#SBATCH --error=hello_world_%A_%a.err
#SBATCH --partition=sapphire
#SBATCH --qos=normal
#SBATCH --time=0-00:05:00
source /soft/sapphire/intel/oneapi/setvars.sh
srun -n $SLURM_NTASKS hello_world.shEn la línea 1, como ya se ha detallado, se especifica el tipo de shell que ejecutará los comandos linux del script.
Todas las líneas que comienzan con #SBATCH son las directivas que interpretará el gestor de tareas. Explicadas a continuación:
--ntasks --> Fija el número de cores deseados para la ejecución del script, en este caso 32 cores.
--job-name --> Nombre asignado al trabajo.
--mail-user--> Dirección de correo electrónico a donde se enviarán las notificaciones relacionadas con el trabajo.
--mail-type --> Define en qué circunstancias se enviará un correo electrónico al usuario. En este caso “ALL” será al comienzo de la ejecución, al finalizar la misma y en caso de que la tarea sea cancelada.
--output --> Es el fichero de salida estándar. Si no se define un fichero de salida para los errores, por defecto se unifica en un solo archivo la salida estándar de la ejecución y la salida de los posibles errores.
--error --> Define el fichero de salida de errores.
--partition --> Partición a la que se envía el trabajo.
--qos --> QOS con la que se envía el trabajo. En este enlace se le muestra los QOS disponibles.
--time --> Límite de tiempo para el trabajo (D-HH:MM:SS).
IMPORTANTE: Para que el trabajo funcione correctamente es obligatorio añadir el parametro
#SBATCH --time=(D-HH:MM:SS)al script. D son días, HH son horas, MM son minutos y SS son segundos. El tiempo definido con el parámetro "---time" en ningún caso tendrá prioridad sobre el tiempo máximo de ejecución asociado a la QOS del trabajo.
Cada QOS (Quality Of Services) permite personalizar diversos parámetros como el tiempo máximo que un trabajo puede ejecutarse, el número máximo de cores que pueden ser solicitados por un usuario o qué usuarios pueden enviar trabajos a esa partición.
Por defecto, los usuarios tienen acceso a determinados límites. Para solicitar el acceso a una QOS en particular, el usuario debe ponerse en contacto con el personal de soporte.
A continuación se muestran los límites de las QOS que tenemos disponibles donde:
| Nombre | Prioridad | MaxWall | MaxTRESPU | MaxJobsPU |
|---|---|---|---|---|
| normal | 100 | 5-00:00:00 | cpu=512 | 50 |
| long | 100 | 15-00:00:00 | cpu=256 | |
| xlong | 100 | 30-00:00:00 | cpu=128 | |
| xxlong | 100 | 45-00:00:00 | cpu=64 |
La QOS por defecto que utilizan los usuarios si no se especifica nada, es la QOS normal.
Cuando un mismo trabajo debe repetirse una serie de veces variando únicamente el valor de algún parámetro, el gestor de tareas permite realizar esta tarea de forma automatizada. A este tipo de trabajos se les denomina array jobs.
Para enviar un array job se debe usar la opción --array del comando sbatch, por ejemplo desde la línea de comandos:
frontend11> sbatch ... --array 1-20 ... test.shEnviaría 20 ejecuciones simultáneas del programa test.sh.
Si quisiéramos incluirlo en el própio script, deberíamos añadirlo al resto de opciones del gestor de tareas:
#SBATCH --output=hello_world_%A_%a.out
#SBATCH --error=hello_world_%A_%a.err
#SBATCH –-partition=broadwell
#SBATCH –-qos=normal 10
#SBATCH –-array=1-20 <----Dadas las características de los límites del sistema de colas, utilizaremos el siguiente parámetro de SLURM para tener de forma simultánea una ejecución, con --array=1-20 %<numero>.
#SBATCH --array=1-20%4Donde <numero> introduciremos el valor de trabajos que queremos de forma simultánea.
Esto no garantiza que los trabajos entren uno detrás de otro ya que depende de la carga de la máquina y las prioridades.
Existen un número de variables que se definen en el entorno del trabajo cuando el script se ejecuta a través del gestor de tareas. Estas variables se pueden usar en el script.
Entre las más interesantes para el uso habitual están las siguientes:
$SLURM_JOB_ID: Identificador del trabajo.
$SLURM_JOB_NAME: Nombre del trabajo.
$SLURM_SUBMIT_DIR: Directorio de envío.
$SLURM_JOB_NUM_NODES: Número de nodos asignados al trabajo.
$SLURM_CPUS_ON_NODE: Número de cores/nodo.
$SLURM_NTASKS: Número total de cores por trabajo.
$SLURM_NODEID: Índice del nodo que se ejecuta en relación a los nodos asignados al trabajo.
$SLURM_PROCID: Índice de la tarea en relación con el trabajo.
Utilizar las features (características) y constraints (restricciones) da la capacidad a los usuarios de definir con precisión sus necesidades, ya sea la preferencia de interconexión de su aplicación, la cantidad de memoria requerida, o la disposición a usar máquinas de baja prioridad. Tener un conocimiento claro de cómo operan estas características y cuáles son las más adecuadas para su aplicación puede maximizar el rendimiento en el entorno de colas.
Para seleccionar una "feature" con #SBATCH utilizaremos el siguiente parámetro:
#SBATCH --constraint=<nombre_de_la_feature>Donde <nombre_de_la_feature> será uno de los nombres que encontrará en la tabla definida más abajo.
En este apartado encontrará las características (columna nombre) que podrá introducir en el parámetro "--constraint=":
| Nombre | Descripción |
|---|---|
| intel | Selecciona solo nodos con CPUs Intel |
| amd | Selecciona solo nodos con CPUs AMD |
| cascadelake | Selecciona solo nodos con CPUs basadas en la arquitectura Cascade Lake |
| icelake | Selecciona solo nodos con CPUs basadas en la arquitectura Ice Lake |
| sapphirerapids | Selecciona solo nodos con CPUs basadas en la arquitectura Sapphire Rapids |
| broadwell | Selecciona solo nodos con CPU basadas en la arquitectura Broadwell |
| genoa | Selecciona solo nodos con CPU basadas en la arquitectura Genoa |
| gpu_v100 | Selecciona solo nodos con GPU NVidia Tesla V100 |
| gpu_a100 | Selecciona solo nodos con GPU NVidia Tesla A100 |
| gpu_h100 | Selecciona solo nodos con GPU NVidia Tesla H100 |
| 192GB | Selecciona solo los nodos que tengan disponible un máximo de 192GB de memoria RAM |
| 256GB | Selecciona solo los nodos que tengan disponible un máximo de 256GB de memoria RAM |
| 384GB | Selecciona solo los nodos que tengan disponible un máximo de 384GB de memoria RAM |
| 1024GB | Selecciona solo los nodos que tengan disponible un máximo de 1024GB de memoria RAM |
| 1536GB | Selecciona solo los nodos que tengan disponible un máximo de 1536GB de memoria RAM |
| 2048GB | Selecciona solo los nodos que tengan disponible un máximo de 2048GB de memoria RAM |
| 2434GB | Selecciona solo los nodos que tengan disponible un máximo de 2434GB de memoria RAM |
| xeon_6240 | Selecciona solo nodos con CPUs Intel Xeon 6240 |
| xeon_6252 | Selecciona solo nodos con CPUs Intel Xeon 6252 |
| xeon_8358 | Selecciona solo nodos con CPUs Intel Xeon 8358 |
| xeon_e5-2695v4 | Selecciona solo nodos con CPUs Intel Xeon E5-2695 v4 |
| xeon_8462y+ | Selecciona solo nodos con CPUs Intel Xeon 8462y+ |
| epyc_9374f | Selecciona solo nodos con CPUs AMD EPYC 9374F |
Última actualización: 10/02/2025 14:36