Cluster Quickstart

RDlab@lsi.upc.edu
February 2015

castellano Bienvenidos a LSI.

El siguiente manual tiene por objetivo servir de introducción para 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).

Introducción

Cuando hablamos de Clústers en el ámbito de la computación nos referimos al conjunto de hardware y software que aglutina grupos de ordenadores que, unidos mediante redes de alta velocidad, trabajan de forma conjunta en la resolución de problemas.

El clúster del departamento de LSI de la Universidad Politécnica de Cataluña se presenta como una potente herramienta de computación, gracias a su elevado número de procesadores, memoria y su extenso espacio de disco. Los nodos de ejecución se agrupan en grupos, llamados colas, que recogen los trabajos de los usuarios y gestionan su asignación.

Indicaciones

Es necesario tener en cuenta algunos parámetros por defecto a la hora de enviar trabajos a les colas del clúster.

El clúster se divide en 4 colas de ejecución. Cada cola está determinada por el tiempo máximo de ejecución de los procesos que ejecuta:

Short Cola dedicada a trabajos de un dia (24h) de duración como máximo.
Cola por defecto si no se especifica otra.
Medium Cola dedicada a trabajos de una setmana de duración como máximo.
Long Cola dedicada a trabajos que requieren una duración ilimitada.

Si no se especifica la duración del trabajo, este irá a la cola Short. Si un trabajo excede el tiempo máximo que permite la cola, éste será finalizado automáticamente.

IMPORTANTE: Se aconseja especificar la duración del trabajo (qsub -l h_rt=horas:minutos:segundos) para evitar que el sistema finalice la ejecución prematuramente.

Los usuarios también disponen de la cola Test que sirve para ejecutar pruebas de concepto de modo inmediato. Esta cola tiene nodos menos potentes, y por tanto, sólo ha de usarse para comprobar que los trabajos son correctos, y no para ejecuciones.

La memoria máxima por defecto que puede usar un trabajo es de 2 Gigabytes. Este valor es modificable por el usuario.

El número máximo de procesos en ejecución simultanea viene determinado por la cantidad de slots y memoria, que varían según el tipo de usuario. En caso de duda, contacte con el RDlab.

La configuración por defecto del clúster hace uso de la propiedad core binding. Dicha propiedad fija ("bind") cada trabajo a un núcleo de procesador. Esto garantiza que en ningún momento el trabajo será migrado a otro núcleo o procesador, ahorrando así el coste del cambio de contexto. Si se trata de un trabajo paralelo, el core binding lo fijará a tantos procesadores como se hayan reservado, con las mismas garantías.

Finalmente, la configuración del clúster define que a cada trabajo le corresponde exactamente un núcleo de procesador, lo que garantiza la exclusividad de uso del procesador por parte del proceso.

Conexión al clúster de computación en modo texto

Para conectarnos en modo texto (terminal o línea de comandos) en sistemas Unix necesitaremos un cliente de Secure Shell (SSH) instalado.
Desde el terminal, ejecutaremos el siguiente comando donde <username> es el nombre de usuario del departamento de LSI.

ssh <username>@logincluster.lsi.upc.edu

El sistema nos pedirá nuestra contraseña de usuario, y una vez introducida, ya estaremos dentro del sistema

Para entornos Windows, hemos de disponer de un cliente SSH como Putty u otros:
http://en.wikipedia.org/wiki/Comparison_of_SSH_clients

Conexión al clúster de computación en modo gráfico

En caso de querer usar un entorno gráfico en un sistema Unix y querer redireccionarlo podemos usar el flag -X:

ssh -X <username>@logincluster.lsi.upc.edu

O bien ejecutando la siguiente comando en nuestro ordenador:

xhost +logincluster.lsi.upc.edu

Entonces, una vez abierta la conexión remota la clúster, ejecutamos:

setenv DISPLAY <la_nostra_ip>

En sistemas Windows, si queremos soporte visual, es necesario redireccionar el servidor de X mediante un programa como Xwin32 o alternativas similares.

Configuración del entorno de usuario (path)

Ciertas aplicaciones de Grid Engine - el gestor de colas de trabajo - son dependientes de la arquitectura y requieren redefinir el path del sistema. Para hacerlo, modificaremos el fichero .tcshrc situado en nuestro home modificando la variable PATH:

set ARCH=`/usr/local/sge/util/arch`
set path=( /usr/local/sge/bin/${ARCH} $path)

Hemos de tener en cuenta que si tenemos alguna mención explícita a ejecutables de un tipo concreto, tendremos que eliminar la entrada del path

setenv PATH /usr/local/sge/bin/lx24-x86

Para hacer activo el cambio, es necesario cerrar la sesión y volver a logarse en el sistema.

Enviar trabajo en batch

