Interoperabilidad en redes heterogéneas de computadores

Transcripción

1 Interoperabilidad en redes heterogéneas de computadores Introducción a la computación distribuida y paralela La computación distribuida es un modelo para resolver problemas de computación masiva utilizando un gran número de computadoras en una infraestructura de telecomunicaciones distribuida. Este paradigma consiste en compartir recursos heterogéneos (basados en distintas plataformas, arquitecturas de equipos y programas, lenguajes de programación), situados en distintos lugares y pertenecientes a diferentes dominios de administración sobre una red que utiliza estándares abiertos. Dicho brevemente, consiste en virtualizar los recursos informáticos. Es un paradigma pensado para resolver problemas demasiado grandes para cualquier supercomputadora, mientras se mantiene la flexibilidad de trabajar en múltiples problemas más pequeños. Puesto que se trabaja en un entorno multi usuario, las técnicas de seguridad son esenciales antes de permitir que los recursos informáticos sean controlados por usuarios remotos. Se trata de un tipo de computación paralela, en el que además de paralelizar el programa a ejecutar, hay que tener en cuenta los diferentes entornos y plataformas en los que se ejecutará cada trozo del problema. Por ejemplo, dos computadoras en red seguramente tengan diferentes sistemas de ficheros y hardware. La computación distribuida es un resultado natural del uso de las redes para comunicar eficientemente los computadores. Otro concepto importante a distinguir es networking. En este caso nos estaremos refiriendo a varias máquinas interaccionando, pero no necesariamente compartiendo la carga computacional de un programa (eso sí se da en la computación distribuida). Más adelante estudiaremos DREAM y gsoap que están pensados para hacer computación distribuida. La interacción entre máquinas es muy importante en una red heterogénea, de forma que las comunicaciones y los protocolos deben ser entendibles por todas las máquinas que en un momento dado se puedan conectar a la red. Otro factor muy importante es la posibilidad de enviar el software o trozo de programa a ejecutar en otra máquina a través de la red. Debe hacerse en un formato portable y entendible por todas las arquitecturas. Veremos que DREAM, al usar java, incluye esta característica. Hay muchos tipos de sistemas de computación distribuida. El objetivo principal de estos es conectar usuarios y recursos de forma transparente, abierta y escalable. En este sentido, los protocolos estándar de servicios web permiten crear sistemas abiertos y escalables (que se pueden adaptar fácilmente al 1

2 crecer el número de usuarios y/o recursos conectados). Por otro lado, es deseable que el sistema distribuido no se vea afectado si un nodo de computación deja de estar disponible en un momento dado. No todos los sistemas lo permiten, por ejemplo, en un cluster, si una máquina deja de funcionar, puede verse afectado el funcionamiento del resto de máquinas. Además, en un sistema en el que haya una dependencia del ancho de banda o la latencia de las comunicaciones, el rendimiento se puede ver afectado. En este tipo de desarrollos se utilizan multicomputadores, compuestos por varias máquinas independientes comunicadas con una red. Estas máquinas pueden ser homogéneas (todas las CPU son similares) o heterogéneas (arquitecturas y plataformas diferentes). Al desarrollar un sistema de este tipo, se suelen hacer algunas suposiciones para simplificar el problema de las comunicaciones. Sin embargo, hay que tener en cuenta los siguientes puntos: 1. la red no siempre es fiable 2. la latencia no es cero 3. el ancho de banda no es infinito 4. la red no es segura 5. la topología de red puede cambiar 6. no siempre habrá una administración centralizada 7. existe un coste en las comunicaciones 8. la red es heterogénea Clasificación atendiendo a la forma de distribuir la carga computacional Computación de ciclos redundantes El modelo de computación de ciclos redundantes, también conocido como computación zombi, es el empleado por aplicaciones como Seti@Home, consistente en que un servidor o grupo de servidores distribuyen trabajo de procesamiento a un grupo de computadoras que ceden voluntariamente capacidad de procesamiento no utilizada. Básicamente, cuando dejamos nuestro ordenador encendido, pero sin utilizarlo, la capacidad de procesamiento se desperdicia por lo general en algún protector de pantalla. Este tipo de procesamiento distribuido utiliza nuestra computadora cuando nosotros no la necesitamos, aprovechando al máximo la capacidad de procesamiento. Clustering Otro método para crear sistemas de supercomputadoras es el clustering. Un cluster de computadoras consiste en un grupo de computadoras de relativo bajo costo conectadas entre sí mediante un sistema de red de alta velocidad (gigabit de fibra óptica por lo general) y un software que realiza la distribución de la carga de trabajo entre los equipos. Por lo general, éste tipo de sistemas cuentan con un centro de almacenamiento de datos único. 2

3 Grid La computación en grid es un paradigma de computación distribuida en el cual todos los recursos de un número indeterminado de computadoras son englobados para ser tratados como un único superordenador de manera transparente. Estas computadoras no están conectadas o enlazadas firmemente, es decir no tienen por qué estar en el mismo lugar geográfico. Existen diferencias respecto a otros tipos de computación distribuida: en un SSI (Single System Image) todas las computadoras vinculadas dependen de un sistema operativo común, diseñado al efecto. En cambio, un grid es heterogéneo, en el sentido en que las computadoras pueden tener diferentes sistemas operativos. Entre otros sistemas operativos de tipo SSI, cabe destacar BProc, Mosix/OpenMosix, OpenSSI, Plurix o TruCluster. Por otro lado, en un cluster todos los nodos se encuentran en el mismo lugar, conectados por una red local y así englobar todos lo recursos, en cambio en un grid no tienen por qué estar en el mismo espacio geográfico, pueden estar en diferentes puntos del mundo. Sistema distribuido La programación distribuida es un paradigma de programación enfocado a desarrollar sistemas distribuidos, abiertos, escalables, transparentes y tolerantes a fallos. Este paradigma es el resultado natural del uso de las computadoras y las redes. Los sistemas distribuidos están diseñados para que muchos usuarios trabajen en forma conjunta. Ej: Sistema de automatización de una fábrica donde el sistema distribuido controla los robots y máquinas en la línea de montaje. Es un sistema formado por varios componentes, hardware y/o software, localizados en diferentes dispositivos, conectados en red, comunicados y coordinados (no poseen memoria compartida por lo que no se pueden utilizar formas de sincronización como monitores o semáforos). Un sistema distribuido puede verse como un sistema formado por varios ordenadores haciendo algo conjuntamente, de lo que se desprenden tres características inmediatas: Compuesto por múltiples ordenadores. Un sistema distribuido está compuesto de más de un sistema independiente, cada uno con una o más CPU, memoria local, memoria secundaria (discos) y, en general, conexiones con periféricos deacceso inmediato (on line). Hay interconexión entre ellos. Parece claro que si varios ordenadores distintos van a colaborar en la realización de tareas, deben comunicarse y sincronizarse entre ellos, por lo que debe haber alguna línea o red de interconexión. Tienen un estado compartido. Si los ordenadores realizan un trabajo conjuntamente, deben mantener un estado compartido, es decir, todos los ordenadores tienen la misma visión del 3

