Cómo usar PROTEUS

Cualquier miembro del Instituto Carlos I de Física Teórica y Computacional tiene derecho a utilizar este servicio de computación. Además, el iC1 mantiene acuerdos de colaboración y desarrollo con otras instituciones y centros de investigación.

Para usar PROTEUS antes es necesario ser miembro del Instituto Interuniversitario Carlos I de Física Teórica y Computacional.

Para trabajar en PROTEUS es necesario conectarnos por SSH a su puerta de entrada:

# ssh username@proteus.ugr.es

No hay ningún tipo de restricción de acceso (como por ejemplo, una IP concreta). Sin embargo, tiene un filtro de seguridad: si nos equivocamos 3 veces seguidas al teclear nuestro usuario/password, el sistema lo percibe como un ataque y bloquea la IP. En ese caso, habrá que ponerse en contacto con el administrador para desbloquearla.

IMPORTANTE: PROTEUS es la máquina de entrada pero en ella NO se ejecutan trabajos. Tenemos que enviar nuestros trabajos al gestor de colas y éste se encargará de ejecutarlos en alguna de las máquinas por nosotros.

PROTEUS está orientado al cómputo masivo de aplicaciones de una manera fiable, con tolerancia a fallos, robustez y seguridad, y sencilla para los usuarios.

Un gestor de colas se encarga de planificar y ejecutar los trabajos que los usuarios solicitan. La puerta de entrada al cluster es a través del nodo proteus.ugr.es, desde la cual se envían trabajos a la cola de ejecución.

Es el gestor de colas el que se encarga de elegir qué trabajos se han de ejecutar (orden de prioridades), la máquina en la que se ejecutará (disponibilidad de la misma), supervisar la ejecución y recoger resultados y posibles errores.

Para compilar programas, se dispone de las últimas versiones de los compiladores para C, C++ y Fortran de GNU (gcc, gfortran) y de Intel (icc, ifort).

También están disponible las bibliotecas de programación paralela y distribuida openMP y MPI y las bibliotecas matemáticas BLAS optimizadas para la arquitectura del cluster. El software se gestiona mediante un sistema de módulos. Todos los detalles se pueden consultar en esta página.

Cualquier software libre se podrá instalar a petición. Si el software es de pago y el interesado proporciona la licencia, tampoco hay problema en instalarlo, siempre y cuando todos los miembros del cluster puedan hacer uso del mismo.

Para evitar problemas de diferentes versiones de bibliotecas, lo recomendable es compilar el código fuente en PROTEUS.

Todos los procesadores de PROTEUS son Intel x86_64, de 3 familias. El entorno está configurado para generar código optimizado para estos, siempre que se use el compilador de Intel. Además, es posible añadir optimizaciones mediante el empleo de los flags generales de optimización (-O[1,2,3]).

Disponemos de los compiladores de de Intel y de GNU para los lenguajes C/C++ y Fortran (icc – ifort | gcc – gfortran).

Se recomienda el uso de los compiladores de Intel porque hemos observado empíricamente que los programas que se obtienen con éstos se ejecutan más rápido.

Para ejecutar un programa, es necesario indicar al gestor de colas una serie de información como el nombre del ejecutable, los recursos que necesita (CPU, RAM,…), su tiempo de ejecución, etc.

La forma de hacerlo es mediante un script donde hemos de indicar esos datos. Aunque su sintaxis no es demasiado compleja, es necesario conocerla y escribir un script para cada programa que se envíe.

Con el fin de aliviar este esfuerzo extra, se ha creado un pequeño programa que se encarga de crear el script y enviar el trabajo a SLURM.

Después de envíar un trabajo, éste pasa una cola a la espera de ser ejecutado. El gestor de colas le asigna un slots con los recursos solicitados en función de los disponibles y la prioridad del usuario.

Los principales estados en los que puede estar un trabajo son:

• PD (pending)
• R (running)
• CA (cancelled)
• CF(configuring)
• CG (completing)
• CD (completed)
• F (failed)
• TO (timeout)
• NF (node failure)
• RV (revoked)
• SE (special exit state)

squeue #

Muestra información sobre el estado de los trabajos.

$ squeue

Mostrar información de un trabajo específico

$ squeue -j <jobid>

Conocer la hora estimada de comienzo de ejecución de los trabajos pendientes

$ squeue --start

Mostrar los trabajos en ejecución

$ squeue -t RUNNING

Trabajos pendientes

$ squeue -t PENDING

Listar los trabajos de una determinada partición

$ squeue -p <partition name>

