GUÍA DE USO

CLUSTER CICA

1. Esquema General
2. Conexión
3. Sistema de Colas
4. Compilación de aplicaciones
5. Aplicaciones disponibles
6. Almacenamiento compartido
7. Monitorización de tareas
 1. Esquema general

En CICA disponemos del siguiente esquema de computación:

A continuación detallamos las máquinas y el propósito general de cada una:

· devel.cica.es

Esta máquina, destinada a la compilación de las aplicaciones que el usuario

quiera tener en su /home, dispone de las librerías necesarias y compiladores
adecuados para este propósito.
Si el usuario necesita de alguna otra librería/aplicación, siempre puede solicitarlo
en el correo eciencia@cica.es .

En el apartado 5 se detallan las aplicaciones que dispone la máquina.

· pool.cica.es

Dicha máquina actúa como cabecera del gestor de colas del cluster Sun Grid
Engine (SGE). En esta máquina únicamente está permitido lanzar tareas al propio
de gestor de colas, así como su monitorización. La ejecución de cualquier otra
aplicación, compilación o tarea quedará terminantemente prohibida por motivos de
seguridad e integridad de la máquina.

Puede encontrar documentación acerca del gestor de colas SGE en nuestra

página http://eciencia.cica.es , dentro del apartado Espacio Colaborativo –
Documentación. Si tiene alguna duda sobre como crear scripts de ejecución para
SGE puede consultarnos en la dirección eciencia@cica.es .

· Cluster de computación

Actualmente disponemos de 90 máquinas dual core, junto con varios

servidores de memoria compartida y un cluster Bull con Infiniband como dispositivo
de comunicación entre los nodos.
En total se dispone de 512 cores y aproximadamente 700 GB de memoria
RAM disponible. Cada una de las máquinas está definida en una cola de ejecución
de SGE, por lo que en el proceso de alta debe indicarnos que tipo de ejecución
deseará realizar para dar los permisos adecuados. Puede consultar la
documentación relativa en nuestra página http://eciencia.cica.es .

· Sistema de Fichero Compartido Lustre

Lustre es un sistema de ficheros compartido, propiedad de Sun

Microsystems, que proporciona una gran escalabilidad y alto rendimiento. Está
especialmente optimizado para sistemas que manejen gran cantidad de volumen
de datos.
En la actualidad disponemos de 9.8 TB de almacenamiento, siendo visible
por todas las máquinas del cluster.
 2. Conexión

Para acceder a los recursos de supercomputación debe realizarse una

conexión ssh a la máquina correspondiente (pool.cica.es o devel.cica.es,
dependiendo del objetivo).

En los sistemas Linux, hay un cliente ssh integrado. Si desea realizar una
conexión desde un sistema Windows, recomendamos el uso de Putty o Tunnelier.

Para realizar una conexión:

> ssh usuario@pool.cica.es [devel.cica.es]

Una vez realizada la conexión le pedirá una contraseña de acceso.

En el caso que no se disponga de una IP estática, podemos proporcionar un

acceso a través de una máquina de salto. Para utilizar este servicio, debe
solicitarlo en la dirección de correo eciencia@cica.es .
 3. Sistema de Colas

Para utilizar los recursos de computación de CICA, tenemos disponible un

gestor de colas llamado Sun Grid Engine (SGE). Puede consultar toda la
documentación necesaria en la página de e-Ciencia: http://eciencia.cica.es, dentro
del apartado Espacio Colaborativo - Documentación.

En dicho sistema, dentro de la máquina pool.cica.es, hay configuradas 5

colas principales:

@eca_short: Servidores dual-core. En total hay 60 cpus, destinados a trabajos de

corta duración. Por lo tanto, esta cola se destinará a trabajos cuya duración
estimada sea inferior a 24 horas. En el caso que su duración sea mayor a este
límite, SGE parará automáticamente la tarea.

@eca: Cola por defecto del cluster CICA. Se dispone de aproximadamente 156
procesadores para tareas que requieran de paralelización y para una duración
estimada superior a 24 horas.

