SGE

De i2basque

Contenido

Descripción de los cluster disponibles a través de Sun Grid Engine

Los clusters están físicamente distribuidos entre Vitoria, Donostia y Lejona. Todos los clusters están formados por máquinas Xeon con Hyperthreading, lo que permite ejecutar hasta dos procesos en cada procesador físico.

En Donostia se encuentran las máquinas que forman el cluster don y el multiprocesador multi0. Las máquinas de don son 8 biprocesadores Xeon de 32 bits con 2GB de memoria por nodo. multi0 es un SMP de 4 procesadores Xeon de 32 bits con 16GB de memoria, capaz de ejecutar procesos paralelos que usen hasta 8 slots debido a que los procesadores tienen Hyperthreading, aunque es preferible ejecutar un proceso por procesador, dando un total de 4 procesos simultáneos, y ejecutar 8 procesos simultáneos aprovechando el Hyperthreading sólo en casos estrictamente necesarios y para realizar experimentación, ya que puede ser contraproducente con respecto del rendimiento dependiendo del tipo de aplicación ejecutado.

En Lejona está el cluster lej formado por 8 máquinas biprocesadoras Xeon de 64 bits (EM64T) con 4 GB de memoria por nodo.

En Vitoria se encuentra el cluster vit formado por 8 máquinas biprocesadoras Xeon de 64 bits (EM64T) con 4 GB de memoria por nodo.

Las colas de Sun Grid Engine (SGE) que se refieren a estos clusters son:

don formado por las máquinas del cluster don exceptuando al frontend (don1-don7). Trabajos 32 bits.

lej formada por las máquinas del cluster lej (lej1-lej8). Trabajos 64 bits.

vit formada por las máquinas del cluster vit (vit1-vit8). Trabajos 64 bits.

multi formada por la máquina multi0. Trabajos 32 bits.

32 formada por las máquinas del cluster don, incluyendo el frontend (don1-don7, fe). Trabajos 32 bits.

64 formada por las máquinas de los clusters lej y vit (lej1-lej8, vit1-vit8). Trabajos 64 bits.

Introducción a Sun Grid Engine (SGE)

Sun Grid Engine es un sistema de colas que permite gestionar el envío de trabajos, orden de ejecución y reglas de uso en un conjunto de ordenadores o clusters. Permite la ejecución remota de trabajos tanto batch (procesos por lotes) o interactivos y ver el estado actual de los trabajos enviados, así como modificarlos o borrarlos.

Los comandos básicos para controlar el sistema de colas son:

  • qconf: Permite al administrador añadir, borrar y modificar la configuración de SGE, incluyendo la gestión de las colas, la hosts, variables del sistema y usuarios. También permite ver la configuración de las colas existentes.
qconf -sql        #Muestra una lista de las colas configuradas.
qconf -sq {queue} #Muestra la configuración de la cola indicada


Configuración de inicio para los usuarios del sistema

Para que se inicien correctamente varias variables de entorno del sistema correspondientes al sistema de colas se debe ejecutar antes de usar cualquier comando correspondiente a SGE el siguiente script que ya está incluido en el arranque de los usuarios del Grid.

source /opt/sge/default/common/settings.sh

Asímismo para ejecutar la interfaz gráfica de monitorización y gestión del sistema de colas (qmon), hay que ejecutarlo de la siguiente manera:

env LD_LIBRARY_PATH=/opt/sge/libmotif2/usr/X11R6/lib/:$SGE_ROOT/lib/lx24-amd64 qmon

este cambio también está previsto entre los scripts de inicio de sesión de los usuarios, con lo que basta con hacer qmon para ejecutarlo.

Envío de trabajos al sistema de colas

Se pueden enviar trabajos al sistema de colas o bien usando el comando qsub, que es lo más habitual, o bien mediante la interfraz gráfica del sistema, qmon. Por ejemplo:

qsub trabajo1.sh

Si se envía correctamente al sistema de colas el sistema devolverá el siguiente mensaje:

your job 1 (``trabajo1.sh) has been submitted.

