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
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: Alberto Romero Luezas
DIRECTOR: Antonio Fuentes Bermejo
RedIRIS, Red Nacional de I+D+i MADRID, Junio 2006
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.
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.
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.
Índice General
1. Introducción ……….. 1
1.1 Sistemas de monitorización en Grid ……….. 2
1.2 Sistemas distribuidos ………. 5
1.3 Estado actual del arte ………... 11
1.4 Motivación ………... 13
1.5 Objetivos ………. 14
1.6 Organización del documento ………... 16
2. Tecnologías utilizadas en Grid ……….. 17
2.1 Open Grid Services Architecture ……… 18
2.2 Globus Toolkit ……… 23
2.3 Arquitectura de Monitorización (GAM) ………. 25
2.4 XML ……… 26
2.5 Web Services ………...29
2.6 SOAP ………... 32
2.7 Web Services Resource Framework ……….... 37
3. Sistemas de Monitorización de Recursos ………. 40
3.1 Requerimientos de un sistema de monitorización …………... 41
3.2 Sistemas de Información ………. 43 3.2.1 MDS ………. 44 3.2.2 NWS ………. 48 3.2.3 Ganglia ………. 50 4. Arquitectura WSGIIS ……… 53 4.1 Introducción ………. 54 4.2 Marco de utilización ……… 55 4.3 Limitaciones ……… 56
5. Arquitectura SID ……… 58
5.1 Introducción ………. 59
5.2 Framework ………... 60
5.2.1 Sistema de Información Unificado …………... 61
5.2.2 Gestor de la Información ……….. 69
5.2.3 Servicio de Búsqueda de Recursos ………... 72
5.2.4 Sincronización entre Servicios de Información……. 90
5.2.5 Adhesión Federativa ………. 91
5.2.6 Acceso a Interfaz de Recursos ………. 92
6. Presupuesto ………. 93
7. Conclusiones ………... 95
7.1 Mejoras que supone la nueva arquitectura ……….. 96
7.2 Trabajos futuros ……….. 98
8. Anexos ………. 99
8.1 Anexo A: Instalación de Globus Toolkit 4.0 ……….100
8.2 Anexo B: Definición del XML Glue Scheme ……….. 103
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.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
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.
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.
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.
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
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?
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:
• 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
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.
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 (http://public.eu-egee.org/). 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 (http://it.nees.org/): Proporciona una gran infraestructura para el NEES (Network for Earthquake Engineering Simulation) uniendo grandes centros de investigación de los Estados Unidos.
- TeraGrid (http://www.teragrid.org/): 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.
- Access Grid (http://www.accessgrid.org/): Un sistema Grid utilizado para encuentros de colaboración, grandes sesiones de trabajo, seminarios y tutoriales.
- eDiaMoND (http://www.ediamond.ox.ac.uk/): 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.
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.
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.
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.
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.
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.
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
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 2.1.1 Framework de OGSA
- 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.
- 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 2.1.2 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
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.
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,
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.
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.
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="http://platon.rediris.es:8080/axis/services/wsgiislower"> <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>
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 http://platon.rediris.es:8080/axis/services/wsgiislower.
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 2135.
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.
• 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.
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:
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
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.
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 (http://www.w3.org/TR/SOAP/) 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.
• 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
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 2.6.1 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á
invocado por SOAP.
Figura 2.6.2 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:
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.
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.
Figura 2.7.1 Ejemplo de funcionamiento de WS
A través del WS-Addressing podemos construir referencias a puntos de acceso que nos permitan acceder a servicios de Web services, que se trataría básicamente de una URI que hiciera referencia a un Web service determinado. Además debemos incluir alguna indicación en nuestra referencia para acceder a un recurso determinado detrás de ese Web service, que se conoce como WS-Resource.qualified endpoint reference (EPR).
En esta línea, podemos entender un EPR como un puntero a un recurso de un Web service (WS-Resource).
Propiedades de los recursos:
Los diferentes valores que existen en cada recurso son las propiedades de ese recurso. Generalmente se utilizan para almacenar los tres tipos siguientes de información:
Valores de datos del servicio: Proporcionan información del estado actual del servicio, como pueden ser sus propiedades, resultados de sus operaciones, resultados intermedios, información de ejecución, etc. En este apartado podríamos incluir los referentes a nombre archivo, tamaño y descriptores.
Metadatos del valor: Información acerca de los valores de los datos propios del servicio. Por ejemplo, podríamos tener una propiedad de un recurso que nos dijera cuándo modificó el usuario por última vez las propiedades del recurso.
Información necesaria para gestionar el estado: Este tipo de información es similar a los metadatos, pero se refiere al recurso como un todo. Por ejemplo, podemos crear una propiedad que especifique el momento en el que queramos que el recurso sea destruido.
3. Sistemas de Monitorización de
Recursos
En este apartado describimos los sistemas de monitorización utilizados por los principales desarrollos de Grid europeos como son MDS [14], NWS [13] y Ganglia [16], todos ellos de interfaces abiertas para garantizar una compatibilidad máxima entre sí.
3.1 Requerimientos de un sistema de monitorización
Dada la heterogeneidad de un Grid y debido al gran número de elementos que intervienen en él no se puede decir que exista una solución única de monitorización. Al contrario, los sistemas Grid suelen contar con varios sistemas de monitorización para cubrir el mayor número posible de necesidades, unificándose para dar la impresión de tener un único sistema global.
En Globus existe un framework de monitorización para Grid, conocido como GAM y del que ya se ha hablado anteriormente. De cualquier forma, se utilice el entorno que se utilice hay una serie de requisitos de obligado cumplimiento:
• Fiabilidad: Aunque alguno de los componentes del sistema de
monitorización falle, éste debe poder seguir ofreciendo servicio. Esto implica que cada uno de los módulos del sistema de monitorización sea lo suficientemente independiente del resto como para que los demás módulos continúen funcionando en condiciones de fallo del primero.
• Persistencia: Toda la información que se vaya generando por medio del sistema de monitorización se deberá ir almacenando en discos u otros medios de almacenamiento duraderos.
• Escalabilidad: Se debe tener siempre en cuenta la posibilidad de añadir
nuevos recursos al sistema de monitorización evitando que los posibles cambios perjudiquen a la totalidad del sistema, sino que al contrario, éste mejore proporcionalmente.
• Seguridad: Será necesario que el sistema valide la información que proceda de las distintas partes del Grid mediante la utilización de certificados o elementos de seguridad similares.
Existen otras valoraciones que aunque no son estrictamente necesarias, sí que son bastante aconsejables:
• Evolución: Los sistemas de monitorización deben estar en continua
evolución para adaptarse a las nuevas necesidades que vayan surgiendo en el entorno de los Grid.
• Utilización de estándares abiertos: La utilización de estándares abiertos es la forma más indicada para que todos los sistemas Grid puedan entenderse y se puedan gestionar de la manera más homogénea posible.
3.2.1. MDS
El Monitoring and Discovery System (MDS) [14] es el entorno de monitorización que proporciona el Globus Toolkit, actualmente en su versión 4. MDS4 implementa una interfaz de Web Services estándar y una gran variedad de herramientas de monitorización y otras fuentes de información. Puede verse como un conjunto de protocolos que define unos estándares de acceso a información y de representación a través de esquemas predefinidos. Por debajo de esos protocolos quedarían las interfaces a las diferentes fuentes de información, convirtiendo sus esquemas propios de representación de la información en esquemas XML basados en el esquema estándar GLUE).
Por encima de estos protocolos se pueden construir varias herramientas y aplicaciones que puedan aprovechar las ventajas que ofrecen las peticiones de Web Services, las suscripciones y las interfaces de notificación a estas fuentes de información que MDS4 implementa. Todas estas implementaciones vienen definidas en el WSRF (WS Resource Framework) y en el WS-Notification.
Los recursos y servicios de un Grid pueden generar una gran cantidad de información por varios casos de uso diferentes. MDS4 fue específicamente diseñado para satisfacer las necesidades de un sistema de monitorización de Grid, es decir, uno que proporcione información que está siendo utilizada por mucha gente a lo largo de muchas organizaciones virtuales. Como tal, no se trata de un sistema de control de eventos como puede ser NetLogger, o un gestor de clusters como se verá más adelante en Ganglia [16], pero interacciona con estas fuentes de información para unificarlas.
Es necesario tener en cuenta dos factores a la hora de diseñar un sistema de monitorización para encontrar el balance adecuado entre cantidad de información y los costes que éstos pueden suponer. MDS4 permite que el usuario decida acerca de estos parámetros controlando la información que va a ser publicada.
* hacer peticiones a los servicios de WSRF para obtener información de las características del recurso
* ejecutar un programa para adquirir información
* actuar de interfaz con otros sistemas de monitorización
Servicios de MDS4:
MDS4 incluye dos servicios basados en WSRF: un servicio de índice (Index Service) que recoge datos de varias fuentes y proporciona un interfaz de query/suscripción a esos datos, y un servicio de disparador (Trigger Service) [8] que recoge datos de varias fuentes y se puede configurar para tomar la acción basándose en esos datos. Se planea para un lanzamiento futuro un servicio de archivo que proporcionará el acceso a los datos históricos.
El servicio del índice es un registro similar a UDDI, pero mucho más flexible. Los índices recogen la información y la publican como características del recurso . Los clientes utilizan las peticiones estándar de las características del recurso de WSRF e interfaces de suscripción/notificación para recuperar la información de un índice. Los índices pueden colocarse de manera jerárquica para agregar datos en varios niveles. Los índices son self-cleaning, lo que quiere decir que cada entrada del índice tiene un ciclo de vida y será eliminada del índice si no se restaura antes de que expire.
Cada contenedor de Globus que tiene MDS4 instalado tendrá automáticamente una instancia del servicio del índice. Por defecto, cualquier servicio del GRAM, de RFT, o del CAS que funciona en ese contenedor se colocará al servicio del contenedor por defecto del Index Service.
El Trigger Service recoge la información y la compara con un conjunto de condiciones definidas en una archivo de configuración. Cuando una condición se produce, o se acciona un disparador, una acción ocurre, por ejemplo el envío de un mail a un administrador de sistema cuando el espacio de disco en un servidor alcanza un cierto umbral.
Interfaces de Información – Aggregator Framework:
Además de los servicios descritos anteriormente, MDS4 incluye varios componentes de software adicionales, incluyendo el Aggregator Framework, que proporciona un mecanismo unificado utilizado por el Index Service y el Trigger Service para recoger datos.
El Aggregator Framework es una interfaz para construir los servicios que recogen y agregan datos. A los servicios (tales como el Index Service y el Trigger Service) que están construidos en este framework se les conoce como los servicios del aggregator y tienen las siguientes características en común:
• Recogen la información a través de Aggregator Sources. Un Aggregator Source es una clase Java que implementa un interfaz (definido como parte del Aggregator Framework) para recoger datos con formato XML.
• Utilizan un mecanismo de configuración común para mantener
información acerca de qué Aggregator Source utilizar y sus parámetros asociados (que especifican generalmente qué datos conseguir y de dónde). El Aggregator Framework WSDL define grupo de servicios de agregación que mantiene tanto información de configuración como los propios datos. Los programas cliente emplean un mecanismo estándar de registro de servicios de WSRF para colocar estas entradas en el
Aggregator Service.
• Son self-cleaning, lo que quiere decir que cada registro tiene un tiempo de vida, y que si un registro expira sin haber sido confirmado, él y sus datos asociados se eliminan del servidor.
MDS4 incluye los tres Aggregator Sources siguientes:
• la Query Aggregator Source que pide a un servicio WSRF información de alguna característica de un recurso,
• la Subscription Aggregator Source que recoge datos de un servicio
• WSRF a través del estándar WSRF de suscripción/notificación,
• la Execution Aggregator Source que ejecuta un programa proporcionado por el administrador provisto para recoger la información.
3.2.2. NWS
El Network Weather Service [13] es un sistema distribuido que periódicamente monitoriza y pronostica de manera dinámica el funcionamiento de una gran cantidad de recursos tanto de red como de cómputo durante un intervalo dado de tiempo. El servicio funciona mediante un conjunto de sensores distribuidos (monitores de red, monitores de CPU, etc.) de los cuales recoge las lecturas de las condiciones en un instante concreto. Para ello utiliza modelos numéricos para generar pronósticos de cuáles serán las condiciones para un intervalo de tiempo dado. Esta funcionalidad es la que se utiliza análogamente en el pronóstico de tiempo, y de ahí es de donde el sistema hereda su nombre.
El NWS ha sido desarrollado para ser utilizado por planificadores dinámicos y para proporcionar lecturas estadísticas del QoS (Quality of Service) en entornos de computación en red. Además, se han desarrollado prototipos para su integración con Globus Toolkit y con la arquitectura GIS (Grid Information System) creada por el Global Grid Forum (GGF) [1].
Actualmente, el sistema incluye sensores que miden el rendimiento end-to-end de TCP/IP (ancho de banda y latencia), el porcentaje de utilización de la CPU, y la memoria sin paginar disponible. El interfaz del sensor, sin embargo, permite que nuevos sensores internos sean configurados e integrados junto al resto en el sistema, aunque aún se está mejorando.
El conjunto actual de métodos de pronóstico trata las sucesivas medidas de cada sensor como una serie en el tiempo. Estos métodos están encuadrados en tres categorías:
• métodos basados en la media, que utilizan una cierta estimación de la media de la muestra como pronóstico
• métodos basados en la mediana, que utilizan un estimador de la media
El sistema sigue la exactitud (utilizando el error de la predicción como medida de la exactitud) de todos los sensores y utiliza la que tiene un error acumulativo menor en cualquier momento dado para generar un pronóstico. De esta manera, el NWS identifica automáticamente la mejor técnica de pronóstico para cualquier recurso dado. Por otra parte, a medida que se agregan nuevos métodos, éstos serán utilizados automáticamente para pronosticar el funcionamiento del recurso para el cual son los más precisos.
3.2.3. Ganglia
Ganglia [16] se basa en un diseño jerárquico centrado en federaciones de clusters. Utiliza un protocolo de escucha/respuesta multicast para monitorizar el estado de los clusters y emplea un árbol de conexiones punto a punto entre nodos significativos de un cluster para federar sus clusters asociados y para agregar su estado. Utiliza tecnologías tan utilizadas como XML para la representación de datos, XDR para el transporte compacto y portable de los datos, y RRDtool para el almacenamiento y representación de los datos. Además ha sido portado a una cantidad importante de sistemas operativos y arquitecturas.
Ganglia utiliza dos demonios, un frontend web basado en PHP y alguna otra utilidad pequeña.
Ganglia Monitoring Daemon (gmond)
Gmond es un demonio multihilo que funciona en todos los nodos del cluster que se desea monitorizar. Tiene cuatro cometidos principales: monitorizar los cambios de estado del host, anunciar cambios relevantes, escuchar el estado del resto de los nodos monitorizados mediante canales unicast o multicast pidiendo descripciones XML del estado del cluster.
Cada gmond transmite la información de dos posibles maneras: estado del host unicast/multicast en el formato externo de la representación de datos (XDR) usando mensajes UDP o enviando XML sobre una conexión TCP.
En su archivo de configuración permite especificar un buen número de métricas con la siguiente morfología:
Ganglia Meta Daemon (gmetad)
La federación en Ganglia se consigue utilizando un árbol de conexiones punto a punto entre los nodos representativos del cluster para agregar su estado. En cada nodo del árbol un gmetad recoge una colección de datos, analiza el XML recogido, guarda todas las métricas y las exporta a las bases de datos mediante sockets TCP a los clientes. Las fuentes de datos puede ser cualquier demonio gmond, representando clusters específicos, u otros representando conjuntos de clusters. Las fuentes de datos utilizan direcciones IP para el control de acceso.
Es necesario especificarle a gmetad una fuente de datos (data source) de la siguiente manera a través de su archivo de configuración:
collection_group { collect_once = yes time_threshold = 1200 metric { name = "cpu_num" } metric { name = "cpu_speed" } metric { name = "mem_total" }
Si no se le especifica el puerto como en este caso se ha hecho, tomará por defecto el 8649.
Interfaz PHP
El frontend web de Ganglia proporciona una vista de la información recopilada mediante páginas dinámicas generadas en tiempo real. Lo que es más importante, muestra los datos de Ganglia de una manera más apropiada para los administradores de sistema y los usuarios del sistema. De esta forma, muestra gráficos similares para la utilización de memoria, de disco, estadísticas de red, el número de procesos en ejecución y el resto de las métricas de Ganglia.
4. Arquitectura WSGIIS
Este capítulo cierra la sección dedicada a tecnologías utilizadas en Grid, describiendo el framework WSGIIS, cuya finalidad es la unificación de información de los distintos sistemas de información que un almacén de recursos puede utilizar, valiéndose de Web Services para realizar el intercambio de información.
4.1 Introducción
WSGIIS [5] es un middleware que crea una capa de abstracción entre varios sistemas de monitorización permitiendo unificar de una manera elegante los datos de éstos para proporcionárselos a los planificadores de manera normalizada. Además de ser un sistema de información global de Grid, WSGIIS es un framework.
Los objetivos principales que persigue son los siguientes:
- Crear un sistema de información global del Grid - Uso de tecnologías web para dicho sistema
- Creación de un framework para poder crear módulos que se interconecten a varios proveedores de información de diferentes sistemas
