• Centro de Supercomputación de Galicia
• J. I. López Cabido, P. González Gómez
• Grupo de Sistemas Autónomos, Escola Politécnica Superior de Ferrol, Universidade da Coruña
• R. Luaces, J. A. Becerra, R. J. Duro

Moitos dos problemas computacionais dos investigadores requiren complexos sistemas informáticos para ser resoltos. En múltiples ocasións, o elevado custo destes equipos non permite a resolución dos problemas. As tecnoloxías paralelas son un bo exemplo; un usuario pode ter un problema perfectamente escalable a un número elevado de procesadores (centos ou miles), aínda que normalmente o usuario non dispón de acceso a unha maquina destas características.

Entre os problemas paralelizables poderiamos considerar dous tipos: aqueles nos que existe unha grande cantidade de comunicación entre os distintos procesadores e por tanto precisan dunha arquitectura de comunicación dedicada a optimizar estas comunicacións; e aqueles problemas nos que a comunicación entre os distintos procesadores e moi escasa ou inexistente. No primeiro caso, o problema só pode ser resolto nunha máquina paralela convencional. … no segundo caso onde ten sentido unha plataforma do tipo do Superordenador VirtualGalego (SVG).

O proxecto do SVG baséase na idea de utiliza-la grande cantidade de ordenadores existentes na comunidade aproveitando os momentos nos que os usuarios non os están empregando. Debido á potencia que teñen na actualidade os ordenadores dos usuarios (fundamentalmente os PCs), é fácil decatarse do enorme potencial de computación existente e a idea de poder utilizar-lo e suficientemente atractiva como para abordar este proxecto.

Hoxe en día, as tecnoloxías para facer isto están dispoñibles e o proxecto podería abordarse de diferentes maneiras. De feito, se un usuario ten una conta en varias máquinas xa pode utiliza-los contornos de programación paralela para uni-los esforzos das diversas máquinas. Existen incluso varias iniciativas que aproveitan miles e mesmo millóns de ordenadores dispersos conectados pola rede Internet entre os que quizais o máis coñecido sexa o do proxecto SETI@home. O obxectivo do CESGA e proporcionar un mecanismo simple e ben definido para poder achegar este tipo de experiencias. O proxecto desenvólvese conxuntamente entre o CESGA e o Grupo de Sistemas Autónomos (GSA) da Universidade da Coruña. O CESGA traballa na definición e implantación da plataforma virtual de computación e o GSA desenvolve unha aplicación do mesmo a un problema concreto.

O esquema de funcionamento do SVG é o seguinte: certos usuarios ofrecen as súas máquinas ó SVG baixo un calendario establecido. Por exemplo, un usuario cede o seu PC polas noites. No ordenador do usuario instálase un programa monitor que vixía en cada momento a condición de activación en base ó calendario e a propia carga do usuario, de xeito que se o usuario comezase a traballar co seu ordenador o SVG deixaría automaticamente de utilizalo. Existe un xestor central de recursos que dispón en todo momento da información do estado de tódolos nodos asociados ó SVG. Unha aplicación de usuario que estivese correndo no SVG chegaría a un punto no que tivera que executar un cálculo en moitos nodos pediría ó xestor central do SVG a execución dun fragmento de programa nun número determinado de nodos. O xestor central, en base á dispoñibilidade de nodos nese momento, repartiría da maneira máis axeitada as diferentes execucións.

A estructura do Superordenador Virtual Galego (imaxe 1) pódese dividir en catro compoñentes diferenciados que se replican segundo se requira para a aplicación e en función dos recursos dispoñibles nun momento dado.

(1) Punto de Entrada: é unha máquina cun proceso java activo que permite ó usuario introduci-los seus programas (divididos en fragmentos) e todos aqueles parámetros de execución que se requiran. O punto de entrada comunícase cun Pool enviándolle os fragmentos proporcionados polo usuario para a súa distribución e execución nos nodos. Desde o Punto de Entrada o usuario pode consulta-lo estado dos seus procesos.