Generalmente se pueden enviar a las colas todos los trabajos que puedan ser ejecutados manualmente desde la línea de comandos, siempre y cuando no requieran intervención interactiva. Usaremos el siguiente script, que se ejecuta durante 20 segundos, a modo de ejemplo:

simple.sh

You can find the following job in the file /sge-root/examples/jobs/simple.sh.
#!/bin/sh
#
#
# (c) 2004 Sun Microsystems, Inc. Use is subject to license terms.
# This is a simple example of a SGE batch script
# request Bourne shell as shell for job
#$ -S /bin/sh
#
# print date and time
date
# Sleep for 20 seconds
sleep 20
# print date and time again
date

Para poder ejecutar el script es necesario cambiar el permiso para que sea ejecutable (755 o solo tener permiso +x)

chmod +x simple.sh

Enviando el trabajo a la cola: qsub

Enviamos el trabajo a la cola mediante el comando:

qsub simple.sh

Si el trabajo ha sido enviado correctamente, veremos lo siguiente por pantalla:

your job 1 (“simple.sh”)
has been submitted

Algunos flags importantes

La llamada qsub, así como el propio cuerpo del script, permiten especificar flags (propiedades) que se tendrán en cuenta a la hora de ejecutar un trabajo. En caso de querer especificarlas en el momento de hacer la llamada, las añadiremos como parámetros de la llamada. Por ejemplo:

qsub -m bea -o output.txt simple.sh

Alternativamente, si los queremos especificar de forma permanente, lo haremos añadiéndolos al cuerpo del script de nuestro trabajo, del siguiente modo:

#$ -m bea
#$ -o output.txt

Algunos de los flags más importantes son

-e : Especifica donde se dejará el fichero con la salida en caso de error.

qsub -e error.txt simple.sh

-l: Permite indicar requisitos especiales para el trabajo (duración, memoria, etc.)
Para especificar una duración distinta a la definición por defecto:

qsub -l h_rt=horas:minutos:segundos

Si ejecutamos un trabajo que sabemos de durará menos que el tiempo por defecto, especificarlo en el momento de la llamada puede hacer que la prioridad del trabajo aumente respecto de otros con el valor por defecto; es decir, que sea ejecutado antes que los otros trabajos en espera con el valor por defecto.

Para especificar una cantidad de memoria distinta a la definición por defecto (actualmente 4Gb.):

qsub -l h_vmem=1G

NOTA: Si conoces la cantidad máxima de memoria que consumirá el trabajo, se recomienda especificarlo en el momento de la llamada con tal de agilizar la asignación de trabajos a los nodos.

-m : Permite especificar cuándo queremos recibir un correo: 'n'(none), 'a' (aborted), 'b' (begin), 'e' (end) , 's' (supended).

qsub -m bea simple.sh

Para usar este flag es necesario especificar la dirección donde queremos recibir el correo, mediante el flag -M:

qsub -M <email-address>

-o : Especifica dónde se dejará la salida del script

qsub -o output.txt simple.sh


-q : Indica la cola de ejecución.
Enviar el trabajo "simple.sh" a la cola short:

qsub -q short simple.sh

También permite enviar el trabajo a uno o varios nodos concretos.

qsub -q short@node112,short@node113 simple.sh

Indica que queremos que el trabajo se ejecute en la cola short en uno de los dos nodos indicados: node112 o node113.

-S : Especifica el shell intérprete a usar en la ejecución.

qsub -S /bin/sh simple.sh

Per a más información:

man qsub

Consulta el estado del trabajo en la cola: qstat

Cuando enviamos un trabajo a una de las colas de nodos, es posible que éste no se ejecute inmediatamente. El planificador analiza el estado del sistema para ejecutarlo en las mejores condiciones. Podemos consultar su estado mediante el siguiente comando:

qstat

El programa nos retorna la siguiente información:

job-ID prior name user state submit/start at queue slots ja-task-ID
------------------------------------- ------------------------------------------------------
000001 0.55000 simple.sh gabriel qw 10/14/2010 11:16:56 short@node112 1

Podemos ver solo nuestros trabajos con el flag -u e indicando nuestro username:

qstat -u <username>


Podemos obtener información extra de un trabajo con el flag -j e indicando el número de trabajo:

qstat -j <#job>

Obtendríamos una salida similar

qstat -j 000001
==============================================================
job_number:000001
exec_file:job_scripts/000001
submission_time:Fri Oct 15 13:42:05 2010
owner:gabriel
uid:64
group:staff
gid:50
sge_o_home:/home/usuarios/gabriel
sge_o_log_name:gabriel
sge_o_path:/usr/local/sge/bin/lx24-amd64:/usr/local/bin:/usr/bin:/bin
sge_o_shell:/bin/tcsh
sge_o_workdir:/home/usuarios/gabriel/prueba
sge_o_host:logincluster2
account:sge
hard resource_list:h_rt=604800,h_vmem=4G
mail_list:gabriel@logincluster2
notify:FALSE
job_name:simple.sh
jobshare:0
shell_list:NONE:/bin/sh
env_list:
script_file:simple.sh
usage 1:cpu=00:00:00, mem=0.00000 GBs, io=0.00000, vmem=N/A, maxvmem=N/A
scheduling info:queue instance "short@node112" dropped because it is disabled
queue instance "short@node113" dropped because it is disabled
queue instance "short@node114" dropped because it is disabled