@smnodes: Servidores de memoria compartida. Se dispone de 2 unidades Sun

x4600, de 16 y 24 procesadores, junto a otros 2 servidores de 8 cores. En total se
dispone de 256 GB de memoria RAM disponible aproximadamente, destinadas a
tareas que requieran de una gran cantidad de memoria para su ejecución.

@ibnodes: Para la cola de ejecución en el cluster Bull. Para el uso de dicho cluster
debe solicitar permiso al departamento de Supercomputación, indicando que tipo
de ejecución va a realizar y el tiempo estimado de uso. Esta cola está orientada
principalmente a tareas que requieran de una gran velocidad de computación,
debido a la característica de sus procesadores y a su interconexión a través de
Infiniband.

Para la ejecución con SGE se necesita un script escrito en lenguaje Shell

(bash, csh, etc..). La única diferencia es una serie de opciones que se añaden en
el mismo script, todas comenzando con los caracteres “#$” .

Una vez que se tenga este script, puede lanzarlo desde la máquina
pool.cica.es:

> qsub script.sge

SGE automáticamente le asignará un identificador a la tarea. En este momento

podrá monitorizar el estado de la ejecución con los comandos adecuados:

> qstat -u usuario (Observar el estado de la tarea)

> qstat -g c (Observar el estado de las colas de ejecución)
> qdel id_tarea (Eliminar la tarea seleccionada)
 SGE asigna a cada tarea alguno de los recursos que estén libres en ese
momento. Es un proceso completamente transparente al usuario, los resultados de
la ejecución pueden verse desde cualquiera de las máquinas de acceso
(pool.cica.es / devel.cica.es).
Para transferir el resultado de la ejecución a su máquina local puede hacerlo con el
comando scp o con un cliente ftp.

> scp usuario@devel.cica.es:/home/usuario/resultado /home/directorio/local

Las opciones más comunes son las siguientes:

#$ -S shell : Shell por defecto que se utilizará en la ejecución de la tarea.

#$ -N nombre : Nombre que tomará la tarea, para poder identificarla.

#$ -wd /home/usuario/directorio : Directorio de trabajo que se tomará por defecto

en la ejecución de la tarea.

#$ -pe [mpi|mpi_slots|make|mpich|lam] n_slots : Entorno paralelo que se utilizará

en la ejecución de la tarea.

#$ -o salida.txt : Fichero de salida de la ejecución.

#$ -e error.txt: Fichero de error de la ejecución.

Ejemplo Script:

### ZONA DE OPCIONES. Se definen las opciones de SGE, como pueden ser el
## shell por defecto (-S), el nombre de la tarea, para su posterior identificación
## (-N), el directorio por defecto que tendrá para la ejecución (-wd), y la cola y el
## tipo de paralelización que tendrá (-q y -pe). Todas comienzan con #$:

#$ -S /bin/bash
#$ -N prueba
#$ -wd /home/usuario/
#$ -q eca
#$ -pe mpi_slots 8

## Cargamos los módulos de los compiladores de intel y openmpi:

. /etc/profile
module load cc_intel/9.1 fc_intel/9.1 openmpi-1.2.7/gnu mkl/9.0

## Realizamos la ejecución, utilizando el fichero de máquinas que SGE nos ha

asignado:

mpirun -n 8 -hostfile $TMP/machines /home/usuario/aplicacion

 4. Compilación de aplicaciones

Para este propósito, hemos configurado una máquina con todos los
compiladores y librerías necesarias para ejecutar aplicaciones en el cluster CICA.
Puede realizar una conexión a esta máquina con ssh:

> ssh usuario@devel.cica.es

pass:

Una vez dentro, tendrá acceso a todos los ficheros que disponga en el cluster,
debido a la compartición por Lustre de todos ellos. Puede compilar todas las
aplicaciones que considere necesarias, sin ninguna restricción. En el apartado 5
puede consultar las aplicaciones que ya tenemos precompiladas en el cluster, así
como su utilización.
Dentro de esta máquina se dispone de una utilidad llamada
“modules_environment”.
Con esta utilidad modificamos el entorno de usuario de forma dinámica, creando
variables de entorno y añadiendo rutas al PATH para que pueda ejecutarse
correctamente una aplicación dentro de una sesión.

