wiki:WikiStart

INFRAESTRUCTURA DE SUPERCOMPUTACIÓN EN EL CICA

1. INTRODUCCIÓN

El CICA pone a disposición de los usuarios de las Universidades y centros públicos de investigación en Andalucía un cluster de Supercomputación con las siguientes características:

  • 680 cores de cálculo
  • 2 TB de memoria
  • 6,2 TFlops de potencia de cálculo
  • 13 TB de almacenamiento en un sistema de ficheros LustreFS
  • 32 nodos (256 cores) de cálculo conectados por Infiniband DDR a 20Gbit/seg.
  • SGE (Sun Grid Engine) como sistema de colas
  • Sistema operativo CentOS Linux 7.3

2. REQUISITOS Y SOLICITUD DE ACCESO AL CLUSTER

Aquel investigador que desee usar la infraestructura de Supercomputación de CICA debe cumplir los siguientes requisitos:

La información del formulario de registro le llegará al equipo de supercomputación de CICA y este se pondrá en contacto con el investigador para darle el alta en los servicios.

3. MÉTODO DE TRABAJO EN EL CLUSTER

Cuando un usuario quiere calcular en el cluster debe ejecutar sus programas de forma que no entorpezcan lo que otros usuarios estén haciendo. Por tanto, el usuario no pone en marcha directamente sus programas sino que los ejecuta a través de un sistema de colas que es quien se encargará buscar los ordenadores necesarios para ejecutar el programa esperando, si hace falta, que los recursos de cálculo necesarios estén libres. Una vez esos recursos estén libres, lanzará el programa en nombre del usuario y controlará su ejecución.

Para comunicarse con el gestor de colas, el usuario escribe un fichero con las instruciones necesarias para ejecutar el programa y se lo entrega al gestor. El usuario no tiene que permanecer conectado al cluster mientras los trabajos se ejecutan.

En el cluster hay diferentes máquinas a las que los usuarios pueden acceder dependiendo de qué deseen hacer: así tenemos el nodo de entrada de los usuarios (sesamo.cica.es), la máquina para desarrollo y compilación de los programas que los usuarios quieran ejecutar (devel.hpc.cica.es) y la máquina en la que reside el gestor de colas (pool.hpc.cica.es)

Para conectarse al cluster de CICA sólo hay un punto de entrada: la máquina sesamo. Por tanto lo primero que el usuario tiene que hacer es conectarse por ssh (si trabaja con Linux) o por Putty (en Windows) a sesamo.cica.es:

ssh usuario@sesamo.cica.es

Una vez dentro, saltaremos a los nodos devel.hpc.cica.es (para compilar nuestros propios programas) o pool.hpc.cica.es (para lanzar trabajos).

En el servidor sesamo ya hay acceso directo a los datos que el usuario tenga en el cluster (/home), de forma que no son necesarias transferencias de ficheros dentro del cluster. Por ejemplo, los resultados de una compilación en devel automáticamente estarán también en pool, sesamo, etc.

Aquí hay un videotutorial disponible

3.1 Esquema de colas

Lo más importante para lanzar trabajos en el cluster es saber qué colas hay y para qué se usan.

Las colas se subdividen en tres contenedores:

  • simple: Para lanzar trabajos que no necesitan más de un procesador.
  • multicore: Para lanzar trabajos que requieran más potencia y más de un core.
  • mpi: Para lanzar trabajos que utilicen librerías mpi.

Cada uno de estos tres contenedores se subdivide en 4 colas específicas ordenadas por duración: diaria (estimación de trabajos de un día como máximo), corta (duración máxima de 3 días), media (duración máxima de 1 semana), larga (duración máxima de 1 mes). Si cualquier investigador necesita lanzar un trabajo de mayor duración deberá ponerse en contacto con el departamento de supercomputación a través de la dirección de correo eciencia@cica.es .

De esta forma, los nombres de las colas habilitadas son, según su propósito:

  • Programas que NO necesitan multihilo ni proceso distribuido: diaria_simple, corta_simple, media_simple, larga_simple.
  • Programas multihilo o que necesiten mucha memoria (a partir de 4GB): diaria_multicore, corta_multicore, media_multicore, larga_multicore.
  • Programas de proceso distribuido que usen MPI: diaria_mpi, corta_mpi, media_mpi, larga_mpi.
  • Trabajos de larga duración: longtime (se requiere autorización específica para poner trabajos en esta cola)

El usuario debe intentar poner el trabajo en la cola de menor duración posible porque así se asegura menos tiempo esperando en cola.

3.2 Creación del fichero para el sistema de colas

Para lanzar cualquier trabajo al cluster hay que crear un pequeño script donde configurar los parámetros necesarios para el entorno y las colas.