Los trabajos que se envían son siempre scripts con diferentes opciones que invocan al trabajo en sí. A continuación pondremos varios ejemplos detrabajos reales que se ejecutan en el sistema y los explicaremos.

Trabajos paralelos MPI

Este ejemplo sirve para lanzar el programa CPMD (cálculo de dinámica molecular) versión de 64 bits que usa MPI y OpenMP en 16 procesos de un hilo de ejecución cada uno (16 procesos MPI y uno OpenMP), en la cola de 64 bits vit.

#!/bin/bash

# SGE variables

# Shell used to run the task on SGE
#$ -S /bin/bash 

# Name of the job
#$ -N cpmd64-al.5

# Specifies whether or not the standard error stream of the job 
# is merged into the standard output stream
#$ -j y

# SGE Environment Variables:
# HOME  Home directory on execution machine
# USER  User ID of job owner
# JOB_ID  Current job ID
# JOB_NAME  Current job name; see the -N option
# HOSTNAME  Name of the execution host
# TASK_ID  Array job task index number 

# Path where will be stored output (-o option)
# and error files (opcion -e)
#$ -o $JOB_NAME.$JOB_ID.$TASK_ID

# With this option error and output files are stored in the 
# directory from where the job is submitted using qsub
#$ -cwd

# E-mail address where the status of the job will be send
#$ -M franciscojavier.ridruejo@ehu.es

# When an email is sent to inform the user about the status of
# a job: -m e (end of a job), -m b (before of a job)
#$ -m be

# If the job is parallel, we indicate what kind of environment
# we use mpich for MPICH jobs or openmp for OPENMP jobs
# and the number of processes to use
#$ -pe mpich 16

# Request a maximum of 12 hours of execution time
# This parameter is commented because a real execution of CPMD lasts much more
##$ -l h_rt=12:00:00 

# Request 1GB of RAM memory for the execution
#$ -l vf=1G

# Multiple jobs to execute from-to:step
# In this example only one job
#$ -t 1-1:1

# Which queues to use?
# There are multiple queues in the system:
# 32: queue for 32 bit jobs
# 64: queue for 64 bit jobs
# don: queue of Donostia (32 bit cluster)
# lej: queue of Lejona (64 bit cluster)
# vit: queue of Vitoria (64 bit cluster)
# multi: queue of Multi (4-way 32 bit SMP) 
#$ -q vit

# With the -V option all environment variables are exported
# to SGE but using -v only the specified variable is exported
#$ -v OMP_NUM_THREADS=1
echo Running on host $HOSTNAME
echo Directory is `pwd`
ORIG_DIR=`pwd`

# create temporary directory to copy input and support files later
TEMP_DIR=/var/tmp/`whoami`.$$
echo TEMP_DIR es $TEMP_DIR
mkdir $TEMP_DIR
cat $TMPDIR

# Variables needed to run the job 
MPIRUN=/opt/mpich-cpmd64/bin/mpirun
MACHINEFILE=./machines.LINUX.vit
INPUT_FILE=./alcl3.64ur-H-d_ur-growth.in
OUTPUT_FILE=./alcl3.64ur-H-d_ur-growth.out
AUXILIAR_FILES="*.uspp RESTART* LATEST"
PPDIR=$TEMP_DIR
BINDIR=/opt/mpich-cpmd64/bin

# copy input and support files to a temporary directory on compute node
cp $INPUT_FILE $AUXILIAR_FILES $MACHINEFILE $TEMP_DIR
cd $TEMP_DIR
#source /opt/intel64/fce/9.0/bin/ifortvars.sh
echo This job has allocated $NSLOTS processors
echo Init time is `date`

$MPIRUN -v -machinefile $TMPDIR/machines -np $NSLOTS \
	$BINDIR/cpmd64.x $INPUT_FILE > $OUTPUT_FILE

echo End time is `date`

# copy files back and clean up
cp * $ORIG_DIR
rm -rf $TEMP_DIR

