Arquitectura de CLUES

CLUES tiene una arquitectura completamente modular cuyo objetivo principal es que sea fácilmente adaptable a prácticamente cualquier sistema de gestión de clusters, y que pueda integrarse con prácticamente cualquier infraestructura.

El resultado del diseño puede verse en la siguiente figura, en la que se destacan los componentes principales de CLUES.

La arquitectura consta de un componente principal, que es el gestor CLUES que utiliza una serie de conectores con los gestores del cluster y un conjunto de mecanismos de encendido y apagado de máquinas.

Todos estos componentes requieren una única instalación en el equipo principal (front-end) que se utiliza para realizar la gestión del cluster.

Conectores con los middlewares de Gestión

Estos conectores tienen dos tareas principales: la captura de las solicitudes de trabajo y la monitorización de la utilización de los nodos por parte del middleware de gestión.

Captura de solicitudes de trabajo

Muchos gestores de cluster (como Torque/PBS o OpenNebula) incorporan mecanismos que permiten realizar acciones en el momento de lanzar un trabajo a la cola de su planificador. Esta es una forma muy adecuada de interceptar trabajos ya que permite integrar el middleware de gestión con CLUES siguiendo su propia arquitectura.

En caso de que esta posibilidad no se encuentre disponible, siempre es posible escribir una aplicación o script que sustituya a la llamada real, que se encargue de integrar el middleware con CLUES y que posteriormente haga la llamada efectiva a la aplicación real.

Como aspecto avanzado, es posible desarrollar planificadores específicos que se comuniquen con CLUES mediante su API, y que hagan la solicitud de recursos de forma expresa. Si bien este es el aspecto que permite realizar una mejor gestión, en todo momento se puede tratar de seguir las aproximaciones anteriores para no modificar los sistemas de gestión reales.

Monitorización

Prácticamente cualquier middleware de gestión de clusters incorpora comandos para comprobar el estado en que se encuentran los nodos de trabajo (por ejemplo, el comando "pbsnodes" en el caso de Torque, o los comandos "onehost" y "onevm" en el caso de OpenNebula). Así, podemos utilizar estos comandos para comunicar a CLUES el estado de utilización de la infraestructura por parte del subsistema en concreto.

Para conseguir resultados más adecuados, en algunos sistemas como OpenNebula resulta muy sencillo realizar aplicaciones que, utilizando su propia API, pueden proporcionar una información mucho más actualizada y extendida.

Integración con la infraestructura

No todos los clusters son iguales, empezando por la plataforma (Windows, Linux, etc.) y continuando por la disponibilidad de características de encendido remoto diversas, como Wake-on-Lan (que permite encender un equipo enviando información a la tarjeta de red) o sistemas basados en Power Device Units (que permiten proporcionar energía o no a determinados equipos).

Los plugins de integración con la infraestructura pretenden resolver esta diversidad, permitiendo utilizar comandos personalizados que enciendan o apaguen los equipos utilizando los mecanismos específicos de nuestro cluster.

Mecanismo de hooks

Además de estos componentes, CLUES incorpora un mecanismo de hooks muy completo que permite realizar acciones específicas para cada subsistema de gestión del cluster, en los momentos en que ocurran acciones relevantes en el estado del cluster (por ejemplo, el encendido o apagado de un nodo, la detección de encendidos o apagados inesperados, etc.).