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.
ACCESO AL CLUSTER
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.
TRABAJANDO EN PROTEUS
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.
Compilar programas
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.
Envío de trabajos
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.
Scripts para el envío de trabajos
Script que facilita el envío de trabajos a SLURM.
Modo de uso:
$ slanzarv [opciones] programa [argumentos]
Opciones:
- –cpus-per-task | -c : número de CPUs
- –mem | -m : tamaño de memoria en MB
- –nomail : desactiva el envio de email en caso de fallo o cuando finaliza el trabajo
- –short : envia el trabajo a la cola corta
- –time | -t: máximo tiempo de ejecución (ha de ser menor que el tiempo límite de la partición). Por defecto, el tiempo por defecto de la partición. Formatos:
- «minutes», «minutes:seconds», «hours:minutes:seconds», «days-hours», «days-hours:minutes» and «days-hours:minutes:seconds»
- –use-only-faster-nodes : el trabajo solo podrá ser ejecutado en los nodos más potentes (grupo metis, hermes o kratos). No tiene efecto en la cola corta, puesto que esta cola solo usa los más nodos rápidos
- –family : permite seleccionar la familia de CPUs en la que se ejecutará el trabajo. Las opciones disponibles son (ordenados de más nuevos a más antiguos)
- por grupos: metis, hermes, kratos, calypso
- por microarquitectura: cascadelake, skylake, broadwell, haswell, westmere-ep, harpertown
- –min-family : permite seleccionar la familia más antigua de CPUs a usar. Ejemplo: –min-family=kratos podrá usar metis, hermes y kratos, pero no calypso
- –with-modules : lista separada por comas y sin espacios de modulos necesarios para la ejecucion
Ejemplo de uso:
Solicitar 8 CPUs y 2400 MB de RAM para miprograma llamado con los los argumentos ‘230 asx’
slanzarv -c 8 -m 24000 ./miprograma 230 asx
Uso avanzado:
Se pueden pasar opciones adicionales a sbatch. Para ello, es necesario indicar el fin de las opciones con —
slanzarv -c 4 -m 3400 --contiguous --hold -- ./miprograma 230 asx
Si slanzarv no es apropiado para el trabajo, o simplemente así se prefiere, se puede usar directamente los comandos de SLURM sbatch y srun.
Pequeño resumen con sus principales opciones desde este enlace.
Estado de los trabajos
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
Particiones y estado de los nodos
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
Cancelar trabajos
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
Otros comandos de SLURM
sacct #
Consulta del histórico de trabajos
Salida estándar y de errores
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
Notificaciones por email
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.
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 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.
PRIORIDADES EN PROTEUS
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