Después de la ejecución del trabajo se obtendrán dos ficheros, uno como resultado de la ejecución del propio trabajo y llamado ./alcl3.64ur-H-d_ur-growth.out ($OUTPUT_FILE) y otro llamado cpmd64-al.5.700.1, por ejemplo, siendo ese nombre el resultado de la expresión $JOB_NAME.$JOB_ID.$TASK_ID que es el nombre del trabajo especificada como la opción -N, el identificador del trabajo en el sistema, que en este caso le ha dado el número consecutivo 700, y el 1 como número de tarea dentro del trabajo dado por la opción -t, y que en este caso como sólo hay una (-t 1-1:1), pues sólo escribe un fichero como resultado de la ejecución. Si hubiesen N tareas habría N ficheros resultado, uno por cada tarea, y con un sufijo que iría desde 1 a N.

El fichero resultado (cpmd64-al.5.700.1) es la mezcla tanto de la salida estándar como de la salida de errores, debido a que hemos especificado la opción -j y que indica que se mezclen ambas salidas.

En este script también se copian todos los ficheros necesarios para la ejecución del trabajo a un directorio en la máquina donde se ejecute este, para que no se lea y escriba todo el rato usando NFS (los trabajos suponemos que selanzan desde los directorios de losusuarios que están en un servidor de alamcenamiento montado por NFS) que conlleva un trasiego importante de información por red y por tanto una pérdida de rendimiento. Una vez acabado el trabajo se vuelven a copiar los ficheros de entrada y el resultado al directorio donde se lanzó el trabajo.

Este script está guardado como plantilla en el directorio /opt/sge/examples/jobs/paralelo_MPI.sh

Trabajos paralelos mixtos MPI y OpenMP

Para que en el script anterior se ejecutara el mismo trabajo MPI pero con dos hilos de ejecución OpenMP bastaría con modificar una línea:

#$ -v OMP_NUM_THREADS=1 por  #$ -v OMP_NUM_THREADS=2 

Trabajos paralelos OpenMP

Si quisiéramos ejecutar el mismo script en el multiprocesador multi0 sin MPI y con 8 procesadores usando OpenMP con 8 hilos de ejecución habría que cambiar la línea donde se especifica que es un trabajo MPI:

#$ -pe mpich 16 por #$ -pe openmp 8

Modificar la línea donde se especifican el número de threads OpenMP:

#$ -v OMP_NUM_THREADS=1 por  #$ -v OMP_NUM_THREADS=8

Cambiar la cola de ejecución ya que el multi0 tiene su propia cola llamada multi:

#$ -q multi

Y por último modificar los ejecutables a utilizar por los equivalentes para los nodos de 32 bits, ya que multi0 es un SMP de 32 bits.

Trabajos no paralelos múltiples

Este ejemplo consiste en lanzar un mismo trabajo pero con 10 parámetros diferentes, o sea 10 tareas para un mismo trabajo. El trabajo es un programa java que se lanza en una cola de 64 bits, vit, y para especificar que son 10 tareas se usa el parámetro -t 1-10:1

Este ejemplo ha comentado las líneas referentes al uso de MPI, y al uso de OpenMP, ya que no es un trabajo paralelo. Usa java de 64 bits.

Este script está guardado cono plantilla en el directorio /opt/sge/examples/jobs/no_paralelo_multiple.sh

#!/bin/bash

# SGE variables

# Shell used to run the task on SGE
#$ -S /bin/bash

# Name of the job
#$ -N java_vehicle_0_5_10I

# Specifies whether or not the standard error stream of the job 
# is merged into the standard output stream
#$ -j y

# SGE Environment Variables:
# HOME  Home directory on execution machine
# USER  User ID of job owner
# JOB_ID  Current job ID
# JOB_NAME  Current job name; see the -N option
# HOSTNAME  Name of the execution host
# TASK_ID  Array job task index number


# Path where will be stored output (-o option)
# and error files (opcion -e)
#$ -o $JOB_NAME.$JOB_ID.$TASK_ID

