Tutorial de uso Solvay

Owned by Juan Jose Villaplana Querol
Last updated: Jul 23, 2021 by Julio Tena Fortanet

ANAR A LA  VERSIÓ EN VALENCIÀ

Introducción

El Servei d’Informàtica (SI) de la Universitat Jaume I (UJI) de Castellón es consciente de la criticidad de sus productos y servicios para la producción de la Universitat. Para no defraudar las expectativas, la UJI ha de disponer de una infraestructura TIC corporativa (infoestructura) escalable (i.e., que se adapte a los incrementos de la demanda) que soporte los procesos de la UJI en ciclo de producción continua (24x7x365), para lo que es necesario afianzar los atributos de la garantía de funcionamiento RAS de las TIC. Esto se ha convertido en una prioridad  para el SI, respondiendo a la demanda de los usuarios y a la criticidad de los procesos de producción de la UJI que las usan. La estrategia elegida por el SI para lograrlo sigue pasando por dotarse de la mejor infraestructura TIC posible [a la capacidad económica de la UJI] que asegure la calidad del servicio ofertado.

Infraestructura

Hardware

La facilidad corporativa actual de cálculo científico, adquirida en el marco de diferentes ampliaciones, está formada por un cluster PBS compuesto actualmente por los siguientes elementos:

  • Api: nodo central biprocesador adquirido en 2006 en la compra SU/30/06. (HP ProLiant DL360 G5, 2 Intel Xeon 5160 3 GHz, 14GB RAM, 5x60GB SATA). Este nodo central será sustituido por solvay en breve espacio de tiempo, aunque en estos momentos convivan los dos.
  • Solvay: nodo central biprocesador adquirido en 2011 en la compra SU/06/11 (Dell R710 con 2 Intel Xeon E5649 2.53GHz, 48 GB de RAM y 6x300 Gb SAS).
  • n1xx: 27 nodos biprocesador de doble núcleo x86_64 adquiridos en 2006 en la compra SU/30/06 (HP ProLiant DL360 G5, 2 Intel Xeon 5160 3 GHz, 14GB RAM, 5x60GB SATA).
  • n2xx: 11 nodos biprocesador con cuádruple núcleo x86_64 adquirido en 2009 en la compra SU/31/08. (chasis Blade HP c7000 que alberga 11 ProLiant BL460c con 2 Intel Xeon E5450 a 3 GHz quad core (ocho cores en total). Disponen de 32 GB de RAM y un espacio de scratch de 250 GB).
  • n301-n372: 72 nodos biprocesador ultradensos adquiridos en 2011 en la compra SU/06/11 (18 chasis Dell C6100 con 4 nodos cada uno, que disponen de 2 Intel Xeon E5649 2.53GHz, 48 GB de RAM y 2x500 Gb SATA).
  • n385-n399: 15 nodos biprocesador en 2 chasis HP SL6500. Nodos ProLiant SL170S G6 con 2 Intel Xeon X5670 a 2,93 GHz hexa core (12 cores en total por nodo). Disponen de 26 GB de RAM y un espacio de scratch de 1 TB.

Adicionalmente se dispone de un espacio de almacenamiento en una cabina EMC2 CX3-40c accesible por iSCSI que aporta unos recursos de almacenamiento adicional de 3 volúmenes de 2 TB destinados al HOME y directorios de scratch en los nodos centrales. Se realiza copia de seguridad del directorio HOME pero no de los scratch.

Todos los nodos disponen de tarjeta de red Ethernet a 1Gb/s y están conectados a switches a 1Gb/s. En el caso de los nodos n3xx, los switches están enlazados entre ellos a una velocidad de 10 Gb/s.

Software

Desde el SI se apuesta por el uso de software libre en todos los ámbitos y, por ello, se tiende a utilizar este tipo de software siempre que es posible. Por ello, el nodo central Api y los nodos n1xx y n2xx cuentas con un sistema operativo CentOS 4 de 64 bits y el siguiente software:

  • adf2009.01

  • charmm33b1

  • crystal98

  • crystal03

  • crystal06

  • crystal09

  • ekopath 4.0.10

  • Gaussian03
  • Gaussian09.b01

  • NAMD2.6

  • openmpi 1.4.2

  • orca 2.6

  • Python 2.5.5

  • R 2.9.0

  • ruby 1.9.1-p431

  • SNNS 4.3

  • spartan 08.131_26_int9e

  • vasp 5.2

