Autorizada la entrega del proyecto al alumno: D. Alberto Romero Luezas. Madrid, 23 de Junio de 2006 EL DIRECTOR DEL PROYECTO

Transcripción

1 Autorizada la entrega del proyecto al alumno: D. Alberto Romero Luezas Madrid, 23 de Junio de 2006 EL DIRECTOR DEL PROYECTO Fdo.: D. Antonio Fuentes Bermejo Vº Bº del Coordinador de Proyectos Fdo.: D. David Contreras Bárcena Fecha: / /

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA SISTEMA DE INFORMACIÓN DISTRIBUIDO PARA GRID BASADO EN BÚSQUEDA JERARQUIZADA DE RECURSOS Y ADHESIÓN FEDERATIVA DE NODOS AUTOR: DIRECTOR: Alberto Romero Luezas Antonio Fuentes Bermejo RedIRIS, Red Nacional de I+D+i MADRID, Junio 2006

3 Agradecimientos: Quisiera agradecer muy especialmente a mi Jefe de Proyecto, Antonio, su dedicación y entrega al proyecto. Con él he tenido la ocasión de aprender muchísimo de su amplia experiencia en la materia y he pasado muy buenos ratos intercambiando impresiones y escuchando sus explicaciones. Muchas gracias por tus soluciones siempre certeras y tus ideas geniales. También quisiera agradecer a David, mi coordinador, sus consignas e indicaciones para llevar este proyecto a buen puerto. En segundo lugar, pero no por ello menos importante, quisiera darles las gracias a mis padres por aportar los medios y darme la oportunidad de estudiar la carrera en un lugar de prestigio como ICAI. También a mi hermano Rafa por aquellas escasas cinco líneas de código hace tantos años y a mis amigos por su apoyo incondicional. ii

4 Resumen: La tecnología Grid Computing tiene por objetivo la interconexión de recursos distribuidos por Internet, tanto hardware como software, definiendo como requisito la implementación de interfaces abiertos y bien definidos. Así, el uso de esta tecnología, permitirá interconectar diferentes organizaciones sin estar sujetas a un control centralizado, gestionando así sus propias políticas internas de manejo de la información. El hecho de que los recursos computacionales y de almacenamiento se encuentren distribuidos, implica que la red de interconexión de éstos será Internet y por tanto, al ser éste un medio compartido, disponer de información acerca del estado de los recursos y de la red de interconexión (anchos de banda entre nodos computacionales, latencia, etc) es fundamental en la toma de decisiones de planificación, impactando directamente en el rendimiento global. Dadas estas circunstancias, la necesidad de disponer de información de calidad acerca del estado actual de la red es fundamental para catalogar los recursos dinámicamente. Actualmente, existen diferentes desarrollos y frameworks que proporcionan esta información, teniendo como principal inconveniente la forma de gestión centralizada de la información. Esta gestión de la información no resuelve por diseño problemas tales como disponibilidad (caída de servidores o líneas de acceso a éstos), escalabilidad del servicio, excelencia de la información y seguridad de la información. El objeto de este proyecto es el desarrollo de un framework distribuido, SID (Sistema de Información Distribuido), que subsane los problemas señalados anteriormente por diseño. Para ello se diseñará una jerarquía de sistemas de información con capacidad para dar de alta y de baja nodos basada en una estructura federativa. iii

5 Abstract: Grid Computing technology has as its main objective the communication of distributed resources, both hardware and software, over the Internet, having as a requirement the implementation of well-defined open interfaces. Therefore, the use of this technology will permit the interconnection of different organizations without a centralized control and allowing each organization to manage their own resources. The fact that those process and storage resources are distributed means that the network that is connecting all them is the Internet and for this reason, being a shared resource as it is, it is very important to have information about the state of resources and networking (bandwidth, latency, etc) basic in planning decision as it has its influence in global performance. For this reason, quality information of the actual state of the network need to be considered to classify the resources dynamically. In the present, there are a few systems providing all this information. Their main inconvenience is the use of centralized information management that carries availability problems (if the server or access links came down). The objective of this Project is to develop a distributed information system, SID (Distributed Information System in Spanish) that fixes the problems mentioned before. We will design a hierarchical information system which will be able to subscribe and unsubscribe hosts in a federative-based structure way. iv

6 Índice General 1. Introducción Sistemas de monitorización en Grid Sistemas distribuidos Estado actual del arte Motivación Objetivos Organización del documento Tecnologías utilizadas en Grid Open Grid Services Architecture Globus Toolkit Arquitectura de Monitorización (GAM) XML Web Services SOAP Web Services Resource Framework Sistemas de Monitorización de Recursos Requerimientos de un sistema de monitorización Sistemas de Información MDS NWS Ganglia Arquitectura WSGIIS Introducción Marco de utilización Limitaciones Propuesta de mejora 57 v

7 5. Arquitectura SID Introducción Framework Sistema de Información Unificado Gestor de la Información Servicio de Búsqueda de Recursos Sincronización entre Servicios de Información Adhesión Federativa Acceso a Interfaz de Recursos Presupuesto Conclusiones Mejoras que supone la nueva arquitectura Trabajos futuros Anexos Anexo A: Instalación de Globus Toolkit Anexo B: Definición del XML Glue Scheme Bibliografía vi

8 vii

9 1. Introducción Este apartado describe sencillamente los objetivos del proyecto, y la forma de abordar las soluciones para el desarrollo de un framework distribuido tolerante a fallos. Para ello, se realiza una breve introducción a tecnologías de monitorización en Grid Computing existentes y su problemática. 1