Aquí tiene un completo tutorial sobre cómo escribir esos scripts. No deje de leerlo si no ha trabajado nunca con SGE.

Recomendamos a todos los usuarios que usen la partición /scratch como lugar donde colocar o generar ficheros durante sus cálculos. Les recordamos que el $HOME del usuario se monta a través de red en todos los nodos, por lo que el acceso a datos es más lento que la propia partición de /scratch, que es local para cada nodo. Entonces, el proceso a seguir por cada usuario sería copiar los ficheros que necesite al /scratch de los nodos, crear allí los ficheros de salida, y al final de la ejecución del script copiar los ficheros que necesite a su $HOME para que vuelva a tenerlos accesibles en toda la red, y no sólo en el nodo en el que los ha lanzado.

Como recomendación final, y para que todos los usuarios del cluster tengan un uso correcto del servicio, les pedimos que borren los ficheros que no necesiten de la partición de /scratch, para evitar que se llene.

Vamos a ver un ejemplo más elaborado, que hace uso de la partición /scratch:

Supongamos que quiero ejecutar un programa escrito en lenguaje R. En la máquina pool editamos un fichero que llamaremos R-prueba.sge con el siguiente contenido:

#$ -S /bin/bash
#$ -N R-prueba
#$ -wd /home/heisenberg
#$ -o R-prueba.salida
#$ -e R-prueba.err
#$ -q diaria_multicore
#$ -pe smp 2-8
#$ -l virtual_free=8G
#
# Copio el fichero de entrada a un subdirectorio mio en /scratch
mkdir -p /scratch/heisenberg/R-prueba
cp R-benchmark-25.R /scratch/heisenberg/R-prueba
# Ahora que he preparado el entorno de trabajo
# en el nodo en el que se va a ejecutar mi programa, lo lanzo
#
export OMP_NUM_THREADS=$NSLOTS
module load R
R --slave --no-save < /scratch/heisenberg/R-prueba/R-benchmark-25.R
#
# Limpio el scratch
# Si el proceso hubiese dejado ficheros de salida que me interesan
# los copio antes a mi /home:
# cp /scratch/heisenberg/R-prueba/algun-fichero-de-salida /home/heisenberg/...
rm -rf /scratch/heisenberg/R-prueba

Se lo entregamos al sistema de colas del cluster con el comando:

qsub R-prueba.sge

Una vez lanzado, podemos ver su estado con:

qstat

Que nos mostrará el estado de todos los trabajos del usuario heisenberg.

La salida del comando anterior será algo así:

job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID 
-----------------------------------------------------------------------------------------------------------------
    513 0,00000 R-prueba   heisenberg       qw    09/30/2013 16:06:53                                    1        

La columna state con valor qw nos dice que el trabajo está esperando que se encuentre un nodo de cálculo libre para ejecutar el trabajo.

Cuando el sistema de colas encuentra una máquina libre y le envía el trabajo para su ejecución, la salida de qstat será:

job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID 
-----------------------------------------------------------------------------------------------------------------
    513 0,55500 R-prueba   heisenberg       r     09/30/2013 16:07:06 diaria_multicore@nova31.hpc.ci     1        

Observe cómo ahora el estado es r (running) y se indica la cola@nodo en el que se está ejecutando el programa.

Insistimos en que, como norma general, es muy recomendable usar la partición /scratch para llevar allí ficheros de entrada, generar ficheros temporales o ficheros de salida que luego, una vez terminado el cálculo, se pueden copiar en nuestro /home. Sin embargo, habrá veces que el trabajo de mover ficheros de un directorio a otro no compense. Este será el caso de ficheros de entrada o salida pequeños o, aún siendo grandes, que sólo se use una pequeña parte. En ese caso, es posible que sea más rápido dejarlos en nuestro /home y acceder a ellos directamente, sin perder tiempo en copiarlos antes al nodo de ejecución.

Además de lanzar trabajos y ver su estado en el sistema de colas también puede eliminar trabajos y monitorizar el comportamiento del nodo que está ejecutando sus trabajos. Para no alargar esta sección, si está interesado puede leer más sobre esta cuestión aquí.

3.3 Nuevo servicio GPU

En abril de 2016 se ha incorporado a uno de los nodos de cálculo una aceleradora GPU nVidia Tesla K10 con las siguientes características:

  • 2 GPUs GK-104 con microarquitectura Kepler.
  • 1536 cores cada GPU (3072 en total) a 745 MHz
  • 3584 MB de RAM GDDR5 a 2,5GHz y bus de 256 bits.
  • 4500GFlops en single precision. 190GFlops en double precision.

Se ha creado una cola específica llamada "cuda".

