Clúster Advanced

RDlab@lsi.upc.edu
Febrer 2015

català Benvinguts a LSI.

El següent manual té com a objectiu introduir conceptes avançats en l'ús del Clúster de Computació del Departament de Llenguatges i Sistemes Informàtics (LSI) de la Universitat Politècnica de Catalunya (UPC), gestionat pel Laboratori de Recerca i Desenvolupament (RDlab).

Array jobs

En cas de tenir una gran quantitat de treballs idèntics que enviar al clúster la única diferència dels quals siguin els paràmetres d'entrada, el recomanable en lloc d'enviar tots els treballs per separat és emprar els array jobs.

Els array jobs es caracteritzen per tenir tots el mateix identificador de treball (job_id) però diferent identificador de tasca (task_id). El format per especificar un array job és el següent:

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

task_id_inicial serà el task_id del primer treball, task_id_final el del darrer, i pas (opcional) la diferència entre els task_id dels treballs consecutius. Per exemple:

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

Executarà l'script render.sh amb paràmetres d'entrada data.in de manera que obtindrem un mateix job_ib y diferents task_id (2,4,6,8 y 10) per a cadascuna de les crides

És possible utilitzar el paràmetre task_id en l'script a executar, mitjançant el paràmetre $SGE_TASK_ID

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

En aquest exemple, el fitxer $HOME/myJob_params.txt conté els paràmetres d'entrada de l'script $HOME/myJob.sh. En cada línia conté els paràmetres de cada crida; la línia u, els paràmtres de la crida amb task-id=1, la línia dos, els de la crida amb task_id=2, i així successivament. La utilitat de sistema awk llegirà els paràmetres emprant el valor de $SGE_TASK_ID per a accedir a la línia que coincideix amb aquest valor, i deixarà aquests paràmetres en la variable PARAM. Finalment, passarem la variable PARAM a l'script que executarà el treball myJob.

Entorns d'execució paral·lels

Per a l'execució de treballs que necessitin emprar més d'un nucli de processador simultaneament és necessari utilitzar un entorn d'execució paral·lel. El clúster del RDlab ofereix la possibilitat d'usar dos entorns d'execució paral·lels: MPI (message-passing interface), basat en l'intercanvi simultani de missatges, i MAKE, basat en smp (symmetrical nultiprocessing).

A efectes pràctics, la diferència principal entre ambdós radica en el fet que MPI permet que els processos s'executin en diferents nodes, mentre que MAKE només permet la execució en paral·lel en nuclis del mateix node.

A més, l'entorn MPI requereix de treballs preparats explícitament per a l'ús d'aquest entorn, mentre que MAKE (SMP) permet que certs treballs (OpenMP, matlab, java, processos amb threads, etc) augmentin el seu rendiment al disposar de més nuclis d'execució.

qsub -pe <entorno> <num_cores>

Si volem que el nostre treball s'executi de forma paral·lela en 4 processadors en un entorn make, executarem:

qsub -pe make 4

Es pot combinar aquesta propietat amb el core binding de manera que l'entorn intenti reservar els 4 nodes de forma consecutiva:

qsub -binding linear:4 -pe make 4

Ejecución de trabajos MPI

El clúster permet l'execució de treballs MPI gràcies a la integració de OpenMPI amb el gestor de cues Grid Engine a través de l'entorn paral·lel "ompi". Les aplicacions MPI han de ser compilades amb la versió de OpenMPI del clúster, que resideix a /home/soft/openmpi.

Prèviament cal configurar l'accés ssh intranode sense password, ja que la interacció entre els diferents nodes del pool MPI es fa com a usuari via ssh:

ssh-keygen

Prémer return a les preguntes que es faran per generar claus sense passphrase

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

A continuació mostrem una plantilla d'un job script per a un treball típic MPI:

# Job d'exemple openmpi 
#
#
#
#$ -N job_name
#
# Use current working directory
#$ -cwd
#
# PARALLEL ENVIRONMENT:
# 
# Nombre d’slots a utilitzar (A l’exemple 1 master, 19 slaves)
#
#$ -pe ompi 20 
#
# Declaració de variables necessàries
#
PATH=/home/soft/openmpi/bin:${PATH}
LD_LIBRARY_PATH=/home/soft/openmpi/lib

