Cluster Linux - cenachero.ctima.uma.es

Angel Martin Alganza, http://www.ugr.es/~ama/
José L. Oliver, http://www.ugr.es/~oliver/

Hardware

2x Superserver 6015T 1U Twin (dos servidores en 1U)
8x Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (32 cores)
4x 8GB RAM
3x disco duro de 80GB SATA 7200 rpm HotSwap para sistema operativo en cada nodo de cálculo
2x disco duro de 500GB SATA 7200 rmp HotSwap para datos y sistema operativo del nodo maestro

Software

Debian GNU/Linux 4.0 (aka Etch)
Linux Kernel 2.6.18-amd64
NFS 1.0.10 (ejecutando nfs-kernel-server)
Clustering software: Ruby Queue v2.3.2 (versiones más modernas están dando algunos problemas de momento)

Distribución de nodos

Hay un nodo «maestro» (host01 aka cenachero) y 3 (host02-host04) «esclavos».

El nodo «maestro» es el único con conexión externa y es donde se entra por defecto al conectar con 'cenachero.ctima.uma.es'. Se reserva para gestión y administración (login de usuarios, sesiones interactivas, mantenimiento, etc.). Por tanto, el nodo host01 (cenachero) NO se debe utilizar para encolar procesos de cálculo intensivo, sino solo para lanzarlos a las máquinas esclavas. El objetivo es garantizar en todo momento el acceso de los usuarios independientemente de la carga del servidor.

NFS (Network File System) permite utilizar directorios remotos como recursos locales de forma transparente al usuario. Los directorios remotos aparecen como directorios locales en el árbol de directorios.

Tenemos exportados (NFS) en el nodo «maestro» los directorios '/opt/', '/srv/', '/home/', '/usr/local/' y '/var/mail/' que aparecen como tales en los nodos «esclavos» (en cenachero).

De este modo se asegura que estén disponibles en todos los nodos del cluster en todo momento

Los datos comunes (/srv/)
Los datos de usuario (/home/)
Los programas instalados localmente (/usr/local/)
Las colas de correo electrónico local de todos los nodos

El directorio '/srv/' es para almacenar datos comunes y de servicios. Por ejemplo, en /srv/sec/ están los ensamblados de los genomas más utilizados: hg18, hg17, mm7, etc. Se irá actualizando periódicamente. Por tanto, no es necesario bajarse estos genomas a los home de cada usuario. Es mejor apuntar el software para que lea las secuencias de estos directorios.

Ruby Queue – Getting started

En Ruby Queue (rq) no existe gestión centralizada de colas; cada usuario se crea y gestiona su/s propia/s cola/s.

Un manual detallado de rq se puede obtener tecleando 'rq help'. Por conveniencia, la salida de ese comando se incluye al final de este documento como un Apéndice.

Los pasos imprescindibles para echar a andar una cola en el home del usuario, tras conectarse por SSH (desde Windows utilizando el cliente PuTTy, por ejemplo) a cenachero.ctima.uma.es, se resumen a continuación

Crear una cola. Por ejemplo, para crear la cola 'q' teclear:
```
rq q c
```
Esto crea el directorio 'q' en nuestro directorio home, con todo lo necesario (fundamentalmente, una base de datos SQLite) para gestionar y mantener la cola.
Definir los nodos «feeders», es decir las máquinas que van a procesar las órdenes enviadas a esta cola. Como «feeders» solo deben usarse los nodos «esclavos», es decir host02-04, nunca el host01.
Por ejemplo, para definir host02 como feeder de la cola q que acabamos de crear, se hace lo siguiente:
```
username@cenachero:~$ ssh host02
Linux host02 2.4.26-om1.om+libata+tuneado+iptables2 #1 SMP dom may 21 22:27:31 CEST 2006 i686 GNU/Linux 

username@host02:~$ crontab -e
```
Aparece entonces el contenido del crontab del usuario en el editor por omisión del usuario (o del sistema, si el usuario no tiene definido ninguno, que es Vim). En tabla de cron (crontab) del usuario hay que incluir (i, para entrar en modo INSERT) la siguiente línea:
```
# m h  dom mon dow   command
*/15 * * * * /usr/local/rq-2.3.2/bin/rq /home/username/q feed --max_feed=8 >> /dev/null 2>&1
~
~
```
cambiando «username» por el usn del usuario correspondiente; y siendo 8 el número máximo (--max_feed) de procesos de la cola que debe ejecutar el nodo (nunca debe ser mayor que el número de núcleos (cores) en los microprocesadores del nodo).