4 estado del sistema distribuido (tablas, bases de datos del sistema, de servidores, etc.). Terminología en computación paralela (recordatorio) Algunos términos importantes a recordar sobre computación paralela son: Parallel Overhead: el trabajo extra asociado a la versión paralela comparado con la versión secuencial. Tiene que ver con el coste en CPU y memoria para sincronización, comunicaciones, etc. Sincronización: la coordinación de varias tareas simultáneas. Tarea: una sección discreta e independiente de trabajo computacional. Se suele ejecutar en un procesador como un programa. Ganancia ( speedup ): tiempo de ejecución de la versión secuencial del algoritmo dividido entre el tiempo de la versión paralela. Suele llegar un punto en el que añadir nuevos procesadores no hace subir la ganancia. A partir de ese momento, el sistema pierde escalabilidad y no merecerá la pena desembolsar más dinero para adquirir más procesadores, ya que la mejora no compensará. Sin embargo, si se disponen de muchas máquinas y no supone un desembolso configurarlas y añadirlas a la red (computación distribuida en redes heterogéneas), cualquier ganacia, por pequeña, valdrá la pena. S = T 1 / T p Escalabilidad: capacidad de incrementar proporcionalmente la ganancia al añadir más procesadores. Rendimiento (eficiencia): en la práctica es muy complicado alcanzar una ganancia lineal (proporcional al número de procesadores) debido a que muchos algoritmos tienen muchas secciones de código secuenciales. De hecho, algunos algoritmos no pueden ser paralelizados. E = S / p Fracción serie: La fracción serie es una medida que permite determinar si la pérdida de eficiencia ante un aumento del número de nodos se debe a las partes del programa que no se ejecutan en paralelo. Si la ganancia de velocidad es baja pero la fracción serie permanece constante, se puede afirmar que los resultados son buenos. f = ( 1/S 1/p ) / ( 1 1/p ) Para medir cómo de bien funciona un sistema paralelo se suele utilizar la medida de la ganancia de velocidad y la fracción serie. La ganancia de velocidad se toma respecto al sistema más rápido. Además, si se disponen de varias máquinas diferentes, se va añadiendo la mejor máquina de las 4

5 disponibles, hasta completar un máximo de nodos. De esta forma se puede garantizar que si la ganancia obtenida es superior a la unidad, el rendimiento del sistema paralelo es superior al de cualquier sistema monoprocesador. Comunicaciones e interoperabilidad Ultimamente están suscitando un enorme interés las plataformas y los sistemas distribuidos a gran escala, comprendidos los sistemas a base de redes denominadas GRIDS (Global Resources Information Database) que permiten aportar soluciones eficaces a problemas complejos en campos como el medio ambiente, la energía, la salud, el transporte, y el diseño industrial. En este curso incidiremos en los aspectos relacionados con la configuración de las plataformas que tengan que ver con la mejora de las prestaciones de comunicación. Con el estudio de las redes de computadores heterogéneos se persigue disponer de recursos de altas prestaciones a costes reducidos, y perseguimos también facilitar el acceso a los resultados de nuestra investigación, aprovechando para ello la tecnología de Internet. También queremos presentar el desarrollo de métodos y herramientas potentes y flexibles, tanto para el trabajo individual como en cooperación y en grupo. En el contexto de una red la interoperabilidad se refiere a protocolos comunes. Debemos pensar en una arquitectura de protocolos que definan los mecanismos básicos para la negociación, manejo, compartición y la utilización de los recursos. La arquitectura basada en estándares facilita la extensibilidad, interoperabilidad, portabilidad y compartición de código; los protocolos estándares hacen más fácil definir servicios. Se pueden construir interfaces de aplicaciones para programación y kits de desarrollo de software que provean abstracciones de programación requeridas. Recientemente están siendo objeto de un enorme interés los clusters de computadores, arquitecturas paralelas basadas en computadores personales o estaciones de trabajo, conectados mediante redes de comunicación como Giga Ethernet, ATM, ServerNet, SCI, Autonet, Memory Channel, Synfinity, HiPPI, Myrinet, Infiniband, QsNet, etc. Estos sistemas ofrecen la posibilidad de aprovechar el procesamiento paralelo para conseguir una potencia de cómputo elevada a un coste mucho menor que otras arquitecturas multi procesador al utilizar elementos hardware estándar, para los que existe un amplio mercado, con volúmenes de ventas significativos, y donde es más fácil repercutir los costes de investigación y desarrollo necesarios para producir elementos con mejores prestaciones. 5