10 1.1 Sistemas de monitorización en Grid Los entornos de Grid típicos están altamente distribuidos y compuestos de un gran número de elementos. Con el amplio rango de recursos disponibles, los procesos del Grid necesitan una manera de conocer el estado actual de varios elementos para poder tomar decisiones de planificación [1]. La monitorización en Grid es la medida y publicación del estado de un componente de un Grid en un determinado instante. Para ser efectivo, la monitorización debe ser end-to-end, es decir, que todos los componentes entre los endpoints de la aplicación deben ser monitorizados. Esto incluye software (aplicaciones, middleware, servicios, sistemas operativos ), hardware (CPU, discos, memoria ) y redes (routers, switches ). La monitorización es necesaria por muchas razones, entre las cuales se encuentra el chequeo de estado, resolución de problemas, rendimiento y depuración. A continuación se detallan los usos más comunes de la monitorización: Detección y resolución de fallos: Cuando un proceso de un Grid falla puede ser difícil determinar el origen del fallo. Una información de monitorización adecuada es necesaria tanto para la detección de fallos en tiempo real como para un análisis forense. Análisis de rendimiento: Los desarrolladores de aplicaciones Grid y de middleware suelen observar problemas de rendimiento como pueden ser latencias inesperadamente altas. Determinar el origen de los problemas de rendimiento requiere una monitorización detallada de todos los componentes del Grid, incluyendo aplicaciones, sistemas operativos, hosts y redes. Decisiones de planificación: En un entorno en el que los recursos de comunicaciones y computación cambian constantemente, las medidas para conocer el estado actual pueden ser utilizadas para tomar decisiones de reubicación en la planificación de recursos. Por ejemplo, los datos de monitorización de red pueden ser 2

11 utilizados por el middleware de gestión de datos del Grid cuando se elige la mejor fuente desde la que copiar datos replicados. La mejor optimización de planificación de los procesos del Grid requiere una monitorización dinámica, como puede ser la longitud de una cola de procesos batch, carga de CPU y de red, utilización de memoria, etc. Agrupar datos para mejorar la siguiente ejecución del programa: Los datos son agrupados en el transcurso de una ejecución y utilizados por el desarrollador o el compilador para alterar el programa de tal forma que se ejecute más rápido la siguiente vez. Adaptar un proceso en ejecución: Para programas de larga ejecución, los recursos requeridos o disponibles pueden cambiar en el transcurso de una ejecución. Los datos pueden ser utilizados para guiar el manejo computacional o para permitir a aplicaciones que puedan adaptar su comportamiento de acuerdo a las observaciones realizadas. Depurar: Los programas complejos, con multihilo, o distribuidos pueden ser difíciles de depurar habitualmente. Las herramientas de análisis y monitorización pueden ayudar en el proceso de depurado. Auditoría y detección de intrusos: Los servicios de seguridad y protección son otros importantes consumidores de información de monitorización. Figura 1.1 Componentes de monitorización 3

12 Debido a la criticidad de la información necesaria para la optimización de las aplicaciones en Grid Computing, se ha diseñado un framework, SID, que cumpla con los requisititos anteriormente explicitados, y que deben ser cubiertos por cualquier sistema de monitorización. 4

13 1.2 Sistemas distribuidos Un sistema distribuido es aquel sistema que utiliza ordenadores y dispositivos independientes utilizando como medio de comunicación una red para cooperar en un objetivo común [1]. Estos ordenadores o dispositivos pueden ser completamente diferentes en arquitectura hardware, sistema operativo e incluso en lo que concierne al lenguaje de programación en el que están desarrolladas sus aplicaciones. Es especialmente interesante puesto que su localización geográfica puede ser radicalmente distinta. Organización La organización de la interacción entre cada ordenador es de gran importancia. Para poder utilizar la gama más amplia posible de ordenadores, el protocolo o el canal de comunicaciones no debe contener ni utilizar ninguna información que no pueda ser entendida por ciertas máquinas. También se debe tomar un cuidado especial con que los mensajes se entreguen correctamente y que los mensajes inválidos puedan ser rechazados para evitar que pueda echar abajo el sistema y quizás el resto de la red. Otro factor importante es la capacidad de enviar software de alto nivel a otro ordenador de una manera portable de modo que pueda ejecutarse y operar correctamente con la red existente. Obviamente, esto no puede siempre ser posible al usar hardware y recursos diferentes, así que se deben utilizar otros métodos, como por ejemplo la compilación para esas especificaciones determinadas utilizando los fuentes. Meta Hay muchos tipos de sistemas de cálculo distribuido y de muchos desafíos a superar para diseñar uno con éxito. La meta principal de un sistema de cálculo distribuido es conectar usuarios y recursos de una manera transparente, abierta y escalable. Idealmente, este modelo es drásticamente más tolerante a fallos que muchas combinaciones de máquinas independientes. 5

14 Ejemplos Un ejemplo de un sistema distribuido es la World Wide Web. Cuando se está accediendo a un sitio Web se está haciendo uso de un sistema distribuido en el que el usuario es el cliente a través de su navegador, y el servidor es aquel que ofrece acceso a su página. Posiblemente el navegador utiliza un servidor proxy para tener acceso al contenido de la web almacenado en los servidores locales más rápidamente y con más seguridad. Para encontrar estos servidores, también utiliza el Domain Name Server, que es a su vez otro sistema distribuido. Arquitectura La computación distribuida se puede presentar de muchas formas diferentes, entre las que cabe destacar las siguientes por su extensión y su importancia en la actualidad: Orientado a servicios: Se organiza como sistema de los servicios altamente reutilizables que se podrían ofrecer con los interfaces estandarizados. Peer to peer: Se trata de una arquitectura donde no hay una máquina o máquinas especiales que proporcionan un servicio o manejan los recursos de la red. En su lugar, todas las responsabilidades se dividen uniformemente entre todas las máquinas. Cluster: Se refiere típicamente a un sistema de máquinas altamente integradas que ejecutan un mismo proceso en paralelo, subdividiendo la tarea en fragmentos que son procesados individualmente por cada uno, y que después juntan para obtener el resultado final. Las máquinas son independientes y actúan en paralelo a través de una red de alta velocidad local, pero son homogéneas y se encuentran geográficamente en una misma localización. Por esta razón no se puede definir un cluster como un sistema distribuido como tal, sino que podría decirse que es un sistema distribuido local. Grid Computing: Se trata del sistema distribuido más utilizado en el ámbito científico. Es el centro de todo este proyecto, por lo que se pasará a estudiarlo con mayor profundidad. 6