# With this option error and output files are stored in the 
# directory from where the job is submitted using qsub
#$ -cwd

# If the job is parallel, we indicate what kind of environment
# we use mpich for MPICH jobs or openmp for OPENMP jobs
# and the number of processes to use
# This parameter is comented because this is not a parallel job
##$ -pe mpich 16

# Request a maximum of 25 hours of execution time
#$ -l h_rt=25:00:00

# Request 1GB of RAM memory for the execution
#$ -l vf=256M

# Multiple jobs to execute from-to:step
# In this example ten jobs
#$ -t 1-10:1

# Which queues to use?
# There are multiple queues in the system:
# 32: queue for 32 bit jobs
# 64: queue for 64 bit jobs
# don: queue of Donostia (32 bit cluster)
# lej: queue of Lejona (64 bit cluster)
# vit: queue of Vitoria (64 bit cluster)
# multi: queue of Multi (4-way 32 bit SMP) 
#$ -q lej

# With the -V option all environment variables are exported
# to SGE but using -v only the specified variable is exported
# This job is not OpenMP
##$ -v OMP_NUM_THREADS=1

echo Running on host $HOSTNAME
echo Directory is `pwd`
ORIG_DIR=`pwd`

# create temporary directory to copy input and support files later
TEMP_DIR=/var/tmp/`whoami`.$$
echo TEMP_DIR es $TEMP_DIR
mkdir $TEMP_DIR
echo TMPDIR es $TMPDIR

# Variables needed to run the job 
DATA_FILE="vehicle_TRAIN_0_5.dbc vehicle_TEST_0_5.dbc"
BIN_FILES="elvira/ weka/"
INPUT_FILE="vehicle_TRAIN_0_5.dbc vehicle_TRAIN_0_5D.dbc"
OUTPUT_FILE="vehicle_0_5_01.log"
AUXILIAR_FILES="vehicle_TEST_0_5.dbc vehicle_TEST_0_5D.dbc"
BIN=/opt/java64/bin/java

# copy input and support files to a temporary directory on compute node
cp -R $BIN_FILES $DATA_FILE $TEMP_DIR
cd $TEMP_DIR

echo Init time is `date`

$BIN elvira.learning.preprocessing.Discretization $INPUT_FILE  5 2 true $AUXILIAR_FILES > vehicle_0_5_$SGE_TASK_ID.log

echo End time is `date`

# copy files back and clean up
cp * $ORIG_DIR
rm -rf $TEMP_DIR

En este otro ejemplo pueden verse cómo varían los parámetros para cada una de las 3 tareas del trabajo que tiene pámetros diferentes para cada una. En este ejemplo también se han quitado todas las variables no relevantes, y no se copian los ficheros de entrada a un directorio de la máquina, ya que el trabajo no hace un uso intensivo del disco duro. Este trabajo se lanza indistintamente en las colas de 32 y de 64 bits, ya que usa un programa de 32 bits que funciona en las plataformas de 32 y 64 bits.

#!/bin/bash
#$ -S /bin/bash
#$ -t 1-3:1
#$ -cwd
#$ -j y
#$ -o uniform.$TASK_ID
#$ -q 64,32
args=(0 "bub_to_adap=0 intransit_pr=0" "bub_to_adap=3 intransit_pr=0" 
"bub_to_adap=0 intransit_pr=1")
./fsin ${args[$SGE_TASK_ID]} tpattern=uniform shotmode=1

Este script está guardado cono plantilla en el directorio /opt/sge/examples/jobs/no_paralelo_multiple_array_argumentos.sh

Control del trabajo

El control de trabajos engloba la modificación de algún parámetro SGE del trabajo, el borrado y la suspensión-reanudación manual por parte del usuario. Para la modificación de un trabajo, este ha de estar en estado “pendiente” y no haber pasado a ejecución. Para ello ejecutar:

qalter <id-trabajo> <parametro-a-modificar> ...

Donde id-trabajo es el número del trabajo tal como informa qsub al mandarlo, o qstat cuando se consulta su estado. Para más información, acceder al manual de qalter (man).