6 Estructura de un cluster de ordenadores homogéneos. Es evidente que, para que el paralelismo constituya una herramienta ámpliamente utilizada en la práctica, es preciso que su utilidad quede patente en este tipo de sistemas, que están al alcance de prácticamente todas las empresas, centros de investigación y desarrollo, etc. Además, si es posible resolver una aplicación computacionalmente costosa en un sistema del que ya se dispone o que resulta relativamente barato de adquirir o configurar, el desarrollo de software paralelo es todavía más importante. Por lo tanto, el uso de clusters y el desarrollo de procedimientos paralelos eficaces para aprovechar su capacidad tiene un enorme interés, puesto que permite ampliar el conjunto de aplicaciones abordables, no sólo técnicamente, sino también de forma económicamente rentable. Otra línea de investigación que cobra cada vez más importancia la constituye la computación en grid (grid computing). Se trata de integrar recursos distribuidos de forma que un usuario conectado a uno de los computadores pueda disfrutar de la funcionalidad y las prestaciones del sistema completo con total transparencia. Si el ancho de banda de comunicación crece, la ubicación de la potencia de cálculo pierde importancia y es posible configurar plataformas de altas prestaciones a partir de redes de computadores distribuidos geográficamente. La imagen que se impone es la de una red de cómputo con características de ubicuidad, disponibilidad, y transparencia similares a las de la red eléctrica. No sólo las aplicaciones que requieren altas prestaciones de cómputo, típicas en ciencia, ingeniería, y negocios, aprovecharían las posibilidades de esta tecnología sino también la exploración de datos, el trabajo cooperativo, y todas las aplicaciones que requieren alto rendimiento y fiabilidad. Desde el punto de vista de la investigación en el área de arquitectura de computadores, la implementación de una estructura de 6

7 computación en grid implica abordar problemas de gran interés relacionados con la heterogeneidad, la escalabilidad, la adaptabilidad y fiabilidad de las plataformas, y el desarrollo de una capa intermedia (middleware) que permita el acceso transparente a los recursos utilizados. Estructura de una red de computadores heterogéneos. Uno de los principales problemas que trae aparejada la implementación de la computación grid es la forma en que se administrarán los recursos que son parte de su infraestructura. Los recursos que utiliza la computación grid se dividen en: Recursos que forman parte de la infraestructura, tales como recursos de hardware, de software y de red. Recursos que forman parte de los requerimientos; por ejemplo, el tiempo que se dispone de los recursos de infraestructura, los datos requeridos para un proceso dado, etc. Por ser un sistema de cómputo distribuido, la computación grid presenta problemas típicos de éstos, por ejemplo a la hora de acceder a los recursos de cómputos y a los de red. Como se trata de un sistema dinámico, los recursos cambian, y por lo tanto se deben utilizar sistemas que se encarguen de buscar recursos disponibles. De la misma forma en que se pueden agregar nodos que aporten recursos, más tarde pueden desaparecer, reduciéndose los recursos que aportaban y el software que pudieran tener. También puede haber pérdida de recursos por un fallo en las comunicaciones. Para optimizar las infraestructuras distribuidas que forman el grid y facilitar su utilización, surge la necesidad de una arquitectura global que se encargue de prestar los servicios de asignación y planificación de recursos. En este sentido, una red de aplicación (Application Level Network, ALN) es una abstracción de red que integra diferentes redes de recubrimiento (sistemas grid y P2P) sobre la red física de Internet. Una característica común a las ALN es la redundancia, acceso distribuido a los datos y servicios de 7

8 computación, al tiempo que oculta la hetereogeneidad de los servicios y recursos al usuario final. Son arquitecturas de software que coordinan ciertos servicios que requieren muchos recursos por medio de la conexión de un alto número de computadores (arquitecturas grid o P2P). El objetivo de la ALN es dar servicio de forma que se minimice el número de peticiones rechazadas, y a la vez se optimice el coste. Un requisito de las ALN es implementar mecanismos escalables, dinámicos y adaptables. Estos temas se están llevando a cabo en diversos proyectos, como Globus, Legion, Gridbus, GridLab, Ibis, Nimrod/G, CATNETS, Jini, JXTA, IrisGRID y Gnutella. Clusters y computación en GRID Estas propuestas consideran plataformas de cómputo basadas en sistemas heterogéneos de computadores y clusters conectados en red para implementar eficazmente las aplicaciones en las que se utilizan los procedimientos paralelos desarrollados. Gracias a la disponibilidad y a los niveles de prestaciones que podrían alcanzarse en las plataformas indicadas, el procesamiento paralelo puede constituir una solución rentable en muchos entornos en los que no es posible una inversión elevada en computadores de altas prestaciones (pequeñas y medianas empresas) y hace a su vez aflorar gran cantidad de problemas interesantes que ahora sí pueden ser abordados. Para la ejecución eficiente de una aplicación hay que tener en cuenta el tipo de paralelismo que puede aprovecharse y confrontarlo con las características concretas de la plataforma donde se piensa ejecutar. Muchos problemas constan de una serie de unidades interrelacionadas, de forma que cada una de ellas es un problema en sí; el número de módulos concurrentes es relativamente pequeño y puede implementarse de forma eficaz en entornos distribuidos, ya que la latencia de comunicación entre los módulos asociados a los problemas es menos crítica y las necesidades de ancho de banda son menores. En estos casos, cada módulo (predicción, aproximación funcional, simulación, optimización, etc.) corresponde a un problema diferente que se puede implementar en un cluster o computador distinto. Estas máquinas pueden estar distribuidas geográficamente y encontrarse conectadas por redes que no tienen que ofrecer unas prestaciones de comunicación elevadas. Gracias a la masiva conexión de equipos a través de redes de área local y área amplia, resulta posible configurar plataformas de este tipo con unas características bastante interesantes desde el punto de vista del acceso a aplicaciones con grandes volúmenes de cómputo y de datos, ejecutadas eficazmente gracias al trabajo cooperativo y coordinado de las plataformas de cómputo interconectadas. A medida que el ancho de banda disponible para la comunicación aumenta, la ubicación de los 8