(2) Pool: encargado da distribución dos fragmentos proporcionados polo usuario entre os recursos proporcionados polo Servidor de Nodos. Para isto o Pool comunícase cos Puntos de Entrada, recibindo os procesos que requiren execución, comunícase co Servidor de Nodos, solicitando os recursos necesarios.

O Pool tamén se comunica cos nodos enviándolle os fragmentos que teñan que ser executados e solicitando ós nodos información sobre o estado dos procesos ante requirimentos dos Puntos de Entrada. Ademais o Pool xestiona copias de seguridade, redundancia e migracións de fragmentos.

(3) Servidor de Nodos: contén unha base de datos con tódolos nodos habilitados para a execución de fragmentos de código nun momento dado. Encárgase da xestión de altas e baixas, autentificación, etc. Comunícase co Pool para proporcionarlle recursos e informalo de modificacións nestes.

(4) Nodos: máquinas postas ó dispor do SVG para a execución de fragmentos de código. En cada nodo existe un monitor de actividade que indica ó Servidor deNodos cando está dispoñible para executar fragmentos e cando deixa de estalo. î incorporarse o nodo ó SVG, este daemon inicia a máquina virtual Java e a interface Java do SVG no nodo. Cada nodo conta tamén cunha interface Java do SVG que é a encargada de recibi-los fragmentos enviados polo Pool, executalos e xestiona-la comunicación co Pool.


Excepto o Servidor de Nodos e os Monitores de Actividade, tódolos compoñentes do SVG foron programados en Java. No tocante ó Servidor de Nodos e o Monitor de Actividade, estes servicios foron desenvolvidos en C para minimiza-lo impacto na utilización de recursos nos ordenadores cedidos como nodos do SVG. A liberdade na elección da linguaxe óptima para implementar estes servicios en cada sistema foi posible gracias á definición dun protocolo de comunicacións interno entre o Servidor de Nodos e o Pool.

Calquera proceso que pretendamos que aproveite as capacidades do SVG haberá de descompoñerse en fragmentos necesariamente programados en Java. O usuario é o responsable desta fragmentación, xa que é o propio usuario quen mellor coñece a aplicación que desexa executar.

Tódalas comunicacións dos compoñentes Java do SVG baséanse en RMI (Remote Method Invocation). Desta forma poderemos invocar métodos de clases remotas co conseguinte paso de parámetros e resultados entre máquinas, o único que debemos saber é o seu nome (hostname) ou a súa dirección IP. As demais comunicacións, isto é, entre o Pool e o Servidor de Nodos e entre o Servidor de Nodos e os nodos, Lévanse a cabo mediante Sockets empregando unprotocolo propietario.

A APLICACIÓN

A primeira aplicación que implementada no SVG contempla un tipo de procesos que requiren inxentes recursos de cálculo, pero que son intrinsecamente moi sinxelos de distribuír: procesos de optimización e deseño evolucionista. A idea deste tipo de algoritmos é utilizar operadores como os de selección, cruce e mutación para explorar en paralelo o espacio de solucións a un problema dunha forma eficiente partindo de múltiples puntos; e determina-la solución óptima,ou polo menos unha aceptable.

Este tipo de procesos son de fácil distribuición xa que, en moitos casos, o proceso de avaliar cada individuo é computacionalmente moitísimo máis custoso que o resto das tarefas que se realizan e en xeral, esta avaliación é independente da dos demais individuos. Un exemplo disto é o caso concreto que foi implementado: a evolución de controladores de robots autónomos. Para avaliar este tipo de controladores é necesario implementalos nun robot simulado dentro dun contorno de simulación realista e executalo durante un período de tempo de vida do robot.

Os resultados preliminares son moi alentadores xa que nos permitiron obter controladores dunha forma moi eficiente. De feito, neste tipo de procesos o speed up pro porcionado polo SVG é casi lineal e o feito de poder dispor dun grande nœmero de máquinas operando simultaneamente permite reducir execucións que tardan días ou incluso semanas nunha estación de traballo a horas ou incluso minutos no SVG.