Multivac es un cluster de PC's, integrados por la empresa Catón, Sistemas Alernativos. Dispone de 68 nodos de cálculo, cada uno de los cuales es de una generación de servidor en concreto, pero que en común mantienen: arquitectura x86_64 (procesadores Intel) y mínimo de 2 GB de RAM por core. Estos nodos están controlados por un front-end (multivac), que se encarga de gestionar el sistema de colas, los usuarios y los sistemas de ficheros compartidos. Todo el software de clustering usado en este montaje se distribuye bajo licencia GPL, incluido el gestor de colas.

La instalación de este equipo responde a la necesidad de realizar cálculos relativamente largos pero con unos requerimientos de memoria y disco que no justifican el empleo del supercomputador. Esto provocaba que el tiempo de espera en la cola de ejecución de César fuese muy elevado. Con este sistema se espera poder repartir la carga de trabajos, agilizando los tiempos necesarios para obtener un resultado.

El uso de este servidor se recomienda para aquellos usuarios cuyos trabajos respondan a estas características (de modo general):

• Trabajos MONOPROCESADOR.
• Necesidades de memoria RAM por debajo de 10 GB.
• Necesidades de disco duro por debajo de 500 GB.
• Tiempos de ejecución largos (hasta 2 meses).

Entorno de usuario

El uso de un cluster de PC's difiere sustancialmente del uso de un equipo de memoria compartida. Mientras que en este último disponemos de una única imagen del sistema operativo, en un cluster cada equipo tiene su propia imagen y sus propios discos internos. Cuando un usuario desea usar el cluster, se conecta a multivac.uv.es que es el denominado nodo front-end. Este nodo se encarga de gestionar todos los servicios del cluster (DHCP, DNS, NIS, gestor de colas, monitorización, PROXY LDAP, etc...) y es el lugar en el que los usuarios preparan sus trabajos y los envían al gestor de colas. De él cuelgan los nodos de cálculo, denominados hypercatXX (donde XX va de 03 a 71 actualmente). Cada máquina tiene un área local de trabajo temporal denominada /scr con 900 GB de capacidad. Los ficheros temporales que creen los cálculos deben ser escritos obligatoriamente en esta área, para evitar la saturación de la red NFS.

Cuando un trabajo entra en ejecución el SGE crea automáticamente un directorio temporal en el /scr local de cada máquina. El nombre de ese directorio coincide con el identificador del trabajo enviado. Se recomienda a los usuarios utilizar este directorio para almacenar sus ficheros temporales. Una vez finalizado el cálculo, DEBE borrarse este directorio, previa copia de su contenido, para evitar la saturación de los discos locales.

El acceso a los nodos en interactivo está permitido, aunque el tiempode cpu está restringido a 5 minutos y sólo puedes abrirse dos sesiones simultáneas en cada equipo.

Enviando trabajos al gestor de colas

En el Cluster de cálculo se ha instalado un gestor de colas de libre distribución llamado Sun Grid Engine, en su versión 6.5u3. Este gestor de colas, está en constante mejora y permite un reparto adecuado de los recursos de cálculo en un cluster. La configuración de este gestor de colas sufre constantemente cambios para poder adaptarse a las necesidades de cálculo de los usuarios, por lo que intentamos mantener esta página lo más actualizada posible.

Comando qsub:es el encargado de enviar trabajos al SGE. Para información detallada de sus múltiples opciones, consultar el man qsub.

El comando qsub permite lanzar trabajos a una cola determinada, lo cual presupone que el usuario conoce los límites de cada cola y ha escogido cual es la más adecuada para que su cálculo se ejecute correctamente. Si no se elige la cola de forma adecuada, es probable que ésta no proporcione recursos suficientes (tiempo de CPU, memoria RAM, etc... ) como para que el cálculo finalice correctamente. Las opciones más comunes son:

• '-e' y '-o' : definen el nombre del fichero de error y de salida respectivamente. Es común hacer que ambos ficheros sean el mismo (por comodidad). Para ello basta especificar el nombre del fichero de salida y añadir la opción '-j y[es]'. Para establecer el nombre, el SGE define una serie de variables de entorno que pueden ser muy útiles:

1. $HOME directorio /home en la máquina de ejecución
2. $USER user ID del propietario del tabajo
3. $JOB_ID SGE job ID
4. $JOB_NAME nombre actual del trabajo
5. $HOSTNAME nombre de la máquina de ejecución