9 recursos de cómputo se hace más irrelevante. El uso de plataformas conectadas a través de Internet para configurar sistemas de cómputo distribuido con gran cantidad de nodos, ha pasado a ser el nuevo paradigma, tras los clusters, para disponer de sistemas con mayores capacidades de cómputo y almacenamiento, y costos reducidos. Se trata de integrar recursos distribuidos de forma que un usuario conectado a uno de los computadores pueda disfrutar de la funcionalidad y las prestaciones del sistema completo con total transparencia. Existen muchos entornos socio económicos que pueden verse beneficiados de esta posibilidad. Las empresas, o las instituciones de investigación y desarrollo distribuidas geográficamente pueden aprovechar así todos sus recursos de forma cooperativa haciendo interactuar códigos que se ejecutan en plataformas diversas soportando aplicaciones integradas. Por otro lado, sería deseable que las empresas con aplicaciones cuya resolución necesita de computadores de altas prestaciones, pero que no pueden disponer de arquitecturas de supercomputación propias, puedan acceder a plataformas potentes a través de internet, manteniendo la integridad de sus datos y sin tener que adquirir nuevos recursos hardware o software. Se trata de una alternativa interesante dados los tiempos cada vez más reducidos de depreciación de los equipos hardware, y los costos crecientes de adquisición, instalación, mantenimiento y gestión de las plataformas y las aplicaciones. La configuración de un metacomputador plantea ciertos problemas relacionados con el diseño de aplicaciones. Los aspectos clave que deben resolverse son los siguientes: Programabilidad. Los programas deben desarrollarse para una máquina virtual uniforme y predecible ya que el usuario no tiene que conocer las características de todas las máquinas que se utilizan en la aplicación. De esta forma el sistema operativo debe implementar la máquina virtual y permitir que el modelo de programación sea independiente del entorno de ejecución. El usuario no tiene por qué saber en qué máquina se ejecuta cada proceso. Entorno de ejecución dinámico. No se puede predecir qué máquinas serán accesibles para ejecutar una aplicación en un momento dado. Algo análogo ocurre con la conectividad de la red y los retardos. Esta situación es mucho más patente que en el caso de los clusters. Heterogeneidad y portabilidad. Las máquinas accesibles a través de internet tienen arquitecturas y sistemas operativos diferentes, y están conectadas por redes distintas. Seguridad y accesibilidad. Para permitir que procesos extraños se ejecuten en una máquina se necesitan garantías del tipo de uso que se va a hacer de la máquina. En una red de área local es más sencillo restringir el acceso sólo a ciertos usuarios fiables. Escalabilidad. Sin escalabilidad, un sistema metacomputador no tiene mucho sentido puesto que no se podría aprovechar la cooperación de muchos computadores. Existen infraestructuras de metacomputación que aportan soluciones más o menos aceptables a algunos de estos problemas. Entre otros, se pueden destacar Legion, Globus, SNIPE, DISCWorld, Javelin, Bayanihan, Ibis, JXTA, etc. 9

10 En cualquier caso, como se ha visto, la configuración de entornos de metacomputación plantea una amplia gama de problemas, existiendo un largo camino por recorrer hasta encontrar soluciones integrales verdaderamente eficientes. ALN: Application Level Networks Según lo descrito hasta ahora, estamos interesados en el problema de la heterogeneidad y portabilidad, las comunicaciones y la interoperabilidad de módulos paralelos ejecutados en máquinas distribuidas y conectadas entre sí. En relación con esto, las ALN son una capa de software que gestionan ciertos servicios que requieren muchos recursos, por medio de la conexión de un alto número de computadores (tipo grid o P2P). Sobre la red física se ejecuta la ALN y cada nodo pasa a ejecutar la máquina virtual de forma que pasa a esperar instancias de experimentos al tiempo que daría servicio a los usuarios de la máquina, de forma similar a P2P. Las ALN tienen como objetivo atender las peticiones de servicio, minimizando el número de peticiones no atendidas y el coste. Conforme la oferta y demanda de servicio (carga computacional en los nodos) varía, el sistema debe reconfigurar los recursos tal que la disponibilidad y el uso de estos sea eficiente. La entrada o salida de nodos a la red variará la cantidad de recursos disponibles en ese momento. Por último, la utilización de mecanismos centralizados para la asignación de recursos (como en ciertas plataformas implementadas a partir de GLOBUS o CONDOR G) tiene inconvenientes. Afrontarlo de forma emergente (manejado de forma coherente por los nodos, sin necesidad de un gestor centralizado) parece una mejor opción. La red debe exhibir un comportamiento optimizado en cuanto a poca sobrecarga de las comunicaciones, rapidez en éstas, y mínimo coste. Objetivos de este curso Este curso pretende ofrecer una información detallada acerca del diseño e implementación de redes de aplicación que mapeen una red heterogénea de computadores para integrar recursos distribuidos de forma que un usuario disponga de toda la funcionalidad y potencia con transparencia. Estudiaremos diferentes opciones para desarrollar plataformas de computación paralela basadas en redes distribuidas heterogéneas, cuyo funcionamiento sea lo más sencillo y accesible posible. Para ello se usarán capas software (red de aplicación) de forma que en cada nodo haya una máquina virtual que haga de interfaz para la capa de algoritmos. También se analizará la forma en que se deben establecer las comunicaciones y conexiones entre los 10

