Clúster Advanced

RDlab@lsi.upc.edu
Febrero 2015

castellano Bienvenidos a LSI.

El siguiente manual tiene por objetivo introducir conceptos avanzados en el uso del clúster de Computación del Departamento de Lenguajes y Sistemas Informáticos (LSI) del la Universidad Politécnica de Cataluña (UPC), gestionado por el Laboratorio de Investigación y Desarrollo (RDlab).

Para consultar la información básica de uso del clúster diríjase al Cluster Quickstart

Array jobs

En caso de tener una gran cantidad de trabajos idénticos que enviar al clúster cuyas únicas diferencias sean los parámetros de entrada, lo recomendable en vez de enviar todos los trabajos por separado es usar los array jobs.

Los array jobs se caracterizan por tener todos el mismo identificador de trabajo (job_id) pero distinto identificador de tarea (task_id). El formato para especificar un array job es el siguiente:

qsub -t <task_id_inicial>-<task_id_final>:<paso>

task_id_inicial será el task_id del primer trabajo, task_id_final el del último, y paso (opcional) la diferencia entre los task_id de los trabajos consecutivos. Por ejemplo:

qsub -l h_cpu=0:45:0 -t 2-10:2 render.sh data.in

Ejecutará el script render.sh con parámetros de entrada data.in de forma que obtendremos un mismo job_ib y distintos task_id (2,4,6,8 y 10) para cada una de las llamadas

Es posible usar el parámetro task_id en el script a ejecutar, mediante el parámetro $SGE_TASK_ID:

#!/bin/bash
#$ -t 1-100
PARAM=`awk "NR==$SGE_TASK_ID" $HOME/myJob_params.txt`
$HOME/myJob.sh $PARAM

En este ejemplo, el fichero $HOME/myJob_params.txt contiene los parámetros de entrada del script $HOME/myJob.sh. En cada línea contiene los parámetros de cada llamada; la línea uno, los parámetros de la llamada con task_id=1, la línea 2, los de la llamada con task_id=2, y así sucesivamente. La utilidad de sistema awk leerá los parámetros usando el valor de $SGE_TASK_ID para acceder a la línea que coincide con este valor, y dejará dichos parámetros en la variable PARAM. Finalmente, pasaremos la variable PARAM al script que ejecutará el trabajo myJob.

Entornos de ejecución paralelos

Para la ejecución de trabajos que necesiten usar más de un núcleo de procesador simultáneamente es necesario utilizar un entorno de ejecución paralelo. El clúster del RDlab ofrece la posibilidad de usar dos entornos de ejecución paralelos: MPI (message-passing interface), basada en el intercambio de mensajes, y MAKE, basado en smp (symmetrical multiprocessing).

A efectos prácticos, la diferencia principal entre ambos reside en el hecho que MPI permite que los procesos se ejecuten en distintos nodos, mientras que MAKE solamente permite la ejecución en paralelo en núcleos del mismo nodo.

Además, el entorno MPI require de trabajos preparados explícitamente para el uso de este entorno, mientras que MAKE (SMP) permite que ciertos jobs (OpenMP, matlab, java, procesos con threads, etc) aumenten su rendimiento al disponer de más núcleos de ejecución.

qsub -pe <entorno> <num_cores>

Si queremos que nuestro trabajo se ejecute de forma paralela en 4 procesadores en un entorno make, ejecutaremos:

qsub -pe make 4

Se puede combinar esta propiedad con el core binding de modo que el entorno intente reservar los 4 nodos de forma consecutiva:

qsub -binding linear:4 -pe make 4

Ejecución de trabajos MPI

El clúster permite la ejecución de trabajos MPI gracias a la integración de OpenMPI con el gestor de colas Grid Engine a través del entorno paralelo “ompi”. Las aplicaciones MPI deben ser compiladas con la versión de OpenMPI del clúster, que reside en /home/soft/openmpi.

Previamente es necesario configurar el acceso ssh intranodo sin password, ya que la interacción entre los distintos nodos del pool MPI se hace como usuario vía ssh:

ssh-keygen

Pulsar return a las preguntas que se harán para generar claves sin passphrase.

cat ~/.ssh/.id_rsa.pub > ~/.ssh/authorized_keys
cp /home/soft/rdlab/known_hosts ~/.ssh/

A continuación mostramos una plantilla de un jobscript para un trabajo típico MPI:

# Trabajo de ejemplo openmpi 
#
#
#
#$ -N job_name
#
# Use current working directory
#$ -cwd
#
# PARALLEL ENVIRONMENT:
# 
# Numero de slots a utilitzar (En el ejemplo 1 master, 19 slaves)
#
#$ -pe ompi 20 
#
# Declaracion de variables necesarias
#
PATH=/home/soft/openmpi/bin:${PATH}
LD_LIBRARY_PATH=/home/soft/openmpi/lib

# Ejecutamos comandos mpirun
mpirun -np $NSLOTS path_del_meu_proces_mpi
			

En este tipo de trabajos los límtes de memoria (h_vmem) se aplican a los distintos procesos MPI de forma individual.

Es posible ver en qué nodos se ejecutan los distintos procesos del trabajo con el comando