Conocer el estado los trabajos del usuario:

$ mi_squeue

Las particiones son grupos de nodos que tienen las mismas características y permisos de uso. Más info.

sinfo permite obtener información sobre las particiones y el estado de los nodos.

$ sinfo

el cual devuelve las siguientes columnas:

• PARTITION: nombre de la partición
• AVAIL: si está disponible (up) o no (down)
• TIMELIMIT: máximo tiempo de ejecución
• NODES: número de nodos
• STATE: estado de esos nodos. Éste puede ser:
  • idle: disponible
  • alloc: en uso
  • mix: parte disponible, parte en uso
  • resv: reservado
  • drain/drng: no disponible por motivos técnicos

Otros ejemplos de uso: #

Mostrar la información de una partición específica:

$ sinfo -p <partitionname>

Mostrar las razones de por qué los nodos están: caídos, han fallado o están fallando:

$ sinfo -R

scancel #

Permite cancelar un trabajo. El trabajo se deja de ejecutar y desaparece de la cola. Los archivos que haya generado se mantienen.

$ scancel <jobid>

Cancelar todos los trabajos pendientes

$ scancel -t PENDING

sacct #

Consulta del histórico de trabajos

Slurm redirecciona la salida estándar y de errores a archivos. Si se ha usado el script slanzarv estos archivos son, respectivamente:

<programa>.<jobid>.out

<programa>.<jobid>.err

Por defecto estos ficheros se guardan en el directorio de envío. Se puede modificar este comportamiento con las siguientes opciones del comando ​ sbatch ​ :

• –error /path/to/dir/filename
• –output /path/to/dir/filename

Es posible recibir avisos los eventos y estados por los que pasa un programa, como por ejemplo cuándo empieza, cuándo termina, si ha fallado, etc.

slanzarv por defecto envía un mail cuando el programa ha terminado o si ha fallado. Este comportamiento se puede desactivar con el flag –no-mail

$ slanzarv --no-mail miprograma

Slurm provee de las siguientes opciones para controlar el comportamiento de las notificaciones por email:

–mail-user: dirección de correo electrónico a la que enviar

–mail-type: evento por el que enviar el email. Estos eventos pueden ser alguno de los siguientes:

• NONE
• BEGIN
• END
• FAIL
• REQUEUE
• STAGE_OUT
• ALL (= todos los anteriores)
• TIME_LIMIT_50 (cuando se alcance el 50% del tiempo máximo de ejecución del programa)
• TIME_LIMIT_80 (ídem 80%)
• TIME_LIMIT_90 (ídem 90%)
• TIME_LIMIT (ídem total)

La dirección de correo que haya utilizado para el registro en este servicio también será añadida a una lista de noticias, a la que se envían los cambios, novedades, avisos y fallos que ocurran.

Los programas pueden tener diferentes requisitos hardware para su ejecución, como la arquitectura del procesador, el número de procesadores, la cantidad de memoria principal o de almacenamiento en disco, etc.

Esto se especifica a través de slanzarv o, si este es insuficiente para expresar todos los requisitos, a través del archivo de descripción.

El programa esperará en cola hasta que los recursos que ha solicitado estén disponibles. Evidentemente, cuanto más bajos sean los requisitos, más fácil será que estén libres en un determinado momento. Si no se pueden satisfacer, el programa permanecerá esperando en cola indefinidamente.

HTCondor implementa un uso equitativo de los recursos del cluster para todos sus usuarios. Mantiene un historial de los recursos consumido por cada usuario y, en base a ello, calcula la prioridad de cada usuario de forma que los usuarios que más hayan estado o estén utilizando el cluster reciban una prioridad menor a favor de los que lo estén utilizando menos para, así, garantizar que a la larga todos los usuarios puedan utilizar la misma cantidad de recursos del cluster.

En caso de que un nuevo trabajo entre en la cola y los recursos que ha solicitado estén en uso por otro trabajo (bien porque el cluster esté completamente en uso, bien porque son unos recursos concretos que sólo tienen unos pocos nodos), se comparan las prioridades de los usuarios que están actualmente ejecutando trabajos en esos recursos y la del propietario del nuevo. Si ésta es superior, el trabajo anterior pasa a estado de espera (se deja de ejecutar) y su puesto es ocupado por el nuevo.

También se puede hacer distinción de prioridades entre los trabajos de un usuario, dándole preferencia a aquellos que deseemos. Es decir, si tenemos varios trabajos y queremos que algunos de ellos se ejecuten antes de otros. Para ello, podemos utilizar el comando condor_prio