11 nodos disponibles en la red a la hora de lanzar un experimento, de forma que sea una tarea automática, transparente al usuario. En lo posible se usarán esquemas descentralizados y adaptables, que tengan en cuenta los recursos disponibles en cada instante, de forma que todos los ordenadores conectados a la red se comporten como un grupo de nodos de computación que colaboran en la resolución del problema. Para hacer más accesible la plataforma, conviene utilizar tecnologías y protocolos estándar y abiertos aceptados por la comunidad científica. Los principales protocolos estándar para desarrollar servicios en red son WSDL, SSDL, OGSA o SOAP. Existen plataformas de desarrollo (frameworks) de sistemas de computación en grid ampliamente utilizados y de código abierto que podrían sernos de utilidad. Comentaremos varios de ellos y estudiaremos en profundidad DREAM y gsoap (para programación en Java y C++ respectivamente). Protocolos estándar para el desarrollo de servicios web en redes heterogéneas Los servicios web (Web Services, WS) permiten la interoperación de sistemas distribuidos heterogéneos con independencia de las plataformas hardware y software empleadas. Puede pensarse en ellos como en una arquitectura, conceptual y tecnológica, que hace posible que distintos servicios se describan, publiquen, descubran y utilicen a través de sistemas distribuidos, empleando la infraestructura proporcionada por Internet. Los WS son arquitecturas distribuidas (al igual que las que pueden crearse empleando CORBA, DCOM, EJB y otras tecnologías) que tienen una serie de características que las hacen de especial interés: Diversifican las oportunidades de negocio al facilitar que aparezcan escenarios de libre intercambio de servicios normalizados. Son arquitecturas acopladas de manera muy débil, lo que facilita la operación entre plataformas con distinto hardware, sistema operativo o que empleen distintos lenguajes de programación en sus aplicaciones. Los servicios son fáciles de reutilizar y reemplazar, lo que produce una reducción de costes, especialmente del de mantenimiento. Es posible lograr un mayor control sobre el funcionamiento de los procesos remotos cuando se emplean las tecnologías adecuadas. Pueden funcionar síncrona o asíncronamente, según las necesidades. No obstante, también presentan algunas desventajas como que su rendimiento es, por lo general, 11

12 bastante inferior al de otras arquitecturas distribuidas clásicas, y que necesitan una serie de tecnologías y especificaciones adicionales para poder operar de manera adecuada (con seguridad, fiabilidad, etc.). Los WS engloban una serie de tecnologías XML que se encargan de solucionar problemas concretos de interoperación, como son SOAP, WSDL, UDDI, BPel, etc. Herramientas de desarrollo para entornos grid En esta sección se presentan las principales herramientas de desarrollo para entornos grid. No son las únicas, pero sí son las más utilizadas, tanto en investigación como en entornos empresariales. Globus Toolkit version 4 Globus Toolkit es una serie de herramientas que han resultado de numerosos esfuerzos para resolver problemas que se plantean al afrontar el desarrollo de aplicaciones reales. Estas herramientas incluyen programas para mantener la seguridad, para el control de recursos y datos, para comunicaciones, detección de fallos, y para asegurar la portabilidad. Sus servicios, interfaces y protocolos permiten acceder a los recursos de forma remota como si estuviesen en la máquina local. Al mismo tiempo aseguran un control sobre los recursos propios para permitir o denegar el acceso a otros. Las dos ideas principales en el desarrollo de Globus son: Heterogeneidad: En sistemas distribuidos no resulta práctico imponer sistemas heterogéneos, debido a las diferentes necesidades de cada usuario. Una alternativa más adecuada es implementar interfaces estándar para que las diversas partes heterogéneas interaccionen. Estándares: En lugar de implementar nuevos protocolos, los componentes de Globus están basados en estándares aceptados internacionalmente. Algunos son: SSL/TLS, LDAP, X.509 Proxy Certificates, SOAP, HTTP, GridFTP y OGSI. El diseño de Globus está orientado a usar componentes estándar soportados por el máximo de aplicaciones e interfaces. De esta forma, no hay que desarrollar una infraestructura nueva para cada aplicación. Globus no es un sistema Grid que se ajuste a todas las necesidades, sino un conjunto de bloques de construcción y herramientas con las que desarrollar e integrar el sistema completo. Cada componente por sí mismo no resuelve más que una parte del problema, y deben organizarse e integrarse de acuerdo a los requisitos del proyecto global. 12

13 Las herramientas englobadas en el Globus Toolkit pueden resultar de gran ayuda, facilitando el desarrollo de la plataforma Grid. Cada sistema Grid tiene un conjunto de requerimientos distinto que debe abordarse mediante una combinación de componentes software particular y adaptada. Diferentes aplicaciones o sistemas harán uso de diferentes componentes de Globus. Los más importantes son: Software Development Kits : sistemas de desarrollo para crear servicios Grid basados en el framework OGSA. Web Services Core (WS Core) : desarrollo de servicios Grid compatibles con OGSA tanto en C++ como en Java. Grid Security Infrastructure (GSI) : comunicaciones entre servicios y clientes. Computing / Processing Power (GRAM) : compartición de recursos computacionales. Data Management (GridFTP, DAI, RLS) : intercambio de datos. Monitoring / Discovery (MDS) : monitorización y descubrimiento de servicios ofrecidos por la plataforma. Authorization / Security (CAS) : asegurar la seguridad en las comunicaciones y los tipos de acceso a los servicios. Developer APIS : interfaces para los lenguajes de programación C++ y Java de cada herramienta. Globus puede ser de mucha utilidad para desarrolladores, una vez que se ha analizado el sistema a desarrollar (en el que se comparten recursos tanto lógicos como físicos). Así, al tener muchos aspectos del sistema resueltos (accesos seguros, comunicaciones, intercambio de datos, recursos computacionales, etc.) podemos centrarnos en la capa de algoritmos, de aplicaciones y los servicios que ofrecería la plataforma. Por último, otra ventaja de desarrollar utilizando Globus radica en que sus componentes han sido utilizados y han resultado de mucha utilidad en diversos proyectos. De hecho, al utilizar herramientas estándar utilizadas en otros sistemas Grid, la compatibilidad con estos resultará más fácil. Entre otras, Globus viene siendo utilizado por las siguientes organizaciones: el Large Hadron Collider (CERN), Grid Physics Network, Particle Physics Data Grid, Network for Earthquake Engineering and Simulation o Earth System Grid. Además, desde el 2000, varias compañías como Avaki, DataSynapse, Entropia, Fujitsu, Hewlett Packard, IBM, NEC, Oracle, Patform, Sun y United Devices han desarrollado plataformas basadas en Globus. 13