Para la suspensión-reanudación de un trabajo en ejecución-suspensión, ejecutaremos:

Suspensión: qmod -sj <id-trabajo>
Reanudación: qmod -usj <id-trabajo>

Para el replanificación del trabajo, ejecutar: qmod -rj <id-trabajo> (Requiere privilegios de Administrador) Para eliminar un trabajo del sistema (matando sus procesos), ejecutar: qdel <id-trabajo>

Monitorización del trabajo

Monitorización del trabajo Podemos monitorizar los estados de los trabajos que mantenemos en el sistema de colas, los recursos que consumen y el estado de las máquinas, averiguar en determinados casos porqué el trabajo no entra en ejecución o muere. Para ello se utiliza el comando qstat cuyos usos principales son:

qstat: Muestra el estado de todos los trabajos sin tener en cuenta el estado de las colas.
qstat -u <nombre-usuario>: Monitorización del estado de los trabajos de un usuario.
qstat -f: Lista toda la información sobre trabajos y colas para todos los usuarios.
qstat -F: Muestra el estado de todos los parámetros de todas las colas, por ejemplo, la carga, uso de memoria, swap, etc.
qstat -j <id-trabajo>: Da la razón de por qué un trabajo pendiente no ha sido planificado.

Para más información sobre qstat consultar las páginas del manual (man qstat).

Políticas de control

A continuación describimos las políticas de uso que hay implemntadas en el gestor de colas. Estas políticas pueden ser cambiadas en cualquier momento. Consulten esta página para comprobar actualizaciones.

  • Actualmente no hay ningún límite de tiempo en las colas para la ejecución de trabajos, ya que hay al menos un usuario que tarda semanas para terminar un trabajo. Esto es probable que cambie en el futuro, según las necesidades del momento. De todas maneras es conveniente que se especifique si se tiene el tiempo de ejecución del trabajo estimado para ayudar al planificador a calcular los recursos disponibles y su óptima ejecución:
#$ -l h_rt=12:00:00

De esta manera se reservan 12 horas de ejecución.

  • No hay un límite en el número de procesadores a utilizar, aunque como se ha comentado, al estar compuesto el Grid de varios clusters distribuidos, no conviene utilizar diferentes clusters a la vez para trabajos paralelos, ya que la comunicación paralela será un importante cuello de botella al estar físicamente separados los clusters por unos 100 km. de media.
  • El límite de memoria es de 2GB para trabajos que vayan a la cola don, y de 4 GB para lej y vit, mientras que para la multi es de 16GB. Para especificar la memoria que necesita el trabajo usar:
#$ -l vf=256M (Este trabajo necesita 256MB)
  • Los procesos paralelos tienen mayor priridad por defecto que los trabajos en serie. esto es para incentivar el envío de trabajos paralelos a los clusters. Para comprobar la memoria disponible por cada nodo usar el comando:
qhost -F mem_free

Para ver la lista de los nodos que pueden atender un trabajo que requiera 1G de memoria hacer:

qhost -l mem_free=1G
  • Se puede reservar uno o todos los clusters para trabajos puntuales bajo petición expresa, si es bajo la expresa aprobación de i2BASQUE. Para solicitar una reserva contactar con i2BASQUE.
  • La cola lej en este momento es pública pero tiene una reserva hecha por el usuario isg. De manera que si hubiese alguien utilizando esa cola, y dicho usuario mandase un trabajo a la misma, el o los trabajos que estuviesen ejecutando en dicha cola automáticamente entrarían en suspensión y se empezaría a ejecutar el trabajo del usuario isg. Una vez acabado el trabajo, seguiría ejecutándose el o los trabajos suspendidos.

Para que el usuario isg pueda ejercer dicho privilegio, es decir, el de suspender los trabajos que se estén ejecutando en la cola que ha reservado, basta con que mande su trabajo de la siguiente manera:

qsub -l im trabajo.sh

Referencias


Volver a Manual GRID de i2BASQUE

Herramientas personales
Otros idiomas