Dentro de la máquina devel.cica.es, tenemos disponibles los compiladores y

librerías:

· GNU (4.1.2 y 4.3.2)

· Intel C/C++/Fortran Compilers (9.1 y 10.1)
· Java Compiler (1.6u14)

· Bull MPI
· OpenMPI
· LAM-MPI
· MPICHv2

· FFTW (2.1.5 y 3.1.2)

· HDF5
· MKL (9.0 y 10.1)
· NetCDF
· Jasper
· BLAS
· GotoBLAS
· Lapack

Si el usuario necesita alguna otra librería o compilador, puede ponerse en contacto

con el departamento de Supercomputación para instalar la aplicación que
considere.
 4.1 Modules Environment

Modules-environment es una utilidad liberada bajo licencia GPL, orientada a

la modificación dinámica de los entornos de ejecución. Con ella podremos
modificar las variables de entorno, PATHs y otros aspectos de forma sencilla.

Se han desarrollado varios módulos orientados a la ejecución con Intel

Compilers y bajo MPI. En estos momentos estamos desarrollando varios módulos
más con información para la ejecución de diversas aplicaciones como NAMD,
VMD, Gaussian y LAMMPS, entre otras.

A continuación muestro la información acerca de la utilidad:

1. Comandos básicos: module

Con este comando podremos ejecutar todas las opciones para la

modificación del entorno de ejecución. Las opciones son:

· module avail : Nos muestra información sobre los módulos que están
disponibles.
· module list: Nos informa de los módulos que están cargados en nuestro
entorno.
· module add module_name : Añade un módulo para poder utilizarlo.
· module rm module_name: Elimina el módulo correspondiente.
· module switch module_1 module_2 : Elimina el módulo_1 y añade el
módulo _2.

· module show|whatis module_name: Muestra información del módulo

concreto.

2. Uso de la aplicación

En estos momentos tenemos los siguientes módulos en el cluster:

[usuario@devel ~]# module avail

(..)

/opt/modules/modulefiles

BullMPI/7.1.4 cc_intel/9.1 mkl/10.1 modules use.own

LAM/7.1.4 dot mkl/9.0 null
R-2.8.1 fc_intel/10.1 module-cvs openmpi-1.2.7/intel
cc_intel/10.1 fc_intel/9.1 module-info oscar-modules/1.0.3(default)

(..)
 Al tener estos módulos cargados por defecto, al hacer login podemos ver los
módulos que efectivamente están cargados:

[usuario@devel ~]# module list

Currently Loaded Modulefiles:

1) oscar-modules/1.0.3 2) BullMPI/7.1.4 3) fc_intel/10.1 4) cc_intel/10.1
5) mkl/10.1

Si queremos añadir el entorno de ejecución necesario para la aplicación R-2.8.1:

[usuario@devel ~]# module add R-2.8.1

Si deseamos eliminar alguno de los módulos cargados:

[usuario@devel ~]# module rm fc_intel/10.1

[usuario@devel ~]# module list

Currently Loaded Modulefiles:

1) oscar-modules/1.0.3 2) BullMPI/7.1.4 3) cc_intel/10.1 4) mkl/10.1

Si deseamos cambiar los compiladores de Intel v.10 por los v.9 :

[usuario@devel ~]# module switch fc_intel/10.1 fc_intel/9.1

Podéis encontrar más documentación sobre las opciones de carga y descarga de

los módulos con man module o info module.

3. Integración con SGE

Modules puede ser utilizado junto con SGE. Tan sólo habría que incluir en el
script el comando:

. /etc/profile

A continuación se indicarían los módulos para ser cargados, tal y como se ha

mostrado anteriormente:

(..)

. /etc/profile
module load openmpi-1.3.2/intel cc_intel/10 fc_intel/10

(..)
 5. Aplicaciones Disponibles