14 Gridbus El proyecto Gridbus da soporte a la computación en clusters y computación en grid a través de las herramientas de desarrollo. Sigue una estructura en capas: las herramientas base se encuentran en una capa intermedia entre los servicios y las aplicaciones. Dado un trabajo a ejecutar, Gridbus utiliza un broker de servicios para identificar los recursos (a través del Grid Market Directory). La capa de proveedores de servicios de Gridbus está basada en Alchemi (bajo Windows, usando la tecnología.net de Microsoft) y Globus (bajo Unix/Linux). GridLab El objetivo del proyecto GridLab es ofrecer un entorno de desarrollo para crear aplicaciones basadas en grid. La herramienta Grid Application Toolkit (GAT) ofrece un conjunto de APIs que pueden utilizar las aplicaciones para usar los servicios de las capas inferiores. El diseño de GridLab busca la abstracción, flexibilidad y robustez. Una aplicación que necesite acceder a los recursos del grid, debe hacerlo a través de estas APIs. El GridLab Resource Management System implementa los mecanismos para monitorizar el funcionamiento del sistema, la ejecución de trabajos, monitorizar los recursos y servicios (acceso y cuentas de usuario, y seguridad). GridLab es similar a Globus en el sentido de que ofrece servicios y políticas para formar una plataforma de desarrollo para crear aplicaciones basadas en grid. CONDOR Condor es un gestor de tareas distribuidas con soporte en varias plataformas (Linux, Solaris, Windows, MacOS y AIX en 32 y 64 bits, entre otros). Es muy robusto y ofrece alta disponibilidad y gran escalabilidad. Soporta múltiples estándares (Globus, OSGA) y es seguro (soporta cifrado, autentificado, y certificado). Condor se define en el terreno del High Troughput Computing (HTC), o computación de alta capacidad, es decir que enfatiza la capacidad de absorber la mayor cantidad de carga y garantizar su ejecución de la manera más eficaz posible con los recursos disponibles. Sin embargo la gestión de estos trabajos suele conllevar un retraso, o latencia, que hace que las tareas muy breves, típicamente por debajo de un minuto de duración en una CPU normal, sean penalizadas en el Grid. No obstante, cuando se trata de miles de estas tareas el uso del Grid gana relevancia, siempre que se puedan ejecutar simultáneamente. 14

15 Una extensión a Condor es utilizar Condor G, que permite planificación de trabajos en grids desarrollados con Globus. Condor G actúa como una pasarela a los recursos en grid, se comunica con esos recursos y transfiere los archivos necesarios utilizando los mecanismos de Globus. Recientemente, varias organizaciones han implementado grids corporativos con CONDOR. En el caso de BANESTO, algunas de las operaciones en tiempo real requeridas por los agentes de contratación desde la sala tardaban un tiempo excesivo en realizarse. Otras operaciones posibles no se abordaban por no ser viables en el tiempo requerido. Se recurrió a configurar una plataforma grid de forma que se aportaran soluciones a estos problemas: Optimización de los métodos matemáticos y de los programas de cálculo. Uso de máquinas multiprocesador. Computación distribuida en cluster de máquinas dedicadas. Computación distribuida en grid de máquinas no dedicadas. Para cálculo de valoraciones financieras, dado que frecuentemente se utilizan métodos de simulación estadística iterativos, tales como el método de Montecarlo, algunos de los cálculos más solicitados y críticos son suceptibles de un diseño de cálculo modular en paralelo. Ibis: Efficient Java Based Grid Computing El objetivo del proyecto Ibis es crear una plataforma eficiente basada en Java para computación en grid. Actualmente consiste en una librería de comunicaciones y soporta varios modelos de programación para computación distribuida: Java Grid Application Toolkit (JavaGAT) y Zorilla P2P middleware. Todos los componentes se pueden utilizar en cualquier plataforma grid al utilizar Java. JavaGAT puede ejecutarse como capa intermedia entre aplicaciones grid y otras capas middleware para computación en grid, como Globus, Unicore, SSH o Zorilla. Zorilla es un middleware basado en P2P. Implementa la funcionalidad necesaria para ejecutar aplicaciones distribuidas, como programación, transferencia de ficheros y seguridad. Las máquinas que montan Zorilla se organizan automáticamente y de forma descentralizada. Debido a su diseño P2P, Zorilla escala a un alto número de máquinas. Los trabajos se pueden lanzar directamente o a través de JavaGAT. Jini y JGrid Jini es (en palabras de la FAQ de Sun Microsystems) una arquitectura de red pensada para la construcción de sistemas distribuidos en los que la escalabilidad, dinamismo y complejidad son muy 15

16 importantes y no se pueden satisfacer con las tecnologías actuales. Los participantes en una red Jini son al mismo tiempo clientes y servicios. Jini ofrece una infraestructura y un modelo de programación: la infraestructura consiste en una serie de servicios base que permiten la distribución, descubrimiento, seguridad y uso del conjunto de servicios. El modelo de programación se basa en extender las librerías de clases de Java, añadiendo la semántica para hacer computación distribuida. No se trata de una plataforma grid completa, sino que está compuesto por un conjunto de herramientas (de forma similar a Globus), de forma que sus servicios base se pueden utilizar para construir un sistema distribuido parecido a un sistema grid. Hay algunos proyectos que parten de Jini para conseguir crear sistemas grid, como el proyecto JGrid. Sin embargo una de sus características es que actualmente JGrid está enfocado a problemas computacionales (en el sentido de compartir recursos computacionales exclusivamente). JXTA JXTA (Juxtapose) es una plataforma peer to peer open source creada por Sun Microsystems en el año Esta plataforma esta definida como un conjunto de protocolos basados en XML. Dichos protocolos permiten que dispositivos conectados a una red intercambien mensajes entre sí. Esta tecnología está formada por un conjunto de protocolos abiertos que permiten conectar cualquier dispositivo (teléfono móvil, PDA, PCs, etc) a una red P2P. Como JXTA esta basado en una serie de protocolos abiertos, en teoría, puede ser portado a cualquier lenguaje moderno de computación. Actualmente, la implementación de JXTA de Java es la más avanzada. Existen versiones para C y C++, JXTA C y JXTA C++ respectivamente. JXTA crea una red virtual que permite a los peers interactuar entre sí, aún cuando algunos de ellos estén detras de firewalls, NATs o usen distintos transportes de red. Además, cada peer es identificado por un ID único, permitiendo que los peers puedan cambiar su dirección pero conservar su número de identificación. Los nodos en un sistema desarrollado con JXTA forman una red virtual donde cada nodo puede interaccionar con los otros y acceder a los recursos directamente. Los objetivos del proyecto JXTA son: Interoperabilidad entre los diferentes sistemas P2P Independiente de la plataforma para usar diversos lenguajes, sistemas y redes Ubicuidad, para que todo dispositivo pueda participar en la plataforma distribuida 16