En el caso del nodo central Solvay y los nodos n3xx se ha instalado un sistema operativo CentOS 6 de 64 bits con el siguiente software:

  • arpack

  • charmm29b1

  • charmm33b1

  • crystal09

  • FiPy 2.1.1

  • Gaussian03

  • Gaussian09.b01

  • gamess_us-2011R1

  • mpi4py 1.3

  • mpich2 1.4.1p1

  • namd 2.8

  • numpy 1.6.1

  • nwchem 6.0

  • orca 2.9

  • pysparse 1.1.1

  • R 2.14.1

  • ruby 1.9.3-p125
  • scipy 0.10.1
  • trilinos 10.10.1

  • vasp_5.2

Desde el Servicio de Informática (SI) estamos abiertos a la posibilidad de instalar nuevo software siempre que sea de tipo libre o que las personas o grupos interesados aporten el software, las licencias necesarias y las instrucciones de instalación.

Comenzando a utilizar el sistema de colas

Concepto

En el clúster de cálculo científico de la UJI se utiliza un sistema de colas para poder organizar el trabajo de cálculo en los diferentes nodos. Un sistema de colas permite que los usuarios definan los trabajos que quieren realizar para conseguir un cálculo y los envíen al sistema. Entonces el sistema revisa todos los trabajos pendientes, los nodos libres y los recursos que cada trabajo requiere para organizar el orden en el que se ejecutarán los diferentes trabajos de todos los usuarios atendiendo a criterios de uso compartido, eficiencia, recursos solicitados, etc.

El sistema de colas que se utiliza en los nodos centrales está basado en Torque y utiliza el planificador maui, ambos programas de software libre. En la actualidad, contamos con dos servicios de gestión de colas independientes y no conectados:

  • Api, como nodo central, que gestiona los nodos n1xx y n2xx. Este cluster se extinguirá poco a poco y los nodos irán migrándose al nuevo clúster de Solvay.
  • Solvay, como nodo central, que gestiona los nodos n3xx y, paulatinamente, los nodos n1xx y n2xx a medida que se vayan cambiando del clúster antiguo al nuevo.

Órdenes básicas

  • Para lanzar trabajos al sistema de colas la orden básica es qsub.

qsub mitrabajo.sh

  • El sistema de colas identifica el tipo de cola automáticamente a partir de los requisitos solicitados y redirige el trabajo a la cola genérica adecuada. En caso de querer lanzar el trabajo a una de las colas específicamente se puede usar el parámetro -q

qsub -q longq mitrabajo.sh

  • Para ver el estado de los trabajos en la cola y saber si están en ejecución (R, running)  o en espera (Q, queued) se utiliza la orden qstat. A continuación se puede ver un ejemplo de información devuelta por qstat

qstat

Job id                    Name             User            Time Use S Queue

5886.solvay             job.17            usuari          68:44:09  R shortq         

5892.solvay             job.21            usuari          68:44:09  R shortq         

5896.solvay             job.23            usuari          68:44:09  Q shortq         

5898.solvay             job.24            usuari          68:43:37  Q shortq       

5948.solvay             job.13            usuari          68:07:40  R qfaq          

  • Para eliminar un trabajo enviado al sistema de colas se usa la orden qdel y el identificador numérico del trabajo a cancelar

qdel 5898


Envío de trabajos

Parámetros de los trabajos

Existen diferentes parámetros que condicionan el tipo de nodos y la cola a la que se enrutan automáticamente los trabajos. Los parámetros más habituales son el número de cpus, el tiempo de cálculo y la memoria RAM requerida.

Para solicitar un parámetro en concreto se puede especificar en la línea de órdenes donde se manda el trabajo al sistema de colas mediante qsub o dentro del propio trabajo con un a sintaxis especial.

Los parámetros se indican así:

  • cput = XX:XX:XX     --> Indica el tiempo de cálculo que necesitamos
  • mem = XXMB o XXGB    --> Indica la cantidad de memoria total que requiere el trabajo
  • ncpus = X  --> Indica cuántos cores se requieren en un nodo para realizar el trabajo