• '-N' : especifica el nombre del trabajo (ver variable $JOB_NAME). Este nombre se usa a efectos identificativos en el sistema de colas.
• '-pe' : especifica el entorno paralelo que se desea usar. Su sintaxis completa es '-pe entorno_paralelo n[-o]'. Donde n es el número de procesadores solicitados al entorno paralelo. En el caso de entornos tipo MPI, puede usarse un intervalo de procesadores (n-o), por lo que se usaran tantos como haya disponibles en el momento de la ejecución en el intervalo (n-o).
• '-q' : especifica el nombre de la cola a la que se quiere enviar el trabajo. Por ejemplo, '-q llarga' enviaría el trabajo a la cola llarga.
• '-S' : especifica la shell del SGE. Ejemplo: '-S /bin/tcsh' provoca que el trabajo se ejecute en un entorno tcsh. Este valor está configurado por defecto en el sistema de colas a tcsh, aunque puede ser alterado mediante este modificador. Se recomienda el valor de "/bin/sh".
• "-l" : especifica la lista de recursos que va a emplear un cálculo. En nuestro caso es obligatorio especificar la cantidad de memoria RAM que se piensa que va a consumir el trabajo. El motivo de esto es para impedir que el SGE envíe un trabajo de alto consumo de memoria a un nodo que no dispone de memoria libre suficente para ejecutarlo. El recurso que es necesario especificar es "vf" (virtual free).
  • La sintáxis correcta es: "-l vf=memoria", donde memoria representa el valor de la memoria que se estima consumirá el cálculo. El valor de la memoria puede especificarse en megas (sufijo M) o gigas (sufijo G). Este valor no representa un límite de memoria, sino que expresa una necesidad. Cada cola del sistema tiene puesto un límite de memoria que no puede ser superado.
  • Otro valor interesante es el de "hostname". Permite especificar a qué nodo se desea enviar el trabajo. La sintaxis correcta en caso de quere usar esta opción que NO es obligatoria sería "-l vf=2G,hostname=hypercatXX". Esto nos permitirá continuar un trabajo que quedó a mitad o se cortó por algún motivo, cuyos datos siguen aún en el /scr del nodo XX.

Comando qstat: es el que más se usará, permite comprobar el estado de los cálculos que hemos enviado al gestor de colas. Existe una versión gráfica de este comando que quizá pueda resultar más intuitiva para algunos usuarios. Además, es accesible directamente vía web, lo cual nos evita el tener que conectarnos a la máquina.

Comando qdel: borra un trabajo del sistema de colas. Su uso es 'qdel id_del_job'. Para obtener el id del job, basta con copiarlos del output del comando qstat.

Comando qhost: muestra el estado de los equipos del cluster y sus parámetros físicos y de uso (carga actual, memoria física, memoria usada, swap, etc..)

Comando qquota: muestra el estado de las quotas del sistema de colas para cada usuario. Nos dice cuantos recursos estamos consumiendo y cúal es nuestro límite de recursos en la máquina (número de cálculos, memoria ram, etc..). En nuestro caso, los recursos que se consumen son el número de cálculos por usuario, limitados a un número determinado por cola.

No obstante, el SGE permite incorporar las opciones que queremos aplicar al trabajo en el propio script que se envía. Para ello se ponen como comentarios al principio del script (es un sistema similar al utilizado por el LSF). Por ejemplo, el script mi_script contendría:

  #!/bin/sh  #  #$ -S /bin/sh  #$ -o /scr/$JOB_ID.err -j y  #$ -q gran  #$ -l vf=100M  cd /scr/$JOB_ID  Programa_a_Ejecutar  . . .

Ejemplo

A modo de ejemplo vamos a poner el envío de un trabajo del programa Gaussian al sistema de colas. En cualquier otro caso, sería necesario modificar ligeramente el script para ejecutar nuestro trabajo

#!/bin/sh##$ -S /bin/sh#$ -o /scr/$JOB_ID.err -j y#$ -q gran#$ -l vf=2G cd /scr/$JOB_ID export g03root=/util/software/G03_RevD02. $g03root/g03/bsd/g03.profile cp /scratch/as/asorian/ejemplo.com . g03 < ejemplo.com > ejemplo.log cp ejemplo.log /scratch/as/asoriancp ../$JOB_ID.err /scratch/as/asorian rm -rf /scr/$JOB_ID;rm /scr/$JOB_ID.err