15 La tecnología Grid Computing tiene por objetivo la interconexión de recursos distribuidos por Internet [4], tanto hardware como software, definiendo como requisito la implementación de interfaces abiertos y bien definidos. Así, el uso de ésta tecnología permitirá interconectar diferentes organizaciones sin estar sujetas a un control centralizado, gestionando así sus propias políticas de gestión de recursos. Tal y como se puede intuir, estos recursos serán todos aquellos elementos (hardware o software) de los que disponga una Organización Virtual (VO) y cuya disponibilidad puede ser paramétricamente definida. La implementación de esta tecnología, todavía en evolución, supone un gran avance en computación de alto rendimiento, donde las capacidades de computación y tratamiento digital han aumentado de forma considerable debido a los nuevos retos aplicados a diversos ámbitos, tanto de la ciencia como de la empresa. Así, la aplicabilidad de la tecnología Grid Computing abarca áreas como el de la Física de Altas Energías, Biotecnología, Medicina, Sistemas Complejos, Meteorología, Astrofísica, o en la industria para análisis y simulación, como por ejemplo las empresas aeronáuticas, etc. En esencia, si se utiliza Grid Computing, los recursos de diferentes organizaciones se incluyen en pools dinámicos de Organizaciones Virtuales para poder resolver problemas específicos. Además, los usuarios también pueden formar parte de estas organizaciones virtuales. Cuando esto ocurre, podrá tener acceso a todos los recursos del pool de esa organización virtual. El concepto de Grid Computing puede llegar a ser trivial, pero no su implantación, que puede generar muchas cuestiones [4]. Algunas de éstas son: - Cómo decidimos qué recursos forman parte de cada organización virtual? - Con un problema concreto a resolver por el Grid, cómo decidimos qué recursos son los más apropiados para resolver ese problema? Por cuánto tiempo podemos dedicar esos recursos? - De qué manera conseguimos comunicar los recursos entre sí? Hay que tener 7

16 en cuenta la heterogeneidad de los recursos de diferentes VOs. - Cómo se puede dividir una tarea para que pueda ser procesada por diferentes ordenadores de organizaciones distintas? Además hay que continuar considerando que los recursos no son homogéneos. - Que una organización esté dispuesta a compartir sus recursos con otras organizaciones es una idea brillante, pero conlleva muchísimos problemas de seguridad que habrían de tenerse en cuenta, para que esos recursos puedan ser accedidos sólo por usuarios autenticados. Por tanto, podemos decir que Grid Computing nos permite acceder a recursos heterogéneos desde diferentes organizaciones proporcionando un conjunto de protocolos, tecnologías y metodologías que responden a todas las cuestiones anteriormente planteadas Existen cinco capas dentro de la arquitectura Grid: - Fabric: Esta capa hace referencia a los recursos que van a ser compartidos en el Grid, como pueden ser ordenadores individuales, clusters, etc. - Connectivity: Es necesario que nuestros recursos puedan comunicarse entre ellos. Esta capa proporciona todos los protocolos que permitirán a nuestros recursos comunicarse. Entre estos protocolos no podemos olvidar algunos como TCP/IP, HTTP o DNS. También se incluyen muchos protocolos que permiten la seguridad en las comunicaciones. - Resource: En esta capa están contenidos todos aquellos servicios y protocolos que nos permiten gestionar los recursos individualmente. Esta gestión puede incluir tareas como inicializar recursos, monitorizarlos, contabilizarlos y parametrizarlos. Existen dos tipos de protocolos en esta capa: 8

17 Protocolos de información: Nos permiten acceder a información de los rescursos, como puede ser carga de CPU, memoria disponible, número de procesos ejecutándose, etc. Protocolos de gestión: Nos permiten controlar los recursos hasta un cierto límite. No es posible tener un control completo de los recursos de un Grid, pero estos servicios y protocolos se encargarán de comprobar si el tipo de operaciones que se piden sobre un recurso son consistentes con las políticas de la organización. - Collective: Esta capa es la encargada de sincronizar los servicios y protocolos que deben gestionar múltiples recursos. Nos permitirá, por tanto, timar un conjunto de recursos y hacerlos trabajar conjuntamente para resolver una tarea común. Algunos de los tipos de servicios que se pueden encontrar en esta capa son: Registros de recursos: Permite descubrir recursos en una organización virtual y preguntar por sus propiedades. Servicios de programación de tareas: Al ejecutar una tarea en un Grid normalmente no tenemos que decidir en qué parte de éste se va a ejecutar. Este servicio es quien se encarga de utilizar un directorio de recursos para encontrar los recursos adecuados para nuestra tarea. Además decidirá en qué momento se ejecutará la tarea. Servicios de monitorización: Nos permite monitorizar que todos nuestros recursos están funcionando de manera adecuada. Servicio de gestión de datos: Las tareas que ejecutamos en el Grid requieren habitualmente de conjuntos de datos con los que trabajar. Éste servicio se encarga de transferir estos datos a donde 9

18 sean necesarios. - Applications: En esta capa se encuentran las aplicaciones que se ejecutarán en un sistema Grid. No es necesario que estas aplicaciones interactúen directamente con los servicios de la capa Collective. Son, además, libres de acceder a los servicios Resource y Connectivity directamente cuando lo requieran. 10

