Los centros de cálculo utilizados por corporaciones empresariales, centros de investigación e instituciones similares utilizan desde hace años la configuración en cluster como alternativa al más tradicional mainframe, conectando un gran número de nodos entre sí para poder ofrecer así una potencia de cálculo igual o superior a la que se tendría con un big iron. Las personas que necesitan trabajar con este tipo de configuraciones lo hacen normalmente de forma remota o bien a través de un nodo que actúa como cabecera del cluster, facilitando las operaciones de supervisión y administración.
Actualmente cualquier persona con unos conocimientos algo por encima de lo que podría considerar "básico" puede montarse su propio cluster en casa, aunque personalmente creo que esta posibilidad tiene especial interés para los programadores. Seguramente muchos preguntarán "¿para qué quiero yo un cluster en casa?". Cualquiera que necesite ejecutar tareas con una alta demanda de potencia de proceso, programas que pueden emplear horas, días o semanas trabajando con unos datos para generar resultados, pueden beneficiarse de este tipo de configuración dividiendo la tarea original en otras más pequeñas (siguiendo la máxima del divide y vencerás) que pueden ser ejecutadas en paralelo en varias máquinas. Más allá de la utilidad práctica e inmediata, no obstante, para los que siempre buscamos aprender y experimentar sencillamente no es necesario buscar una respuesta a la anterior pregunta. Si puedo hacerlo, ¿por qué no voy a hacerlo? 8-)
Para poder configurar un cluster necesitamos utilizar, lógicamente, una combinación de hardware y software, a saber:
- Ordenadores: Dos o más máquinas que actuarán como nodos del cluster. No es necesario que sean equipos muy potentes, en mi caso he usado cuatro máquinas que tenía con poco uso, portátiles antiguos con entre 2 y 4 Gbytes de memoria RAM. Dado que la idea es mantenerlos en funcionamiento ininterrumpido durante mucho tiempo, cuanto más reducido sea su consumo menor será también el gasto energético, de ahí mi elección de usar ordenadores portátiles con poca potencia.
- Conmutador: Las máquinas del cluster necesitarán comunicarse continuamente y precisan para ello un canal de alta velocidad, de forma que las máquinas no tengan que estar esperando para poder acceder a datos compartidos o recibir comandos. En este entorno doméstico lo ideal es utilizar un conmutador o switch de tipo Gigabit Ethernet, con su correspondiente cable a cada máquina.
- SAI: Si realmente vamos a usar el cluster para ejecutar procesos de cierta importancia, no solamente como experimentación, nos vendrá bien contar con un sistema de alimentación que evite la caída en caso de un corte eléctrico momentáneo.
- Sistema operativo: Todas las máquinas del cluster ejecutarán el mismo sistema operativo, normalmente con una configuración idéntica para así evitar fallos de compatibilidad y poder ejecutar un mismo programa en cualquiera de los nodos sin ningún problema. Aunque podrían uitlizarse otros, la mejor opción para montar un cluster en la actualidad es GNU/Linux. En mi caso he utilizado Ubuntu.
- Sistema de supervisión y gestión del cluster: Sobre el sistema operativo será necesario agregar el software que facilite la supervisión del cluster y su administración, de forma que la carga de trabajo pendiente se distribuya de manera automática entre las máquinas disponibles. Hay varias opciones a nuestra disposición, entre las que yo he optado por SGE (Sun Grid Engine) simplemente porque es un software que conozco al haberlo usado en los clusters de varias universidades.
La instalación del hardware no requiere ningún comentario adicional: basta con conectar los equipos a la fuente de alimentación, por una parte, y al conmutador Ethernet que les permitirá comunicarse, por otra. A la hora de configurar el software, por el contrario, sí es necesario tener en cuenta algunos detalles importantes.
Configuración del sistema operativo
No voy a entrar aquí en el proceso de instalación de Ubuntu en los ordenadores, es realmente sencillo y en la web hay disponible infinidad de información al respecto. Sí es importante, como indiqué antes, que se instale la misma versión y para la misma arquitectura (x86 o x64) en todas los nodos para así evitar posteriores problemas de configuración. En cuanto a la configuración IP, aunque podría usarse DHCP aconsejo que se asigne a cada máquina una dirección IP fija y que se utilice el mismo archivo /etc/hosts
en todas ellas para facilitar la comunicación.
De los nodos que componen el cluster uno ha de operar como coordinador (maestro), supervisando la carga de trabajo de los demás y decidiendo cómo se distribuye la cola de tareas pendientes. Esta máquina será también la que ofrezca el almacenamiento compartido en disco del cluster, haciendo así posible que todas las máquinas operen con el mismo programa y sobre los mismos datos sin necesidad de copiarlos en cada una de ellas. Si este nodo maestro es una máquina poco potente y con escasa memoria puede dedicarse exclusivamente a esta tarea, pero de lo contrario puede tener una personalidad dual: actuando como nodo maestro del cluster pero también como nodo de ejecución. El resto de las máquinas del cluster serán únicamente nodos de ejecución.
En el nodo maestro crearemos el directorio que alojará los programas y datos a usar en el cluster. Para que el resto de nodos tengan acceso a ellos habremos de dar los pasos siguientes:
- Instalar
nfs-kernel-server
yportmap
en el nodo maestro. Agregar al archivo/etc/exports
el directorio creado antes y ejecutarexportfs -a
- Instalar en los demás nodos
nfs-common
, crear el directorio donde queremos montar el espacio compartido y montarlo consudo mount IP_maestro:/directorio_compartido directorio_montaje
. En la captura inferior aparte de montar el espacio compartido se ha hecho una prueba, comprobando que estaba vacío, a continuación creando un archivo de texto desde un nodo y comprobando desde otro que podía accederse al mismo. - Para evitar tener que ejecutar los comandos de exportación (nodo maestro) y montaje (nodos de ejecución) tras cada reinicio podemos actualizar el archivo
/etc/fstab
de cada máquina.
Instalación y configuración de SGE
Completada la configuración del sistema llega el momento de instalar SGE, el software que se encargará de la gestión y administración de colas de trabajo en el cluster. En el nodo maestro ejecutaremos sudo apt-get install gridengine-master gridengine-qmon gridengine-common gridengine-client gridengine-exec
, en el resto de nodos el comando a usar será sudo apt-get install gridengine-client gridengine-exec
. Durante la instalación aparecerán cuadros de diálogo como el de la imagen siguiente solicitando algunos datos. Dejamos los valores propuestos por defecto salvo para el nombre de la máquina maestra que, como es lógico, será el del nodo configurado con ese perfil.
Tras reiniciar las máquinas, a fin de poner en marcha los demonios encargados de los servicios de SGE, llega el momento de configurar el cluster desde un punto de vista lógico. Para ello, en el nodo maestro, ejecutaremos sudo qmon
y usaremos las siguientes opciones de este programa:
- Host Configuration: Para establecer el nombre del nodo maestro y los nodos de ejecución.
- User Configuration: Definiendo los usuarios que podrán enviar trabajos al cluster.
- Queue Control: Estableciendo las colas de trabajo que existirán y las máquinas asociadas.
En un cluster pequeño, como el propuesto, lo normal es que tengamos una sola cola y que estén vinculadas a ella todos los nodos. De esta manera los usuarios podrán enviar sus ejecuciones a dicha cola y SGE se encargará de distribuir el trabajo entre todas las máquinas. Cuando se trabaja con un cluster de mayor tamaño es habitual contar con varias colas, por ejemplo dependiendo de la cantidad de memoria o la potencia de proceso de las máquinas, agrupándolas de forma que los trabajos se envíen a los nodos más adecuados a cada necesidad.
La guía de usuario de Grid Engine de Oracle ofrece una introducción al uso de este software y detalla el uso de qmon
y otras utilidades.
Ejecución de tareas
Una vez que el cluster esté en funcionamiento llega el momento de aprovecharlo. Los trabajos se lanzarán siempre desde el nodo maestro, indicándole mediante un script el nombre del trabajo, la cola a que debe enviarse y el programa que es necesario ejecutar. Dicho guión se facilita a SGE mediante el comando qsub
. Un ejemplo de guión podría ser el siguiente:
Podemos crear tantos script como necesitemos y enviarlos uno tras otro con qsub
a la cola de ejecución. También existe la posibilidad de que un mismo guión genere una lista o array de tareas. En cualquier caso, tras enviar los trabajos podemos comprobar su estado mediante el comando qstat
que, entre otras cosas, mostrará cuáles de nuestras tareas están ejecutándose, indicando en qué máquinas, y cuáles están aun en espera. Con el comando qhost
se obtiene información sobre el estado de los nodos: carga de trabajo de cada una, memoria en uso y disponible, etc. En la wiki How to Use Sun Grid Engine podemos encontrar información sobre esos y otros muchos comandos de SGE. Obviamente también podemos consultar la documentación que se instala con dicho software.
Lógicamente SGE cuenta con muchos otros comandos, hay más parámetros de configuración y multitud de detalles relativos a la preparación de scripts de ejecución de tareas, pero sobre todo ello es fácil encontrar información en la web una vez que se sabe qué es lo que hay que buscar. La finalidad de este artículo ha sido esbozar el procedimiento general y facilitar algunas referencias útiles que permitan a cualquiera montar su propio cluster.