Un ejemplo de trabajo que requiera 24 horas de cpu, 2 cores y 4 GBytes de memoria RAM sería así:

qsub -l cput=24:00:00 -l mem=4GB -l ncpus=2 mitrabajo.sh

También se puede incluir al principio del fichero del trabajo con una sintaxis especial:

#PBS -l cput=24:00:00

#PBS -l mem=4GB

#PBS -l ncpus=2

y lanzarlo con:

qsub mitrabajo.sh

Las colas del sistema

El sistema cuenta con diversas colas, que podrán ser utilizadas o no por los usuarios en función de su vinculación con la UJI o departamento. Las colas actualmente son las siguientes:

  • shortq: trabajos de hasta dos cores, con un máximo de tiempo de ejecución de 72 horas. Cada usuario puede ejecutar hasta 50 trabajos simultáneamente. Dispone de 480 cores.
  • longq: trabajos de hasta dos cores con un mínimo de 72 horas de ejecución. Cada usuario puede ejecutar hasta 20 trabajos simultáneamente. Dispone de 144 cores.
  • paralq: trabajos de un  mínimo de 4 cores en un único nodo. Cada usuario puede ejecutar hasta 6 trabajos simultáneamente. Dispone de 144 cores compartidos con la cola multiq.
  • multiq: trabajos de un mínimo de 2 nodos. Cada usuario puede ejecutar hasta 2 trabajos simultáneamente. Dispone de 144 cores compartidos con la cola paralq.
  • guestq: trabajos de usuarios invitados (grupo guest). Cada usuario puede ejecutar hasta 20 trabajos simultáneamente. Dispone de 96 cores.
  • qfaq: trabajos de usuarios del departamento qfa. Dispone de 120 cores.

Además existe una cola de enrutado especial que se encarga de enviar cada trabajo a la cola correspondiente (shortq, longq, paralq o guestq) en función de los recursos solicitados y el tipo de usuario.

Ejemplo de trabajo simple

Aquí se puede ver un ejemplo concreto de cómo lanzar un trabajo con ficheros de entrada y salida. Es un trabajo de un core, 1 GB de memoria RAM y 24 horas de cpu.

Dado un ejecutable llamado "prueba.sh" que está en el HOME de solvay.uji.es, dentro del directorio "prueba", con el siguiente código:

#!/bin/bash

wc -l datos1 > datos2
if [ $? -eq 0 ] ; then
    echo "Todo ha ido bien"
else
    echo "Revisa la salida de error"
fi

y el archivo "datos1" con el siguiente contenido

Línea 1
Línea 2

Para enviar el trabajo al sistema de colas, utilizaremos el script "mitrabajo.sh", con el siguiente código:

#!/bin/bash
#PBS -l cput=24:00:00
#PBS -l mem=1GB
#PBS -l ncpus=1

## ID del trabajo
ID="$(echo $PBS_JOBID | cut -d . -f 1)"

## Directorio de solvay.uji.es que contiene el programa (script, ejecutable...) y los archivos de entrada
MAIN="solvay:prueba"
## Lista de archivos de entrada (separados por espacios en blanco)
IN="prueba.sh datos1"
## Lista de archivos de salida (separados por espacios en blanco)
OUT="salida datos2"

## Directorio de trabajo en el nodo de ejecucion
SCR="/scratch1/$USER/scr-$ID"

## Cambiamos al directorio de trabajo
mkdir -p $SCR && cd $SCR
if [ $? -ne 0 ] ; then
    echo "No he podido cambiar al directorio '${SCR}'"
    exit 1
fi

## Copiamos los archivos de entrada
for archivo in $IN ; do
    scp -p "$MAIN/$archivo" .
    if [ $? -ne 0 ] ; then
        echo "No se ha podido copiar el archivo de entrada '$archivo'"
        exit 1
    fi
done

## Ejecutar programa
./prueba.sh > salida

## Copiamos archivos de salida
for archivo in $OUT ; do
    scp -p "$archivo" "$MAIN/$archivo-$ID"
    if [ $? -ne 0 ] ; then
        echo "No se ha podido copiar el archivo de salida '$archivo'"
        exit 1
    fi
done