En la página http://eciencia.cica.es dispone de una lista completa y

actualizada del software que disponemos, así como los manuales de uso de cada
uno de ellos.

6. Almacenamiento compartido

CICA dispone en los recursos de supercomputación un sistema de ficheros

compartido Lustre. Dicho sistema de fichero proporciona una gran escalabilidad y
usabilidad para gran cantidad de nodos (o clientes). Dicho sistema está en alta
disponibilidad, lo que, en caso de fallo, la recuperación del sistema es automática y
no compromete a la integridad de los ficheros que se encuentran en él.

Actualmente disponemos de 9.8 TB de almacenamiento, junto a

aproximadamente 5 GB de scratch local en cada nodo. Dicho directorio situado
en /scratch, puede ser usado por todos los usuarios para sus ejecuciones,
teniendo únicamente la restricción de los 5 GB comentados anteriormente, sin
posibilidad de backup.

Todos los nodos disponen de este sistema de ficheros situado en /home, por
lo que las carpetas de los usuarios serán visibles por todas las máquinas de
computación.
Por motivos de seguridad, recomendamos que se haga un chequeo
periódico de los ficheros de cada carpeta de usuario, eliminando aquellos que sean
más antiguos o no se vaya a hacer más uso de ellos.

No existe restricción en cuanto a la capacidad de cada carpeta de usuario,

aunque apelamos al sentido común, ya que al ser compartido por varias decenas
de usuarios investigadores, puede verse afectado al rendimiento cuando se tenga
más de 500 GB / por uno sólo de ellos.

Para cálculos que requieran de un espacio para ficheros temporales durante

su ejecución, también hemos habilitado una partición local en cada nodo, situada
en /scratch. Esta partición dispone de 5 GB, los cuáles pueden ser utilizados sin
ninguna restricción. El propio investigador, dentro del script de SGE, debe eliminar
estos ficheros temporales una vez que haya terminado la ejecución de su tarea.
 7. Monitorización de tareas

Una vez que la tarea esté en ejecución, disponemos de varios mecanismos

para monitorizar el estado de la tarea (memoria consumida, posibles errores, carga
de CPU utilizada..).

Para poder observar el estado general del cluster, está a disposición un

sistema de monitorización por Ganglia, dentro de la página:

http://cube.cica.es

En dicha página podemos ver el estado de todas las máquinas del cluster, así
como el uso que se hace de cada una de forma individual, pinchando en el nodo
correspondiente:
Dentro de cada uno de los apartados podemos ver la lista de nodos que
corresponden a cada cluster:

Ya dentro del nodo correspondiente, podemos ver el estado de la(s) CPU(s) y el

consumo de memoria actual, entre otros aspectos como red, procesos, etc...
 Otra forma de ver el estado de la tarea de forma individual, es a través del
comando qstat:

> qstat -j 10000

Ej:
==============================================================
job_number: 10000
exec_file: job_scripts/10000
submission_time: Mon Mar 15 08:10:36 2010
owner: user
uid: 1111
group: user
gid: 1111
sge_o_home: /home/user
sge_o_log_name: fsoler
sge_o_path: /var/sge/bin/lx24-
amd64:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/condor/sbin:/usr/local/condor/bin:/home/user/bin
sge_o_shell: /bin/bash
sge_o_workdir: /home/user/tarea
sge_o_host: pool
account: sge
cwd: /home/user/tarea
stderr_path_list: NONE:NONE:error.txt
mail_list: user@pool.hpc.cica.es
notify: FALSE
job_name: tarea
stdout_path_list: NONE:NONE:salida.txt
jobshare: 0
hard_queue_list: eca
shell_list: NONE:/bin/bash
env_list:
script_file: script.sge
usage 1: cpu=6:10:28:06,mem=220528.32584GBs,io=0.00000,vmem=812.219M,maxvmem=812.219M
scheduling info: (...)

En dicha salida podemos observar el consumo de CPU y memoria actual (campo

usage), las características definidas en el script de SGE, así como el PATH que
utilizará para la ejecución.