Acceso y funcionamiento

En esta sección se explica cómo trabajar con PROTEUS. Para ello, necesita tener una cuenta en el sistema. Si todavía no la tiene, más abajo dispone de información sobre cómo conseguir una. Para cualquier duda, dispone de diversos medios de comunicación en la sección "Contacto".

Una vez que tenga su usuario, podrá acceder y utilizar PROTEUS tal y como se indica a continuación.

Obtención de una cuenta

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. Puede encontrar más información al respecto en la sección "Proyectos Externos".

Si cumple con los requisitos expuestos, puede solicitar una cuenta bien por email, bien mediante el formulario de la sección "Contacto", indicando en el asunto del mensaje "Solicitud cuenta Proteus". En el mensaje, ha de indicar su nombre, una dirección email de contacto (a la que se le enviarán avisos y otras noticias relacionadas con el cluster), la relación que tiene con el iC1 y el nombre de usuario que desea utilizar.

Si todo es correcto, en un plazo breve, recibirá una notificación, avisándole de que ya puede utilizar el cluster. Se le asignará una contraseña, que deberá cambiar en el primer acceso.

Trabajando en PROTEUS

La configuración del cluster está orientada al cómputo másivo de aplicaciones de una manera fiable (tolerancia a fallos, robustez, seguridad,etc) y sencilla para los usuarios.

El sistema está dispuesto para correr programas que necesiten una gran cantidad de recursos, ya sea en tiempo de CPU, memoria o disco. No hay restricciones en cuanto al uso de estos recursos, ni en el tiempo que un programa puede estar ejecutándose.