qstat -g -t

Integración con Hadoop

El clúster del RDlab ofrece además la posibilidad de ejecutar un entorno Hadoop. Para poder usar este entorno es necesario pedir acceso al RDlab.

Dependencias entre trabajos

Las dependencias entre trabajos permiten retrasar la ejecución de un trabajo hasta que otro trabajo haya terminado. De esta forma podemos definir el orden de ejecución de los trabajos para asegurar las dependencias que existen.

Para ello, se debe añadir el flag hold_jid y el identificador del trabajo del que ha de depender:

qsub -hold_jid <job_id>

En el caso concreto de los array jobs, estos pueden depender de otros trabajos, pero las tareas no pueden tener dependencias con otros trabajos o tareas.

Trabajos interactivos: qlogin

Hasta este punto del manual se ha mostrado como interactuar con el clúster con trabajos en batch. Sin embargo, también es posible abrir un shell interactivo directamente con un nodo de computación, usando la llamada qlogin.

Esta sesión interactiva es útil en situaciones en que es necesario ejecutar trabajos con entrada directa del usuario, en aplicaciones con ventanas o en compilaciones pesadas.

qlogin -q short

NOTA: Cabe destacar que este shell es un proceso del clúster y por tanto está limitado en sus recursos (memoria y tiempo de ejecución).

La herramienta qlogin acepta los mismos flags que la llamada qsub, está sujeto a las mismas restricciones, y solo nos permitirá acceder a aquellos nodos a los que tenemos acceso. Los flags permiten especificar otros límites igual que con cualquier trabajo enviado mediante qsub o especificar a qué nodo nos queremos conectar mediante el flag hostname:

qlogin -l hostname=node210,h_vmem=1G

En el ejemplo anterior, estableceríamos conexión con el nodo 210 siempre y cuando éste tenga 1GB de memoria libre.

Es necesario tener en cuenta que, a diferencia de un trabajo batch, si las peticiones de recursos no están disponibles el trabajo no se encolará ni tampoco nos abrirá la sesión interactiva.

Afinidad: Core Binding

Entendemos por core binding la fijación (bind) de un trabajo a un procesador concreto. Por defecto, el clúster del RDlab usa esta propiedad para todos los procesos de usuario tal y como se ha descrito en la sección indicaciones del manual de uso básico.

Sin embargo, es posible definir el flag binding para ajustarlo a las necesidades concretas de nuestro trabajo, asociando éste a tantos nucleos como creamos conveniente.

qsub -binding <binding_strategy>

La estrategia de binding que se puede usar en el clúster puede ser linear o striding:

Con linear el sistema intentará asociar el trabajo a tantos núcleos consecutivos como especifiquemos.

qsub -binding linear:<num_cores>

Con striding el sistema intentará asociar el trabajo a tantos núcleos a una distancia step-size como especifiquemos.

qsub -binding striding:<amount>:<step-size>

Ejecución en GPUs

Actualmente el clúster del RDlab dispone de nodos de cómputo con tarjetas NVIDIA TESLA y GTX Titan. Estas tarjetas se encuentran en los nodos 800 y 801. Para obtener datos sobre las tarjetas se puede ejecutar el siguiente comando en el nodo:

nvidia-smi

node 800

+------------------------------------------------------+                       
| NVIDIA-SMI 361.28     Driver Version: 361.28         |                       
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla K20m          Off  | 0000:05:00.0     Off |                  Off |
| N/A   32C    P0    46W / 225W |     14MiB /  5119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  Tesla K20m          Off  | 0000:42:00.0     Off |                  Off |
| N/A   28C    P0    43W / 225W |     14MiB /  5119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
		    

node 801

 
+------------------------------------------------------+                       
| NVIDIA-SMI 352.39     Driver Version: 352.39         |                       
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX TIT...  Off  | 0000:03:00.0     Off |                  N/A |
| 22%   48C    P0    74W / 250W |     23MiB / 12287MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  Tesla K40c          Off  | 0000:06:00.0     Off |                    0 |
| 23%   44C    P0    67W / 235W |     22MiB / 11519MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

		    

El comando, además, muestra los datos relativos a los procesos en ejecución en las tarjetas

                                                     
+-----------------------------------------------------------------------------+
| Compute processes:                                               GPU Memory |
|  GPU       PID  Process name                                     Usage      |
|=============================================================================|
|  No running compute processes found 					      |
+-----------------------------------------------------------------------------+
		    

Para usar dicho nodo es necesario enviar los trabajos a una cola de nombre gpu. Para tener acceso es necesario pedirlo al RDlab. Se trata de una cola tanto batch como interactiva, usable de la forma habitual.

IMPORTANTE: Los usuarios con acceso a la cola GPU han de indicar explícitamente la cola (short, medium, long o GPU) en la ejecución de cualquier trabajo; de otro modo, un trabajo "normal" se podría ejecutar en la cola GPU.

Para un envio de trabajo en batch:

qsub -q gpu ...

Para una conexión interactiva:

qlogin -q gpu

Los jobs de la cola no tienen límite de tiempo, pero sí un límite de 2 GB de RAM por defecto, cambiable de la manera habitual