Táboa de Contidos

INFORMACIÓN OBSOLETA: CONSULTA hpc_old

>>Página principal HPC

Guía de usuario del clúster ctcomp2

Si quieres utilizar el clúster por primera vez, debes solicitar acceso a citius.tic@usc.es o abriendo una incidencia.

La primera vez que entras, el par de claves pública/privada se genera automáticamente, ya no es necesario generarlas como aparece en el vídeo introductorio.

Descarga la Guía de usuario v1.2 [Septiembre 2013] en PDF

Otros contenidos:

ctcomp2 para impacientes (old version):
<video width=480 height=320>:centro:servizos:cluster_de_computacion_hpc_ctcomp2:ctcomp2_for_impatients_verylow.webm</video>|

Introducción

El clúster ctcomp2 es un sistema de computación de altas prestaciones (CAP) que proporciona a los usuarios del CITIUS la posibilidad de ejecutar programas computacionalmente exigentes.

En su forma más simple, la utilización de los recursos computacionales de este clúster se puede resumir en los siguientes pasos:

  1. Acceder, mediante ssh, al clúster. Los ficheros necesarios para la ejecución de los trabajos se pueden importar al espacio de usuario del clúster mediante scp. - Si utilizamos lenguajes compilados (C, C++, Fortran…) es necesario compilar adecuadamente el código fuente.
  2. Escribir un script que indique al gestor de colas los parámetros de la ejecución: el directorio de trabajo, el comando de ejecución, el número de nodos/núcleos necesarios….
  3. Enviar, mediante qsub, el script al gestor de colas para que lo incluya en la cola de planificación de trabajos, a la espera de ser emitido para su ejecución en los nodos computacionales. - La emisión del trabajo a los nodos computacionales se realizará cuando el gestor de colas encuentre un hueco temporal y espacial adecuado para la ejecución del trabajo, en función de los parámetros de ejecución indicados en el script. Es posible utilizar una opción en el script para indicar una dirección de correo electrónico en la que se notificará la finalización de las tareas indicadas en el script.

Descripcion del sistema

El clúster ctcomp2 es un clúster heterogéneo, formado por 8 nodos computacionales HP Proliant BL685c G7, 5 nodos Dell PowerEdge M910 y 5 nodos Dell PowerEdge M620. Cada nodo HP Proliant dispone de 4 procesadores AMD Opteron 6262 HE (16 núcleos) y 128 GB de RAM. Cada nodo Dell PowerEdge M910 está equipado con 2 procesadores Intel Xeon L7555 (8 núcleos, 16 hilos) y 64 GB de RAM. Cada nodo Dell PowerEdge M620 está equipado con 2 procesadores Intel Xeon E5-2650L (8 núcleos, 16 hilos) y 64 GB de RAM. Los nodos compationales están conectados entre sí a través de varias redes 10 GbE.

El acceso de los usuarios al clúster se realiza a través de una máquina independiente, que denominamos frontend. Este frontend tiene unas prestaciones limitadas, y únicamente está preparado para gestionar ficheros, compilar código y enviar trabajos al sistema de colas del clúster. No está permitida la ejecución de código paralelo en esta máquina.

El usuario dispone de los siguientes espacios, dentro del sistema de ficheros del clúster, para ubicar los ficheros relacionados con los trabajos realizados en clúster:

Actualmente, no se realizan backups del directorio $HOME de los usuarios.

Acceso al clúster ctcomp2

Los servicios del clúster son accesibles a través del frontend (ctcomp2.inv.usc.es). El acceso remoto a este servidor se realiza mediante ssh (secure shell). Se utiliza el sistema de autentificación centralizado del CITIUS. Nota: En caso de tener problemas accediendo con el nombre completo del equipo, se puede utilizar la IP en su lugar: 172.16.242.122. 

local$ ssh [-X] [-p<port>] nome.apelido@ctcomp2.inv.usc.es
Password:
ct$

Los argumentos de este comando son:

Importación/exportación

El espacio de usuario del clúster es independiente de otros sistemas en el CITIUS, por lo que es necesario importar al espacio de usuario del clúster todos los ficheros necesarios para la ejecución de nuestros programas (por ejemplo, el código fuente o los ficheros de entrada del programa). El comando scp permite el intercambio de ficheros con otros sistemas conectados en red. La sintaxis del comando scp es la siguiente: 