19 1.3 Estado actual del arte Como anteriormente expresábamos, el hecho de que los recursos se encuentren distribuidos, implica que la red de interconexión de éstos será Internet y por tanto, al ser éste un medio compartido, disponer de información acerca del estado de los recursos es fundamental [4]. Por esta razón actúa directamente en el rendimiento global. Dadas estas bases, la necesidad de disponer de información de calidad acerca del estado actual de la red es fundamental para catalogar los recursos dinámicamente. Actualmente, existen diferentes sistemas que proporcionan esta información, teniendo como principal inconveniente el interfaz de acceso. En un proyecto anterior, se desarrolló un middleware, WSGIIS [5], basado en Web Services, que unificaba toda la información de cada uno de los sistemas de información, y creaba un único punto de acceso para obtener en tiempo real los datos de cada uno de los recursos. Existen una serie de proyectos de similares características a nivel europeo y mundial que son los siguientes: - EGEE [6]: Enabling Grids for E-Science in Europe ( Se trata del proyecto de Grid más ambicioso de Europa, con capacidad de acceso a sus recursos desde 27 países diferentes. EGEE es responsable de proporcionar la capacidad computacional necesaria para el acelerador de partículas ubicado en Ginebra (Suiza) conocido como LHC, en sus investigaciones acerca del bosón de Higgs. - NEESit ( Proporciona una gran infraestructura para el NEES (Network for Earthquake Engineering Simulation) uniendo grandes centros de investigación de los Estados Unidos. - TeraGrid ( Se trata de un sistema Grid que posee una importante infraestructura para investigaciones científicas. Desde 2004, TeraGrid tiene 20 teraflops de proceso y un petabyte de almacenamiento distribuido. 11

20 - Access Grid ( Un sistema Grid utilizado para encuentros de colaboración, grandes sesiones de trabajo, seminarios y tutoriales. - ediamond ( El proyecto ediamond es un ejemplo de cómo la tecnología Grid Computing puede utilizarse para la medicina. Este proyecto almacena y distribuye información de tratamientos de cáncer, permite un diagnóstico temprano y un gran número de aplicaciones médicas. La problemática de este tipo de desarrollos reside en la forma de gestión centralizada de la información. La utilización de un sistema centralizado para el almacenamiento de esta información puede conllevar problemas de disponibilidad porque el servidor esté caído o porque tenga una carga excesiva de peticiones. Un sistema Grid que necesita un alto rendimiento y una gran disponibilidad no podemos permitir que falle o se ralentice por razones de acceso a información de recursos. Por ello, basándonos en la naturaleza descentralizada de la tecnología Grid Computing, el objetivo de este proyecto es crear un sistema que permita el despliegue de una infraestructura descentralizada de información que solucione los problemas de disponibilidad en el acceso a la información que tradicionalmente se venía dando en el entorno Grid en los proyectos mencionados. 12

21 1.4 Motivación A lo largo de la carrera he ido moldeando mis gustos en lo referente a la informática, a lo que sin duda también ha contribuido el hecho de haber trabajado durante el transcurso de la misma en dos empresas muy diferentes. Siempre me ha atraído mucho más lo referente a sistemas y redes que otro tipo de campos, como puede ser la gestión propiamente dicha. Por ello, creo que un proyecto sobre Grid Computing es de alguna manera poner un broche final que me permita (y me exija) aprender más tanto sobre sistemas como redes. Por otra parte, también me gusta la investigación de una manera especial. Pienso que todo lo que se haga en este mundo siempre es mejorable, y que continuamente se pueden seguir investigando nuevas vías tecnológicas que mejoren nuestra vida. En este caso, Grid Computing es una forma de utilizar la computación en beneficio de otros tipos de investigación más importantes como la medicina o la previsión de desastres naturales, y no cabe duda que todo avance puede ayudar a agilizar esos tipos de investigación. 13

22 1.5 Objetivos El objeto de este proyecto es el desarrollo de un sistema distribuido de información que subsane los problemas señalados anteriormente. Para ello se diseñará una jerarquía de sistemas de información basados en Web Services utilizando XML con capacidad para dar de alta y de baja nodos basada en una estructura federativa. El acceso a la información de los recursos se realizará mediante un procedimiento similar al que se realiza en los servidores DNS para la resolución de nombres de dominio. Es decir, que cuando se haga una solicitud de información específica se enviará la petición al nodo más cercano de la jerarquía que en función del tipo de información que se pida reenviará la petición a niveles superiores hasta que concluya la búsqueda en una máquina concreta. La dirección de esta máquina será la respuesta que recibirá quien realizó la petición. De esta forma se podrán comunicar ambas máquinas entre sí para la transferencia de información. Por tanto se distinguen dos niveles diferentes. Por un lado tendríamos el nivel de petición que es el que se realiza en primer lugar y que da lugar al recorrido del árbol de la jerarquía hasta dar con la dirección del servidor que posee la información deseada, y por otro lado el nivel de consulta que se realizaría en una comunicación directa entre máquina solicitante y servidor. Los objetivos se podrían sintetizar en distintas partes más concretas: 1. Diseñar un framework de monitorización y análisis distribuido, SIU, que resuelva por diseño la problemática de los sistemas de monitorización actuales, basados en un modelo centralizado. 2. Crear un servicio de búsqueda de recursos que realice peticiones recursivamente a través de los distintos SIUs asociados y la propagación de la información. 3. Diseño de un módulo de adhesión federativa de nodos, y el diseño de los canales de comunicación entre los hosts, y su correspondiente SIU. 4. Diseño de un módulo de sincronización jerarquizado geográficamente que 14

23 permita la propagación de la información hacia niveles superiores. 5. Adaptar WSGIIS para que opere de una forma distribuida y pueda unificar la información de los diferentes sistemas de información. 6. Integración de nuestro framework en Globus 4 [11], y MDS4 [14] usando XML. 15

24 1.6 Organización del documento La documentación del proyecto se ha organizado de forma se sienten los conocimientos básicos que permitan un total entendimiento de la arquitectura SID. Así, en el punto 2, se realiza una introducción a la tecnologías usadas por Grid Computing, y a su arquitectura. El punto 3 introduce los sistemas de monitorización que son usados actualmente en las infraestructuras Grid existentes, y cuyo modelo proponemos sea modificado a la nueva arquitectura SID diseñada. El punto 4 realizamos una breve introducción a WSGIIS, sistema de información unificada, y que usaremos como pieza inicial para el desarrollo de la arquitectura SID. El desarrollo del framework SID El, una vez introducidos todos los conceptos necesarios para su entendimiento, se hará en el punto 5. El punto 6 introduce una aproximación del presupuesto para realizar este proyecto. Las conclusiones y trabajo futuro están recogidas en el punto 7 de este documento. Además, se añaden dos anexos con aspectos técnicos relevantes de ayuda para entender el desarrollo que hemos realizado. 16

25 2. Tecnologías utilizadas en Grid Son muchas las tecnologías que deben ser utilizadas en el ámbito de este proyecto. A continuación pasaremos a describir las más importantes utilizando cuando sea posible esquemas y gráficos que muestren su funcionamiento detallado. 17

26 2.1 Open Grid Services Architecture En el año 2001 el rápido crecimiento de la tecnología Grid y la aparición del Global Grid Forum hicieron necesario el desarrollo de una estandarización del framework orientado a Grid [3]. De esta idea surgió OGSA (Open Grid Services Architecture), un framework orientado a servicios y definido por un conjunto de estándares desarrollados dentro del Global Grid Forum. Un concepto fundamental de OGSA es el de Servicio Grid. Se trata de un servicio Web (más conocido en su forma anglosajona, Web Service) que implementa una serie de interfaces estándares, comportamientos y convenciones que permiten de una forma global que los servicios sean transitorios (pueden ser creados y destruidos) y estáticos (se pueden distinguir instancias distintas de un mismo servicio). La especificación OGSI (Open Grid Services Infraestructure) [3] define los interfaces, comportamientos y convenciones que controlan cómo los servicios Grid pueden ser creados, destruidos, renombrados, monitorizados, etc. OGSI define un conjunto de bloques que pueden ser utilizados para implementar una amplia variedad de capas de recursos, así como interfaces y comportamientos. Se podría resumir que los objetivos de OGSA son: Gestión de los recursos a través de plataformas heterogéneas distribuidas. Proporcionar calidad de servicio (QoS). La topología Grid es a menudo compleja. La interacción de los recursos del Grid es generalmente dinámica. Es importante que el Grid proporcione servicios robustos, tales como autorización, control de acceso, y delegación. Proporcionar una base común para las soluciones de gestión. Un Grid puede contener muchos recursos, con muchas combinaciones de 18

27 configuraciones, interacciones, y cambios de estado, por lo que es necesaria una forma inteligente de autorregulación y gestión de estos recursos. Define los interfaces abiertos y publicados. OGSA es un estándar abierto manejado por el GGF. Para la interoperabilidad de recursos diversos, los Grid se deben construir utilizando interfaces y protocolos estándares. Explotar tecnologías estándares de integración de la industria. Los creadores de OGSA utilizaron soluciones ya existentes para aplicarlas cuando fuera apropiado. Arquitectura de OGSA Figura Framework de OGSA La arquitectura OGSA se compone de las siguientes capas: 19

28 - Capa física y lógica de los recursos El concepto de recursos es muy importante tanto en OGSA como en Grid Computing. Los recursos abarcan las capacidades del Grid, y no se limitan a capacidad de proceso, incluyen los servidores, el almacenamiento y la red en el caso de recursos físicos. Por encima de los recursos físicos están los recursos lógicos. Proporcionan la función adicional de virtualizar y agregar los recursos en la capa física. El middleware de los sistemas de ficheros, encargados de base de datos, directorios y también del workflow proporciona estos servicios abstractos por encima del Grid físico. - Capa de Web Services Una máxima importante de OGSA es que todos los recursos del Grid (lógicos y físicos) se modelan como servicios. La Open Grid Services Infraestructure (OGSI) define servicios del Grid y las bases para construir servicios web que faciliten su acceso. OGSI explota las tecnologías de los servicios web como XML y WSDL para especificar interfaces, comportamientos, y la interacción de manera estándar para todos los recursos del Grid. OGSI amplía la definición de los servicios web para proporcionar las capacidades para los servicios web dinámicos que se requieren para modelar los recursos del Grid. - Capa OGSA de servicios del Grid La capa de Web Services, con sus extensiones de OGSI, proporciona una infraestructura importante para esta capa. El Global Grid Forum trabaja actualmente para definir muchos de éstos servicios Grid en áreas como la ejecución de programas, servicios de datos y servicios principales. Algunos ya están definidos y han sido puestos en práctica. A medida que se vayan poniendo en práctica el resto de nuevos servicios, OGSA se convertirá en una arquitectura orientada a servicios (SOA) más útil. 20

29 - Capa de aplicaciones del Grid En un cierto plazo, a medida que se vayan desarrollando servicios Grid, irán surgiendo nuevas aplicaciones para Grid. Estas aplicaciones abarcan la cuarta capa principal de la arquitectura de OGSA. Estructura de OGSA Figura Estructura de OGSA Los dos componentes lógicos principales de OGSA son los Web Services más la capa OGSI, y capa de los servicios OGSA. La razón de esta separación es que el GGF creyó que era necesario aumentar funcionalidad de los principales servicios Web para tratar los requisitos de los servicios Grid. OGSI amplía servicios Web introduciendo interfaces y las convenciones en dos áreas principales. En primer lugar está la naturaleza dinámica y potencialmente transitoria de servicios en un Grid. En un Grid, algunas instancias del servicio particulares pueden ir a venir a medida que se envía el trabajo, mientras que los recursos se configuran y mientras que el estado del sistema cambia. Por lo tanto, los servicios del Grid 21

30 necesitan interfaces para controlar su creación, destrucción y gestión del ciclo vital. En segundo lugar, está el estado. Los servicios del Grid pueden tener atributos y datos asociados a ellos. Esto es conceptualmente similar a la estructura de objetos en la programación orientada a objetos (POO). Los objetos tienen comportamiento y datos, por lo que los Web Services deben ampliar el soporte al estado de los datos asociados a servicios Grid. 22

31 2.2 Globus Toolkit Las herramientas que necesitaremos para la administración de recursos del Grid y para la ejecución correcta de procesos incluyendo descubrimiento y selección de recursos, planificación de la ejecución, monitorización y finalización correcta de las ejecuciones, se encuentran dentro del paquete de software Globus [11]. Actualmente Globus es el estándar más difundido en tecnología Grid. El software de código abierto Globus Toolkit es una tecnología fundamental para Grid Computing, puesto que permite compartir capacidad de proceso, bases de datos y otras herramientas con seguridad en línea desde cualquier ubicación corporativa, institucional y geográfica sin sacrificar la autonomía local. Globus Toolkit incluye servicios y bibliotecas necesarias para monitorización, descubrimiento, gestión, y acceso seguro de recursos. Además de ser un componente fundamental en el ámbito científico y de gestionar proyectos de miles de millones de euros internacionalmente, Globus Toolkit es una de las bases en donde las compañías están construyendo importantes productos comerciales de Grid Computing. Globus Toolkit incluye software para la seguridad, la infraestructura de la información, la gestión de recursos y de datos, la comunicación, la detección de fallos y la portabilidad. Los componentes que incorpora el software pueden ser utilizados independientemente o juntos desarrollar aplicaciones. Cada organización tiene modo de operación único, y la colaboración entre las organizaciones múltiples es obstaculizada por la incompatibilidad de recursos tales como archivos, computadoras, y redes de los datos. Globus Toolkit fue concebido para eliminar estos obstáculos que impiden la colaboración distribuida. Sus principales servicios, interfaces y protocolos permiten que los usuarios tengan acceso a recursos remotos como si estuvieran situados en su propia máquina mientras que simultáneamente preservan el control local sobre quién puede utilizar esos recursos y cuándo. Globus Toolkit ha crecido con una estrategia de código abierto similar al sistema operativo Linux, fuera de tentativas propietarias. Esto facilita una adopción más amplia, 23

32 más rápida y conduce a la mayor innovación técnica, pues la comunidad de software libre proporciona avances continuos al producto. Algunas de las herramientas que proporciona son: - GRAM (Globus Resource Allocation Manager) - GASS (Globus Access to Secondary Storage) - GSI (Grid Security Infraestructure) - MDS (Monitoring and Discovery Service) - DataGrid (incluye GridFTP, Replica Catalog y Replica Management) - GAM (Grid Architecture Monitor) Para el desarrollo concreto del proyecto nos interesan principalmente GAM y MDS [14], puesto que se encargan de la recogida de información a través de monitorización, y de la información y descubrimiento de los recursos. Por ello, más adelante los describiremos brevemente. 24

33 2.3 Arquitectura de monitorización (GAM) Se trata de la arquitectura que se encarga de monitorizar los elementos de un Grid a través de la gestión de eventos relacionados a recursos o a información recolectada de otras aplicaciones. Funciona mediante relaciones Productor-Consumidor, siendo el productor quien genera los eventos y el consumidor quien los requiere. GAM dispone además de un servicio de directorio en el que se pueden consultar los eventos accesibles y los productores que los han creado. Figura Flujo GAM 25

34 2.4 XML (extensible Markup Language) XML es un metalenguaje de etiquetas universalmente convenido utilizado sobre todo para el intercambio de información. Un buen ejemplo de lenguaje de etiquetas es HTML (Hyper Text Markup Language). A diferencia de HTML, la grandeza de XML reside en el hecho de que es extensible. Puesto de manera simple, XML es un sistema de reglas predefinidas (framework sintáctico) que es necesario seguir para estructurar los datos. Durante mucho tiempo, los programadores y los fabricantes han utilizado sistemas propietarios para la transmisión de información entre sus aplicaciones, con el inconveniente de no ser portables a plataformas de otros fabricantes, y por tanto dificultando la comunicación entre sistemas diferentes. Pero como el intercambio de información entre aplicaciones y sistemas entre empresas llegó a ser frecuente, se empezó a plantear alguna manera de intercambiar datos de una manera estandarizada puesto que los sistemas nunca fueron diseñados para aceptar datos de sistemas externos o desconocidos. XML proporciona una estructura de datos estándar y común para compartir datos entre sistemas heterogéneos. Además, XML tiene validación de datos incorporada, que garantiza que la estructura de los datos que se reciben es válida. Por ejemplo, podemos definir con XML la estructura que va a tener nuestro servicio de información WSGIIS de la siguiente manera: <wsgiis webservice=" <vo name="rediris"> <is type="nws" ip="socrates.rediris.es" port="8090"/> <is type="mds-ldap" ip="aristoteles.rediris.es" port="2135"/> </vo> <vo name="elalcazar"> <is type="nws" ip="elalcazar.org" port="8090"/> </vo> </wsgiis> 26

35 Como se puede observar, nuestro WSGIIS tendrá la propiedad webservice con el valor que hace referencia a la url del Web service, en nuestro caso Por otra parte, dentro de nuestro WSGIIS definimos dos organizaciones virtuales (VO), cada una de ellas con su identificador name. Dentro de cada VO definiremos el tipo de sensor que tiene implementado mediante is type y especificando los datos que ubican a ese sensor, es decir, ip y port. Por ejemplo, para el primer caso tendremos la VO Rediris, que tiene dos sensores. El primero de ellos es de tipo NWS y se responde en la dirección socrates.rediris.es en el puerto 8090, mientras que el segundo, de tipo MDS-LDAP, se encuentra en aristoteles.rediris.es en el puerto DTD (Document Type Definition): Cuando se comienza la codificación en cualquier lenguaje de programación es necesario conocer la especificación del lenguaje. De la misma manera, el DTD es una especificación que tiene que ser seguida cuando se crea un documento XML. Además, igual que como para cualquier lenguaje de programación se comprueba al compilar si la especificación fue seguida, de manera similar es posible utilizar programas de análisis que utilizan el DTD contra un documento de XML para comprobar que el documento es válido. Un DTD ayuda a definir la estructura de un documento XML y proporciona un framework y unas reglas estrictos que se seguirán al crear documentos XML. Además, el DTD se puede utilizar para comprobar la validez y la integridad de los datos contenidos en un documento XML. Algunas características del DTD son las siguientes: El DTD se utiliza para especificar los elementos y las cualidades válidos que se pueden utilizar en el documento XML. Con un DTD se puede definir una jerarquía en árbol de los elementos. 27

36 La organización secuencial de una colección de elementos hijo que pueden existir en un documento XML puede también ser definida usando un DTD. El DTD se puede utilizar directamente dentro del fichero fuente XML o puede estar fuera del documento XML con un enlace especificado en el documento de XML a ese DTD. 28

37 2.5 Web services Un Web service es una colección de protocolos y estándares utilizados para el intercambio de información entre aplicaciones o sistemas. Aplicaciones escritas en lenguajes muy diversos y ejecutadas en plataformas muy variadas pueden utilizar los Web services para intercambiar datos sobre redes de ordenadores, como puede ser Internet, de una forma similar a como lo haría un proceso interno de un ordenador aislado. La interoperabilidad antes mencionada se debe a la utilización de estándares abiertos. De esta manera, una aplicación escrita en Java y ejecutada en un ordenador Windows podría comunicarse con otra aplicación escrita en Perl en un ordenador Linux. Arquitectura de Web Services: Figura Framework de Web Services 29

38 La arquitectura de los Web Services se puede descomponer en los siguientes componentes tal y como se observa en la figura anterior [2]: - Servicio de Procesos: Esta parte de la arquitectura normalmente implica más de un Web service. Por ejemplo, el servicio de descubrimiento pertenece a esta capa puesto que nos permite localizar un servicio particular de una colección de Web services. - Servicio de Descripción: Una de las cosas más interesantes de los Web Services es que son auto-descriptivos. Esto quiere decir que una vez que se ha localizado un Web service se puede pedirle que se "describa a sí mismo" y te diga qué operaciones soporta y la forma de llamarlas. Esto está manejado por el WSDL (Web Services Description Language). - Servicio de Llamada: Invocar un Web service (y en general cualquier tipo de servicio distribuido como un objeto CORBA o un EJB) requiere un intercambio de mensajes entre el cliente y el servidor. SOAP especifica cómo debemos formatear las peticiones al servidor y cómo el servidor debe formatear sus respuestas. En teoría podemos utilizar otros lenguajes de invocación de servicios como XML-RPC, pero SOAP es el estándar más extendido para los Web services. - Servicio de Transporte: Por último todos estos mensajes deben ser transmitidos de alguna manera entre el cliente y el servidor. El protocolo que se ha seleccionado para esta parte de la arquitectura es HTTP, que es el mismo protocolo que se utiliza para acceder a páginas web convencionales en Internet. Los dos problemas principales solucionados por los Web Services respecto a los anteriores modelos de sistemas distribuidos tales como CORBA, DCOM, RPC y demás fueron: 1. Interoperabilidad: Los sistemas distribuidos anteriores tuvieron problemas de interoperabilidad porque cada fabricante utilizó su propio protocolo de comunicación para la mensajería distribuida de objetos. Usando XML como estándar de la comunicación, plataformas tan opuestas como Java/J2EE y.net/c # pueden ahora comunicarse entre sí. 30

39 2. Cortafuegos transversal: La colaboración entre corporaciones era complicado porque los sistemas distribuidos tales como CORBA y DCOM utilizaban puertos no estándar. Consecuentemente, la colaboración implicaba la creación de un agujero en sus cortafuegos, que era a menudo inaceptable. Los Web services utilizan el protocolo HTTP, a través del puerto 80, que es un puerto al que la mayoría de los cortafuegos permiten el acceso llevando así a una colaboración más fácil y dinámica. A todo esto hay que sumar que la naturaleza dinámica de los Web services proporciona muchos servicios interesantes a los usuarios en computación colaborativa entre organizaciones. 31

40 2.6 SOAP SOAP (Simple Object Access Protocol) es un protocolo elaborado para facilitar la llamada remota de funciones a través de Internet, permitiendo que dos aplicaciones se comuniquen de una manera muy similar técnicamente a la invocación de páginas Web. El protocolo SOAP tiene diversas ventajas sobre otras maneras de llamar funciones de manera remota como DCOM, CORBA o directamente en TCP/IP: Es sencillo de implementar, probar y usar. Es un estándar de la industria adoptado por W3C ( y por varias otras empresas. Utiliza los mismos estándares de la Web para casi todo: la comunicación se hace mediante HTTP con paquetes virtualmente idénticos; los protocolos de autenticación y encriptación son los mismos; el mantenimiento de estado se hace de la misma forma; se implementa normalmente por el propio servidor Web. Es capaz de pasar a través de firewalls y routers, que toman estos mensajes como una comunicación HTTP. Tanto los datos como las funciones se describen en XML, lo que permite que el protocolo no sólo sea más fácil de utilizar sino que también sea muy sólido. Es independiente del sistema operativo, del procesador e incluso del lenguaje en el que se programe puesto que se emplea código XML estándar. Esto quiere decir que un programa cliente puede estar desarrollado en una arquitectura Intel bajo Windows en lenguaje Java, mientras que el servidor podría estar en un PPC con Linux programado en Perl. 32

41 Se puede utilizar tanto de forma anónima como con autenticación (nombre/clave). También hay que señalar que la utilización de SOAP y Web Services tiene algún defecto y que por supuesto no es la panacea [2]: Si se quieren transmitir grandes volúmenes de datos, hacerlo con XML no es tan eficiente como podría ser hacerlo en algún código binario propietario. Es decir, que lo que se gana en portabilidad se pierde en eficiencia. Incluso aunque esta sobrecarga de datos en XML es aceptable para la mayoría de aplicaciones, no se debería utilizar en entornos de tiempo real (RT). Falta de madurez. Los Web Services son relativamente nuevos y aunque las especificaciones principales que se tratan con lenguajes como XML o WSDL son muy estables, aún están sufriendo mejoras. Las solicitudes SOAP se pueden hacer en tres estándares: GET, POST y SOAP. Los estándares GET y POST son idénticos a las solicitudes hechas por navegadores de Internet. SOAP es un estándar similar a POST, pero las solicitudes se hacen en XML y permiten recursos más sofisticados, como pasar estructuras y arrays. Independientemente de cómo se haga la solicitud, las respuestas siempre son en XML. XML describe perfectamente los datos en tiempo de ejecución y evita los problemas ocasionados por cambios inadvertidos en las funciones, ya que los objetos llamados tienen la posibilidad de validar siempre los argumentos de las funciones, haciendo que el protocolo sea muy sólido. Así mismo, SOAP define un estándar llamado WSDL, que describe perfectamente los objetos y métodos disponibles a través de páginas XML accesibles por la Web. La idea es la siguiente: quien publica un servicio crea también estas páginas. Quien quiera llamar al servicio puede utilizar estas páginas como documentación de la llamada y también utilizarlas antes de llamar las funciones para 33

42 verificar si cambió algo. Pila de Web Services: El modelo de Web services sigue el paradigma de publicar, encontrar, y enlazar. En el primer paso, un proveedor de servicios publica un Web service en un servicio de registro de Web services, llamado Web Service Registry (WSR). En segundo lugar, un cliente que está buscando un servicio para un cierto requisito busca en un WSR. Cuando lo encuentra, elige un servicio que se ajuste a sus preferencias. El cliente después descarga la descripción del servicio y enlaza con él para llamarlo y utilizarlo. Figura Participantes del protocolo SOAP Una de las preocupaciones principales de los programadores de Web Services era cómo transmitir datos de una manera unívoca. En la última capa de la pila se encuentra el estándar XML, que es precisamente quien se encarga de esto. El protocolo SOAP por su parte se puede ver como un mecanismo basado en XML utilizado para la mensajería. Se soluciona el problema fundamental del cortafuegos transversal en sistemas RPC usando el HTTP como el protocolo de transporte. El servicio será 34

43 invocado por SOAP. Figura Pila de SOAP WSDL (Web Services Description Language) proporciona una forma basada en XML de describir un Web service, dando los detalles de cómo usarlo. WSDL es un equivalente en XML de IDL (lenguaje de definición de interfaz), utilizado cuando los RPC estaban más extendidos. UDDI (Universal Description Discovery Integration) proporciona un directorio de páginas amarillas de los Web services, haciendo más fácil a los clientes descubrir los servicios que necesiten. El proveedor de un servicio publica su descripción (WSDL) y otros detalles interesantes en el registro de UDDI. Por su parte, un cliente utilizará UDDI para realizar la búsqueda de un servicio determinado. Llamada típica a Web Services con SOAP: Suponiendo que ya hayamos localizado el Web service que queremos utilizar (bien porque hayamos realizado una consulta a un servicio de búsqueda o bien porque ya tuviéramos de antemano la URI del Web service), podemos realizar la comunicación de la siguiente manera: 1. En el momento en el que la aplicación cliente necesite llamar al Web service, 35

44 lo que realmente hará será llamar al stub del cliente. El stub del cliente transformará esta llamada local en una petición SOAP. Este proceso se conoce como marshaling. 2. La petición SOAP se envía a través de la red utilizando el protocolo HTTP. El servidor recibe la petición SOAP y la envía al stub del servidor, que transformará la petición SOAP en algo que el servicio implementado pueda entender. Este proceso se conoce como unmarshaling. 3. Una vez que la petición SOAP ha sido deserializada, el stub del servidor hace una llamada al servicio implementado, que se encarga de ejecutar la tarea para la que ha sido llamado. 4. El resultado de la operación solicitada es enviado al stub del servidor, que lo convertirá en una respuesta SOAP. 5. La respuesta SOAP se envía a través de la red utilizando el protocolo HTTP. El stub del cliente recibe la respuesta SOAP y la convierte en algo que la aplicación cliente pueda entender. 6. Por último, la aplicación recibe el resultado de la llamada al Web service [9] y la utiliza. 36

45 2.7 Web Services Resource Framework (WSRF) Anteriormente se ha visto que la tecnología de Web services es la elección más adecuada para aplicaciones basadas en comunicación a través de Internet y con una gran descentralización tanto de clientes como de servidores. Esto hace de los Web services la mejor opción para construir aplicaciones para Grid computing, aunque por sí mismos son insuficientes para este fin debido a sus limitaciones. Mediante WSRF [2] se mejoran un gran número de aspectos de los Web services para adecuarlos a aplicaciones Grid. La mejora más importante introducida por WSRF es, sin duda, proveer de estado a los Web services. Los Web services por si mismos son incapaces de guardar estados. Esto quiere decir que no puede recordar información de una llamada a otra, puesto que no puede almacenar la información de la primera llamada para poder utilizarla en la siguiente. Las aplicaciones Grid requieren habitualmente almacenamiento de estado y los Web services por sí mismos no pueden ofrecérselo. La solución a este problema pasa por mantener la información de estado por separado en entidades que se conocen como recursos. Cada recurso tiene una clave única, lo que quiere decir que cada vez que queramos que cierta información de estado interactúe con un Web service simplemente le tenemos que decir a éste que utilice un recurso en particular. 37