Sistemas distribuidos Tecnología de Gridssistema operativo de una computadora o servidor. El...

Sistemas distribuidos Tecnología de Grids

Página 1


Página 2

Grids y e-Ciencia Los proyectos científicos de comienzos de este siglo abordan objetivos cada vez más ambiciosos que requieren la resolución de problemas computacionales complejos, tanto por el volumen de los cálculos a realizar como por el tamaño y complejidad de las bases de datos utilizadas. Del mismo modo, los equipos científicos son en muchos casos colaboraciones internacionales, con miembros distribuidos por todo el planeta. Áreas científicas como la Física de Altas Energías, Ciencias del Espacio, Genómica y Proteómica, Meteorología, Biomedicina/Diagnóstico Médico, basan su desarrollo en estos proyectos. El término e-Ciencia se utiliza para denominar la vertiente computacional de estos proyectos. La organización de los correspondientes recursos de computación, es un desafío. Transformando este desafío en parte de la solución, la tecnología Grid propone agregar y compartir recursos de computación distribuidos entre diferentes organizaciones e instituciones, a través de redes de alta velocidad, de modo que el acceso a los mismos por parte de los científicos para sus necesidades de cálculo sea tan sencillo, flexible y fiable como el uso de la corriente eléctrica para satisfacer sus necesidades de energía.

Evolución de los recursos computacionales A pesar de que la ley de Moore se cumple año tras año, y un ordenador personal, o PC, actual tiene una potencia superior a la de un supercomputador Cray de hace 10 años, la resolución de muchos problemas de cálculo científico sigue siendo un desafío, tanto en cuanto a técnicas como a recursos. La solución como veremos viene dada por dos acciones conjuntas: agregar y compartir. En paralelo al desarrollo de supercomputadores con un número creciente de procesadores, una de las soluciones con más éxito en los últimos años ha sido la construcción de clusters de ordenadores individuales: “granjas” con nodos interconectados mediante una red local de alta velocidad. En particular, para reducir el costo se emplea “commodity hardware”: PC’s con procesadores Intel Pentium o similares y conectados por Fast o Gigabit Ethernet. La computación en Física de Partículas es un ejemplo claro de esta evolución: los experimentos del anterior acelerador LEP del CERN (el Centro Europeo de Física de Partículas, Ginebra) pasaron de usar ordenadores Cray e IBM a granjas con decenas de procesadores RISC y sistema operativo Unix en la primera parte de la década de los 90, y “fabricas” de cientos de PC’s con sistema operativo Linux a finales de la misma. Un ejemplo de las posibilidades de compartir estos recursos lo proporcionó la simulación en un solo fin de semana utilizando los recursos completos del CERN de más de cinco millones de colisiones e+e-, para mejorar los resultados de la búsqueda del bosón de Higgs del experimento DELPHI: una tarea de meses en las máquinas RISC dedicadas de la colaboración. El próximo acelerador LHC, que entrará en funcionamiento en el año 2007, requerirá el almacenamiento y procesamiento de varios Petabytes (millones de Gigabytes) de datos cada año. Los recursos necesarios se estiman en el equivalente de una “fábrica” de 200.000 PC’s, un orden de magnitud por encima de los mayores supercomputadores actuales, y con claras dificultades técnicas, operativas y de financiación. La solución viene de la mano del problema: agregar y compartir los recursos proporcionados por las instituciones participantes en los experimentos del LHC, distribuidas geográficamente por todo el mundo. La evolución de los recursos de red, doblando su capacidad cada nueve meses, a comparar con los dieciocho meses de la ley de Moore para la capacidad de cálculo, han hecho factible esta posibilidad. Evolución tecnológica: � Network vs. performance de

computadoras: � La velocidad de las computadoras se

duplica cada 18 meses. � La velocidad de la red se duplica cada 9

meses. � La diferencia en orden de magnitud es

de 5 años. � 1986 a 2000: � Computers: x 500. � Networks: x 340,000.

� 2001 a 2010: � Computers: x 60. � Networks: x 4000.


Página 3

Cadena Alimenticia de la Computación (presente y futuro)

Evolución de las plataformas