## Eliminar directorio de trabajo
rm $IN $OUT && cd && rmdir $SCR
if [ $? -ne 0 ] ; then
    echo "No se ha podido eliminar el directorio de trabajo"
    echo
    ls -la $SCR
    exit 1
fi

exit 0

Finalmente, lo enviaremos al sistema de colas mediante la siguiente orden:

$ qsub mitrabajo.sh
2544244.solvay.uji.es

Una vez finalizada la ejecución del trabajo, comprobaremos el contenido de los archivos "mitrabajo.sh.e2544244" y "mitrabajo.sh.o2544244". Estos archivos los genera el sistema de colas.

En los archivos "salida-2544244" y "datos2-2544244", tendremos el resultado generado por el ejecutable "prueba.sh".

Trabajos multicore y multinodo

En aquellas ocasiones en las que se desea obtener un mejor rendimiento de los trabajos es preciso aplicar técnicas de cálculo en paralelo. El sistema de colas permite solicitar varios cores en un nodo con el recurso llamado "ncpus". Sin embargo, es difícil encontrar nodos con muchos cores libres o, en ocasiones, se desea utilizar más cores de los que un nodo puede tener y se debe aplicar una técnica de trabajo en paralelo entre varios nodos.  Para solicitar varios cores en diferentes nodos se utiliza la siguiente nomenclatura "nodes=X:ppn=Y" donde se solicitan X nodos con Y cores cada nodo. Por ejemplo, para pedir 2 nodos con cuatro cores cada uno (8 en total) se puede solicitar así:
qsub -l nodes=2:ppn=4 mitrabajo.sh
O añadiendo en el trabajo a enviar la línea al inicio:
#PBS -l nodes=2:ppn=4
Cuando se solicitan varios nodos existe una variable de entorno en los nodos asignados llamada PBS_NODEFILE que indica la ubicación de un fichero que contiene la información, por cada línea, de un core en un nodo de los asignados. Por ejemplo, una asignación de dos nodos con tres cores cada uno podría tener un fichero PBS_NODEFILE como el siguiente, indicando que se asignan tres cores del nodo n301 y tres cores del nodo n302, siendo el n301 el nodo principal donde lanzar el programa paralelo (el primero de la lista):
cat  $PBS_NODEFILE
n301
n301
n301
n302
n302
n302

Ejemplo de trabajo paralelo con MPI

En este ejemplo se solicitan 4 nodos con cuatro cores cada uno y se ejecuta, mediante MPI, el programa "hostname"

#!/bin/bash

#PBS -l cput=20:00:00
#PBS -l mem=1GB
#PBS -l ncpus=1
#PBS -l nodes=4:ppn=4

## ID del treball
ID="$(echo $PBS_JOBID | cut -d . -f 1)"

## Arxius d'entrada, d'eixida i temporals
## Servidor central:directori on es troben els arxius a copiar
MAIN="solvay:test_solvay"
## Arxius a copiar en format "arxiu1 arxiu2 arxiu3 .. arxiuN"
IN="prova.sh"
OUT="salida"

## Definicio del directori de scratch
SCR="/scratch1/$USER/scr-$ID"

## Ens possicionem en el directori de SCRATCH
mkdir -p $SCR && cd $SCR
if [ $? -ne 0 ] ; then
    echo "No puc situar-me en el directori de scratch"
    exit 1
fi

## Transferim els arxius d'entrada
for arxiu in $IN ; do
    scp -p $MAIN/$arxiu .
    if [ $? -ne 0 ] ; then
        echo "No he pogut copiar l'arxiu d'entrada '$arxiu'"
        exit 1
    fi
done

## Executar programa

mpiexec -wdir /scratch1/traverj -f $PBS_NODEFILE -n $( cat $PBS_NODEFILE | wc -l ) "hostname" > salida

## Transferim arxius eixida
for arxiu in $OUT ; do
    scp -p $arxiu $MAIN/$arxiu-$ID
    if [ $? -ne 0 ] ; then
        echo "No he pogut copiar l'arxiu d'eixida '$arxiu'"
        exit 1
    fi
done

## Eliminar directori temporal
rm $IN $OUT $TMP && cd && rmdir $SCR
if [ $? -ne 0 ] ; then
    echo "No he pogut eliminar el directori de scratch"
    echo
    ls -la $SCR
    exit 1
fi

exit 0