Para facilitar el uso del cluster, se ha habilitado un gestor de colas encargado de planificar y ejecutar los trabajos que los usuarios solicitan. El cluster tiene una puerta de entrada (el 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. De esta forma, no nos tenemos que preocupar de buscar una máquina disponible para nuestros trabajos, ni de tener que escribir scripts para ejecutar serialmente varios trabajos, o de estar atentos de ver cuándo finalizan. De todo esto se encarga nuestro gestor de colas.

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.

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.

Política de Uso

El objetivo que se pretende con esta infraestructura es alcanzar su máxima eficiencia y provecho, por lo que el uso de la misma se ha intentado simplificar en todo lo posible.

Es por ello, que se han suprimido las colas de duración corta, media y larga, muy frecuentes en sistemas de este tipo. Se ha optado por que todos los programas corran en una única cola de cara a que sea más fácil para todos los usuarios.

La comunicación con los usarios del servicio se hará vía email a la dirección que el usuario indique en su registro. Cada vez que haya alguna novedad, se pondrá en conocimiento de todos mediante este medio. También aparecerán en la página de inicio de esta web, en la sección "Últimas Noticias".

Se ruega a los usuarios que en todas sus publicaciones y trabajos que hayan obtenido utilizando estos recursos informáticos, hagan mención de ello, agradeciendo al Instituto Carlos I sus servicios de computación. Esto servirá para pedir nuevas ayudas y subvenciones para la ampliación y mejora del hardware y para la contratación de personal técnico.

Acceso

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 ubicación de acceso (como por ejemplo en UGRGRID que sólo permite acceder desde 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.

NOTA: 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.

Sistema de Colas

El gestor de colas encargado de administrar los recursos del cluster y el acceso justo y equitativo para todos los miembros es HTCondor, desarrollado por la universidad de Wisconsin-Madison bajo licencia GPL y en continuo desarrollo. La decisión de qué programa correrá en qué se hace siguiendo los criterios de prioridades de los usuarios y los requerimientos del programa.

Las principales características de Condor son:

• control sobre la ejecución de los trabajos
• log y notificaciones de eventos
• orden de ejecución de los trabajos
• prioridades
• checkpoints y recuperación ante fallos

Cola de trabajos

Solo existe una única cola a la que van todos los programas que se lanzan. No hay distinciones entre programas de duración corta o larga, ni la cantidad de otros recursos que puedan necesitar. Esta planificación simplifica enormemente el uso a los usuarios.

Requisitos de los programas

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 en el 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.

Prioridades

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.

Para comprobar la prioridad que tenemos en cada momento, se puede utilizar la orden condor_userprio que devuelve una lista de usuarios junto con su prioridad. A mayor valor, menos prioridad efectiva.

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

Compilar programas

Para ejecutar un programa en el cluster lo ideal es copiar el código fuente en él y compilarlo allí porque así garantizamos evitar problemas por diferentes versiones de bibliotecas.

Los compiladores disponibles son los de Intel y los GNU para los lenguajes C/C++ y Fortran (icc - ifort | gcc - gfortran).

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 optimiciones mediante el empleo de los flags generales de optimización (-O[1,2,3]).

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.

Ejecución de los programas

Una vez compilado el programa, la siguiente fase es enviarlo al cluster. Para ello, se han puesto a disposición de los usuarios algunos scripts que facilitan esta tarea.

lanzarv

Con lanzarv se puede enviar automáticamente el trabajo a la cola. Su forma de uso es:

lanzarv [-cCores] [-mMemoria] ejecutable [parámetros]

donde

• -cCores es el número de cores que se solicitan para el trabajo. Opcional, por defecto 1. Sólo habría que usar esta opción si nuestro trabajo es paralelo. En tal caso, podríamos solicitar hasta 12 cores.
• -mMemoria es la cantidad de memoria solicitada (en MB). Opcional, por defecto 900MB. HTCondor asigna esta cantidad de memoria al programa. Si lo rebasa, el programa es abortado (kill -9)

Si el trabajo es sacado de la cola por cuestiones de prioridad o hay algún tipo de error, una vez que retome la cola, se volverá a ejecutar desde el principio, perdiéndose todos sus avances. Incluso es posible que sobreescriba los archivos generados al volver a empezar desde el principio. En realidad, se ha modificado este comportamiento para que, si ocurre algún fallo, el trabajo se quede retenido, a la espera de la intervención del propietario. De esta forma, no se pierde el trabajo almacenado en disco que se llevara hecho hasta la fecha del fallo.

Este modo es el más indicado para trabajos cuyo periodo de ejecución sea corto (del orden de días).

lanvarv2

Para evitar el problema anteriormente comentado, se ha añadido la posibilidad de crear checkpoints (puntos de restauración de un programa) automáticos que van guardando el estado de ejecución de un programa que se pueden retomar si fuera necesario. También soluciona los problemas de caí­das del cluster (sobre todo, por cortes del suministro eléctrico). Su forma de uso es idéntica: lanzarv2 [-cCores] [-mMemoria] ejecutable [parámetros] IMPRESCINDIBLE: para poder utilizar lanzarv2 (y sus checkpoints) en la compilación del ejecutable NO se puede utilizar la opción -static. Además, de algunos programas tampoco se pueden hacer checkpoints por el tipo de funciones que usan.

Este modo es el apropiado para programas con tiempo de ejecución largo (de semanas o meses).

Cuando se envían trabajos al cluster por alguno de estos medios (lanzarv o lanzarv2), se generan varios archivos automáticamente:

• ejecutable.submit: fichero de descripción de trabajo necesario para HTCondor
• ejecutable.identificativo.out: las salidas por pantalla del trabajo se direccionan a este archivo. El identificativo hace referencia al número de ejecución asignado por HTCondor, necesario para no sobreescribir el archivo si se envía varias veces el mismo trabajo
• ejecutable.identificativo.err: almacena los posibles errores
• ejecutable.identificativo.log: es un histórico de todas las etapas y eventos por los que pasa el trabajo

lanvarc

lanzarc es el script que hay que usar para enviar a PROTEUS programas que se ejecutan, total o parcialmente, en tarjetas gráficas. Su forma de uso es similar a la de los anteriores, con la salvedad de que la cantidad de recursos que se pueden utilizar son fijos: se dispone de un computador con dos tarjetas gráficas NVIDIA Tesla C2050, 8 cores y 24GB de RAM, capaz de ejecutar programas escritos en CUDA o en openCL. Esta máquina se ha divido en 2 slots HTCondor. A cada uno de ellos se le ha asignado:

• una de las tarjetas Tesla,
• 2 cores
• y 10GB de RAM.

Así pues, cada programa enviado con lanzarc recibe esos recursos, sin posibilidad de cambiarlos.

Los programas se ejecutan exactamente igual que cualquier otro dentro de HTCondor, con la salvedad de que sólo pueden correr en uno de estos 2 slots. No obstante, es necesario conocer la ID de la tarjeta gráfica que se le ha asignado al programa para que así el programa pueda trabajar con ella. Esto se puede hacer de 2 formas: mediante la variable de entorno GPU_DEVICE_ID o mediante el argumento arguments "--device=X" pasado al programa. lanzarc ejecutable [parámetros]

Volver a lanzar trabajos que han fallado

Si por alguna razón un trabajo ha fallado, es posible volver a retomar su ejecución si se cuenta con su checkpoint (creado con lanzarv2). Para ello, disponemos de

relanzarv2 id

donde id es el número de identificación que le asignó HTCondor al trabajo que se desea restaurar.

Estado de los programas

Cuando se envía un trabajo, éste pasa a la cola y se pone a la espera de ejecución. Cuando consigue un "hueco", pasa al estado de ejecución. Si hay algún error durante el proceso, pasa al estado detenido. Estos son los tres estado principales de HTCondor, denotados con las letras I (Idle), R (Running) y H (Hold).

Para conocer el estado de nuestros trabajos disponemos de la orden: condor_q nos devolverá información de todos los programas. También existe el script mi_condor_q que sólo nos da información sobre los nuestros.

La información devuelta, por columnas, indica lo siguiente:
Identificativo | Usuario | Fecha envío | Tiempo de ejecución | Estado | Prioridad | Memoria usada | Ejecutable

Estado de los nodos de ejecución

También resulta muy útil conocer el estado de los recursos, especialmente si necesitamos enviar un gran número de trabajos. Para ello, además de en esta propia página en la sección "Estado", HTCondor dispone con una orden que muestra la situación actual de los nodos: condor_status La salida es un listado con cada uno de los nodos y sus cores, sistema operativo y arquitectura (LINUX X86_64 para todo PROTEUS), su estado (Unclaimed o Claimed), memoria, etc. y tras esto, una tabla-resumen con el número de cores libres por nodo, memoria libre y la relación memoria libre por core. De esta manera, se puede conocer rápidamente cuántos cores libres hay y la memoria disponible para ellos.

Eliminar trabajos de la cola de ejecución

Si ya no es necesaria la ejecución de un trabajo, podemos eliminarlo de la cola de HTCondor usando condor_rm idTrabajo El trabajo se deja de ejecutar y desaparece de la cola. Los archivos que haya generado se mantienen. Si queremos eliminar todos nuestros trabajos condor_rm -all

Notificaciones por email

Los cambios, novedades, avisos y fallos que ocurran en el servicio serán notificados por email a la dirección que se haya especificado cuando se dé de alta en el servicio.

Además de estas notificaciones, HTCondor le avisará de los eventos de los programas mediante un email automático que dando detalles del mismo. Si no desea recibir estos correos, lo puede solicitar al personal técnico en la dirección email que aparece en la pestaña Contacto del menú.