17 Protocolos en JXTA : Peer Resolver Protocol Peer Information Protocol Rendezvous Protocol Peer Membership Protocol Pipe Binding Protocol Endpoint Routing Protocol JXTA define dos categorías principales de peers: Super peers y edge peers. Los super peers pueden ser divididos en rendezvous y relay peers. Cada peer tiene un rol bien definido el modelo peer to peer de JXTA. Los edge peers son usualmente definidos como peers que tienen bajo ancho de banda. Normalmente están en los límites de internet, escondidos detrás de firewalls corporativos o accesan a la red a través de conexiones no dedicadas. Un peer Rendezvous tiene la tarea especial de coordinar los peers en la red JXTA. Además provee las bases necesarias para la propagación de mensajes. Si los peers están ubicados en distintas subnets deberían tener, al menos, un peer Rendezvous. Un peer Relay permite que peers que esten detrás de un cortafuegos o sistemas NAT tomen parte en la red JXTA. Esto es alcanzado usando protocolos que puedan atravesar firewalls, como por ejemplo, HTTP. Muchas empresas (entre otras Nokia, Digital Dream, Global InfoTek Inc, etc.) y universidades (CERN European Organization for Nuclear Research, Politecnico di Torino, Ecole Polytechnique Federale de Lausanne, Universitat Politecnica de Catalunya, etc.) están entre los colaboradores del proyecto. IrisGRID La iniciativa IRISGrid, lanzada en el 2002, es la evolución de la Red Temática IRIS sobre Grid. Surge con el objetivo de coordinar a nivel académico y científico a los grupos de investigación interesados en esta tecnología, tanto en su desarrollo, implantación y aplicaciones. Además de esta coordinación, IRISGrid tiene como objetivo crear la infraestrutura GRID nacional que permita el uso de esta tecnología tanto a nivel de aplicabilidad en diferentes ámbitos, como a nivel de desarrollo e innovación en este campo. Actualmente, en la iniciativa IRISGrid participan diferentes grupos del ambito científico y académico, 17

18 y está reconocida como la iniciativa nacional para la implantación, desarrollo e investigación en entornos GRIDs. BOINC: Berkeley Open Infrastructure for Network Computing La Infraestructura Abierta de Berkeley para la Computación en Red (BOINC) es una infraestructura para la computación distribuida, desarrollada originalmente para el proyecto SETI@home, pero que actualmente se utiliza para diversos campos como física, medicina nuclear, climatología... La intención de este proyecto es obtener una capacidad de computación enorme utilizando ordenadores personales. Actualmente, BOINC es desarrollado por un grupo con sede en Berkeley, en la Universidad de California y dirigido por David Anderson, director del proyecto SETI@home. La plataforma BOINC es considerada como un cuasi superordenador, disponiendo de unos ordenadores activos en todo el mundo y con un rendimiento medio de 745 TFLOPS a fecha de 5 de diciembre de El administrador original de SETI@home tenía un nivel bajo de seguridad y era común que usuarios maliciosos enviasen falsos resultados para conseguir créditos. Para intentar solucionar estos problemas de seguridad se creó BOINC, que fue desarrollado originalmente para administrar exclusivamente el proyecto SETI@home. BOINC está diseñado para ofrecer la herramienta necesaria a todo aquel que desee ser voluntario en este tipo de redes. Los proyectos que usan BOINC como cliente suelen componerse de ordenadores de voluntarios, ya que suelen ser proyectos sin beneficio económico dirigidos por universidades o entidades públicas. En esencia, BOINC utiliza los ciclos que quedan libres en el procesador para donarlos al proyecto que hayas elegido. El sistema se basa en un servidor que reparte las tareas entre los diferentes clientes, para posteriormente recoger los resultados obtenidos. El software requerido para donar tiempo de proceso debe ser descargado desde la página oficial de BOINC, donde se puede elegir la plataforma de la descarga y el tipo de arquitectura que posea el hardware. También se puede disponer del código fuente del software cliente, para modificarlo a gusto del usuario. Una vez descargado el software, el usuario debe suscribirse a un proyecto según sea su interés, tan sólo registrando su correo electrónico y una contraseña para acceder a sus estadísticas. 18

19 En el servidor se monitorizan todos los procesos, se adjudican nuevas cargas de trabajo y se recogen los resultados. Se dispone de una interfaz web muy potente para realizar todas las tareas administrativas: 19

20 Algunas aplicaciones que están actualmente en explotación: apoyo a los científicos del CERN SETI@home búqueda de inteligencia extraterrestre APS@Home estudia los efectos del modelos de dispersión atmosférica para poder predecir con mayor exactitud el clima. Zebra RSA Bruteforce estudia la encriptación RSA. Storage@home es una infraestructura de almacenamiento distribuido Climateprediction.net intentar predecir el clima Malaria Control para buscar el módelo estocástico de la epidemia Configuración básica de un servidor BOINC La documentación completa (muy detallada) está en: Un proyecto BOINC necesita un servidor web con PHP para servir toda la información, y MySQL para manejar todos los datos que se van generando. La estructura en directorios de un proyecto típico de BOINC es: PROJECT/ apps/ bin/ cgi bin/ log_hostname/ pid_hostname/ download/ html/ inc/ ops/ project/ stats/ user/ user_profile/ keys/ upload/ donde PROJECT es el nombre del proyecto y HOSTNAME es el servidor. Los programas en el servidor se ejecutan como dos usuarios diferentes: el scheduler y el manejador de archivos son programas CGI, por lo que se ejecutan como el usuario del servidor web (Apache) y están en el directorio reservado a los CGI 20