scp [-P<port>] [-r] <direccion_origen> <direccion_copia>

Los argumentos de este comando son:

Ejemplos scp en ctcomp2

A modo de ejemplo, se muestran varios ejemplos de importación de ficheros. En estos ejemplos, se supone que el puesto de trabajo habitual del usuario nome.apelido es ctXXX.inv.usc.es. El fichero/directorio que queremos importar está situado en ctXXX.inv.usc.es, en el directorio /datos/work/, y queremos hacer una copia en el espacio de usuario del clúster en el directorio work del $HOME del usuario.

Si ejecutamos scp en el propio clúster: 

ct$ scp -P<port> \
  nome.apelido@ctXXX.inv.usc.es:/datos/work/un.fichero \
  ~/work/
ct$ scp -P<port> -r \
  nome.apelido@ctXXX.inv.usc.es:/datos/work/directorio/ \
  ~/work/

Si ejecutamos scp en nuestro sistema local (externo al clúster): 

local$ scp -P<port>       \
  /datos/work/un.fichero  \
  nome.apelido@ctcomp2.inv.usc.es:~/work/
local$ scp -P<port> -r    \
  /datos/work/directorio/ \
  nome.apelido@ctcomp2.inv.usc.es:~/work/

Gestión de software con modules

El comando modules permite gestionar, de manera eficaz y consistente, múltiples versiones de librerías y sofware para que el usuario utilice la versión adecuada en función de sus requerimientos. Su funcionamiento se basa en el encapsulamiento, dentro de un módulo, de las variables de entorno relacionadas con una versión de software determinada. De este modo, es el propio usuario quien gestiona la utilización de las diferentes versiones de software disponibles en el sistema.

La gestion, a nivel de usuario, de los módulos se realiza con el comando modules : 

ct$ module avail
ct$ module list
ct$ module load module_name
ct$ module unload module_name
ct$ module purge

Las opciones son:

El comando modules manipula las variables de entorno relacionadas con los path del sistema (PATH, LD_LIBRARY_PATH, etc.), por lo que se recomienda a los usuarios no modificar estas variables de modo arbitrario.

Se recomienda utilizar este comando de manera interactiva. Su uso dentro de .bashrc para cargar automáticamente módulos habituales no está recomendado, ya que todos los scripts que se ejecuten leen este fichero.

Se recomienda utilizar las versiones por defecto de los difentes módulos. En cualquier caso, el comando module avail porporciona una lista completa de todos los los módulos y versiones disponibles.

Compilación

Compilación C/C++/Fortran

La colección de compiladores GNU (GNU Compiler Collection, GCC) es accesible en el clúster a través de sus comandos y opciones habituales. Por defecto, los compiladores instalados en el sistema pertenecen a la versión 4.7.2 de GCC (versión por defecto del SO).2) 

ct$ module load gcc
ct$ gcc      -O exemplo.c   -o exemplo
ct$ g++      -O exemplo.cpp -o exemplo
ct$ gfortran -O exemplo.f   -o exemplo

Las opciones recomendadas son:

Compilación OpenMP

La colección de compiladores GCC permite la compilación de código OpenMP, indicándolo mediante la opción -fopenmp. 

ct$ gcc      -O -fopenmp exemplo.c
ct$ g++      -O -fopenmp exemplo.cpp 
ct$ gfortran -O -fopenmp exemplo.f
Compilación MPI

Para compilar código MPI es necesario cargar un módulo MPI (como, por ejemplo, el módulo openmpi), que proporcione los scripts de compilación de código MPI (mpicc, mpicxx, mpif77). Estos scripts hacen llamadas al compilador del lenguaje correspondiente. 

ct$ module load openmpi
ct$ mpicc  -O exemplo.c
ct$ mpicxx -O exemplo.cpp 
ct$ mpif77 -O exemplo.f

Envío de trabajos al sistema de colas Torque/PBS

