Descripcion : Muchos de los problemas computacionales de los investigadores requieren complejos sistemas informáticos para ser resueltos. En múltiples ocasiones, el elevado coste de estos equipos no permite la resolución de los problemas. Las tecnologías paralelas son un buen ejemplo; un usuario puede tener un problema perfectamente escalable a un número elevado de procesadores (cientos o miles), aunque normalmente el usuario no dispone de acceso a una máquina de estas características.
Entre los problemas paralelizables podríamos considerar dos tipos: aquellos en los que existe una gran cantidad de comunicación entre los distintos procesadores y por tanto necesitan de una arquitectura de comunicación dedicada a optimizar estas comunicaciones y aquellos problemas en los que la comunicación entre los distintos procesadores es muy escasa o inexistente. En el primer caso, el problema solo puede ser resuelto en una máquina paralela convencional. Es en el segundo caso donde tiene sentido una plataforma del tipo del Superordenador VirtualGalego (SVG).
El proyecto del SVG se basa en la idea de utilizar la gran cantidad de ordenadores existentes en la comunidad aprovechando los momentos e los que los usuarios no los están utilizando. Debido a la potencia que tienen en la actualidad los ordenadores de los usuarios (fundamentalmente los PCs), es fácil darse cuenta del enorme potencial de computación existente y la idea de poder utilizarlo es suficientemente atractiva como para abordar este proyecto.
Hoy en día, las tecnologías para hacer esto están disponibles y el proyecto podría abordarse de diferentes maneras. De hecho, si un usuario tiene una cuenta en varias máquinas ya puede utilizar los entornos de programación paralela para unir los esfuerzos de las diversas máquinas. Existen incluso varias iniciativas que aprovechan miles e incluso millones de ordenadores dispersos conectados por la red Internet entre los que quizás el más conocido sea el del proyecto SETI@home. El objetivo del CESGA es proporcionar un mecanismo simple y bien definido para poder acercar este tipo de experiencias. El proyecto se desarrolla conjuntamente entre el CESGA y el Grupo de Sistemas Autónomos (GSA) de la Universidade da Coruña. El CESGA trabaja en la definición e implantación de la plataforma virtual de computación y el GSA desarrolla una aplicación del mismo a un problema concreto.
El esquema de funcionamiento del SVG es el siguiente: ciertos usuarios ofrecen sus máquinas al SVG bajo un calendario establecido. Por ejemplo, un usuario cede su PC por las noches. En el ordenador del usuario se instala un programa monitor que vigila en cada momento la condición de activación en base al calendario y a la propia carga del usuario, de forma que si el usuario comenzase a trabajar cos su ordenador el SVG dejaría automáticamente de utilizarlo. Existe un gestor central de recursos que dispone en todo momento de la información del estado de todo los nodos asociados al SVG. Una aplicación de usuario que estuviese corriendo en el SVG llegaría a un punto en el que tuviera que ejecutar un cálculo en muchos nodos pediría al gestor central del SVG la ejecución de un fragmento de programa en un número determinado de nodos. El gestor central, en base a la disponibilidad de nodos en ese momento, repartiría de la manera más adecuada las diferentes ejecuciones.
La estructura del Superordenador Virtual Galego (imagen 1) se puede dividir en cuatro componentes diferenciados que se replican según se requiera para la aplicación y en función de los recursos disponibles en un momento dado.
(1) Punto de Entrada: es una máquina con un proceso java activo que permite al usuario introducir sus programas (divididos en fragmentos) y todos aquellos parámetros de ejecución que se requieran. El punto de entrada se comunica con un Pool enviándole los fragmentos proporcionados por el usuario para su distribución y ejecución en los nodos. Desde el Punto de Entrada el usuario puede consultar el estado dode sus procesos.
(2) Pool: encargado de la distribución de los fragmentos proporcionados por el usuario entre los recursos proporcionados por el Servidor de Nodos. Para esto el Pool se comunica con los Puntos de Entrada, recibiendo los procesos que requieren ejecución, se comunica con el Servidor de Nodos, solicitando los recursos necesarios.
El Pool también se comunica con los nodos enviándole los fragmentos que tengan que ser ejecutados y solicitando los nodos información sobre el estado de los procesos ante requerimientos de los Puntos de Entrada. Además el Pool gestiona copias de seguridad, redundancia y migraciones de fragmentos.
(3) Servidor de Nodos: contiene una base de datos con todos los nodos habilitados para la ejecución de fragmentos de código en un momento dado. Se encarga de la gestión de altas y bajas, autentificación, etc. Se comunica con el Pool para proporcionarle recursos e informarlo de modificaciones en estos.
(4) Nodos: máquinas puestas a disposición del SVG para la ejecución de fragmentos de código. En cada nodo existe un monitor de actividad que indica al Servidor de Nodos cuando está disponible para ejecutar fragmentos y cuando deja de estarlo. Al incorporarse el nodo al SVG, este daemon inicia la máquina virtual Java y la interface Java del SVG en el nodo. Cada nodo cuenta también con una interface Java de SVG que es la encargada de recibir los fragmentos enviados por el Pool, ejecutarlos y gestionar la comunicación con el Pool.
Excepto el Servidor de Nodos y los Monitores de Actividad, todos los componentes del SVG fueron programados en Java. En lo tocante al Servidor de Nodos y al Monitor de Actividad, estos servicios fueron desarrollados en C para minimizar el impacto en la utilización de recursos en los ordenadores cedidos como nodos del SVG. La liberdad en la elección del lenguaje óptimo para implementar estos servicios en cada sistema fue posible gracias a la definición de un protocolo de comunicaciones interno entre el Servidor de Nodos y el Pool.
Cualquier proceso que pretendamos que aproveche las capacidades del SVG habrá de descomponerse en fragmentos necesariamente programados en Java. El usuario es el responsable de esta fragmentación, ya que es el propio usuario quien mejor conoce la aplicación que desea ejecutar.
Todas las comunicaciones de los componentes Java del SVG se basan en RMI (Remote Method Invocation). De esta forma podremos invocar métodos de clases remotas con el consiguiente paso de parámetros y resultados entre máquinas, el único que debemos saber es su nombre (hostname) o su dirección IP. Las demás comunicaciones, esto es, entre el Pool y el Servidor de Nodos y entre el Servidor de Nodos y los nodos, se llevan a cabo mediante Sockets empleando un protocolo propietario.
LA APLICACIÓN
La primera aplicación que implementada en el SVG contempla un tipo de procesos que requieren ingentes recursos de cálculo, pero que son intrinsecamente muy sencillos de distribuír: procesos de optimización y diseño evolucionista. La idea de este tipo de algoritmos es utilizar operadores como los de selección, cruce y mutación para explorar en paralelo el espacio de soluciones a un problema de una forma eficiente partiendo de múltiples puntos; y determinar la solución óptima, o por lo menos una aceptable.
Este tipo de procesos son de fácil distribuición ya que, en muchos casos, el proceso de evaluar cada individuo es computacionalmente muchísimo más costoso que el resto de las tareas que se realizan e en general, esta evaluación es independiente de la de los demás individuos. Un ejemplo de esto es el caso concreto que fue implementado: la evolución de controladores de robots autónomos. Para evaluar este tipo de controladores es necesario implementarlos en un robot simulado dentro de un entorno de simulación realista y ejecutarlo durante un período de tiempo de vida del robot.
Los resultados preliminares son muy alentadores ya que nos permitieron obtener controladores de una forma muy eficiente. De hecho, en este tipo de procesos el speed up pro porcionado por el SVG es casi lineal y el hecho de poder disponer de un gran número de máquinas operando simultáneamente permite reducir ejecuciones que tardan días o incluso semanas en una estación de trabajo a horas o incluso minutos en el SVG. |
cesga.es
:: Telf.: +34 981 569810 - Fax: 981 594616 ::
Avda. de Vigo s/n 15705, Santiago de Compostela.