Además, si el trabajo no se está ejecutando y permanece a la espera, adicionalmente informa del motivo por el cual todavía está en la cola. Si qstat no muestra ninguna salida, significa que no hay trabajos en espera ni en ejecución en el sistema, lo que puede querer decir que la ejecución de nuestro trabajo ha finalizado.

Eliminar el trabajo de la cola: qdel

Si queremos eliminar un trabajo que hemos enviado a una de las colas, lo podemos hacer mediante el siguiente comando:

qdel <#job>
user has deleted job 000001

NOTA: Para obtener el identificador del trabajo (#job) podemos ejecutar el comando qstat

Como debugar un trabajo

Si queremos saber si nuestro trabajo ha terminado correctamente, debemos mirar la información de accounting del trabajo y fijarnos en los campos exit status y failed. Para obtener la información de accounting de un trabajo ejecutamos:

qacct -g <job_id>

==============================================================
qnameshort
hostnamenode119
grouplsi
owner fgalindo
project NONE
department sistemas
jobnamesimple.sh
jobnumber3221295
taskidundefined
accountsge
priority0
qsub_timeFri Mar 14 12:13:07 2014
start_timeFri Mar 14 12:13:22 2014
end_time Fri Mar 14 12:13:22 2014
granted_peNONE
slots1
failed0
exit_status1
ru_wallclock0
ru_utime0.001
ru_stime0.008
ru_maxrss4244
ru_ixrss0
ru_ismrss0
ru_idrss0
ru_isrss0
ru_minflt1860
ru_majflt0
ru_nswap0
ru_inblock0
ru_oublock16
ru_msgsnd 0
ru_msgrcv 0
ru_nsignals0
ru_nvcsw15
ru_nivcsw1
cpu0.009
mem0.000
io0.000
iow0.000
maxvmem0.000
aridundefined

El campo failed indica el motivo por el cual un trabajo no ha podido ser ejecutado. Por otra parte, el campo exit status indica el código de salida del trabajo, siguiendo la convención normal de un shell.

En caso de error, el sistema suma 128 al código de salida. Por ejemplo si el trabajo muere por un SIGKILL (código 9), mostraría el código 137.

Si pedimos que el sistema nos envíe un correo cuando el trabajo ha terminado o ha sido abortado, también veremos información relevante:

Job 3240728 (simple.sh) Aborted
Exit Status      = 137
Signal           = KILL
User             = fgalindo
Queue            = short@node112
Host             = node112
Start Time       = 03/19/2014 12:32:33
End Time         = 03/19/2014 12:32:35
CPU              = 00:00:00
Max vmem         = 14.855M
failed assumedly after job because:
job 3240728.1 died through signal KILL (9)
			

Suspender y reanudar un trabajo: qmod

Si queremos dejar un trabajo en suspensión hasta que decidamos reanudarlo, ejecutaremos:

qmod -sj <#job>

Cuando queramos reanudar la ejecución, ejecutaremos:

qmod -usj <#job>

Archivos de salida del proceso ejecutado

Dado que los trabajos que enviamos no se ejecutan en modo interactivo, la salida estándar y la salida de error se redireccionan hacia ficheros.
Una vez el trabajo está en ejecución, por defecto nos deja la salida estándar y la salida de error en sendos ficheros en nuestro home de usuario, identificados por:

<nombre_del_trabajo>.o<id_del_trabajo>
<nombre_del_trabajo>.e<id_del_trabajo>

simple.sh.e000001  simple.sh.o000001

Asimismo, si queremos redirigir una (o ambas) salida(s) a alguna otra ubicación, lo podemos hacer, como ya hemos visto, mediante los flags siguientes:

-e : error
-o : output

Qmon

Qmon és un programa para entorno gráfico que ofrece una ventana de diálogo para enviar trabajos a las colas de ejecución y consultar aspectos del sistema. Podemos invocar Qmon con el siguiente comando:

qmon

Después de la pantalla de presentación, accederemos a la ventana de diálogo que nos permitirá escoger una de las opciones del programa.

qmon_main

Podemos encontrar más información de Qmon en:

Enlaces de interés

Información de los nodes y sus características: http://mastercluster1.lsi.upc.edu/info_nodes
Software de monitoritzación Ganglia: http://mastercluster1.lsi.upc.edu/ganglia