Los usuarios no pueden conectarse a los nodos computacionales, por lo que la ejecución de trabajos en los nodos computacionales tiene que realizarse, obligatoriamente, a través del sistema de colas Torque/PBS. El sistema de colas registrará por orden cada una de las solicitudes enviadas y las emitirá, para su ejecución en los nodos computacionales, cuando estén disponibles los recursos requeridos.

El envío de trabajos se realiza a través del comando qsub, cuyo argumento obligatorio es el nombre de un script de shell. El script tiene que disponer de permisos de ejecución. Dentro del script, el usuario debe indicar la acciones que se realizarán en los nodos, una vez que los recursos requeridos estén disponibles Ejemplos de scripts contiene diferentes ejemplos relacionados con los módulos instalados en el clúster). 

ct$ chmod u+x script.sh
ct$ qsub script.sh

Los comandos qstat y pbsnodes permiten al usuario consultar el estado de la cola PBS. 

ct$ qstat    # Información de los trabajos de usuario
ct$ qstat -q # Información global de las colas
ct$ pbsnodes # Información del estado de los nodos

El comando qdel permite al usuario eliminar un trabajo de la cola PBS, antes de que sea emitido a los nodos computacionales para su ejecución. Este comando necesita como argumento el identificador que PBS le asigna cuando se registra un nuevo trabajo, y que se puede consultar con qstat. 

ct$ qdel job_id

Opciones de configuración Torque/PBS

El sistema de colas PBS permite a los usuarios configurar diferentes aspectos de la ejecución de los trabajos. Las instrucciones de configuración Torque/PBS se indican en los scripts a través de líneas que comienzan (sin espacios) con #PBS.3) También es posible indicar estas opciones directamente como argumentos de qsub en la línea de comandos.

Algunas de las opciones más comunes son:

Por defecto, el entorno de ejecución del sistema Torque/PBS define algunas variables de entorno que pueden ser utilizadas dentro de los scripts:

Colas de usuario

El sistema PBS del clúster ctcomp2 tiene cuatro colas de usuario y ocho colas de sistema. Las colas de usuario son en realidad colas routing que determinan, en función del número de núcleos computacionales solicitados, la cola de sistema en la que debe ejecutarse cada trabajo. Los usuarios deben enviar sus trabajos a las colas de usuario, ya que no pueden enviar trabajos directamente a las colas de sistema.

Independientemente del tipo de cola que se utilice para el envío de trabajos, los únicos parámetros que puede solicitar el usuario son el número de nodos, el número de núcleos (procesos) por nodo y el tiempo de ejecución. La memoria asignada y el tiempo máximo de ejecución de un trabajo están determinados por la cola de sistema en la que se ejecute el trabajo. Los trabajos que superen estos límites durante su ejecución serán cancelados. Por lo tanto, aquellos trabajos en los que tanto la memoria como el tiempo de ejecución son críticos, se recomienda a los usuarios modificar el número de procesos solicitados (aunque realmente no se utilicen todos durante su ejecución) para que se garanticen los requisitos del trabajo. El límite máximo de trabajos por usuario y la prioridad de los trabajos es también dependiente de la cola de sistema. Se permite que los usuarios determinen el tiempo de ejecución de los trabajos ya que una estimación precisa de los tiempos de ejecución permite al sistema de colas hacer un uso eficiente de los recursos sin perturbar las prioridades establecidas. En cualquier caso, es recomendable establecer un margen de tiempo suficiente para garantizar la correcta ejecución del trabajo y evitar la cancelación del mismo. Para ejecutar trabajos que no se ajusten a los parámetros de las colas PBS será necesario ponerse en contacto con el responsable del clúster.

Las colas de usuario son batch, short, bigmem e interactive. 

ct$ qsub -q short script.sh 
ct$ qsub -q bigmem script.sh 
ct$ qsub -q interactive -I

Las colas de sistema son np1, np2, np4, np8, np16, np32, np64 y parallel.

La siguiente tabla resume las características de las colas de usuario y de sistema del clúster ctcomp2:

Cola Límites
Procesos Nodos Memoria (GB) Trabajos/usuario Tiempo máximo (horas) Prioridad6)
batch 1-64 - - 256 - 1
short 1-16 - - 256 - 3
bigmem 64 - - 8 - 2
interactive 1 1 2 1 1 7
np1 1 1 1,99 300 672 6
np2 2 2 3,75 150 192 5
np4 4 4 7,5 75 192 4
np8 8 5 15 40 192 4
np16 16 5 31 20 192 3
np32 32 5 63 10 288 2
np64 64 5 127 5 384 1
parallel 32-160 5 64 15 192 3
Solicitud de recursos específicos

Cada nodo computacional está asociado con diferentes etiquetas que identifican sus características. Las etiquetas de cada nodo se puede consultar con el comando pbsnodes, en el campo propiedades. La función básica de estas etiquetas en ctcomp2 es crear conjuntos de nodos homogéneos, lo que permite a los usuarios solicitar la ejecución de sus trabajos en un tipo de nodo computacional específico. En particular, los nodos HP Proliant tienen asociada la etiqueta amd y los nodos Dell PowerEdge la etiqueta intel.

Para solicitar la ejecución de un trabajo en un nodo asociado a una etiqueta particular es necesario indicarlo explícitamente en el comando qsub, dentro el campo nodes de la opción -l. Por ejemplo, si queremos ejecutar un trabajo (1 núcleo, 1 nodo, 1 hora) en un nodo Dell PowerEdge 910 (procesadores Intel Xeon L755) la correspondiente línea #PBS del scrip debería ser: 

#PBS -l nodes=1:ppn=1:intel:xeonl

Si queremos que nuestro trabajo se ejecute en un nodo Dell PowerEdge 620 (procesadores Intel Xeon E5-2650L), la línea debería ser: 

#PBS -l nodes=1:ppn=1:intel:xeone5

Si por el contrario, queremos que se ejecute en un nodo HP Proliant, la línea debería ser: 

#PBS -l nodes=1:ppn=1:amd

Si no se indica ninguna etiqueta el trabajo se ejecutará indiferentemente en cualquier tipo de nodo, en función de los recursos disponibles en ese instante. Si únicamente se indica la etiqueta intel, el trabajo se ejecutará indiferentemente cualquiera de los nodos Dell PowerEdge.

Sesión interactiva con gráficos

Por defecto, las colas de usuario no permiten la ejecución de aplicaciones en modo gráfico. Además, en el frontend la ejecución de este tipo de aplicaciones está restringida. En general, los usuarios que necesiten ejecutar en el clúster aplicaciones en modo gráfico de manera interactiva, deberán utilizar el comando graphicX_session: 

ct$ graphicX_session NPROC

Este comando solicita una sesión interactiva en un nodo del clúster y, automáticamente, se conecta por SSH a ese nodo con la redirección de las X activada. Para que este comando funcione correctamente es necesario que la conexión SSH inicial al frontend tenga también la redirección de X activada (ssh -X …). El tiempo de ejecución de esta sesión interactiva está limitado a 4 horas.

Ejemplos de scripts

A continuación se muestran varios ejemplos de scripts que muestran el conjunto básico de intrucciones para el envio de diferentes tipos de trabajos al gestor de colas.

Ejemplo de trabajo secuencial:
#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ejemplo
#PBS -e salida.out
#PBS -o salida.err
#PBS -m ae -M direccion_correo@usc.es
cd $PBS_O_WORKDIR
./executable
Ejemplo de trabajos secuenciales en paralelo:
#!/bin/bash
#PBS -l nodes=1:ppn=4,walltime=1:00:00
#PBS -N ejemplo
cd $PBS_O_WORKDIR
(cd dir1; ./executable1) &
(cd dir2; ./executable2) &
(cd dir3; ./executable3) &
(cd dir4; ./executable4) &
wait
Ejemplo de trabajo Java:

Java consume, por defecto, toda la memoria del sistema. En un sistema compartido por diferentes usuarios es necesario limitar la cantidad de memoria asignada a cada proceso, por lo que el tamaño del heap de Java en ctcomp2 está limitado al 25 del límite de memoria de la cola asignada al proceso y, cualquier caso, con un tamaño máximo de 8 GB.

Los usuarios pueden utilizar otros tamaños de heap en sus trabajos si modifican, antes de ejecutar JAVA, el valor de la opción -Xmx de JAVA a través de la variable _JAVA_OPTIONS. Por ejemplo, si queremos que el heap tenga 16 GB, el comando sería: 