El uso de este hardware por parte de las aplicaciones necesita de compilaciones especiales y depende de cada aplicación. Aquellos usuarios que quieran ejecutar aplicaciones de su interés sobre esta GPU deben ponerse en contacto con eciencia@cica.es indicándonos que aplicación desea usar.

Se ha hecho una prueba para comparar el rendimiento de dos aplicaciones con y sin CUDA. Como se puede observar en la siguente tabla, el incremento de rendimiento puede llegar a ser espectacular:

Aplicación Fichero de entrada Tiempo de ejecución sin CUDA Tiempo de ejecución con CUDA
LAMMPS (MPI en 8 cores) bench/FERMI/in.eam 77,29 seg. 17,87 seg.
BEAST (BEAGLE) examples/Benchmarks/benchmark2.xml 25,12 min. 6,13 min.

3.4 Usuarios con necesidades especiales

Si las necesidades de cálculo del usuario no se adaptan al uso a través de un sistema de colas, el usuario puede contactar con el personal de Supercomputación del CICA y explicarnos su caso. Dependiendo de los recursos disponibles podremos crearle soluciones particulares para su caso.

4. APLICACIONES INSTALADAS EN EL CLUSTER

Matemáticas

Para ejecutar en el cluster programas escritos en el lenguaje R se debe usar alguna de las colas simple o multicore dependiendo de la cantidad de memoria que necesite su programa.

Para su uso hay que cargar primero su módulo de entorno mediante el comando module load R

La versión instalada no tiene soporte MPI por lo que las tareas que usen este lenguaje deben ponerse en alguna de las colas simple o multicore.

Para ejecutar programas escritos para Freefem debe cargar el modulo de entorno con el comando module load freefem++

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load 4ti2

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load Macaulay2

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load Singular

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load gap4

Física

Química

GAMESS es un programa para Química Cuántica "ab initio". Para su funcionamiento usa la biblioteca MPI y, por tanto, los cálculos que se lancen con este programa deben colocarse en alguna de las colas mpi: corta-mpi, media-mpi...

Bioinformática

Están instalados en /home/software/bowtie y /home/software/bowtie2. Para usarlos, primero debe cargar el módulo de entorno correspondiente con el comando module load bowtie o module load bowtie2 . Otros directorios con documentación y datos están en la ruta antes indicada.

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load bioperl

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load blast+

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load cufflinks

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load fastqc

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load fastx-toolkit

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load samtools-1.1

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load sra-toolkit

Antes de usar cualquiera de las herramientas de este paquete, el usuario debe configurar su entorno ejecutando el comando configuration-assistant.perl.

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load tophat

Para usarlo hay que cargar primero su módulo de entorno mediante el comando module load trinity

Aplicación R con multitud de módulos para bioinformática.

Para usarlo hay que cargar su módulo de entorno con el comando module load R-Bioconductor

Para usarlo hay que cargar su módulo de entorno con el comando module load velvet-1.2.10

Para usarlo tenemos que invocarlo con la ruta /home/software/oases_0.2.8/oases

Lenguajes de programación y bibliotecas

  • Java SDK y JRE
  • Python
  • Perl
  • Bibliotecas:
    • Intel MKL
    • mpich2
    • openmpi compilado para su uso con gcc/gfortran, Intel c/c++ e Intel Fortran
    • BLAS, LAPACK, ATLAS y openBlas
    • AMD ACML
    • Librerías Boost y Petsc
  • Compiladores Intel Fortran, GNU Fortran y GNU C/C++
    • NOTA: Para hacer uso de los compiladores de Intel o algún programa compilado con ellos, deberá ejecutarse el siguiente comando:
          source /home/software/libraries/intel/composerxe/bin/compilervars.sh intel64
      
      La extensión del archivo "compilevars" será .sh siempre que se use bash y .csh si se utiliza csh.
      

Los usuarios pueden instalar sus propios programas en su directorio HOME. Para ello debe usar la máquina devel.hpc.cica.es como plataforma de desarrollo y compilación. Si el usuario necesita instalar alguna aplicación y no sabe cómo, puede pedirla al personal del CICA en eciencia@cica.es .

En caso de que el software a ejecutar sea comercial, es el usuario quien debe aportar una licencia.

5. COPIAS DE SEGURIDAD

Queremos aprovechar la ocasión para recordarles que el sistema de copias de seguridad configurado actualmente sólo hace copia de lo que contengan en su carpeta /home/usuario/backup/ y sólo si ésta ocupa menos de 300GB.

No considere el almacenamiento en el cluster como un lugar fiable a largo plazo para sus datos. La forma más prudente de hacer las cosas es mantener en el cluster solamente los datos con los que esté trabajando. Una vez tenga resultados definitivos de sus cálculos haga copia de ellos en su máquina local y haga un backup de los mismos.

Last modified 3 days ago Last modified on Jun 21, 2017 1:16:32 PM