Se termina la edición de la tabla cron (crontab) guardando los datos y saliendo del editor (ESC :wq en el caso de Vim) y se comprueba que hemos incluido esa línea correctamente:
```
username@host02:~$ crontab -l
# m h  dom mon dow   command
*/15 * * * * /usr/local/rq-2.3.2/bin/rq /home/username/q feed --max_feed=8 >> /dev/null 2>&1
```
De esta forma, ya tenemos definido host02 como «feeder» de nuestros procesos. Este paso hay que repetirlo para todos los feeders que queramos añadir (host02-04).

Recordar que host01 (cenachero) no se debe usar como «feeder».

El/los host/s definido/s como feeder/s mediante el cron se «activarán» automáticamente cada 15 minutos para, en caso de tener recursos disponibles, hacerse cargo de uno o varios procesos de la cola q.

Otra forma de echar a andar manualmente, pero de forma inmediata, una cola en cualquier feeder es, una vez hecho el login en el host correspondiente, teclear:
```
~$ rq q start
```

Enviar procesos a la cola

Crear un archivo de proceso por lotes. Por ejemplo, el archivo joblist podría contener las líneas:

perl   /home/username/CpGcluster/CpGcluster.pl   /share/sec/hg18/chr1.fa 50 1E-5   /home/username/CpGcluster/chr1.cpg
perl   /home/username/CpGcluster/CpGcluster.pl   /share/sec/hg18/chrY.fa 50 1E-5   /home/username/CpGcluster/chrY.cpg
perl   /home/username/CpGcluster/CpGcluster.pl   /share/sec/hg18/chr2.fa 50 1E-5   /home/username/CpGcluster/chr2.cpg

Nótese

Se deben utilizar siempre rutas absolutas tanto para la ubicación del programa, como para la entrada/salida de datos.
Las secuencias de los cromosomas se leen del disco compartido (/share/sec/hg…).

Enviar esos procesos a la cola q:

~$ rq q s --infile=joblist

o bien

~$ rq q s - <joblist

El estado de la cola se puede consultar con:

Resumen (status):
```
~$ rq q t
```
Listado detallado (list) :
```
~$ rq q l
```

Ver procesos en ejecución (list running):

~$ rq q l r | grep command
 oliver@cenachero:~IsoFinderB$ rq ../q l r | grep command
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr1.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr2.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr3.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr4.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr5.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr6.fa 0.95  r 3000 /home/oliver/IsoFinderB/sal
    …
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr17.fa 0.95 r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr18.fa 0.95 r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr19.fa 0.95 r 3000 /home/oliver/IsoFinderB/sal
    command: /home/oliver/IsoFinderB/a.out /share/sec/hg18/chr20.fa 0.95 r 3000 /home/oliver/IsoFinderB/sal
 oliver@cenachero:~/IsoFinderB$

Ver las máquinas que están ejecutando procesos de la cola:

~$rq q l r | grep runner
 oliver@cenachero:~$ rq ../q l r | grep runner
    runner: host04
    runner: host04
    runner: host03
    runner: host03
    …
    runner: host03
    runner: host03
    runner: host02
    runner: host02
 oliver@cenachero:~$

A medida que se van enviando y ejecutando procesos, la base de datos que gestiona la cola se va llenando con información sobre procesos acabados, fallidos, etc. Para limpiar la cola de todo esto, se puede usar:
```
~$ rq q rotate
```
o bien, añadir esta línea al crontab del host01 (cenachero), para limpiar la cola diariamente:
```
59 23 * * * rq q rotate `date +q.%Y%m%d`
```

Más información en el Apéndice, o tecleando:

~$ rq help