export _JAVA_OPTIONS=-Xmx16777216K

Al modificar el tamaño del heap el usuario debe asegurarse, bajo su responsabilidad, que el conjunto de procesos que se estén ejecutando concurrentemente en su trabajo no sobrepase el límite de memoria establecido en la correspondiente cola, ya que en ese caso el trabajo será cancelado automáticamente.

Los usuarios que ejecuten en sus trabajos una sola instancia de java (independientemente de los threads que ejecute) podrán aumentar el tamaño del heap, pero se recomienda que no sea un valor cercano al límite de memoria de la correspondiente cola. 

#!/bin/bash
#PBS -l nodes=1:ppn=64,walltime=1:00:00
#PBS -N ej-java
cd $PBS_O_WORKDIR
module load jdk
export _JAVA_OPTIONS=-Xmx16777216K
java executable
Ejemplo de trabajo OpenMP:
#!/bin/bash
#PBS -l nodes=1:ppn=64,walltime=1:00:00
#PBS -N ej-openmp
cd $PBS_O_WORKDIR
export OMP_NUM_THREADS=64
./executable
Ejemplo de trabajo MPI:
#!/bin/bash
#PBS -l nodes=8:ppn=64,walltime=1:00:00
#PBS -N ej-mpi
cd $PBS_O_WORKDIR
module load openmpi
mpirun -np 512 ./executable
Ejemplo de trabajo R:

No es posible realizar una sesión R interactiva, por lo que es necesario escribir previamente los comandos en un script. 

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ej-R
cd $PBS_O_WORKDIR
module load R
R --no-save < test.R
Ejemplo de trabajo MATLAB:

No es posible realizar una sesión MATLAB interactiva, por lo que es necesario escribir previamente los comandos en un script. MATLAB emplea internamente, y de manera transparente al usuario, threads para paralelizar ciertas operaciones, por lo que se puede utilizar reservando varios núcleos computacionales dentro de un mismo nodo. Sin embargo, en las versiones instaladas no es posible controlar esta característica, por lo que MATLAB utiliza todos los recursos del nodo asignado, independientemente de los recursos solicitados. Para evitar posibles cancelaciones debido a un uso indebido de los recursos asignados, se recomienda a los usuarios utilizar el paralelismo implícito de MATLAB solo cuando se reserve en exclusividad un nodo del clúster. En cualquier otro caso, se recomienda solicitar únicamente un núcleo computacional y utilizar la opción -singleCompThread, que desactiva el paralelismo implícito de MATLAB para realizar una ejecución secuencial. En este ejemplo, el nombre del script es test.m. 

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ej-MATLAB
cd $PBS_O_WORKDIR
module load matlab
matlab -r test -nodisplay -nojvm -singleCompThread
# -r:         indicar el fichero a ejecutar (sin .m)
# IMPORTANTE: incluir la orden quit al final del fichero
# -nodisplay: sin display X.
# -nosplash:  sin pantalla inicial (OPCIONAL)
# -nojvm:     sin entorno java (OPCIONAL)
# -singleCompThread: ejecuta MATLAB secuencialmente
1)
En cualquier caso, los usuarios con necesidades de almacenamiento singulares deberán solicitar esos requerimientos a través del sistema de incidencias del CITIUS.
2)
Esta versión de los compiladores disponen de una opción de optimización (march) para generar código específico para la arquitectura de los nodos del clúster (procesadores Opteron 6200 series, 15th Family Bulldozer Interlagos). Esta opción de compilación no garantiza el cumplimiento del estándar matemático definido en GCC, por lo que no se recomienda su uso, salvo en aquellos casos en los que se conozca en profundidad el comportamiento de las opciones de compilación.
3)
De algún modo, estas órdenes son comentarios especiales del script, ya que el inicio de los comentarios se indica con el símbolo #.
4)
No se garantiza la ejecución en exclusividad de los nodos, si no se solicitan los 64 núcleos de un nodo.
5)
Si no se especifica una cola particular, mediante la opción -q del comando qsub, el trabajo se asignará a la cola batch.
6)
Mayor número = mayor prioridad