21 los demonios de BOINC se ejecutan como un usuario especialmente creado (no conviene que se ejecuten como root) Para instalar BOINC en un Linux basado en Debian, debemos tener los siguiente paquetes: apache2 mpm prefork libapache2 mod php5 mysql client 5.0 mysql server 5.0 php5 mysql php5 cli php5 gd phpmyadmin python mysqldb libmysql++ dev libssl dev Debemos configurar PHP, MySQL y Apache según las instrucciones dadas en: Para descargar y compilar BOINC para el servidor debemos ejecutar las siguientes órdenes: $ cd ~ $ svn co boinc_trunk $ cd ~/boinc_trunk $ svn update $ cd ~/boinc_trunk $./_autosetup $./configure disable client $ make Al compilarlo sólo crearemos el servidor; el cliente conviene bajarlo de la web de BOINC directamente. La configuración final para añadir aplicaciones y poner el proyecto visible para que se unan máquinas es compleja. Conviene seguir los pasos dados en las URLs anteriores y en Una vez tenemos el proyecto en funcionamiento, podemos monitorizar el funcionamiento de BOINC a través de la interfaz web, que nos permite: explorar la base de datos ver los datos de usuarios administrar foros crear y editar aplicaciones enviar s a otros usuarios 21

22 monitorizar cuántos FLOPs se están usando cancelar unidades de trabajo obtener y analizar resultados explorar y analizar ficheros de log Computación distribuida usando DREAM Los sistemas P2P están constituidos por una serie de nodos heterogéneos, los cuales tienen diversas capacidades de procesamiento. Por tanto, dada una carga computacional, será imprescindible equilibrarla de forma que cada nodo procese una parte proporcional a su capacidad. Las políticas de comunicación entre nodos se deben diseñar de tal forma que tengan en cuenta tanto el cambio dinámico de las conexiones, como las propiedades de latencia y ancho de banda de los distintos enlaces en términos de calidad de servicio. La dinamicidad de la topología que forma una red de recubrimiento P2P impide una configuración a priori de los experimentos y obliga a que las citadas políticas sean autoadaptativas a dichos cambios dinámicos. En lo concerniente al desarrollo de sistemas P2P para computación distribuida caben destacar una serie de frameworks como DREAM, enfocado al procesamiento distribuido en computación evolutiva utilizando la red DRM, o G2DGA (equivalente al anterior y que se usa para resolver algoritmos genéticos distribuidos que se adaptan a la topología dinámica de la red que establece el sistema G2P2P o JADE) un sistema con componentes software que siguen el paradigma de sistemas de agentes. La plataforma DREAM está enfocada al procesamiento distribuido en computación evolutiva utilizando la red de Internet como un sistema P2P escalable mediante DRM. DRM es un sistema P2P que mantiene una red de recubrimiento desestructurada que utiliza mecanismos epidémicos. Fue ideado como una implementación experimental del protocolo newscast, que consiste en un protocolo epidémico en el que cada cada nodo difunde información local entre sus nodos vecinos eligiendo con probabilidad uniforme uno de ellos cada determinado tiempo, a lo que se denomina tasa o frecuencia de refresco. Entre sus características están la descentralización, adaptabilidad y heterogeneidad. La principal contribución de DRM consiste en ofrecer un sistema P2P descentralizado con capacidades de autoorganización para atacar el problema de compartir recursos de tiempo de computación en experimentos de computación evolutiva distribuida. Dentro de DREAM, DRM se ha usado en diversos trabajos científicos como plataforma para el desarrollo de algoritmos evolutivos paralelos y distribuidos para mejorar el rendimiento y obtener 22

23 mejores resultados, buscando la mejora de la eficiencia, aprovechando los recursos de un conjunto de máquinas distribuidas. Desarrollo de servicios distribuidos usando gsoap En 1998 Microsoft, IBM y otros crearon el protocolo SOAP (Service Oriented Architecture Protocol), que se convirtió en estándar del W3C. SOAP es un formato de intercambio de mensajes bastante simple y muy ligero. SOAP define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web. Hay bastantes herramientas de desarrollo, para muchos lenguajes de programación, que permiten trabajar con SOAP. Estas herramientas van desde simples APIs hasta SDK (software development kit) muy elaborados y completos para desarrollos SOAP tipo servidor cliente. Entre otros cabe destacar SOAP::Lite para Perl, Apache SOAP for Java, el.net SDK, y el gsoap Toolkit para C/C++. gsoap permite crear aplicaciones en C/C++ para compartir recursos computacionales y de información con otras aplicaciones, posiblemente a través de diferentes plataformas, lenguajes de programación, redes y organizaciones. Como resultado, aplicaciones científicas, sistemas empotrados, y software de tiempo real pueden interactuar como clientes o como servidores. El desarrollo de una aplicación con gsoap pasa por la creación de una especificación WSDL del servicio que después será traducida a una serie de declaraciones de función C/C++ que se guardarán en un archivo de cabecera estándar. Esta traducción hace que la interfaz del servicio (y la descripción del servicio en WSDL) sea transparente al usuario. Bibliografía DREAM, Distributed resource evolutionary algorithms machine, ea m.sourceforge.net M. G. Arenas, P. Collet, A. E. Eiben, M. Jelasity, J. J. Merelo, B. Paechter, M. Preuss and M. Schoenauer, A framework for distributed evolutionary algorithms, Parallel Problem Solving from Nature (PPSN VII), LNCS vol. 2439, pp , 2002 M. G. Arenas, B. Dolin, J. J. Merelo, P. A. Castillo, I. Fernández de Viana and M. Schoenauer, JEO: Java Evolving Objects, GECCO, pp. 991, J. L. J. Laredo, P. A. Castillo, A. M. Mora and J. J. Merelo, Estudio preliminar sobre autoadaptación en agentes evolutivos sobre arquitecturas heterogéneas, XVII Jornadas de Paralelismo (XVII JP), pp. 23