# Executem comandes mpirun
mpirun -np $NSLOTS path_del_meu_proces_mpi
			

En aquest tipus de treballs dels límits de memòria (h_vmem) s'apliquen als diferents processos MPI de forma individual.

És possible veure en quins nodes s'executen els diferents processos del treball amb la comanda

qstat -g -t

Integració amb Hadoop

El clúster del RDlab ofereix també la possibilitat d'executar un entorn Hadoop. Per a tenir accés a aquest entorn cal demanar-ho a l'RDlab.

Dependències entre treballs

Les dependències entre treballs permeten endarrerir l'execució d'un treball fins que un altre treball així acabat. D'aquesta manera podem definir l'ordre d'execució dels treballs per assegurar les dependències que existeixin.

Per a fer-ho és necessari afegir el flag hold_jid i l'identificador de treball del que ha de dependre:

qsub -hold_jid <job_id>

En el cas concret dels array jobs, aquests poden dependre d'altres treballs, però les tasques no poden tenir dependències amb altres treballs o tasques.

Treballs interactius: qlogin

Fins aquest punt del manual s'ha mostrat com interactuar amb el clúster amb treballs en batch. Tanmateix, també és possible obrir un shell interactiu directament amb un node de computació, emprant la crida qlogin.

Aquesta sessió interactiva és útil en situacions on és necessari executar treballs amb entrada directa de l'usuari, en aplicacions amb finestres o en compilacions pesades.

qlogin -q short

NOTA: Cal destacar que aquest shell és un procés del clúster i per tant està limitat en recursos (memòria i temps d'execució).

La eina qlogin accepta els mateixos flags que la crida qsub, es troba subjecte a les mateixes restriccions, i només ens permetrà accedir a aquells nodes als que tenim accés. Els flags permeten especificar altres límits igual que amb qualsevol altre treball enviat mitjançant qsub o especificar a quin node ens volen connectar mitjançant el flag hostname:

qlogin -l hostname=node210,h_vmem=1G

En l'exemple anterior, establiríem connexió amb el node 210 sempre i quan aquest tingui 1GB de memòria lliure.

És necessari tenir en compte que, a diferència d'un treball batch, si les peticions de recursos no estan disponibles el treball no es posarà a la cua ni tampoc se'ns obrirà la sessió interactiva.

Afinitat: Core Binding

Entenem per core binding la fixació (bind) d'un treball a un processador concret. Per defecte, el clúster del RDlab fa servir aquesta propietat per a tots els processos d'usuari tal com s'ha descrit en la secció indicacions .

Tanmateix, és possible definir el flag binding per ajustar-lo a les necessitats concretes del nostre treball, associant aquest a tants nuclis com creiem convenient.

qsub -binding <binding_strategy>

La estratègia de binding que es pot utilitzar en el clúster pot ser linear o striding:

Amb linear el sistema intentarà associar el treball a tants nuclis consecutius como especifiquem.

qsub -binding linear:<num_cores>

Amb striding el sistema intentarà associar el treball a tants nuclis a una distancia step-size como especifiquem.

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

Execució en GPUs

Actualment el clúster del RDlab disposa de nodes de còmput amb targetes NVIDIA TESLA i GTX Titan. Aquestes targetes es troben en els nodes 800 i 801. Per obtenir dades sobre les targetes de cada node es pot executar la següent comanda al node:

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 |
+-------------------------------+----------------------+----------------------+

		    

La comanda, a més, mostra les dades relatives als processos en execució en les targetes

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

Per a usar el node és necessari enviar els treballs a una cua de nom gpu. Per a tenir-hi accés cal demanar-ho a l'RDlab. Es tracta d'una cua batch i interactiva, usable de la manera habitual.

IMPORTANT: Els usuaris amb accés a la cua GPU han d'indicar explícitament la cua (short, medium, long o GPU) en l'execució de qualsevol treball; altrament, un treball "normal" es podria executar en la cua GPU.

Per enviar un treball en batch:

qsub -q gpu ...

Per a una connexió interactiva:

qlogin -q gpu

Els jobs de la cua no tenen límit de temps, però sí un límit de 2GB de RAM per defecte, canviable de la manera habitual.