Computación a través de la red La tecnología Grid nace dentro de la comunidad de supercomputación y de nuevo está basada en las dos acciones, agregar y compartir, junto a la evolución de la red. La evolución de las redes académicas locales posibilita agregar la capacidad de todos los equipos en funcionamiento de una institución: el sistema Condor (http://www.cs.wisc.edu/condor) desarrollado por Miron Livny para la plataforma Linux nació para aprovechar el tiempo de inactividad de estas máquinas, permitiendo agregar y compartir estos recursos, transformándose en un sistema completo de gestión de los mismos. El siguiente paso fue la extensión a recursos conectados a través de Internet: la red Entropía (http://www.entropia.com) agregó en dos años 30.000 ordenadores, logrando por ejemplo calcular el


Página 4

mayor número primo conocido. Del mismo modo, el sistema SETI (http://setiathome.ssl.berkeley.edu) funciona en más de medio millón de PC’s analizando los datos del radio telescopio Arecibo a la búsqueda de señales de inteligencia extraterrestre. La computación utilizando recursos distribuidos a través de la red no es una cuestión trivial. Las aplicaciones del denominado entorno de High Throughput Computing (HTC), son más sencillas de adaptar a una ejecución distribuida, mediante su división en múltiples partes cada una de las cuales procesada independientemente requiere un tiempo considerable de cálculo. Por ejemplo, la simulación de cien millones de colisiones en un experimento de Física de Partículas puede realizarse de modo distribuido en cien máquinas cada una de las cuales realiza de manera independiente la simulación de un millón de sucesos. Por el contrario, en un entorno de High Performance Computing (HPC), requiere una respuesta inmediata global del sistema para que la aplicación progrese y el cálculo no puede distribuirse de manera independiente. Estas fronteras se difuminan tanto más en cuanto la capacidad de la red en tiempo de respuesta y de tranfencia de datos mejora en comparación con el tiempo de ejecución de cada paso en la aplicación, cuando ésta contiene componentes paralelizables. Un caso típico es el entrenamiento de una red neuronal distribuida, donde el error en cada paso sucesivo se puede calcular de modo independiente distribuyendo la muestra de entrenamiento entre los diferentes nodos, y el error global se obtiene al final de cada paso agregando los resultados de los mismos. Las técnicas de paralelismo aplicables a máquinas multiprocesadoras, como las basadas en el uso de MPI (Message Passing Interface - http://www-unix.mcs.anl.gov/mpi/) pasan a poder aplicarse a nodos conectados en red. La tecnología Grid En 1995 durante el congreso SuperComputing ’95, la experiencia I-WAY demostró la posibilidad de ejecutar aplicaciones distribuidas de diferentes áreas científicas en una red de 17 centros de USA conectados con una red de alta velocidad (55 Mbps). Éste fue el punto de partida de varios proyectos en diferentes áreas, con un denominador común: compartir recursos distribuidos de computación. El libro “The Grid: Blueprint for a New Computing Infraestructure”, editado por Ian Foster y Carl Kesselman, presenta muchas de estas iniciativas. En el prólogo, Foster y Kesselman plantean la analogía con la “Electrical Power Grid”: el usuario debe tener acceso a los recursos computacionales en condiciones similares a las que tiene para utilizar la energía eléctrica: desde cualquier sitio (pervasive), con un interfase uniforme (consistent), pudiendo confiar en su funcionamiento (dependable), y a un coste accesible (inexpensive). Esta filosofía marca un punto de inflexión con los proyectos previos, y posibilita su uso en el entorno profesional científico, donde los recursos experimentales y humanos tienen en general un costo elevado y deben ser optimizados. Entre los primeros proyectos Grid surge la Information Power Grid de la NASA, la iniciativa de la National Science Foundation con los centros de supercomputación de NCSA y SDC, y la Advanced Strategic Computing Initiative del DOE. ¿Qué es un grid? Un grid computacional es una infraestructura de hardware y software que provee acceso desde cualquier sitio, de forma consistente, confiable y económica, y con una capacidad de cómputo de alta performance. Un grid es un sistema que: � Coordina recursos que no están sujetos a un control centralizado. Integra y coordina

recursos (de red, de procesamiento, de almacenamiento, etc.) y usuarios que se encuentran en distintos dominios (geográficamente dispersos). Por ejemplo, estaciones de trabajo y unidades de procesamiento central, distintas unidades administrativas de la misma compañía o diferentes compañías, y gestiona asuntos de seguridad, políticas, miembros, y otros que surjan en la posteridad. De lo contrario estaríamos lidiando con una administración local del sistema.

� Utiliza protocolos e interfaces estándar, abiertas y de propósitos generales. Un grid esta construido de protocolos multipropósito e interfaces que gestionan asuntos fundamentales como autenticación, autorización, descubrimiento de recursos y acceso a recursos. Es muy importante que estos protocolos e interfaces sean estándar y abiertos. De otra forma estaríamos lidiando con sistema de aplicación específico.

� Entrega calidades de servicio no triviales. Un grid permite a sus recursos componentes ser utilizados en forma coordinada para entregar distintas calidades de servicios, relacionadas por ejemplo con el tiempo de respuesta, disponibilidad, y/o redistribución de múltiples tipos de recursos para alcanzar las complejas demandas del usuario, tal que las prestaciones del sistema combinado sean significativamente superiores a las de la suma de sus partes.


Página 5

Resumiendo, un grid es una agregación de recursos de red, procesamiento y almacenamiento, geográficamente dispersos, coordinados para proveer de una mejor performance, mayor calidad de servicio, mejor utilización, y más fácil acceso a datos, que permite compartir aplicaciones y datos entre organizaciones, en un ambiente heterogéneo. Las redes grid, como concepto, no son nuevas. Lo que si es reciente es la transición desde investigación y desarrollo hacia mercados más comerciales. La misión del grid es la de virtualizar el procesamiento, con el objetivo de crear un modelo de cómputo sobre un conjunto de recursos distribuidos. En una sola computadora existen elementos estándar incluidos el procesador, almacenamiento, sistema operativo, y dispositivos I/O. El concepto de grid es el de crear un entorno similar, sobre un área distribuida, hecho de elementos heterogéneos incluyendo servidores, dispositivos de almacenamiento, y redes; una plataforma de procesamiento escalable de área amplia. El software que maneja la coordinación entre los elementos participantes es análogo al sistema operativo de una computadora o servidor.

El proceso de cómputo Proceso de cómputo en grid

El denominador común entre todos lo desarrollos de grids es la capa de red. Las tecnologías de red de alta velocidad han sido la piedra basal en la evolución de tecnologías de grids y lo continuarán siendo en el futuro. Sistemas grid distribuidos demandan conectividad de alta velocidad y ultra baja latencia, siendo los sistemas de conmutación High-Performance Ethernet críticos para alcanzar tales requerimientos. El mercado de procesamiento en grids, en su conjunto, está en una etapa temprana, pero ahora es el momento para iniciar el desarrollo de proyectos grids, particularmente por la siguientes razones: � Hay un número significativo de aplicaciones emergentes, proveniente de mercados importantes

incluyendo energía y petróleo, servicios financieros, gobierno, medicina y manufactura. � La infraestructura que soporta estas aplicaciones está actualmente sin reservar. � El mercado potencial es substancial, con predicciones de un gran crecimiento futuro. � Investigación y desarrollo por parte de los jugadores más grandes, incluidos Dell, HP, IBM, Microsoft,

y Sun, es un indicador de que es un mercado en crecimiento. A medida que los grids evolucionan desde clusters a centros virtuales de datos empresariales, campus distribuidos y desarrollos de área amplia, la red subyacente debe crecer (a un costo eficiente) en escala y performance, para satisfacer las demandas durante el proceso. El GRID puede introducirse mediante su comparación con la Web � La Web da soporte a la ubicación y acceso a la información en un área extensa. � Se puede acceder a una Web sin saber donde está ubicada, la PC interpreta el código y

presenta la información. � El GRID da soporte a la iniciación y ejecución de procesos completos que incluyen cualquier

ubicación y recuperación de datos. No es necesario saber en que computadora se están procesando los datos o de donde proceden los mismos. � Se envían los trabajos mediante un “portal”. � Localiza los recursos necesarios. � Gestiona la identificación y autoriza el uso de los recursos dentro de una Organización Virtual.


Página 6

Simil del GRID Computacional con la Red Eléctrica Red Eléctrica: � Plantas de producción de electricidad. � Distribución jerárquica del flujo eléctrico. � Tendidos eléctricos. � Usuario final: acceso a las prestaciones

de la electricidad.

GRID Computacional: � Grandes centros de almacenamiento de

datos/potencia de cálculo. � Distribución jerárquica. � Red Internet. � Usuario Final: acceso a las prestaciones

informáticas. Tipos de Grids Desde la perspectiva de la aplicación, hay dos tipos de grids: � Grids de cómputo. � Grids de datos. Desde una perspectiva de topología se puede discutir la existencia de tres tipos, incluyendo clusters: � Intra-grids. � Extra-grids. � Inter-grids.

En realidad clusters, intra-grids, extra-grids e inter-grids están mejor definidos como etapas de evolución. En cada una de estas etapas, que veremos más adelante, es posible soportar grids de cómputo, grids de datos, o una combinación de ambos. La mayoría de los primeros desarrollos grid hacían foco en aumentar la capacidad de computo, pero como los grids de datos proveen acceso más fácil a grandes archivos compartidos, los grids de datos están ganando importancia. Un grid de cómputo es esencialmente una colección de recursos computacionales distribuidos que se agregan para formar un único recurso de procesamiento o supercomputadora virtual. Estos recursos de cómputo pueden estar o bien dentro o entre dominios administrativos. Para unificar estos recursos hace falta la utilización de políticas de coordinación, programación y cola de tareas, seguridad y autenticación de usuarios. El beneficio es un procesamiento de trabajos intensivos en cálculo más rápido y eficiente. Las grids de cómputo también eliminan la necesidad de tener máquinas para trabajos específicos permitiendo a la grid atender trabajos secuenciales o paralelos. Un grid de datos provee acceso a datos actualizados en un área amplia. Permite a los usuarios y aplicaciones manejar información de bases de datos desde ubicaciones remotas. Al igual que los grid de cómputo, los grids de datos también dependen de un software para un acceso seguro y políticas de uso. Los grids de datos también pueden ser implementadas dentro de un dominio o entre múltiples dominios, siendo en estos casos cuando el software de grid y administrador de políticas se vuelve crítico. Los grids de datos eliminan la necesidad de mover, replicar, o centralizar datos innecesariamente, traduciéndose esto en un ahorro de costos. Actualmente los grids de datos están siendo construidos primariamente para servir principalmente a comunidades de investigación que trabajan en forma conjunta. Fabricantes de software y grandes empresas están estudiando nuevas implementaciones de grids de datos y servicios para aplicaciones corporativas. Mirando al futuro, los grids de datos serán un elemento clave en el desarrollo de servicios Web. La evolución desde grids de cómputo a grids de datos es un factor importante en el reposicionamiento de las aplicaciones de grids desde educación e I&D hacia grandes empresas. Esta transición es un indicador de que el mercado, junto con la tecnología, están madurando. Desde el punto de vista de redes, el impacto de los grids de datos incluirá una más fuerte integración entre protocolos de almacenamiento y redes de alta performance. Este año continuaremos viendo grids de cómputo como desarrollo primario tanto en empresas como en entornos de I&D. La maduración del middleware para grids de cómputo y datos, en adición a los recientes avances en equipamiento de redes, proveerá lo necesario para evolucionar los grids desde clusters locales hacia sistemas de área amplia.


Página 7

Evolución de la computación en grids Aunque mucha gente se refiera a Internet como “El Grid”, esto no es del todo apropiado, ya que no hay un grid único. En lugar de esto hay muchos grids, algunos públicos, algunos privados, algunos locales en una sola habitación y algunos cubriendo un área amplia. Entender esto es importante para una mejor comprensión de la evolución de los grids. En lo que respecta a recursos de red, estos grids pueden o no emplear recursos públicos de Internet para ampliar su extensión y alcance. Debajo veremos un diagrama que ilustra la evolución de los grids.

La primera etapa es la de los cluster grids, o solo clusters. Como la definición de grid incluye términos como “distribuidos” y “heterogéneos”, la inclusión de los clusters es debatible. Sin embargo los clusters son críticos en la evolución de la computación de grids, de ahí su inclusión en este grupo. Los clusters se definen como sistemas de archivos distribuidos y/o colecciones de servidores homogéneos agregados para obtener una mejor performance. Los clusters son ampliamente usados para aplicaciones como experimentación basada en simulación. La mayoría de los clusters nuevos tienen interfases Gigabit Ethernet y pueden tener desde 4 o 5 servidores hasta varios miles. En estos casos una conmutación de baja latencia es también crítica para mantener la performance de las aplicaciones. Como mencionado arriba, los clusters son críticos en la evolución de la computación de grids. Esto es porque para avanzar a la siguiente etapa, conocida como intra-grids, los clusters necesitan estar interconectados. Mediante la interconexión de clusters independientes se crean grids empresariales e ínter departamentales. La creación de intra-grids agrega requerimientos adicionales a la capa de control de software, o middleware, y a la capa de red subyacente. El middleware, ahora, debe tener un mejor entendimiento de la alocación de recursos por la complejidad adicional introducida por las relaciones de compartición de procesadores. Temas como la latencia cobran mayor importancia a nivel de la capa de red introduciendo la necesidad de líneas troncales de 10-Gigabit Ethernet entre clusters. Dos o más clusters pueden conectarse entre departamentos dentro de la misma empresa para incrementar la capacidad de procesamiento y compartir datos. Pero, porque la relación entre clusters aun se da dentro del dominio de una empresa, temas como seguridad y autenticación, aunque importantes, no son tan críticos como en las siguientes etapas. Esta es la etapa actual en la evolución de la computación de grids. Los extra-grids son, en esencia, clusters o intra-grids que están conectadas entre si entre zonas geográficamente distribuidas o entre distintas empresas. Aquí hay que hacer dos importantes distinciones: distribución geográfica y relaciones ínter empresariales. Debido a esta relaciones, los extra-grids son conocidos como grids de socios. Ahora que el procesamiento y/o los datos pueden ser compartidos entre dos diferentes organizaciones, autenticación, administración de políticas, y seguridad


Página 8

se vuelven requerimientos críticos que debe manejar el middleware. Balanceo de cargas, descubrimiento de la topología, y reconocimiento de aplicaciones también son importantes para asegurar la performance. Al nivel de la capa de red, temas como interfases de largo alcance, soporte LAN/WAN PHY, líneas troncales de alta velocidad, y ruteo se vuelven más importantes debido a la naturaleza distribuida de la topología de la grid. Un ejemplo de extra-grid incluye el outsourcing de investigación de nuevas drogas de empresas relacionadas con la medicina a laboratorios farmacéuticos, creando la necesidad de compartir poder de procesamiento y recursos de bases de datos. La etapa final en la evolución es el inter-grid. Aunque esta es la etapa final, y aun no estamos allí desde el puno de vista comercial, se debe tener en cuenta que los inter-grids hoy existen en el medio de la investigación y desarrollo. Más adelante veremos uno de las más significativos inter-grids, el TeraGrid. Los inter-grids superan ampliamente las otras etapas en complejidad relativa. Por ejemplo, en lugar de dos o tres participantes de un extra-grid, un inter-grid puede servir a cientos o miles de usuarios. Como resultado, todas las complejidades de la capa del middleware se multiplican significativamente. Todo indicaría que las etapas finales de desarrollo tomarían lugar en cinco o diez años desde ahora. Lo más interesante es el potencial de los grids de experimentar un crecimiento orgánico por medio de la evolución de los centros de datos empresariales. Este escenario de crecimiento es más realista considerando que cada empresa puede optimizar costo y eficiencia en lugar de apuntar a resolver problemas de cálculo intensivo que representan un mercado menor. Una vez que las empresas individuales evolucionen sus estructuras esto creará un camino más natural para interconectar sus centros de datos en estructuras tipo grid. Tomará tiempo alcanzar las etapas finales en la evolución de los grids, pero el mercado está creciendo desde ambos extremos del espectro evolutivo. Por un lado los clusters están evolucionando hacia intra-grids en el universo comercial, por el otro grandes inter-grids están siendo desarrollados y testeados con propósitos de investigación.

Arquitectura de un grid Diseñar un grid viable incluye mucho más que agregar poder de procesamiento de máquinas ociosas. Hay múltiples capas, cada una de las cuales juegan un papel fundamental. El diagrama de abajo provee una vista gráfica de las capas que definen la computación en grids y el propósito al que cada capa sirve.

La capa de aplicaciones y software de servicios define la capa más alta en la arquitectura de un grid. Esto incluye portales y herramientas de desarrollo. Las aplicaciones varían con la industria en la que se esté trabajando, al igual que los portales y las herramientas de desarrollo. El software de servicios provee de funciones administrativas incluyendo cálculo de costos, manejo de cuentas y medición de parámetros de uso, todos muy importantes para hacer un seguimiento de cómo se están usando los recursos por los diferentes participantes.


Página 9

La capa middleware provee los protocolos que permiten la participación de múltiples elementos en un medio ambiente unificado. Hay muchas diferentes funciones y protocolos que soporta el middleware que veremos más adelante. La capa de recursos esta compuesta de los recursos que son parte del grid incluyendo servidores primarios y dispositivos de almacenamiento. La capa de red es la interconexión subyacente de los recursos del grid. Arquitecturas multicapa como las grids demandan una fuerte estandarización ya que equipos de diferentes fabricantes serán parte de un sistema distribuido. Hay varias iniciativas de creación de estándares específicos de grids. Abajo hay una lista de las actividades más importantes. � Global Grid Forum (GGF): El GGF es responsable de la promoción y soporte de estandares de

grid. Algunos sponsors del GGF son Hewlett Packard, IBM, Intel, Microsoft, y Sun Microsystems. � Globus: Es un proyecto de I&D enfocado a la creación de herramientas que faciliten el

desarrollo de grids computacionales. Globus facilita la implementación del Globus Tollkit. El proyecto está organizado alrededor de cuatro tareas principales: apliaciones, investigación, herramientas de software, y mesas de prueba.

� Globus Tollkit: Es un software de arquitectura y código abiertos, que permite a los usuarios construir más fácilmente grids computacionales. El tollkit tiene una colección de protocolos y servicios para el desarrollo de grids.

� Open Grid Service Architecture (OGSA): Es una propuesta que evoluciona del actual Globus Toolkit hacia una arquitectura de sistema basada en la integración de conceptos y tecnologías de servicios web y grid.

� Otros: hay otras iniciativas también, algunas de las cuales son, Open Grid Service Infrastructure Working Grup (OGSI-WG), Access Grid, y Condor.

Muchas de estas iniciativas han estado circulando por varios años pero es ahora cuando están empezando a cobrar mayor importancia, cuando las grandes empresas empezaron a testear y desarrollar nuevas redes grid.

El software Globus El desarrollo de Internet fue posible gracias a la existencia de un estándar como el protocolo TCP/IP, y la del WWW al éxito del lenguaje HTML y el protocolo http. La tecnología Grid cuenta con un estándar de facto: Globus. El toolkit Globus (http://www.globus.org), un proyecto “open-source” desarrollado por el equipo del Argonne National Laboratory dirigido por Ian Foster en colaboración con el grupo de Carl Kesselman en la University of Southern California, incorpora los protocolos y servicios básicos necesarios para construir aplicaciones Grid. La arquitectura abierta de Globus se estructura en capas: la capa básica denominada “fabric” controla los recursos locales; por encima de esta,“connectivity” incluye los aspectos de comunicación y seguridad; la capa “resource” el acceso y control de recursos de modo individual, mientras collective se encarga de la coordinación de recursos múltiples, y en particular de servicios distribuidos. Uno de los componentes clave de Globus es el protocolo Grid Security Infraestructure (GSI), que permite una autenticación única del usuario para todos los recursos mediante certificación digital basada en PKI y X.509. La capa “connectivity” incluye además los protocolos habituales de Internet (IP,DNS,etc.); los otros tres protocolos clave corresponden a la de “resource”: Grid Resource Allocation Management (GRAM), Grid Resource Information Protocol (GRIS), y el Grid File Transfer Protocol (GridFTP). El Globus Toolkit es probablemente el conjunto de protocolos y herramientas de grid más ampliamente usado en muchos de los primeros desarrollos de grids. Abajo hay una lista de los principales elementos incluidos en Globus Toolkit.


Página 10

� Administrador de alocación de recursos de Globus (GRAM): procesa requerimientos a recursos y localiza recursos para la ejecución de aplicaciones. También administra los trabajos activos corriendo en el grid y devuelve información actualizada de capacidad al Servicio de Monitoreo y Descubrimiento (MDS).

� Servicio de Monitoreo y Descubrimiento (MDS): es un método basado en LDAP (Protocolo compacto de acceso a directorios) de consultar información del sistema de una variedad de componentes (por ejemplo, capacidad de procesamiento, capacidad de ancho de banda, tipo de almacenamiento). MDS permite la recolección de información específica de cada elemento para su uso en el ambiente del grid. Permite la construcción de un espacio de nombre uniforme para los acceder a información dentro de un sistema que puede involucrar diferentes organizaciones.

� Grid Security Infrastruture (GSI): provee autenticación y comunicación segura dentro del grid. Adicionalmente, da soporte de seguridad sobre fronteras organizacionales y sing-on único para usuarios del grid, incluyendo delegación de credenciales para cómputos que requieran múltiples recursos. GSI está basado en encriptación de llave pública, certificados X.509, y secure sokets layer (SSL), con extensiones para aplicaciones específicas de grids.

� Servicio de Información de Recursos de Grid (GRIS): provee un método uniforme de realizar consultas a recursos en un grid para su configuración, capacidad y estado. Dichos recursos pueden incluir servidores, almacenamiento, y nodos de red, además de bases de datos y links de red.

� Servicio de Indización de Información de Grid (GIIS): provee de los medios de coordinación de servicios GRIS para proveer una imagen del sistema consistente que pueda ser explorada y puedan realizarse búsquedas por aplicaciones grid. Adicionalmente a una imagen de sistema consistente, pueden definirse subsets de servicios GRID, como puede ser todo el almacenamiento dentro de un subgrupo específico del grid.

� GridFTP: es un mecanismo de transferencia de datos, seguro, robusto y de alta performance para entornos de grids. Está basado en el protocolo FTP con extensiones para requerimientos específicos de grids. Características adicionales como control de transferencia de datos por parte de terceros, transferencia de datos en paralelo, y transferencia parcial de archivos está también incluidas.

� Catálogos de Réplicas: provee un mecanismo para el mantenimiento un catalogo de réplicas de datos. Esto lo logra proveyendo un mapeo entre nombre lógicos para archivos y una o más copias de los archivos en los sistemas de almacenamiento físicos.

� Administración de Réplicas: Provee un mecanismo que ata el Catalogo de Replicas junto con tecnologías de GridFTP, permitiendo a las aplicaciones crear y manejar réplicas de grandes cantidades de datos.

Muchos de los protocolos y funciones definidos en Globus Toolkit son análogas a protocolos que existen en redes y almacenamientos hoy, aunque optimizados para desarrollos especificos de grids. Muchas de las funciones realizadas por el middleware de grid, incluyendo temas como seguridad, calidad de servicio, detección y recuperación ante fallas, administración de políticas, programación y cola de tareas, autenticación, descubrimiento de topología, alocación de recursos, y balanceo de cargas, son tareas naturales para los productos y protocolos de red actuales. A medida que los mercados de redes y mercados de procesamiento converjan en un futuro, funciones como estas lo harán también en mejoras en hardware y software optimizadas para desarrollos de grids. Arquitectura del Globus Toolkit

GT3 Data Services

Servicios de Alto Nivel

GT3 Base Services

GT3 Security Services

GT3 Core

Servicios no-GT3 que se basan en la arquitectura GT3.

Gestión de grandes cantidades de datos (Replica Management)

Gestión de Jobs (MMJFS), Servicios de Directorio y Monitorización (Index Service), Transferencia de Ficheros (RFT)

GSI (Grid Security Infrastructure), SSL, WS-Security, SOAP, ...

Grid Services, Factorías, Servicio de Notificaciones, Servicio de Persistencia, Servicio de Ciclo de Vida


Página 11

La composición Globus Toolkit puede ser representada como tres pilares, donde seguridad es la base común de los mismos.

Infraestructura de seguridad de la Grid (Security) El Globus Toolkit usa el GSI para proveer autenticación y comunicación segura sobre una red abierta. GSI provee servicios útiles para Grids, incluyendo autenticación mutua y sing-on único. La motivaciones primarias detrás de GSI son: � La necesidad de una comunicación segura (autenticada y quizás confidencial) entre elementos

de una grid computacional. � La necesidad de soportar seguridad sobre fronteras organizacionales, prohibiendo por lo tanto

un sistema de seguridad administrado centralmente. � La necesidad de soportar sing-on único para usuarios del grid, incluyendo delegación de

credenciales para cómputos que involucren múltiples recursos o sitos. Certificados El concepto central en la autenticación en GSI es el certificado. Cada usuario y servicio en el grid es identificado con un certificado, que contiene información vital para identificar y autenticar el usuario o servicio. Un certificado GSI incluye cuatro piezas de información. � Nombre del sujeto, que identifica la persona u objeto del certificado. � La clave pública que pertenece al sujeto. � La identidad de una Autoridad de Certificación (CA) que ha firmado el certificado para certificar

que ambas la llave pública y la identidad pertenezcan al sujeto. � La firma digital de la mencionada CA.

Nótese que un tercero (una CA) es usado para certificar el link entre la llave publica y el sujeto en el certificado. Para poder confiar en el certificado y su contenido, el certificado de la CA debe ser confiable. El link entre CA y su certificado debe ser establecido mediante algún método no criptográfico, de otra manera el sistema no es digno de confianza. Los certificados GSI son codificados con el formato X.509, un formato estándar para certificados establecido por el Internet Engineering Task Force (IETF). Estos certificados pueden ser compartidos por diferentes softwares basados en llave pública, incluyendo exploradores web comerciales. Autenticación mutua Cuando dos partes tienen certificados, y si ambos confían en las CAs que les asigno sus certificados, entonces ambas partes pueden probar que son quienes dicen ser. Esto es conocido autenticación mutua. El GSI usa SSL para su protocolo de autenticación mutua (SSL se conoce ahora por un nuevo nombre estándar de la IETF: Transport Layer Security o TLS) Antes de que pueda producirse la autenticación mutua, las partes involucradas deben confiar en las CAs que firmaron sus certificados. En la practica, esto significa que deben tener copias de los certificados de las CAs, que contienen las llaves públicas de las CAs, y deben confiar que estos certificados realmente pertenecen a las CAs. Para autentificarse mutuamente, la primera persona (A) establece una comunicación con la segunda persona (B). Cuando empieza el proceso de certificación, A entrega a B su certificado. Este certificado le dice a B quien dice ser A (la identidad), cual es la llave pública de A, y que CA esta siendo usada para


Página 12

certificar la identidad de A. B se asegurará de que el certificado es valido chequeando la firma digital de la CA para asegurarse de que la CA realmente firmó el certificado y que este no ha sido modificado (es aquí cuando B debe confiar en la CA que firmo el certificado de A). Una vez que B chequeó el certificado de A, debe asegurarse de que A es la persona identificada en el certificado. B genera un mensaje aleatorio y lo envía A, pidiéndole que lo encripte. A encripta el mensaje utilizando su llave privada y lo envía de vuelta a B. B desencripta el mensaje de A usando la llave pública de A. Si esto resulta en el mensaje aleatorio original entonces B sabe que A es quien dice ser. Nótese que B confía en la identidad de A, la misma operación debe hacerse al revés. B envía su certificado a A, este valida el certificado y envía el mensaje de desafío a ser encriptado. B encripta el mensaje y lo envía de vuelta a A, este lo desencripta y compara con el original. Si concuerdan entonces A sabe que B es quien dice ser. En este punto, A y B establecen una conexión mutua y tienen certeza de sus respectivas identidades. Comunicación confidencial Por defecto, el GSI no establece una comunicación confidencial entre las partes. Una vez que la autenticación mutua se realiza, el GSI se sale del medio para que la comunicación pueda ocurrir sin la carga de trabajo adicional de tener que encriptar y desencriptar constantemente. El GSI puede ser utilizado para establecer una clave compartida de encriptación si se desea una comunicación confidencial. Una característica adicional de seguridad es la integridad de comunicación. Integridad significa que un eavesdropper podría leer la información entre ambas partes pero no podría modificar la comunicación de ninguna manera. El GSI provee integridad de comunicación por defecto (aunque puede desactivarse si se desea). La integridad de comunicación introduce una carga de trabajo adicional en la comunicación, pero no tan grande como la carga del encriptado. Aseguramiento de llaves privadas El corazón del software GSI provisto con el Globus Toolkit espera que la llave privada del usuario esté almacenada en un archivo local. Para prevenir que otros usuarios de la computadora accedan a la clave privada, el archivo que la contiene esta encriptado con una contraseña. Para usar el GSI el usuario debe ingresar esta contraseña requerida para desencriptar el archivo que contiene la llave privada. También se puede usar tarjetas inteligentes en conjunción con el GSI. Esto permite a los usuarios almacenar su clave privada en una smartcard en lugar de un archivo dificultando aun más el acceso por parte de extraños a la llave. Delegación y Sing-On único El GSI provee la capacidad de delegación: una extensión del protocolo SSL estándar que reduce el número de veces que el usuario debe ingresar su contraseña. Si un computo realizado en la grid requiere que varios recursos sean accedidos (cada uno requiriendo autenticación mutua), o si existe la necesidad de tener agentes (locales o remotos) requiriendo servicio en nombre del usuario, la necesidad de reingresar las contraseñas puede ser evitada mediante la creación de un proxy. Un proxy consiste en un nuevo certificado (con una nueva llave pública en él) y una nueva llave privada. El nuevo certificado contiene la identidad de propietario, modificada ligeramente para indicar que se trata de un proxy. El nuevo certificado es firmado por el propietario en vez de una CA (ver diagrama). El certificado también incluye una notación del tiempo después del cual el proxy no deberá ser aceptado por otros. Los proxies tienen tiempos de vida limitados.

FIRMA FIRMA FIRMA FIRMA

CA User Proxy1 Proxyn

sign sign signs

La llave privada del proxy debe mantenerse segura, pero ya que no será valida por mucho tiempo, el requerimiento de seguridad no es tan estricto como la llave privada del propietario. Es por lo tanto posible almacenar la llave privada del proxy en un almacenamiento local sin estar encriptada, siempre y cuando los permisos del archivo prevengan que cualquiera pueda acceder a ella fácilmente. Una vez que el proxy se creó, el usuario puede usar el certificado y llave privada del proxy para la autenticación mutua sin tener que ingresar la contraseña.


Página 13

Cuando se utilizan proxies, el proceso de autenticación mutua difiere ligeramente. La parte remota recibe el certificado del proxy (firmado por el propietario), pero también el certificado del propietario. Durante la autenticación mutua, la llave pública propietaria (obtenida de su certificado) se usa para validar la firma en el certificado del proxy. La llave pública de la CA se usa entonces para validar la firma en el certificado del propietario. Esto establece una cadena de confianza desde la CA hasta el proxy pasando por el propietario. Nótese que el GSI y el software basado en el (Globus Toolkit, GSI-SSH, y GridFTP) es actualmente el único software que soporta delegación de extensiones a TLS. El proyecto Globus está trabajando activamente para establecer con el Grid Forum y la IETF para establecer proxies como una extensión estándar a TLS de manera que los proxies GSI puedan implementarse en otro software TLS. Servicios de administración de datos (Data Management) El servicio de administración de datos del Globus Toolkit consiste en las siguientes partes: GridFTP Es un protocolo de transferencia de datos, de alta performance, seguro y fiable, optimizado para altos anchos de banda en redes de área amplia. Esta basado en el protocolo FTP, el protocolo de transferencia de archivos más popular en Internet. Características del protocolo: � GSI security en control y canales de datos. � Múltiples canales de datos para transferencias en paralelo. � Transferencia parcial de archivos. � Transferencia de terceros (direct server-to-server). � Canales de datos autenticados. � Canales de datos reutilizables. � Comandos simultáneos.

RFT El servicio de transferencia de archivos fiable (RFT) es un servicio basado en OGSA (Open Grid Services Architecture) que provee interfases para controlar y monitorear transferencia de archivos de terceros usando GridFTP Servers. El cliente que controla la transferencia es hosteado dentro de un servicio grid, es por esto que puede ser administrado usando el Soft State Model y consultado usando las interfases ServiceData disponibles en todos los servicios grid. Es esencialmente una fiel y corregida versión de la herramienta Globus-Url-Copy y otras. Prerrequisitos y dependencias Los prerrequisitos para RTF son: � Distribución final del núcleo. � GridFTP Server con un certificado de host. � PostgreSQL.

PostgreSQL es usado para almacenar el estado de la transferencia, permitiendo reiniciar después de fallas. La interfase para PostgreSQL es JDBC por lo tanto cualquier DBMS que soporte JDBC puede ser utilizado, sin embargo ningún otro ha sido testeado. GridFTP realiza la actual transferencia de archivos. GridFTP server puede ser ejecutado únicamente bajo las plataformas Unix o Linux. RLS El servicio de localización de replicas (RLS) mantiene y provee acceso para mapear información, desde nombres lógicos de ítems de datos a nombres de destino. Estos nombres de destino pueden representar localizaciones físicas de ítems de datos, o una entrada en la RLS que puede mapear a otro nivel de nombres lógicos de ítems de datos. El RLS es diseñado para formar parte de un set de servicios que provee administración de réplicas de datos en grids. Pero el mismo, no brinda garantía de consistencia entre replicas de datos o unicidad de


Página 14

nombres de archivos registrados en el directorio. El RLS es diseñado para ser utilizado en servicios grid de mayor nivel los cuales proveen estas funcionalidades. Servicios de administración de recursos (Resource Management) El Globus Toolkit incluye una serie de servicios componentes colectivamente referidos como el Globus Resource Allocation Manager (GRAM). GRAM simplifica el uso de sistemas remotos proporcionando una interfase simple para solicitar y utilizar recursos de sistemas remotos para la ejecución de “jobs”. El uso más común (y con mejor soporte) de GRAM es job submission y control remoto. Este es típicamente utilizado para dar soporte a aplicaciones computacionales distribuidas. Para la mayoría de proyectos basados en Grid, se recomienda utilizar GRAM como un amplio proyecto estándar para job submission remoto y administración de recursos. GRAM es diseñado para proporcionar un único protocolo común y API, para solicitar y utilizar recursos de sistemas remotos, proporcionando una interfase uniforme y flexible a sistemas locales de programación de trabajos. El Grid Security Infrastructure (GSI) proporciona autenticación mutua a ambos usuarios y recursos remotos, utilizando identidades GSI (Grid-wide) PKI-based. GRAM proporciona un mecanismo de autorización simple basado en identidades GSI y un mecanismo para mapear identidades GSI a cuentas de usuario locales. GRAM reduce el número requerido de mecanismos para utilizar recursos remotos (tales como sistemas remotos de computadoras). Los sistemas locales pueden utilizar una amplia variedad de mecanismos de administración (programadores, sistemas de colas de tareas, sistemas de reserva, control de interfases), pero los usuarios y diseñadores de aplicaciones necesitan aprender a utilizar únicamente uno “GRAM”, para solicitar y utilizar estos recursos. Esta capacidad es coherente con la representación de “reloj de arena” de la mayoría de los componentes de Globus Toolkit: GRAM es el cuello del reloj, con aplicaciones y servicios de mayor nivel (tales como brokers de recursos o metaschedulers) por encima y, controles locales y mecanismos de acceso debajo el, como puede observarse en la figura siguiente.

Ambos lados necesitan trabajar únicamente con GRAM, debido a esto, el número de interacciones, API’s y protocolos que necesitan ser utilizados es muy reducido. Se espera que GRAM continúe evolucionando rápidamente dentro del ambiente OGSI (GT3 GRAM), mientras que su protocolo es estandarizado y, son agregadas mejores descripciones de trabajo y capacidad de provisión de recursos. GRAM no proporciona capacidades de programación o brokering de recursos. Han sido diseñados por otros proyectos para el GT2 GRAM una amplia variedad de metaschedulers y brokers de recursos que utilizan los mecanismos GRAM. Debido a su reciente versión de Junio/Julio, GT3 GRAM puede no haber sido integrado todavía dentro de los varios metaschedulers y brokers de recursos. Sin embargo, se espera que estas aplicaciones sean actualizadas para utilizar GT3. GRAM no proporciona características de accounting y billing, se asume que si estas características son necesarias, serán suministradas por mecanismos de administración tales como sistemas de colas o programación. Implementaciones soportadas. � GT2 GRAM � GT3 GRAM

El Globus Resource Allocation Manager (GRAM) es el nivel más bajo de Globus Resource Management Architecture (GRMA). GRAM permite ejecutar jobs remotamente, utilizando un set de interfases de


Página 15

cliente WSDL/OGSI para submitting, monitoreo, y finalización de un trabajo. Las solicitudes de trabajos son escritas por el usuario en el Resource Specification Language (RSL) y procesadas por el Manager Job Service como una parte de la solicitud del trabajo. Servicios de Información (Information Services) El componente de Servicios de Información de Globus Toolkit 3 (GT3) proporciona información acerca de los recursos del grid para ser utilizados en el descubrimiento, selección y optimización de recursos. Esta información es crítica para la operación del grid y la construcción de aplicaciones. En el Open Grid Service Architecture (OGSA) en el que esta basado GT3, todo está representado como un servicio de grid. Estos servicios pueden ser un set estático de servicios persistentes o bien servicios transitorios. Cada servicio expresa su estado en una forma estandarizada como Elementos de Datos de Servicios (Service Data Elements o SDEs). Los servicios de información proveen la funcionalidad dentro de la cual los Datos de Servicios (Service Data) pueden ser coleccionados, agregados, y consultados, se puede monitorear el ingreso de datos, y Datos de Servicios pueden ser creados dinámicamente bajo demanda. El componente de Servicios de Información es por lo tanto un amplio marco que incluye cualquier parte del GT3 que, de alguna manera, genere, registre, genere índices, agregue, suscriba, monitoree, consulte, o muestre Datos de Servicios. El Servicio de Indización En el contexto de Globus Toolkit, los servicios de información tienen los siguientes requerimientos: � Una base para configuración y adaptación en entornos heterogéneos. � Acceso flexible y uniforme a información tanto estática como dinámica. � Acceso eficiente y escalable a datos. � Acceso a múltiples fuentes de información. � Mantenimiento descentralizado.

Como parte de esta infraestructura de información, el Index Service usa un marco extensible para administrar datos estáticos y dinámicos dentro de grids construidos utilizando Globus Toolkit. La funcionalidad provista incluye: � Servicio de creación y administración dinámica de datos mediante programas proveedores de

datos de servicios. � Agregación de datos de servicios de múltiples instancias. � Registro de instancias de servicios de la grid.

El Globus Toolkit está basado en mecanismos Open Grid Service Architecture (OGSA). OGSA integra computación en grids con servicios Web utilizando el lenguaje de descripción de servicios Web (Web Services Descriptios Services o WSDL). Dentro de OGSA, todo se representa como un servicio grid: un servicio Web que provee un set de interfases bien definidas y que siguen convenciones específicas. Estos servicios grid no son solo un set de servicios estáticos persistentes, también pueden ser instancias de servicio transeúntes, como puede ser una consulta a una base de datos, una operación de data mining, una alocación del ancho de banda de una red, una transferencia de datos, o una reserva anticipada de capacidad de procesamiento. Puede haber más de una instancia de un servicio grid en particular. Usos y beneficios del Index Service Cada instancia de un servicio de grid tiene un set de datos asociados a él, y estos datos están representados de una forma estandarizada. Hay también una operación estándar para recuperar estos datos de servicio de una instancia particular de un servicio grid, así como también interfases estándar para registrar información acerca de instancias de servicios grid. El descubrimiento a menudo requiere información de instancias específicas, quizás dinámicas. Los datos de servicios ofrecen una solución en la cual todos los servicios deben soportar algún conjunto de datos de servicios comunes y puede soportar cualquier otro tipo de dato de servicios deseado. El Index service no genera tipos de datos específicos. Los tipos de datos disponibles desde el Index Service para consultas, en cambio, depende de cómo está configurado el servicio; esto es, que tipo de programa proveedor de datos de servicios use para agregar los datos.


Página 16

El Index Service provee las siguientes capacidades clave: � Una interfase para conectar programas proveedores de datos de servicios con instancias de

servicios. El Index Service provee un mecanismo estándar para la generación datos de servicios vía programas externos. Estos programas proveedores externos pueden ser programas núcleo que son parte de GT3 o proveedores creados por el usuario.

� Un marco genérico para agregación de datos de servicios. Datos de servicios provenientes de varios programas proveedores pueden ser agregados de maneras diferentes e indizados para proporcionar un procesamiento eficiente de consultas.

� Un registro de servicios grid. Un set de servicios grid es mantenido en un registro. Un registro permite la registración soft-state de servicios grid, en el cual un set de servicios puede ser registrado y periódicamente actualizado según se requiera. Un registro puede ser usado para dar soporte a consultas u otras operaciones a un determinado servicio.

Modelo de Información de Index Service Como mencionamos arriba, cada instancia de un servicio grid tiene un set particular de datos de servicio asociado. La esencia del Index Service es la de proveer una interfase para operaciones de acceso, agregación, generación, y consulta a esos datos. El modelo OGSA comprende servicios persistentes (unos pocos) y servicios transeúntes (potencialmente muchos). Todos los servicios se adhieren a comportamientos e interfases de servicios grid específicos. Las interfases corresponden a WSDL portTypes y son usadas para administrar las instancias de los servicios grid. El GridService portType es utilizado para realizar consultas y, actualizar los datos de servicio y controlar el tiempo de vida de una instancia. Las interfases y funciones más importantes del Index Service pueden resumirse como sigue: � Factory: Utilizada para crear una nueva instancia del servicio grid mediante su operación

CreateService. Una factoría devuelve un Grid Service Handle (GSH), que se describe abajo, y mantiene un set de Elementos de Datos de Servicios que pueden ser consultados.

� Grid Service Handle (GSH): es el resultado de la operación Factory. Un GSH es una URL usada para nombrar un instancia de grid de manera global. Un GSH debe ser convertido en una Referencia a Servicio Grid (Grid Service Reference) para poder usar el servicio.

� Grid Service Reference (GSR): describe como un cliente se puede comunicar con una instancia de un servicio grid. La interfase HandleMap permite al cliente mapear desde una GSH a un GSR. Mientras el GSH representa solo nombres, el GSR incluye información de enlace para los protocolos de transporte y formatos de codificación de datos.

� Query: provee un lenguaje extensible par realizar consultas. Una instancia de un servicio grid mantiene un set de Elementos de Datos de Servicio, y la operación FindServiceData de la interfase GridService es la usada para consultar esta información. Esta es una operación de consulta, estándar y extensible, a Elementos de Datos de Servicios.

� Registry: soporta el descubrimiento devolviendo los GSH de un set de servicios grid. Un registro permite la registración soft-state de servicios grid, en el un set de servicios grid puede registrar periódicamente sus GSH en un Servicio de Registro para permitir el descubrimiento de servicios en ese set.

� Notificación: la interfase NotificationSource es usada para la suscripción de clientes para registrar su interés en un servicio. Manda mensajes de notificación acerca de los temas registrados. Estos temas pueden ser likeados a valores arbitrarios generados por un servicio en tiempo de ejecución o linkeados a Elementos de Datos de Servicios. La interfase NotificationSink es usada para el envío asíncrono de mensajes de notificación; se puede aplicar para el descubrimiento y registración dinámicos de servicios, monitoreo, notificación de errores de aplicaciones, etc.

Resumiendo, un servicio de grid es creado por la interfase Factory, que devuelve un GSH que identifica al servicio. El GSH se convierte en un GSR (que incluye información de enlace) para que el servicio pueda ser usado. Las instancias pueden ser identificadas en un registro, que puede ser usado para soportar consultas o otras operaciones en un determinado servicio. Consultas (Queries) El descubrimiento de datos a menudo requiere información, a veces dinámica, de instancias específicas. Hasta ahora hemos visto que cada instancia de un servicio grid tiene un set de datos de servicio asociado. Estos datos de servicios ofrecen una solución general para el descubrimiento, en el cual cada


Página 17

servicio debe soportar algún tipo de dato de servicio común y puede soportar algún tipo adicional de dato de servicio deseado. Una función primaria del Index Service es la de proveer una interfase para consultar datos de servicios agregados recolectados de otros servicios. La operación FindServiceData de la interfase GridService se usa para consultar esta información. La interfase NotificationSource es usada para la suscripción de clientes para registrar su interés en un servicio. Manda mensajes de notificación acerca de los temas registrados. Estos temas pueden ser likeados a valores arbitrarios generados por un servicio en tiempo de ejecución o linkeados a Elementos de Datos de Servicios. La interfase NotificationSink es usada para el envío asíncrono de mensajes de notificación; se puede aplicar para el descubrimiento y registración dinámicos de servicios, monitoreo, notificación de errores de aplicaciones, etc. Ambas suscripción y FindServiceData son formas de consultar datos de servicios de una instancia. FindServiceData es una consulta simple sincrónica (pull), mientras que la notificación de suscripción es una consulta persistente, con respuesta asincrónica (push). La interfase de registro soporta el descubrimiento soporta el descubrimiento devolviendo los GSH de un set de servicios grid. Un registro permite la registración soft-state de servicios grid, en el un set de servicios grid puede registrar periódicamente sus GSH en un Servicio de Registro para permitir el descubrimiento de servicios en ese set. Interfase de usuario En GT3 hay dos formas en las cuales uno puede acceder a los datos de servicios agregados por el Index Service: el GT3 Service Data Browser y el comando ogsi-find-service-data. � GT3 Data Browser: es una GUI que da servicio dentro de GT3. El browser nos permite ver el

detalle de los servicios grid disponibles desde el registro configurado por nuestro administrador. Los datos de servicios pueden ser vistos en varios formatos, dependiendo de los requerimientos.

� Comando ogsi-find-service-data: este comando provee una interfase de línea de comandos para consultar los datos de servicios disponibles desde el Index Service o cualquier servicio grid. Este comando permite realizar estos tipos de consultas: � Mediante la especificación los nombres de un servico grid y de uno o más elementos de

datos de servicio. � Especificando una expresión XPath en adicion con lo anterior. Se puede especificar la

salida de este comando con un formato Raw XML o easy-to-read.


Página 18

Proyectos Grid más importantes

Nombre URL & Sponsors Enfoque

Access Grid www.mcs.anl.gov/FL/accessgrid DOE, NSF

Create & deploy group collaboration systems using commodity technologies

BlueGrid IBM Grid testbed linking IBM laboratorios

DISCOM www.cs.sandia.gov/discom DOE Defense Programs

Create operational Grid providing access to resources at three U.S. DOE weapons laboratorios

DOE Science Grid http://sciencegrid.org DOE Office of Science

Create operational Grid providing access to resources & applications at U.S. DOE science laboratories & partner universities

Earth System Grid (ESG) http://earthsystemgrid.org DOE Office of Science

Delivery and analysis of large climate model datasets for the climate research community European Union (EU)

DataGrid http://eu-datagrid.org European Union

Create & apply an operational grid for applications in high energy physics, environmental science, bioinformatics

EuroGrid Grid Interoperability (GRIP)

http://eurogrid.org European Union

Create tech for remote access to supercomp resources & simulation codes; in GRIP, integrate with Globus Toolkit™

Fusion Collaboratory http://fusiongrid.org DOE Off. Science

Create a national computational collaboratory for fusion research

Globus Project™ http://globus.org DARPA, DOE, NSF, NASA, Microsoft

Research on Grid technologies; development and support of Globus Toolkit™; application and deployment

GridLab http://gridlab.org European Union Grid technologies and applications

GridPP http://gridpp.ac.uk U.K. eScience

Create & apply an operational grid within the U.K. for particle physics research

Grid Research Integration Dev. & Support Center

http://grids-center.org NSF

Integration, deployment, support of the NSF Middleware Infrastructure for research & education

Grid Application Dev. Software

http://hipersoft.rice.edu/grads NSF

Research into program development technologies for Grid applications

Grid Physics Network http://griphyn.org NSF

Technology R&D for data analysis in physics expts: ATLAS, CMS, LIGO, SDSS

Information Power Gris http://ipg.nasa.gov NASA

Create and apply a production Grid for aerosciences and other NASA missions

International Virtual Data Grid Laboratory

http://ivdgl.org NSF

Create international Data Grid to enable large-scale experimentation on Grid technologies & applications

Network for Earthquake Eng. Simulation Grid

http://neesgrid.org NSF

Create and apply a production Grid for earthquake engineering

Particle Physics Data Grid

http://ppdg.net DOE Science

Create and apply production Grids for data analysis in high energy and nuclear physics experiments

TeraGrid http://teragrid.org NSF

U.S. science infrastructure linking four major resource sites at 40 Gb/s

UK Grid Support Center http://grid-support.ac.uk U.K. eScience

Support center for Grid projects within the U.K.

Unicote BMBFT Technologies for remote access to supercomputers


Página 19

Proyectos grid en USA El desarrollo de los proyectos Grid en USA es muy amplio: entre los científicos cabe citar PDG y GriPhyN (Física de Particulas), DOE ScienceGrid, Earth System Grid (meteorología), Fusion Collaboratory (fusión nuclear), NEESGRID (simulación para el estudio de los terremotos) así como un centro de soporte Grid del NSF. El International Virtual Data Grid Laboratory (iVDGL – http://www.ivdgl.org) y el proyecto TeraGrid (www.teragrid.org), que unirá cuatro centros USA de supercomputación a 40 Gbps, son dos de los más relevantes.


Página 20

Proyectos grid europeos En el año 2000 el programa comunitario IST lanza el proyecto European DataGrid (EDG - http://www.eu-datagrid.org) coordinado por el CERN, con el objetivo de construir la próxima generación de infraestructura de computación que permita cálculo intensivo y análisis de bases de datos compartidas a gran escala, desde cientos de Terabytes a Petabytes, entre comunidades científicas ampliamente distribuidas”. El proyecto utiliza Globus como software básico, y desarrolla nuevo “middleware” para construir aplicaciones que manejan un gran volumen de datos, como las citadas de Física de Partículas (CERN, LHC), de Bioinformática, y de la ESA (Observación de la Tierra). Con un importe de 10 millones, el proyecto cuenta como socios principales con entidades de investigación nacionales con instalaciones significativas de cálculo, como el INFN (Italia), PPARC (UK), CNRS (Francia) o NIKHEF (Holanda). Su interconexión está basada en la nueva red Gigabit europea Géant (http://www.dante.net/geant), en funcionamiento desde finales del año 2001. Uno de los objetivos básicos del proyecto es el desarrollo de un testbed distribuido por toda Europa, en el que España participa a través de los grupos de Física de Altas Energías: IFAE (Barcelona), IFIC (Valencia), IFCA (Santander) y Universidad de Oviedo, UAM y CIEMAT (Madrid). En paralelo, el programa IST aprueba dos proyectos orientados a la industria: DAMIEN Distributed Applications and Middleware for Industrial Use of European Networks (http://www.hlrs.de/organization/pds/projects/damien), en el que participa el CEPBA (Barcelona), y EUROGRID (http://www.eurogrid.org), basado en el sistema UNICORE. En el año 2001 se lanzan varios proyectos IST en el área científica, como GridLab, EGSO, DataTag y CrossGrid. Este último (http://www.eu-crossgrid.org, http://grid.ifca.unican.es/crossgrid), cuyo objetivo es el desarrollo de aplicaciones interactivas en el entorno Grid, y la extensión del testbed del proyecto DataGrid, cuenta con una notable participación española. El CSIC (IFCA, IFIC y RedIRIS) es uno de los socios principales, responsable del apartado de testbed en el que participan la UAB (Barcelona) y la USC (Santiago) en colaboración con el CESGA. La siguiente figura muestra el testbed del proyecto CrossGrid, incluyendo la infraestructura de red básica de Géant.

http://mapcenter.lip.pt


Página 21

El IFCA es también responsable de la aplicación interactiva de Física de Partículas; la USC y la Universidad de Cantabria participan en el bloque de aplicaciones meteorológicas, y la UAB (Barcelona) desarrolla el software que permita la asignación de recursos distribuidos para aplicaciones interactivas. El proyecto propone además desarrollar para el entorno Grid aplicaciones como el análisis de imágenes y simulación para operaciones de cirugía vascular en medicina, o el control de inundaciones. Uno de los puntos clave del proyecto es el acceso a bases de datos distribuidas, y el desarrollo de técnicas de data-mining como redes neuronales, que requieren técnicas de computación distribuidas, sobre protocolos adaptables al entorno Grid como el citado MPI. Cada centro incluye una configuración mínima, necesaria para permitir la ejecución de aplicaciones en el entorno Grid. La configuración actual, definida por el proyecto DataGrid, está basada en PC’s con sistema operativo Linux. En el testbed de producción los centros pueden aportar los recursos disponibles incrementando el número de Computing y Storage Elements. Este es el caso por ejemplo, de dos centros del CSIC, IFCA e IFIC, que cuentan con “fábricas” de más de un centenar de procesadores: “Santander Grid Wall” (SGW), y “Granja orientada a Grid” (GoG).

Coordinación, estándares internacionales, relación con la industria y OGSA El Global Grid Forum (GGF - http://www.globalgridforum.org) es el foro internacional sobre tecnología Grid. Reunido por primera vez en Ámsterdam en marzo de 2001, gracias al esfuerzo de Ian Foster y de Fabrizio Gagliardi (manager de DataGrid) a ambos lados del Atlántico, realiza una reunión semestral para coordinar los esfuerzos y posibilitar la estandarización. El interés de las compañías comerciales por la tecnología Grid ha ido creciendo, al igual que su presencia como patrocinadores en el GGF: Sun, HP/Compaq, Microsoft, SGI e IBM. La posible convergencia entre la tecnología de Web Services en el campo de e-Business, y la próxima versión de Globus denominada OGSA (Open Grid Services Architecture - http://www.globus.org/ogsa), ha contado con una fuerte participación de IBM que ha apostado por la tecnología Grid. El Globus Toolkit 3 (GT3) esperado a finales de 2002, apuesta por servicios Grid basados en Web Services potencialmente transitorios, con interfases y comportamientos bien definidos que incluyen creación, asignación de nombres y referenciado, autorización, notificación, tiempo de vida, etc. Esta evolución representa una gran oportunidad para lograr una amplia aceptación y difusión de la tecnología Grid, que puede extenderse, al igual que lo hizo el WWW, desde su ámbito original en el área de la computación científica, al de las aplicaciones comerciales.


Página 22

El futuro inmediato: iniciativas y proyectos en marcha Las pasadas reuniones de los Grupos de Trabajo de RedIRIS (http://www.rediris.es/gt/gt2002) incluyeron una revisión de las iniciativas Grid en la red académica española. La participación en la fase inicial del testbed del proyecto europeo DataGrid ha motivado la creación de grupos con experiencia en tecnología Grid en Barcelona, Valencia, Santander, Madrid y Santiago. De ellos han salido iniciativas como la participación en el proyecto CrossGrid, y las primeras “fábricas” Grid en Valencia (GoG, IFIC) y Santander (SGW, IFCA). El apoyo del programa nacional de Física de Altas Energías ha sido fundamental, y actualmente se cuenta con un proyecto nacional trianual (LCG-ES) paralelo al proyecto LCG (LHC Computing Grid) del propio CERN. Así mismo el programa nacional de TIC ha contemplado en su última convocatoria explícitamente el tema de DataGrids. En Europa destaca la iniciativa de e-Science en el Reino Unido (http://www.research-councils.ac.uk/escience). Este programa multidisciplinar, con una dotación de más de 200M , incluye la creación de un centro nacional de e-Science (NeSC, en Edimburgo) así como varios centros regionales, y apuesta por áreas de interés comercial como las bases de datos distribuidas en colaboración con empresas como Oracle o IBM. Por su parte el VI Programa Marco comunitario incluye un epígrafe específicamente destinado a la resolución de problemas científicos complejos, mediante tecnologías Grid. Entre las Expresiones de Interés (EoI) para dicho programa, la propuesta de un proyecto integrado denominado EGEE (Enabling Grids for e-Science and Industry in Europe) coordinada por el CERN ha contado con el respaldo de gran número de instituciones, incluyendo en nuestro país varios centros del CSIC, Universidades (UAB, UAM, UCM, USC, UC, UM) y centros de investigación (IFAE, CIEMAT, o CESGA). Este proyecto podría posibilitar una infraestructura común europea sobre la evolución de la red Géant, y a su vez proporcionaría el marco para las redes de excelencia o proyectos orientados a las diferentes aplicaciones en e-Ciencia. La organización de la participación española, incluyendo el planteamiento de un sistema de centros de e-Ciencia es una de las actividades en marcha. CERN (European Organization of Nuclear Research) – LHC (Large Hadron Collinder) Esquema del proyecto

Tier2 Centre ~1 TIPS

Online System

Offline Processor Farm

~20 TIPS

CERN Computer Centre

FermiLab ~4 TIPSFrance Regional Centre

Italy Regional Centre

Germany Regional Centre

InstituteInstituteInstituteInstitute ~0.25TIPS

Physicist workstations

~100 MBytes/sec

~100 MBytes/sec

~622 Mbits/sec

~1 MBytes/sec

There is a “bunch crossing” every 25 nsecs.There are 100 “triggers” per secondEach triggered event is ~1 MByte in size

Physicists work on analysis “channels”.Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server

Physics data cache

~PBytes/sec

~622 Mbits/sec or Air Freight (deprecated)




Caltech ~1 TIPS

~622 Mbits/sec

Tier 0Tier 0

Tier 1Tier 1

Tier 2Tier 2

Tier 4Tier 4

1 TIPS is approximately 25,000 SpecInt95 equivalents



Online SystemOnline System

Offline Processor Farm

~20 TIPS

CERN Computer Centre

FermiLab ~4 TIPSFrance Regional Centre

Italy Regional Centre

Germany Regional Centre

InstituteInstituteInstituteInstitute ~0.25TIPS

Physicist workstations

~100 MBytes/sec

~100 MBytes/sec

~622 Mbits/sec

~1 MBytes/sec

There is a “bunch crossing” every 25 nsecs.There are 100 “triggers” per secondEach triggered event is ~1 MByte in size



Physics data cache

~PBytes/sec

~622 Mbits/sec or Air Freight (deprecated)







Caltech ~1 TIPSCaltech ~1 TIPS

~622 Mbits/sec

Tier 0Tier 0

Tier 1Tier 1

Tier 2Tier 2

Tier 4Tier 4

1 TIPS is approximately 25,000 SpecInt95 equivalents1 TIPS is approximately 25,000 SpecInt95 equivalents

Sistemas distribuidos Tecnología de Gridssistema operativo de una computadora o servidor. El...

Documents

Transcript of Sistemas distribuidos Tecnología de Gridssistema operativo de una computadora o servidor. El...