Tutorial de uso Shirka
- 1 Introducción
- 2 Recursos
- 2.1 Nodos
- 2.1.1 Tipo
- 2.1.2 Características
- 2.1.3 Cantidad
- 2.2 Colas y particiones
- 2.3 Procesadores, cores y tareas
- 2.4 GPUs
- 2.1 Nodos
- 3 Comandos más comunes
- 3.1 Información sobre los nodos y las particiones
- 3.2 Lanzamiento de trabajos al cluster
- 3.3 Información sobre el Trabajo
- 3.3.1 Mostrar la fecha esperada de entrada a ejecución de los trabajos pendientes
- 3.3.2 Listar los trabajos de un usuario
- 3.3.3 Listar todos los trabajos en ejecución de un usuario
- 3.3.4 Mostrar todos los trabajos en espera de un usuario
- 3.3.5 Listar todos los trabajos de un usuario en una partición
- 3.3.6 Mostrar información detallada de un trabajo
- 3.3.7 Mostrar información sobre los recursos consumidos por un trabajo
- 3.3.8 Visualización de los trabajos de un usuario en modo gráfico
- 3.4 Control de trabajos
- 3.4.1 Cancelar un trabajo
- 3.4.2 Cancelar los trabajos de un usuario
- 3.4.3 Cancelar todos los trabajos pendientes de un usuario
- 3.4.4 Cancelar uno o más trabajos por su nombre
- 3.4.5 Detener un trabajo
- 3.4.6 Reanudar un trabajo retenido
- 3.4.7 Volver a encolar un trabajo en particular (cancelar y ejecutar)
Introducción
Cuando los usuarios inician sesión en la facilidad de cálculo shirka, lo hacen en el nodo central que da acceso a los recursos del sistema. Por ello, los usuarios no deben ejecutar ningún trabajo sobre este equipo ya que todos comparten esta máquina y la ejecución de procesos en ella, ralentiza el trabajo del resto de usuarios y penaliza en la gestión del cluster.
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 shirka.
El gestor de trabajos o gestor de colas 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 de colas usado por la facilidad de cálculo shirka es SLURM.
SLURM Workload Manager, o formalmente (Simple Linux Utility for Resource Management), es un sistema de manejo de colas y planificador de tareas para clusters Linux (https://slurm.schedmd.com).
Recursos
Nodos
El hardware que compone la facilidad de cálculo es el siguiente:
Tipo | Características | Cantidad |
---|---|---|
NODO CÁLCULO
| MODELO: Supermicro SYS-6029P-TRT CPU: Xeon(R) Gold 6248R CPU @ 3.00GHz (24 Cores) MEMORIA: 12 x 16GB DDR4 a 2933 MT/s (2934 MT/s) DISCOS: 4 x INTEL SSDSC2KB960G8 960GB 6Gb/s PUERTOS DE CONEXIÓN: 2 x 10G BASE-T + 1 IPMI | 29 |
NODO GPU
| MODELO: Supermicro SYS-1029GQ-TVRT CPU: 2 x Xeon(R) Gold 5220R CPU @ 2.20GHz (24 cores) MEMORIA: 12 x 32GB DDR4 a 2933 MT/s (2666 MT/s) CONTROLADORA DISCOS: AVAGO MegaRAID SAS 9480-8i8e con 4GB de Memoria RAID Level Supported: RAID0, RAID1, RAID5, RAID6, RAID00, RAID10, RAID50, RAID60 DISCOS: 2 x INTEL SSDSC2KB960G8 960GB 6Gb/s PUERTOS DE CONEXIÓN: 2 x 10G BASE-T + 1 IPMI GPU: 4 x Tesla V100-SXM2 32GB | 2 |
JBOD GPU
| DISCOS: (2 + 2) x INTEL SSDSC2KB960G8 960GB 6Gb/s PUERTOS DE CONEXIÓN: 1 IPMI | 1 |
NODO CENTRAL
| MODELO: Supermicro SYS-6029P-TRT CPU: 2 x Xeon(R) Silver 4214 CPU @ 2.20GHz (12 cores) MEMORIA: 8 x 32GB DDR4 a 2933 MT/s (2400 MT/s) CONTROLADORA DISCOS: AVAGO 3108 MegaRAID 2GB de Memoria RAID Level Supported: RAID0, RAID1, RAID5, RAID6, RAID00, RAID10, RAID50, RAID60 CONTROLADORA JBOD: AVAGO MegaRAID SAS 9480-8i8e con 4GB de Memoria RAID Level Supported: RAID0, RAID1, RAID5, RAID6, RAID00, RAID10, RAID50, RAID60 DISCOS: 8 x SAS SEAGATE ST2400MM0129 2,4TB 12Gb/s PUERTOS DE CONEXIÓN: 2 x 10G BASE-T + 1 IPMI | 1 |
JBOD CENTRAL
| MODELO: Supermicro CSE-PTJBOD-CB3 CPU: N/A MEMORIA: N/A DISCOS: 11 x SAS HGST HUH721212AL5200 12TB 12Gb/s PUERTOS DE CONEXIÓN: 1 IPMI | 1 |
SWITCH | MODELO: Lenovo NE1072T CPU: NXP T1042 MEMORIA: 4096 MB DISCOS: Flash: 128 MB PUERTOS DE CONEXIÓN: 48 x 10G BASE-T + 6 x Slots QSFP+ 40GbE (incluyendo un transceiver 40GbE para el switch Lenovo y otro para el core HP Aruba) | 2 |
Colas y particiones
En SLURM las colas pasan a denominarse particiones.
En la facilidad de cálculo se han configurado las siguientes particiones:
Partición q1: para trabajos que demanden 12 cores o menos en total.
Partición q2: para trabajos que demanden más de 12 cores y hasta un máximo de 24 en total.
Partición q3: para trabajos que requieran la utilización de GPUs y hasta un máximo de 8 GPUs.
Todas las particiones tienen una limitación en la duración de los cálculos de 72 horas. Si los usuarios necesitan tiempos mayores tendrán que optar por llevar a cabo un proceso de checkpoint+restart.
Las particiones q1 y q2 comparten los 29 nodos de cálculo. Mientras que la partición q3 está formada por los 2 nodos con GPU.
Procesadores, cores y tareas
Por lo general en el sistema de colas SLURM se aplican las siguientes equivalencias:
1 tarea = 1 procesador
1 procesador = 1 core
Es decir, que si no se le especifica lo contrario, cuando se asigna un número de tareas (-n), se está indicando el número de procesadores que se utilizaran al ejecutar un trabajo. Sin embargo, existen trabajos en los que las tareas requieren más procesadores, cómo por ejemplo los ejecutables que utilizan hebras (threads).
Por ejemplo, si un ejecutable utiliza la biblioteca OpenMP para paralelizar creando varias hebras, será necesario indicar al gestor de colas el número de hebras/cores que debe asignar al trabajo. Si el ejecutable crea 4 hebras, entonces se deben reservar 4 cores de la siguiente forma:
$ sbatch -n 1 --cpus-per-task=4 script.sh
El comando anterior le indica a SLURM que reserve para 1 tarea con 4 cores.
En el siguiente ejemplo, un ejecutable que utiliza OpenMP y MPI combinados requiere 2 procesos MPI (tareas) en distintos nodos y lanza 2 hebras por proceso MPI:
$ sbatch -N 2 -n 2 --tasks-per-node=1 --cpus-per-task=2 script.sh
En este caso se está especificando que se reserven 2 nodos (-N) para 2 tareas (-n) en total, de manera que en cada nodo me asigne 1 tarea con 2 cores por tarea.
Si se hace uso solo de MPI para paralelizar, sería necesario ejecutar el siguiente comando en el gestor de colas para obtener el mismo resultado :
$ sbatch -N 2 -n 4 --tasks-per-node=2 --cpus-per-task=1 script.sh
GPUs
Los trabajos que requieran el uso de GPUs deben ser ejecutados en la partición q3. Además, es necesario indicar mediante el argumento --gpus-per-node el número de gps que se van a emplear en cada nodo:
$ sbatch -p q3 -N 2 -n 2 --gpus-per-node=4 script.sh
Comandos más comunes
A continuación se describen los comandos más utilizados en este sistema de particiones (colas). Para ampliar la información sobre alguno de estos comandos es suficiente con teclear en el clúster:
$ man <comando slurm>
Donde <comando slurm> es uno de los comandos descritos en los siguientes apartados.
Información sobre los nodos y las particiones
Mostrar información de una partición
$ sinfo -p <partition>
Mostrar información de todas las particiones a intervalos de 60 segundos
$ sinfo -i60
Mostrar los nodos no operativos y su motivo
$ sinfo -R
Lanzamiento de trabajos al cluster
Existen dos maneras de ejecutar un trabajo en los nodos del clúster:
Comando sbatch (envío de un trabajo a una partición para esperar a su ejecución)
Comando srun (envío de un trabajo a una partición en tiempo real de forma interactiva y bloqueante).
Nunca se deben ejecutar los programas en los nodos a través de un ssh. Para realizar pruebas de un ejecutable es necesario utilizar el comando srun en modo interactivo (descrito en los siguiente apartados).
Envío de un trabajo para su ejecución posterior
En primer lugar se debe crear un fichero (script) con datos del trabajo a ejecutar.
Por ejemplo:
#!/bin/bash
#
#SBATCH -p q1 # Partición (cola)
#SBATCH -N 1 # Número de nodos
#SBATCH -n 1 # Número de cores(CPUs)
#SBATCH -t 0-00:02:00 # Duración (D-HH:MM:SS)
#SBATCH -o %x.%j-%N.out #STDOUT
#SBATCH -e %x.%j-%N.err #STDERR
#SBATCH --mail-type=END,FAIL # Notificación si termina o falla
#SBATCH --mail-user=usuario@uji.es # Enviar correo al email
ulimit -v unlimited
ulimit -t unlimited
srun -l bash -c 'echo $(hostname)'
Tal y como se ha indicado anteriormente para lanzar el trabajo basta con ejecutar:
$ sbatch ejemplo.sh
sbatch es un comando utilizado para enviar trabajos al sistema de colas usando el procesamiento por lotes y sin bloqueo (de manera que los resultados se escriben en un archivo y es posible enviar otros comandos de inmediato)
La mayoría de las opciones del script se pueden incluir en la línea de argumentos del comando sbatch:
$ sbatch -p q1 ejemplo.sh
$ sbatch -p q1 -N1 -n1 ejemplo.sh
Envío en tiempo real de un trabajo o de forma interactiva
El comando srun permite enviar trabajos en tiempo real a una partición. El comando srun es interactivo y bloqueante (el resultado se obtiene en el terminal y no es posible escribir otros comandos hasta que haya terminado).
Para lanzar un trabajo en tiempo real con srun:
$ srun -p <partición> -N1 -n1 <programa/orden>
Para ejecutar un trabajo en modo Interactivo:
$ srun -p <partición> -N1 -n1 --pty $SHELL -i
Información sobre el Trabajo
Mostrar la fecha esperada de entrada a ejecución de los trabajos pendientes
$ squeue --start
Listar los trabajos de un usuario
$ squeue -u <username>
Listar todos los trabajos en ejecución de un usuario
$ squeue -t RUNNING
Mostrar todos los trabajos en espera de un usuario
$ squeue -t PENDING
Listar todos los trabajos de un usuario en una partición
$ squeue -u <nombreusuario> -p <partición>
Mostrar información detallada de un trabajo
$ scontrol show jobid -dd <jobid>
Mostrar información sobre los recursos consumidos por un trabajo
$ sacct -j <jobid> --format=JobID,JobName,MaxRSS,Elapsed
Visualización de los trabajos de un usuario en modo gráfico
(Es necesario disponer de un servidor gráfico en el cliente)
$ sview
Control de trabajos
Cancelar un trabajo
$ scancel <jobid>
Cancelar los trabajos de un usuario
$ scancel -u <nombreusuario>
Cancelar todos los trabajos pendientes de un usuario
$ scancel -t PENDING -u <nombreusuario>
Cancelar uno o más trabajos por su nombre
$ scancel --name <nombretrabajo>
Detener un trabajo
$ scontrol hold <jobid>
Reanudar un trabajo retenido
$ scontrol resume <jobid>
Volver a encolar un trabajo en particular (cancelar y ejecutar)
$ scontrol requeue <jobid>