A. Instalación inicial de Globus Toolkit LISiDi 118

Transcripción

1 Proyecto Final Grid, Globus Toolkit y potencia computacional sin límites Ingeniería en Sistemas de Computación Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Miriam Lechner 31 de octubre de 2006

2 Índice general 1. Introducción a la computación Grid Introducción El surgimiento de las Organizaciones Virtuales Globus Toolkit 4 - GT La naturaleza de la arquitectura Grid Descripción de la arquitectura Grid Fabric: interfases para el control local Connectivity: comunicaciones simples y seguras Resource: Compartiendo recursos individuales Collective: Coordinando múltiples recursos Aplicaciones La necesidad de protocolos comunes Componentes de software Componentes de administración Administración Grid distribuida Software donado Submission software Planificadores Comunicaciones Observaciones y medidas Grid y otras tecnologías World Wide Web Proveedores de servicio de almacenamiento y aplicaciones Sistemas de computación empresariales Internet computing and peer-to-peer computing Beneficios de la computación grid Explotar recursos subutilizados Capacidad de CPUs paralelos Recursos virtuales y organizaciones virtuales para la colaboración Acceso a recursos adicionales Balance de recursos Confiabilidad Administración Beneficios empresariales

3 2.9. Sumario Web services resource framework Administración del estado de los recursos utilizando Grid services Qué es un servicio Grid Servicios Grid vs. servicios web Requerimientos de los servicio Grid-OGSA Open Grid Services Interface (OGSI) Grid Services Reestructuración de OGSI a WSRF Fundamentos de WSRF Qué es un WS-Resource? Implied Resource Pattern Especificaciones WS-Resource Framework WS-ResourceLifetime WS-ResourceProperties WS-RenewableReferences WS-ServiceGroup WS-BaseFaults WS-Notification WS-Resource Framework y Globus Toolkit Seguridad en Grid Introducción Requerimientos de la seguridad grid Globus Toolkit Certificados X Protocolo SSL y TLS Fundamentos de seguridad Términos importantes en la seguridad grid Infraestructura de seguridad grid - GSI Consiguiendo acceso al grid Comunicaciónes grid seguras Consideraciones adicionales de seguridad Seguridad física Seguridad del sistema operativo Otros sistemas complementarios Políticas y procedimiento de seguridad PKI Autoridad certificante Algunos cuestionamientos a Globus/GSI Propuesta ASCI Algunas conclusiones

4 5. Gestión de Datos en un entorno Grid GridFTP Experiencia con GridFTP en el LISiDi Reliable File Transfer (RFT) Problemas comunes y sus soluciones Testeo del RFT en el LISiDi Replica Location Service (RLS) Un ejemplo usando RLS Componentes del Replica Location Service Opciones de Configuración RLS y los servicios de Consistencia de Réplicas OGSA-DAI Data Replication Service (DRS) Administración de ejecución Introducción GRAM Tipos de trabajos Componentes de la arquitectura Seguridad Administración de trabajos Administración de datos Coordinación de tareas WS GRAM Aproximación a los componentes de la arquitectura Pasos principales del protocolo Componentes de Globus Toolkit utilizados por WS GRAM Componentes externos utilizados por WS GRAM Componentes internos utilizados por WS GRAM Seguridad Experiencia en el laboratorio LISiDi Configurando WS GRAM Visión del usuario de WS GRAM Monitoring and Discovery System (MDS) Introducción Detalles de MDS Estándares de Web Services usados por MDS Servicios MDS Aggregator Framework Proveedores de Información Interfaz de usuario WebMDS MDS A. Instalación inicial de Globus Toolkit LISiDi 118 3

5 B. Terminos 123 4

6 Capítulo 1 Introducción a la computación Grid La contínua evolución de las redes de area local y de Internet llevan a la comunidad a pensar en nuevas alternativas para aprovechar en forma óptima esta evolución y el potencial inherente a estas configuraciones. Luego, se han planteado diferentes tecnologías como la world wide web y las aplicaciones peer-to-peer a nivel de Internet, o las aplicaciones distribuidas construidas en base a tecnologías como MPI y PVM a nivel de LANs. Estos son solo algunos ejemplos de todas las soluciones que se han planteado al problema de optimizar el uso de los sistemas distribuidos. Todos estos enfoques plantean soluciones parciales al problema de compartir y optimizar el uso de recursos distribuidos, en tal sentido la computación Grid establece un modo general de hacerlo. La tecnología Grid acerca al usuario un conjunto de recursos de tal manera que este no está plenamente consciente de el origen de esos recursos (ya sea almacenamiento, cómputo o servicios). Del mismo modo en que el sistema de suministro eléctrico proporciona energía a los usuarios conectados a la red eléctrica, el Grid computacional proporciona a los usuarios que se conectan a él, el acceso consistente a recursos computacionales que se encuentran geográficamente separados, presentándolos al usuario como un solo recurso unificado. Grid se basa en la naturaleza distribuida de los sistemas de hoy en día y en la virtualización de objetos como medio para facilitar el acceso a los mismos haciendo que este sea independiente de las características de operación específicas. El nivel de virtualización puede variar, dando distintos grados de uso de tecnología Grid. Si focalizamos la atención en soluciones de cómputo distribuido, entonces podemos considerar como definición de cómputo Grid, el cómputo a través de recursos virtualizados en donde el objetivo es crear la ilusión de una simple pero potente computadora virtual en base a una colección de sistemas que comparten varias combinaciones de recursos. En un principio se desarrollaron implementaciones de Grid intra-organizacionales, en la actualidad el Grid inter-organizacional es la principal atracción de esta nueva tecnología, fomentando entre otras cosas el trabajo cooperativo entre distintas organizaciones. Un concepto de gran relevancia es justamente el de Organizaciones Virtuales 5

7 VOs), que identifica a un conjunto de individuos y/o instituciones que definen las reglas bajo las cuales se compartirán los recursos del Grid. El uso de estándares abiertos será la piedra angular en la construcción de una tecnología Grid que permita la interoperatividad de los sistemas que forman parte del Grid y el acceso transparente a los recursos para los usuarios conectados a él Introducción El problema real y específico que subyace al concepto de Grid es coordinar los recursos compartidos y resolver el problema en Organizaciones Virtuales (VO) dinámicas y multi-institucionales. Las Organizaciones Virtuales pueden variar ampliamente en su propósito, alcance, tamaño, duración, estructura y comunidad. Aún así es posible identificar un conjunto amplio de intereses y requerimientos comúnes. Algunos de ellos son la necesidad de relaciones para compartir recursos, altamente flexibles; niveles de control precisos y sofisticados sobre cómo serán usados los recursos compartidos; compartir una gran variedad de recursos y en distintos modos de uso (usuario simple/multi-usuario, costsensitive/performance-sensitive, etc.). Las tecnologías de cómputo distribuido actuales no abarcan todos estos aspectos en forma conjunta. Las tecnologías disponibles sobre Internet no proveen un enfoque integrado para coordinar el uso de múltiples recursos. Las tecnologías utilizadas para cómputo distribuido como CORBA o Enterprise Java, permiten compartir recursos solo dentro de una organización. DCE (Distributed Computing Environment) soporta recursos compartidos entre sitios pero, para la mayoría de las Organizaciones Virtuales es una alternativa demasiado compleja y poco flexible. Los proveedores de almacenamiento (SSP) o aplicaciones (ASP) permiten a las instituciones tercerizar sus requerimientos de almacenamiento y cómputo, pero de manera muy restringida. En resúmen, las tecnologías actuales no se ajustan a las necesidades comunes de la mayoría de las Organizaciones Virtuales. Aquí es donde la tecnología Grid entra en escena. La comunidad Grid ha desarrollado protocolos, servicios y herramientas que precisamente apuntan a los desafíos que surgen al buscar construir VOs escalables. Lejos de reemplazar las tecnologías de cómputo distribuido existentes, Grid las complementa, enfocándose principalmente en la necesidad de compartir recursos en forma dinámica y a través de las organizaciones. Así por ejemplo, los sistemas empresariales para computación distribuida pueden beneficiarse de la tecnología Grid para lograr compartir recursos más allá de los límites institucionales; en el espacio ASP y SSP se abre la posibilidad de entablar contrataciones dinámicas, más flexibles, evitando la necesidad de configuraciones estáticas y la complejidad que las mismas conllevan El surgimiento de las Organizaciones Virtuales Ejemplo de posibles Organizaciones Virtuales formadas por varias organizaciones. 6

8 Figura 1.1: Ejemplo VOs En la Figura 1.1 se ven tres organizaciones (los óvalos), y dos VOs (P y Q). El compartir recursos es condicional, cada propietario de un recurso establece qué, cuándo y dónde puede hacerse con dicho recurso. Además, cada consumidor puede imponer restricciones al tipo de recursos con el que se encuentra preparado para trabajar. La implementación de tales restricciones requiere mecanismos para expresar políticas y para identificacón, autenticación y autorización de usuarios y recursos. Las relaciones no necesariamente involucran un conjunto de individuos nombrados individualmente, en su lugar pueden estar definidas por políticas (por ejemplo, cualquiera que pueda demostrar ser comerciante).[fkt] La naturaleza dinámica de las relaciones que se establecen para compartir recursos, implica la necesidad de contar con medios para descubrir y caracterizar la naturaleza de las relaciones que existen en un dado punto del tiempo. De esta forma un nuevo participante que pretende unirse a una VO puede determinar las características de la misma. Las relaciones para compartir recursos no solo son de tipo cliente-servidor, sino que también pueden ser peer-to-peer 1. Dado el hecho de que estas relaciones pueden expandirse de manera de coordinar y utilizar recursos en múltiples organizaciones, la habilidad para delegar autoridad en forma controlada se convierte en una característica importante. vez. 1 Modelo en el que cada nodo participante de la red peer-to-peer, puede ser cliente y servidor a la 7

9 El concepto de Organización Virtual es fundamental en el planteo Grid. Las VOs disparan la creación de grupos de organizaciones y/o individuos que comparten recursos en una manera controlada, de tal forma que sus miembros puedan colaborar para alcanzar el objetivo compartido.[fkt] 1.3. Globus Toolkit 4 - GT4 Antes de pasar a desarrollar en qué consiste una arquitectura Grid en forma genérica haremos una breve referencia a Globus Toolkit (en particular se verá su versión cuatro - GT4) que es una implementación particular de una arquitectura Grid. Posteriormente en este capítulo se ejemplificaran características generales en base a esta implementación y, en capítulos subsiguientes se ahondara específicamente en los detalles de los componentes de Globus. Globus Toolkit es el producto emblemático de Globus Alliance, la cual produce middleware open source usado en la construcción de Grids alrededor del mundo. Provee las librerías y componentes que permiten el desarrollo de aplicaciones Grid orientadas a servicios. Los componentes del núcleo de globus abarcan las características básicas relacionadas a la seguridad, acceso y administración de recursos, movimiento y administraicón de datos, descubrimiento de recursos, y otros mas, ver Figura 1.2 a continuación.[fos] Globus Toolkit es una implementación particular de un sistema Grid. La estructura subyacente en este middleware es la de suma de servicios. Esto es, el middleware se compone de múltiples servicios, que implementan los distintos componentes necesarios para aunar y administrar los recursos que conforman el Grid. Existen otras implementaciones, como por ejemplo Legion, cuya concepción es totalmente distinta, ya que está diseñado como un sistema operativo virtual para recursos ditribuídos con soporte OS-like para la interacción de recursos[ibmleg]. En los Capítulos 3 a 7 se cubrirán los componentes más sobresalientes de Globus Toolkit, junto con aspectos de instalación, configuración y testeo. Por otra parte, el Apéndice A hace referencia a los pasos previos a la instalación de todos estos componentes, es decir a la instalación y configuración de la estructura básica de Globus, se sugiere al lector, la lectura del mismo para mejor comprensión de los componentes individuales. 8

10 Figura 1.2: Componentes de GT4 Las líneas rellenas denotan los componentes del núcleo de GT4 cuyas interfases no cambian entre versiones, las punteadas gruesas se encuentran en etapa preliminar y sus interfases podrán cambiar entre versiones, por último las punteadas finas se trata de componentes que en un futuras versiones serán eliminados La naturaleza de la arquitectura Grid El objetivo principal será identificar los componentes fundamentales del sistema que conforma la arquitectura Grid. Referirse para más detalle a [FKT]. Comenzando con las necesidades de las VOs, la característica fundamental a ser abordada es la interoperatividad. En un entorno de redes, la interoperatividad significa protocolos comunes. De esta forma la arquitectura Grid será ante todo una arquitectura de protocolos, con los protocolos definiendo los mecanismos básicos con los cuales los usuarios de las VOs y los recursos negocian, establecen, administran y explotan las relaciones para compartir recursos. Como mencionamos anteriormente, una arquitectura basada en estándares abiertos facilita la interoperatividad, extensibilidad, portabilidad y posibilidad de compartir código. A partir de el uso de estándares se hace fácil definir servicios estándares. También es importante construir APIs (Application Programming Interface) y SDKs 2 (Software Development Kits) para crear las abstracciones necesarias para hacer al Grid usable. En conjunto, todos estos compo- 2 ver Apéndice B 9

11 nentes son lo que habitualmente se denomina middleware Grid. La interoperatividad es necesaria para no estar forzados a recurrir a arreglos bilaterales específicos, entre las partes involucradas en compartir recursos, que restringen severamente el tipo de VO que puede conformarse. Los protocolos son críticos para lograr interoperatividad, estos especifican cómo los elementos de los sistemas distribuidos interactúan unos con otros, para lograr un comportamiento específico y cuál es la estructura de la información intercambiada durante esta interacción. Los servicios están definidos únicamente por el protocolo que hablan y el comportamiento que implementan. De esta manera, la definición de servicios estándares nos permitirá mejorar los servicios ofrecidos a los participantes de la VO, así como también abstraernos de los detalles específicos de los recursos que de otra forma dificultarían el desarrollo de aplicaciones de la VO. Por último, las APIs y SDKs permite agilizar el desarrollo de código, compartir el mismo y mejorar la portabilidad de las aplicaciones Descripción de la arquitectura Grid En la especificación de las capas de la arquitectura se sigue el modelo de reloj de arena. El cuello del reloj define un pequeño conjunto de abstracciones principales y protocolos, sobre los cuales pueden mapearse muchos comportamientos de alto nivel diferentes (parte superior del reloj), y los cuales en sí mismos pueden ser mapeados sobre diferentes tecnologías subyacentes (base del reloj).[fkt] El cuello de la botella consiste de los protocolos Resource y Connectivity, los cuales facilitan el compartir recursos individuales. Los protocolos en estas capas están diseñados para que puedan ser implementados en cima de un rango diverso de tipos de recursos, definidos en la capa Fabric, y pueden a su vez ser utilizados para construir un amplio rango de servicios globales y aplicaciones con comportamientos específicos en la capa Collective, así llamada porque involucra el uso coordinado de múltiples recursos. Ver Figura 1.3. Figura 1.3: Capas generales de la arquitectura Grid 10

12 Fabric: interfases para el control local Esta capa provee los recursos cuyo acceso compartido es mediado por los protocolos Grid. Un recurso puede ser una entidad lógica o física, por ejemplo un sistema de archivos distribuido o un cluster de computadoras. Los componentes de la capa Fabric implementan las operaciones locales específicas de cada recurso, que ocurren sobre recursos específicos como resultado de operaciones en los niveles superiores. Existe de este modo una ajustada y sutil dependencia mutua entre las funciones implementadas en la capa Fabric y las operaciones para compartir recursos soportadas. Si agregamos funcionalidad a la capa Fabric, es posible soportar operaciones en el nivel superior más sofisticadas, por otra parte mantener simple esta capa permite que el desarrollo de la infraestructura Grid se vea simplificado. Por ejemplo una característica avanzada sería soportar a nivel de recursos la posibilidad de reservar el mismo en avance. Pocos recursos permiten soportar esta función. Como mínimo los recursos deben implementar mecanismos de consulta que permitan descubrir su estructura, estado y capacidades por un lado, por otro lado se necesita un mecanismo de administración de recursos que provea control sobre la calidad de servicio entregada. Por ejemplo, en el caso de un recurso de almacenamiento se requerirán mecanismos para poner y sacar archivos del mismo. También, son necesarios mecanismos de administración que permita el control sobre los recursos asignados a las transferencias de datos; mecanismos para consultar las características del hardware o espacio disponible, etc. Globus Toolkit, ha sido diseñado para utilizar principalmente los componentes existentes, incluyendo los protocolos e interfases provistas por los vendedores de los mismos. Sinembargo, si no se provee el comportamiento a nivel Fabric necesario, Globus Toolkit anexa la funcionalidad faltante. Es el caso del software de consulta provisto para descubrir la estructura y el estado de tipos de recursos comunes y, para empaquetar esta información de tal manera que facilite la implementación de protocolos de mayor nivel, específicamente en la capa Resource. La administración de recursos, por otra parte, se asume en general, que está en el dominio del administrador de recursos local. Una excepción es la Arquitectura de propósito General para Reservación y Asignación (GARA, de sus siglas en inglés), que provee un administrador que puede ser utilizado para implementar reserva en avance sobre recursos que no poseen esta capacidad Connectivity: comunicaciones simples y seguras La capa connectivity define los protocolos de comunicación y autenticación centrales, necesarias para las transacciones del Grid sobre la red. Los protocolos de comunicación permiten el intercambio de información entre recursos de la capa Fabric. Los protocolos de autenticación se construyen sobre los servicios de comunicación para proveer mecanismos criptográficamente seguros para verificar la identidad de usuarios y recursos. Los requisitos de comunicación incluyen transporte, ruteo y naming. Los protocolos de comunicación se derivan del stack TCP/IP, incluyendo tambén las aplicaciones 11

13 como DNS (Domain Name Service), OSFP y otras. Con respecto a la seguridad, dada la complejidad de el problema de seguridad, es importante que cualquiera sea la solución, esta este basada en protocolos estándares. La solución para autenticación deberá contar con las siguientes características 3 : Single sign on. Delegación. Integración con varias clases de soluciones de seguridad locales. Relaciones confiables basadas en usuarios. Globus Toolkit, utiliza los protocolos de Internet mencionados para las comunicaciones. Para autenticación, protección de las comunicaciones y autorizazión se usan los protocolos de GSI (Grid Security Infrastructure)basados en sistema de clave pública. GSI extiende y se construye sobre el protocolo TLS (Transport Layer Security). Adicionalmente se utiliza el estándar X.509 para dar forma a los certificados de identificacioón de usuarios y recursos Resource: Compartiendo recursos individuales La capa Resource se construye sobre los protocolos de comunicación y autenticación de la capa Connectivity, para definir los protocolos, APIs y SDKs que permitan la negociación segura, iniciación, monitoreo, control, contabilidad y pago de operaciones llevadas a cabo para compartir recursos individuales. Las implementaciones de estos protocolos de la capa Resource hacen llamadas a funciones de la capa Fabric para acceder y controlar los recursos locales. Los protocolos de la capa Resource tratan exclusivamente con recursos individuales, el tratamiento de recursos múltiples lo lleva a cabo la capa Collective. Se distinguen dos clases principales de protocolos en la capa Resource: Protocolos de información (información de estructura y estado) Protocolos de administración (instancian relaciones para compartir recursos) La capa Resource pertenece al cuello del reloj, y por ende debe ser pequeña. Los protocolos deben ser escogidos de tal modo que capturen los mecanismos fundamentales para compartir distintos tipos de recursos. Globus Toolkit, a adoptado un pequeño conjunto de protocolos, principalmente basados en estándares. En particular: Grid Resource Information Protocol - GRIP, basado en LDAP(Lightweight Directory Access Protocol). Define un protocolo estándar de información de recursos y su modelo de información asociado. También asociado a este, se utiliza un protocolo de registro Grid Resource Registration Protocol (GRPP), para registrar recursos con el Grid Index Information Servers. 3 Serán desarrolladas en profundidad en el Capítulo 4. 12

14 Grid Resource Access and Management - GRAM, basado en HTTP. Utilizado para asignar recursos computacionales y, monitorear y controlar las computaciones en dichos recursos. Este solo se utilizó hasta la versión 3 de Globus Toolkit a partir de la cual GRAM significa Grid Resource Allocation and Management y cuya implementación esta basada en web services 4. GridFTP, es una versión extendida del protocolo de transferencia File Transfer Protocol(FTP). Es un protocolo de administración para acceso a datos. LDAP también se utiliza como protocolo de acceso a catálogos. Globus Toolkit define las APIs y SDKs en C y Java, para el lado del cliente, para cada uno de estos protocolos. También se proveen, para cada uno de los protocolos, los SDKs para el lado del servidor, para facilitar la integración de varios recursos (computacional, almacenamiento, red) al Grid. Como ejemplo, la API Generic Security Services (GSS), permite la sustitución por servicios de seguridad alternativos en la capa Connectivity Collective: Coordinando múltiples recursos Mientras que la capa Resource se ocupa de la interacción con recursos individuales, la siguiente capa en la arquitectura contiene protocolos y servicios (APIs y SDKs) que no están asociados a ningún recurso en particular sino que son da naturaleza global y capturan las interacciones entre conjuntos de recursos. Pueden implementarse una amplia variedad de comportamientos para compartir recursos sin imponer nuevos requisitos a los recursos a compartir. Por ejemplo: Servicio de directorio: permite a los participantes de las VO a descubrir la existencia y/o propiedades de los recursos de la VO. Los protocolos GRRP y GRIP de la capa Resource son utilizados para construir directorios. Co-allocation, scheduling and brokering services: permiten a los participantes de la VO solicitar la asignación de uno o mas recursos para un propósito específico, y planificar las tareas sobre los recursos apropiados. Servicios de monitoreo y diagnóstico. Servicio de replicación de datos: da soporte en la administración de recursos de almacenamiento de la VO para maximizar la performance de acceso a los datos con respecto a distintas métricas tales como tiempo de respuesta, confiabilidad y costo. Grid-enabled programming system: permite utilizar modelos de programación familiares en entornos Grid, utilizando distintos Grid services para lograr descubrimiento de recursos, seguridad, asignación de recursos y otros. 4 Este componente se verá más en detalle en el Capítulo 6 13

15 Software discovery service: descubre y selecciona la mejor implementación de software y plataforma de ejecución basado en los parámetros del problema a ser resuelto. Algunos ejemplos son NetSolve y Ninf. Servidores de autorización de la comunidad: implementan las políticas que gobiernan el acceso a los recursos dentro de una comunidad. Se trata de forzar políticas a nivel global. Akenti lleva a cabo algunos de estos aspectos. Servicios de contabilidad y pago de la comunidad: recolecta información acerca del uso de los recursos para propósitos de contabilidad, pago, y/o limitar el uso de los recursos. Servicios de colaboración: provee el intercambio coordinado de información dentro de comunidades de usuarios potencialmente grandes, ya sea sincrónica o asnincrónicamente. Ejemplos son CAVERNsoft y Access Grid. Las funciones de la capa Collective pueden ser implementados como servicios persistentes, con su protocolo asociado, o como SDKs (con las APIs correspondientes) diseñados para ser linkeados con las aplicaciones. En ambos casos, su implementación puede hacerse sobre las APIs y protocolos de la capa Resource (o otra capa Collective). Globus Toolkit. Adicionalmente a los servicios listados anteriormente en esta sección, mencionaremos el Meta Directory Service, el cual introduce Grid Information Index Servers (GIISs) para soportar vistas arbitrarias de subconjuntos de recursos Aplicaciones La última capa de la arquitectura comprende las aplicaciones de usuarios que operan dentro de el entorno de una organización virtual. Las aplicaciones son construidas en términos de, y por medio de llamadas a servicios definidos en cualquier capa inferior. En la Figura 1.4 se ilustra la arquitectura Grid desde el punto de vista de un programador de aplicaciones, las líneas solidas representan una llamada directa, y las punteadas interacciones de protocolos. Las APIs se encuentran implementadas por Software Development Kits (SDKs), que en sí utilizan los protocolos Grid para interactuar con los servicios de red que proveen capacidades al usuario final. Los SDKs de nivel más alto pueden proveer funcionalidades que no se mapean directamente a un protocolo específico, sino que combinan operaciones de protocolos con llamadas a otras APIs así como también implementan funcionalidad local La necesidad de protocolos comunes La arquitectura Grid presentada establece requerimientos sobre los protocolos y APIs que permiten compartir recursos, servicios y código. Por otro lado, no restringe las tecnologías que pueden usarse para implementar estos protocolos y APIs. De hecho es posible definir múltiples implementaciones de los principales elementos de la arquitectura Grid. Por ejemplo, se pueden construir protocolos en la capa Connectivity 14

16 Figura 1.4: Aplicaciones, protocolo, APIs y SDKs basados en Kerberos y también en PKI (Public Key Infrastructure) y acceder a los mecanismos de seguridad a través de la misma API, GSS-API (se verá en más detalle en el Capítulo 4). Sinembargo, los Grids construidos con estos protocolos diferentes no son interoperables y no pueden compartir servicios esenciales, al menos no sin gateways. Por esta razón, el éxito a largo plazo de la computación Grid requiere que se seleccione y se desarrolle ampliamente un conjunto de protocolos en las capas Connectivity y Resource Componentes de software En la sección 1.5 se ha desarrollado en forma general la arquitectura Grid, explicando las capas que componen dicha arquitectura. A continuación se trataran algunos componentes de software específicos de la arquitectura Grid que implementan funcionalidades necesarias en el entorno. De los componentes que se mencionan a continuación, no todos están disponibles como software, pero deberán considerarse a la hora de diseñar y poner en funcionamiento un entorno Grid Componentes de administración Cualquier sistema Grid debe contar con componentes de administración. Uno de estos componentes mantiene registro de los recursos disponibles en el Grid y cuáles son los usuarios miembros del mismo. Esta información será utilizada para decidir la asignación de jobs. Existen componentes de medición que determinan la capacidad disponible y utilización de los nodos del Grid. Esta información es útil para propósitos de planificación, para determinar la salud del Grid (congestionamientos, etc.) y para recolección de estadísticas y contabilidad acerca del uso de recursos. 15

17 Por último, el software avanzado de adminsitración Grid puede manejar automáticamente muchos aspectos del Grid. Esto es conocido como computación autónoma o computación orientada a recuperación. Este software permite la recuperación de varias fallas de Grid y pausas en el servicio, buscando la manera de lograr el procesamiento de la carga de trabajo actual Administración Grid distribuida EL Grid puede tener una organización jerárquica que usualmente se corresponde con la topología de conectividad del Grid. Un Grid puede estar organizado en una jerarquía formada de clusters de clusters. El trabajo necesario para administrar este tipo de Grids debe estar distribuido para lograr escalabilidad. Se debe distribuir tanto los datos, las operaciones como el trabajo de planificación de tal manera que se corresponda con la topología del Grid. Por ejemplo puede haber una jerarquía de planificadores de trabajo; la información de administración fluirá a través de la jerarquía, de modo que los planificadores de mayor nivel no asignan directamente los trabajos a un nodo para su ejecución, sino que los envían a planificadores de menor nivel. Por otra parte los planificadores de los niveles inferiores recolectan y envían a los niveles superiores la información acerca del estado y la actividad de las máquinas de las cuales se encuentran a cargo Software donado Normalmente una computadora que pretende formar parte del Grid necesita asociarse como miembro del mismo e instalar software que permita el manejo de recursos que esta computadora incorpora al Grid. Usualmente se requerirá algún procedimiento de identificación y autenticación antes de permitir que una máquina pueda unirse al Grid (por ejemplo, mediante el uso de certificados). Algunos sistemas Grid tendrán su propio mecanismo de login, mientras que en otros casos la autenticación de usuarios dependerá del sistema operativo nativo (es el caso de GT4). En este último caso existirán mapeos, típicamente manejados manualmente por el administrador local de cada nodo, que establecen la correspondencia entre usuarios Grid y usuarios locales, estableciendo de esta forma los derechos de acceso locales a cada nodo para cada usuario Grid. En un sistema Grid, la información de los nuevos recursos incorporados es distribuida a lo largo del Grid. Las máquinas donantes usualmente cuentan con un software que determina o mide cuan ocupada se encuentran (taza o cantidad de recursos utilizados). Esta información se pondrá a disposición del software de administración del Grid con fines de planificación entre otros. Más importante aún, el software instalado en un dada máquina puede aceptar trabajos ejecutables del sistema de administración del Grid y ejecutarlos. Un usuario en cualquier punto del Grid despacha un trabajo a ejecutar en el Grid. El software de administración debe comunicarse con el software donado por el Grid para enviar el trabajo allí. El software donado por el Grid debe ser capaz de recibir el archivo ejecutable o seleccionar uno apropiado de copias pre-instaladas en la máquina donante. 16

18 El software es ejecutado y el resultado debe enviarse al solicitante. Implementaciones más avanzadas pueden ajustar dinámicamente la prioridad de un trabajo corriendo, suspenderlo, y reiniciarlo luego. Esta clase e acciones pueden ser necesarias para implementar balance de carga, cambio de prioridades o políticas de ejecución en el Grid Submission software Normalmente cualquier máquina miembro del Grid puede ser usada para enviar jobs al Grid. Sinembargo, en algunos sistemas Grid, esta función es implementada como un componente separado instalado en los submission nodes o submission clients. Cuando el Grid es construido usando recursos dedicados en lugar de recolectados, usualmente se instala por separado en el escritorio de usuario o workstation submission software Planificadores La mayoría de los sistemas Grid incorporan alguna clase de software de planificación. Este software se encarga de ubicar una máquina en la cual ejecutar trabajos Grid que han sido solicitados por los usuarios. Estos planificadores pueden ser simples (ej. en round robin) o complejos como el uso de colas con prioridad de jobs. Adicionalmente se pueden implementar distintas políticas en el planificador. Por ejemplo podría implementarse una política que impida la ejecución de trabajos Grid a ciertas horas del día. Los planificadores reaccionan según la carga actual del sistema. La carga se obtiene de mediciones obtenidas de las máquinas que conforman el Grid. Además, pueden estar organizados en forma jerárquica. Los planificadores más avanzados monitorean el progreso de los jobs remitidos, manejando el flujo total de trabajo. Si un job se ve afectado por una falla en un nodo o por otra situación, el planificador lo reacomoda en otro nodo del Grid de ser posible; siempre y cuando el job remitido no sea el causante del problema (ej. se encuentra en un ciclo infinito). Típicamente, los jobs tendrán asociados distintos códigos de finalización, algunos de los cuales serán susceptibles de replanificación y otros no. La reserva en avance de recursos se implementa mediante un sistema de reservación. Es un sistema basado en calendario para la reserva de recursos por períodos específicos de tiempo. También este sistema, debe ser capaz de suspender o remover jobs que utilizan recursos que han sido reservados, cuando se alcanza el momento en que inicia el período de reserva Comunicaciones Un sistema Grid puede incluir software que ayude a los jobs a comunicarse unos con otros. El estándar abierto Message Passing Interface (MPI) se incluye con frecuencia como parte del sistema Grid para dar este tipo de soporte de comunicaciones. 17

19 Observaciones y medidas Con frecuencia el software donado incluyen alguna herramienta que mide la carga corriente y la actividad en una dada máquina, este software es conocido como sensor de carga. Esta información no solo es útil para planificar, también lo es para descubrir patrones de uso global en el Grid. Estos patrones permiten predecir comportamientos, lo cual deriva en un mejor aprovechamiento del Grid. Pueden encontrarse otros usos. También es importante disponer de formas de visualización que permitan la sencilla interpretación de estos datos Grid y otras tecnologías Las tecnologías existentes para cómputo distribuido no aportan soluciones apropiadas a los problemas y necesidades de las organizaciones virtuales. La computación Grid aporta un planteo más general para compartir recursos World Wide Web La tecnología Web aporta una ubicuidad que la hace interesante como plataforma para construir VO pero, si bien es excelente para dar soporte a las relaciones cliente browser-a-servidor web, carece de las características necesarias requeridas para los modelos de interacción mas complejos que pueden ocurrir dentro de una VO. Es posible integrar ambas tecnologías de modo que los web browsers permitan construir portales VO que provean interfases a los clientes de aplicaciones de VO sofisticadas. Por ejemplo, es posible agregar a los web browsers características para dar soporte a mecanismos de single-sign-on y delegación Proveedores de servicio de almacenamiento y aplicaciones Los proveedores de servicios de almacenamiento y aplicaciones (SSP y ASP respectivamente), y compañías que comercializan distintos tipos de hosting, permiten a las empresas tercerizar ciertos servicios. Típicamente un cliente negocia con el proveedor un dado nivel de servicios, definiendo en forma estricta el acceso a una combinación específica de software y hardware. Los aspectos de seguridad normalmente son cubiertos por tecnologías como VPN (ver Apéndice B). En la mayoría de los casos se recurre a configuraciones estáticas, lo cual limita severamente las modalidades para proveer recursos que pueden requerirse dentro de una organización virtual. Por ejemplo, el uso de VPNs hace típicamente imposible para una aplicación de un ASP, acceder a datos ubicados en almacenamiento administrado por un SSP diferente. Del mismo modo, lograr reconfiguraciones dinámincas dentro de un mismo ASP o SSP es todo un desafío. El problema de fondo es que VPN no acompaña la dinámica propia que las organizaciones virtuales poseen en esencia. 18

20 La integración de la tecnología Grid al ámbito de los ASP, SSP y hosting en general, permitirá ampliar el rango de posibilidades. Los protocolos Grid permiten flexibilizar las negociaciones cliente-servidor, evitando la rigidez de las configuraciones estáticas Sistemas de computación empresariales Existen diversas tecnologías diseñadas para la cosntrucción de aplicaciones empresariales distribuidas, tales como CORBA. Estas proveen interfases estándares con los recursos, mecanismos de invocación remota, entre otras características que facilitan el compartir recursos dentro de una misma organización, en donde el principal modelo de interacción es el de cliente-servidor. Sinembargo, no están diseñadas para abordar los requerimientos de las VOs, en las que se necesita el uso coordinado de múltiples recursos. La integración de la tecnología Grid a estos sistemas permitiría entre otras cosas, sobrepasar los límites organizacionales dando soporte para la interacción entre aplicaciones pertenecientes a distintas organizaciones. Hablamos entonces de extender las capacidades y no de reemplazar la tecnología existente Internet computing and peer-to-peer computing Peer-to-peer computing (P2P, por ejemplo Napster) e Internet computing (por ejemplo SETI) permiten compartir recursos de un modo mas general, adaptándose mejor a las necesidades de las VOs. Aún así, el foco de interés que motiva a los desarrolladores P2P o Internet computing han mantenido a la tecnología Grid por una senda aparte. Una de las razones es que se han enfocado enteramente en soluciones integradas verticalmente, en lugar de buscar definir protocolos comunes que permitan crear una infraestructura interoperable para compartir recursos (esta actitud es normal en los mercados nuevos en donde los participantes intentan desarrollar soluciones que les otorgue el monopolio). Otra razón proviene del hecho en que muchas aplicaciones han apuntado a una forma de compartir recursos más limitada, por ejemplo compartir archivos sin necesidad de control de acceso. A medida que las aplicaciones se tornan más sofisticadas y la necesidad de interoperatividad se vuelve mas importante se evidencia la convergencia de intereses entre P2P, Internet y Grid computing. Por ejemplo, las tecnologías de single-sign-on, delegación y autorización cobran importancia cuando los servicios para compartir datos y recursos computacionales deben interoperar, y las políticas que gobiernan el acceso a los recursos se tornan mas complejas. 19

21 Capítulo 2 Beneficios de la computación grid La tecnología grid posibilita la resolución de problemas demasiado costosos a nivel de computación y gestión de la información como para que se resuelvan por una única máquina o un único cluster de estaciones de trabajo. Entre las aplicaciones que hacen uso de este paradigma, debido a su gran necesidad de computación y el enorme conjunto de datos que utilizan, se encuentran aplicaciones de las denominadas ciencias de la vida, que tienen como principal baluarte el conocimiento del genoma humano o los progresos realizados en las neurociencias, así como aplicaciones de física, de modelado del clima atmosférico o de visualización. Estas aplicaciones suelen utilizar sistemas que se encargan de la explotación de la información, a partir de técnicas de data mining 1 u otros algoritmos de tratamiento de la información. Todos estos sistemas requieren módulos de adquisición de datos (information retrieval) eficientes y con una alta capacidad de almacenamiento. En general, las denominadas dataintensive applications o aplicaciones con uso intensivo de datos pueden beneficiarse de la aplicación de la computación grid Explotar recursos subutilizados En muchas organizaciones, existe una gran cantidad de recursos de computación subutilizados. Por ejemplo, muchas computadoras personales están ocupadas menos del 5 % del tiempo en un día laboral. La computación grid provee un marco de trabajo para explotar estos recursos subutilizados y de esta manera tener la posibilidad de incrementar substancialmente la eficiencia en el uso de recursos. El recurso mas común son los ciclos de CPU provistos por los procesadores de las máquinas en el grid. Existen 3 formas principales de explotar los recursos de computación de un grid: La primera y mas simple es usarlos para correr una aplicación existente en una máquina disponible en el grid distinta de la máquina local. Existen, al menos, dos prerequisitos para este escenario. Primero, la aplicación debe poder ejecutarse remotamente y sin ocasionar un overhead inesperado. Segundo, la máquina 1 ver término en el Apéndice B 20

22 remota debe poder encontrar cualquier hardware o software especial, así como también cualquier requerimiento de recursos, impuesto por la aplicación. La segunda es usar una aplicación que se encuentra subdividida en partes independientes de manera que las partes separadas pueden ejecutarse en paralelo sobre diferentes procesadores. La tercera es ejecutar una aplicación que necesita correr varias veces, sobre diferentes máquinas en el grid. Por ejemplo, con motivo de proveer confiabilidad en los resultados obtenidos. Algunos proyectos han creado sistemas que dividen un problema y lo distribuyen a través de Internet a las computadoras de la gente que se ofreció como voluntaria para aplicar sus máquinas en la resolución del problema. Un ejemplo de este tipo de sistemas es SETI@Home (Search for Extraterrestrial Intelligence, Búsqueda de Inteligencia Extraterrestre) el cual junta los ciclos de CPU ociosos de las máquinas de los voluntarios para analizar señales de radio provenientes del espacio exterior (figura 2.1 en la página 21). Figura 2.1: SETI@Home Los recursos de procesamiento no son los únicos que pueden estar subutilizados. A menudo, las máquinas tienen gran capacidad de almacenamiento sin utilizar. La computación grid (mas específicamente los grids de datos ver capitulo 1, página 5) puede ser usada para agregar este almacenamiento sin utilizar, a un almacenamiento virtual de datos mucho mayor. 21

23 El almacenamiento secundario en un grid puede ser utilizado en maneras interesantes para incrementar la capacidad, la performance, la confiabilidad y la utilización compartida de los datos; donde estos pueden ser accedidos sin importar su localización exacta. En la actualidad, existen varias áreas de aplicación que requieren acceso a fuentes de datos distribuídas, por ejemplo: Librerías digitales (y colecciones de datos distribuídos) que proveen servicios para descubrir, manipular y presentar objetos digitales. Ambientes grid para el procesamiento de datos distribuídos con aplicaciones variando desde visualización distribuída hasta descubrimiento y administración de conocimiento. Archivos persistentes para mantener colecciones de datos, durante un potencial cambio en la tecnología subyacente. Común a todas estas áreas existe un tema importante y es la necesidad de proveer una API (Application Programming Interface) uniforme para manejar y acceder datos en fuentes distribuídas. Se necesitan operaciones especializadas para manejar objetos digitales con distinto grado de granularidad: un objeto digital puede almacenado como tal en una base da datos orientada a objetos, o como un Binary Large OBject (BLOB) en una base de datos objeto-relacional, o como un registro dentro de un archivo; y aún utilizar una API en común de forma de ocultar estos detalles al usuario (Ver figura 2.2 en la página 23) Capacidad de CPUs paralelos El potencial de esta característica es uno de los atractivos mas grandes de un grid. Las aplicaciones pueden ser escritas para usar algoritmos que pueden ser divididos en partes ejecutables independientes. Una aplicación grid intensiva en uso de CPU puede ser pensada como varios subjobs mas pequeños, cada uno ejecutándose en una máquina diferente del grid. La escalabilidad es una medida de qué tan eficientemente están siendo usados los múltiples procesadores en un grid. Esta medida, entonces, constituye un aspecto a tener en cuenta a la hora de diseñar algoritmos que hagan uso de la capacidad de CPUs paralelos. Si uno pudiera dividir la aplicación en n partes, esperaría que la aplicación sea n veces mas rápida. Sin embargo, existen límites o barreras en la escalabilidad; estas pueden darse en las siguientes situaciones: Si el algoritmo solo puede ser dividido en un número limitado de partes independientes debido a la lógica del mismo. Además, en algunas ocasiones no existe una solución paralela para una aplicación dada (o sea, la aplicación es inherentemente secuencial). 22

24 Figura 2.2: El cliente accede a los datos sin saber como están almacenados Si las partes no son completamente independientes (esto es, las partes necesitan interactuar), por causa de la contención debida a las latencias en los mensajes de comunicación entre los jobs, las capacidades de la red de comunicación, los protocolos de sincronización, ancho de banda de entrada/salida en almacenamiento y otros dispositivos, etc Recursos virtuales y organizaciones virtuales para la colaboración Otra capacidad que permite la computación grid es proveer un entorno para la colaboración entre una audiencia amplia. En el pasado, la computación distribuida 23

25 Figura 2.3: Grid virtualiza recursos heterogéneos y geográficamente dispersos prometió esta colaboración y la logró en cierta medida. Grid aumenta las posibilidades de colaboración entre organizaciones, yendo más allá de las prestaciones de un sistema distribuido típico. Este aumento se produce por la virtualización tanto de objetos como de organizaciones, facilitando el acceso y permitiendo a varios sistemas heterogéneos trabajar juntos para formar la imagen de un gran sistema de computación virtual que ofrece una variedad de recursos (como se puede apreciar en la figura 2.3 en la página 24) y que provee una interoperabilidad más uniforme entre los participantes heterogéneos del grid. De esta manera, el uso tanto los clusters de computadoras como también el uso de computación grid ha sustituído a las supercomputadoras en muchos proyectos de investigación. Un ejemplo revelador de este hecho es la evolución de la computación en Física de Partículas, del CERN (Centro Europeo de Física de Partículas). Los experimentos realizados sobre el anterior acelerador LEP se realizaban en supercomputadores IBM y CRAY. A principio de los años 90 el entorno de experimentación cambió, pasándose a utilizar clusters de decenas de procesadores RISC, con sistema operativo UNIX. A finales de los años 90 se comenzó a utilizar clusters de centenas de PC Linux. El nuevo acelerador LHC, que comenzará a utilizarse en el año 2007, requiere nuevas soluciones, debido a que necesita gestionar varios petabytes 2 de datos; 2 1 Petabyte = 1024 Terabytes = Gigabytes 24

26 para tener una idea visual de esto observe la figura 2.4 en la página 25. Se calcula que será necesario el uso de aproximadamente nodos interconectados, lo que implica tanto problemas de financiación como dificultades técnicas. La solución pasa por la compartición de los recursos de un gran número de instituciones geográficamente distribuidas, a través del uso de la tecnología grid. Figura 2.4: Pila de CDs con datos del LHC de un año entero 2.4. Acceso a recursos adicionales Existen otros tipos de recursos que pueden ser compartidos por medio de un grid. Por ejemplo, si un usuario necesita incrementar su ancho de banda total a Internet para implementar un motor de búsqueda de datos (para data mining), el trabajo puede ser dividido entre las máquinas del grid que tienen conexiones independientes a Internet. De esta forma, la capacidad de búsqueda total es multiplicada. La capacidad de comunicación no sólo puede ser usada para el acceso a Internet, sino también para proveer caminos redundantes necesarios para sobrellevar potenciales fallas de la red y tráfico de dato excesivo. Algunas máquinas sobre el grid pueden tener instalado software caro que por licencia no puede ser instalado en cada máquina del grid y que los usuarios de otras 25

27 máquinas requieren. Los trabajos de los usuarios pueden ser enviados a esas máquinas, para poder hacer uso de ese software. Otras máquinas podrían tener dispositivos especiales como telescopios, microscopios, herramientas de diagnóstico médico o de robótica para cirugía. Estos dispositivos podrían ser compartidos entre los usuarios (o algunos de ellos) a través del acceso a los mismos por medio del grid Balance de recursos Un grid une en coalisión un gran número de recursos aportados por máquinas individuales, dentro de una imágen de un gran sistema único. El grid puede ofrecer un efecto de balance de recursos para las aplicaciones que interactúan con él, realizando una planificación sobre los jobs teniendo en cuenta la carga de utilización en las máquinas. Esto puede suceder de dos maneras: Ante un pico inesperado de computación, pueden migrarse jobs hacia máquinas con menor utilización. Si la capacidad de computación del grid ya está completamente utilizada, el trabajo de menor prioridad ejecutado puede ser suspendido temporalmente o terminado y comenzado otra vez mas tarde con el fin de darle lugar a un trabajo de mayor prioridad. Sin una estructura de grid, tales decisiones de balance son difíciles de priorizar y ejecutar. Otros beneficios sutiles pueden ocurrir cuando se usa un grid para el balance de carga. Cuando los jobs se comunican via Internet, o con recursos de almacenamiento, un planificador avanzado puede planificarlos de forma de minimizar el tráfico en las comunicaciones o las distancias. Esto puede reducir potencialmente la comunicación y otras formas de contención en el grid. Por último, provee una infraestructura excelente para recursos de brokering. Dependiendo de las facilidades de contabilidad en el lugar, las diferentes organizaciones participando en el grid pueden acumular créditos de grid y usarlos en las ocasiones en que necesita recursos adicionales. Esto forma la base para una contabilidad grid y la habilidad para distribuir el trabajo (y el costo) en el grid de una forma mas justa Confiabilidad Algunos sistemas hacen uso de hardware costoso para incrementar la confiabilidad de los mismos. Estos son construidos usando chips con circuitos redundantes realizando la misma tarea y votando sobre los resultados, y que además contienen lógica para conseguir una recuperación gradual ante la ocurrencia de fallas de hardware; además de contener otros elementos como procesadores y fuentes de alimentación extras. Esto constituye un sistema confiable pero a un alto costo debido a la duplicación de componentes. 26

28 En lugar de utilizar hardware costoso, se podría alcanzar la misma confiabilidad a través de utilizar un conjunto de componentes independientes de un mismo tipo dentro de un grid. Los componentes en un grid son relativamente baratos y geográficamente dispersos. Por lo cual, si hay alguna especie de falla en una ubicación, las otras partes del grid no deberían ser afectadas. El software de gestión del grid puede automáticamente redistribuir los trabajos a otras máquinas del grid cuando la falla es detectada. En situaciones críticas de tiempo real, múltiples copias de trabajos importantes pueden correr en diferentes máquinas. Sus resultados pueden ser verificados por cualquier tipo de inconsistencia, como fallas en la computadora, corrupción de datos o sabotaje. Tales sistemas grid utilizan computación autonómica. Es un tipo de software que automáticamente remedia problemas en el grid, tal vez antes de que un operador o administrador sea consciente de ello Administración El objetivo de virtualizar los recursos en un grid y manejar sistemas heterogéneos de forma mas uniforme creará nuevas oportunidad para una mejor gestión de una infraestructura de IT (Information Technology, tecnología de la información) mas grande y distribuída. Será mas fácil visualizar capacidad y utilización, haciendo mas fácil para los departamentos de IT el controlar los costos para recursos de computación a lo largo de una organización grande. El grid permite el manejo de prioridades entre diferentes proyectos. En el pasado, cada proyecto tenía que hacerse responsable de sus propios recursos de IT y los costos asociados. A menudo estos recursos podían estar subutilizados mientras que otro proyecto se encontraba en problemas al necesitar mas recursos de los disponibles debido a eventos inesperados. Con la vista global que un grid puede ofrecer, se hace sencillo controlar este tipo de situaciones. Los administradores pueden cambiar un número de políticas que determinan como las diferentes organizaciones pueden compartir o competir por recursos. La utilización conjunta de datos sobre un gran número de proyectos puede incrementar la habilidad de la organización de proyectar futuras necesidades de actualización de componentes. Cuando se requiere mantenimiento, los trabajos pueden redirigirse a otras máquinas sin frenar los proyectos involucrados. La computación autonómica también entra en juego aquí. Varias herramientas pueden identificar tendencias importantes en las máquinas a través del grid, informando al administrador de aquellas que requieren atención Beneficios empresariales Desde la vista de una empresa hay una serie de beneficios que pueden observarse al utilizar grid en la operatoria diaria: 27

29 Aceleración en los tiempos de respuestas: La computación grid puede ayudar a mejorar la productividad y la colaboración, así como también para resolver problemas que antes no se podían resolver. Permite la colaboración y promueve la flexibilidad operacional: Une, no sólo recursos de tecnología de información (IT), sino también a personas. Permite a comercios y departamentos ampliamente dispersos crear organizaciones virtuales (VO) para compartir datos y recursos. Escala eficientemente para encontrar demandas de negocio variables: Crea una infraestructura flexible que permite detectar y cambiar ante rápidas fluctuaciones en las demandas y/o necesidades de los clientes. Incrementa la productividad: Puede ayudar a los usuarios finales a obtener acceso a los recursos de computación, datos y almacenamiento que necesitan. Apalancamiento (Leverage) 3 de inversiones de fondos existentes: Grid permite mejorar la utilización óptima de capacidades computacionales, evitando la compra de componentes de última generación que llevan a un sobreabastecimiento y un gasto innecesario ya que la misma performance puede lograrse utilizando los componentes con los que se cuenta o adquiriendo componentes de menor capacidad de cómputo para ponerlos a trabajar en forma conjunta. De esta manera, la relación computación/precio se ve mejorada (aumenta) Sumario Resumiendo, las principales ventajas que ofrece la computación grid son: La potencia ilimitada que ofrecen multitud de computadores conectados en red, con su capacidad de proceso. La integración de sistemas y dispositivos heterogéneos. La eliminación de los cuellos de botella de algunos procesos de computación. Se trata de una solución altamente escalable. Nunca queda obsoleta, como ocurre con los grandes equipos, debido a su capacidad dinámica de modificar el número y características de sus componentes. 3 ver término en el Apéndice B 28

30 Capítulo 3 Web services resource framework Como se ha mencionado, un entorno Grid provee un modo general para compartir recursos dentro de organizaciones virtuales. Estos recursos serán de tipos sumamente variados y es de gran importancia que las relaciones que ocurren para lograr compartir estos recursos se encuentren bajo el control de un conjunto de políticas y condiciones bien definidas. En este contexto las características principales asociadas a la acción de compartir recursos incluyen descubrimiento, autenticación, autorización y mecanismos de acceso. Se verá Web service resource framework como un medio para compartir recursos y, como piedra angular de toda la arquitectura de servicios que da lugar a la arquitectura Grid. En particular se desarrolla la implementación WSRF que cumple con OGSA y, es la elegida por Globus Toolkit 4 para dar base a su middleware de tipo suma de servicios Administración del estado de los recursos utilizando Grid services En el contexto Grid un recurso se asume representado por algún estado o dato, que además posee una interfase que define el grupo de operaciones que pueden ser invocada por los clientes. La emergencia de las Arquitecturas Orientadas a Servicios (SOA, de sus siglas en inglés), impulsa a los recursos del Grid a exponer sus capacidades a través de servicios con interfases estándares. Los servicios web son mecanismos basado en estándares abiertos, y se han convertido en una forma popular de implementar varios componentes de una arquitectura orientada a servicios. Sabemos que los servicios web son de tipo stateless, es decir, no existe un registro de estado entre subsecuentes llamadas a un servicio web. Por otro lado, con frecuencia en computación Grid el estado de un recurso o servicio es importante, y por ende debe persistir entre transacciones subsiguientes. A continuación se desarrolla una discusión que pretende encontrar una manera de conciliar esta diferencia acerca del estado entre web y Grid services, de modo que la 29

31 tecnología de servicios web sirva de base al desarrollo de Grid services Qué es un servicio Grid Un servicio Grid se define como una interfase asociada a un recurso Grid. Entonces en un entorno Grid, un recurso y su estado serán administrados a través del servicio Grid. Un servicio Grid puede requerir el acceso a más de un recurso. También es posible que múltiples servicios Grid accedan al mismo recurso o que un servicio Grid cree una nueva instancia de un recurso cada vez que es invocado. Los recursos Grid pueden requerir interactuar e integrarse unos con otros, además es muy probable que estos recursos se encuentren en un entorno tecnológicamente heterogéneo. De este modo, se requiere un framework que abstraiga el servicio de mensajes entre servicios Grid, de los detalles de implementación del entorno específico. Una Arquitectura Orientada a Servicios (SOA) provee tal framework. Dicha arquitectura nos permitirá lograr compartir recursos distribuidos a través de organizaciones virtuales herterogéneas y dinámicas. El Global Grid Forum (GGF) ha adoptado Open Grid Service Architecture (OGSA) basada en los principios SOA que provee el framework para implementar un Grid. Luego, todos los recursos (físicos o lógicos) en un Grid que sigue OGSA, están modelados mediante servicios Grid. Dichos servicios están construidos en base a la tecnología de servicios web. Esto permite a los servicios Grid utilizar las capacidades del modelo de mensajes de los servicios web, las descripciones de servicio, y descubrimiento. Los estándares utilizados por la tecnología de servicios web han y continúan evolucionado y, esa evolución se ve aun más favorecida por ser la elección para implementar Grids que siguen OGSA (aumenta la comunidad interesada en la evolución de los servicios web) Servicios Grid vs. servicios web Además de la diferencia mencionada entre servicios web y Grid, acerca de la persistencia o no del estado, existe otra relacionada a la persistencia o no del servicio en sí. Los servicios web abordan la cuestión del descubrimiento e invocación de servicios persistentes. Un documento definido según WSDL (Web Service Description Language) apunta a la locación que hospeda al servicio web. El entorno Grid es dinámico en naturaleza, por ende los servicios Grid pueden no ser persistentes. Un servicio Grid puede ser creado y destruido dinámicamente, a diferencia de los servicios web los cuales se asumen disponibles si el correspondiente archivo WSDL está accesible para sus clientes. Además normalmente los servicios web sobreviven a sus clientes. Esta diferencia tiene implicaciones sobre el modo en que los servicios Grid son administrados, nombrados, descubiertos y utilizados. El modelo OGSA adopta el patron de diseño Factory para crear Grid services transitorios. De este modo un servicio Grid-OGSA es un servicio web potencialmente transitorio basado en protocolos Grid usando WSDL. 30

32 Requerimientos de los servicio Grid-OGSA Desde el punto de vista de OGSA un entorno Grid consiste típicamente de servicios Grid de los cuales unos pocos son persistentes y muchos transitorios. Los siguientes son algunas de las capacidades que el modelo de servicio OGSA requiere sobre los Grid services: Creación: se refiere a la creación de nuevas instancias de los recursos asociados con un servicio Grid a través de una operación. Nombramiento global y referencias: una vez que se ha creado una instancia de un recurso, el entorno Grid requiere una única referencia hacia dicha instancia con información acerca de cómo interactuar con la misma a través del servicio Grid. Admninistración del tiempo de vida: la operación de administración de tiempo de vida define el tiempo de vida de un recurso, principalmente dependiendo de si el recurso expira luego de cierto período de tiempo o inmediatamente. Registro y descubrimiento: Este conjunto de operaciones se refiere a la habilidad de encontrar instancias de los servicios Grid. Notificación: La notificación es un mecanismo asincrónico de mensajes, para notificar a los clientes suscritos al grid de ciertos eventos tales como los referentes al tiempo de vida de los recursos, cambio en las propiedades y demás. Los servicios Grid-OGSA también abordan aspectos de autorización, control de concurrencia y administración. Actualmente existen dos estándares disponibles para implementar servicios Grid que cumplen con los requerimientos OGSA. Open Grid Services Interface (OGSI) Grid Services. Web Service Resource Framework (WSRF) Grid Services Open Grid Services Interface (OGSI) Grid Services OGSI define las reglas acerca de como OGSA puede ser implementado utilizando servicios Grid que son extensiones de servicios web. Las especificaciones OGSI definen una instancia de un servicio Grid como un servicio web que se adapta a un conjunto de convenciones expresadas por medio de WSDL tales como interfases de servicios, extensiones, y comportamientos Las especificaciones OGSI definen características de los servicios Grid que incluyen: Statefulness. Interacciones con estado. 31

33 Habilidad para crear nuevas instancias. Servicio de administración del tiempo de vida. Notificación de cambios de estado y grupos de servicios Grid. El modelo OGSI requiere que el servicio Grid sea especificado a través del Grid Web Service Definition Language (GWSDL), que es una extensión de WSDL. La Figura 3.1 muestra el esquema de capas de varios de los componentes OGSI. Figura 3.1: Componentes OGSI Reestructuración de OGSI a WSRF La migración hacia Web Service Resource Framework que se experimenta a partir de GT4 se debe a que este provee una solución que aborda los requerimientos de los servicios Grid mientras que se mantiene aferrado a los fundamentos de los servicios Web, cuestión que debido a la evolución de los servicios web se estaba haciendo difícil de mantener con la implementación OGSI. El punto principal de enfrentamiento es la percibida divergencia entre las especificaciónes OGSI, de las prácticas populares en la comunidad de servicios web. El principal objetivo en la reestructuración hacia WSRF es mantener las comunidades de servicios Grid y servicios web unidas. Algunos de los cuestionamientos hechos por la comunidad de servicios web están relacionados a la poca factorización de funciones que impide una adopción incremental de OGSI 1.0; conflictos con APIs estándares como JAX-RPC; extremada orientación a objetos en el modelo de recursos con estado y conflictos en el soporte de WSDL 2.0. Todos ellos son abordados por la implementación WSRF, y podemos decir que en un nivel alto, la refactorización de OGSI a WSRF ha resultado en lo siguiente: 32

34 La noción de servicio grid como un WS-Resource. Una mejor separación de funciones, dividendo OGSI 1.0 en una familia de especificaciones separadas. La especificación WS-Notification que puede ser utilizada para construir notificaciones acerca de los cambios de estado, utilizando servicios web. [CFF+] 3.2. Fundamentos de WSRF WS-Resource Framework (WSRF) es un conjunto de cinco especificaciones que definen lo que se denomina WS-Resource approach para modelar y administrar el estado de recursos en un contexto de servicios web.[wsrffaq] Los servicios web, sin considerar las especificaciones WSRF, permiten cambiar el estado de recursos pero, este recurso es implícito, es decir no es parte de la deifinición de interfase del servicio web. Los mensajes que el servicio recibe y envía implican la existencia de un recurso con estado asociado. Un WS-resource será la composición de un servicio web y un recurso con estado. La relación está formalizada por una conveción de uso de los endpoints reference estandarizados por WS-Addressing. Dicha convención se denomina Implied Resource Pattern, según esta el identificador de recurso estará encapsulado dentro de un endpoint reference y es el utilizado para identificar el recurso con estado que se utiliza en la ejecución una solicitud de servicio. WS-Resource Framework permite declarar, crear, acceder, monitorear el cambio y destruir WS-Resource a través de mecanismos convencionales de servicios web, sin requerir que el servicio web asuma la existencia implícita de un recurso sobre el cual debe ejecutar las solicitudes Qué es un WS-Resource? Un WS-Resource es un constructor utilizado para modelar recursos con estado usando como framework la arquitectura de servicios Web. De acuerdo con WSRF, un recurso con estado: Tiene los datos que representan el estado descrito en un documento XML. Tine un ciclo de vida bien definido. Es conocido y accedido por uno o más servicios web. Un recurso con estado modelado utilizando el constructor WS-Resource puede ser implementado de diversos modos. Puede ser un archivo en un sistema de archivos, un registro en una base de datos, o puede residir en memoria como una estructura específica de una aplicación. 33

35 En el diagrama de la Figura 3.2 se describe la relación entre un servicio hipotético para renderizar escenas de una película y varios recursos con estado tales como la escena actual, los efectos especiales a ser aplicados, y los estilos de renderizado para tv o pantalla amplia. Figura 3.2: Ejemplo de relación entre WS-Resource y WSDL En el diagrama los recursos están modelados como WS-Resources y el servicio de renderizado de películas se expone como un servicio web a través de su archivo de interfase WSDL, en el que se definirá las operaciones disponibles. Es importante notar que para los clientes, el servicio y los recursos son vistos como una misma cosa a través del archivo WSDL. Dichos clientes nunca tratarán directamente con las instancias de los recursos sino, implícitamente a través de las interacciones con el servicio de renderizado que cumple con la implementación WS- RF. Esta interacción implícita con las instancias de WS-Resources es conocida como Implied Resource Pattern. Cuando un recurso que posee estado está asociado a un servicio web, definimos al elemento resultante de esa composición como WS-Resource. Se verá en próximas secciones ejemplos sobre cómo se produce la asociación entre un archivo WSDL que expone la interfase de un servicio web y un archivo de propiedades de recurso que define el recurso con estado del WS-Resource Implied Resource Pattern Una de las principales críticas a OGSI 1.0 es que era demasiado orientada a objetos, basados en que OGSI modela recursos con estado como servicios web que encapsulan el estado del recurso, con la identidad y ciclo de vida del servicio acoplados al mismo. Este método ha provocado el desvelo de algunos puristas de los servicios web que argumentan que, los servicios web no tienen estado o instancias. Además, algunas implementaciones de servicios web no se adecúan a la creación y destrucción dinámica de servicios. 34

36 WS-Resource Framework re-articula la arquitectura subyacente a OGSI para hacer una distinción explícita entre servicio y recursos con estado actuando bajo ese servicio.ws-resource Framework define los medios por los cuales un servicio web y un recurso con estado se componen. Como mencionamos anteriormente, WS-Resource Framework denomina a esta composición WS-Resource, e introduce Implied Resource Pattern para formalizar la relación entre servicios web y recursos con estado a través de una conveción de uso de WS-Addressing.[CFF+04] Los servicios web son sin estado. En consecuencia, cuando las operaciones de un servicio web se encuentran involucradas con un estado dinámico, estas son las opciones: El estado está provisto explícitamente dentro del mensaje de solicitud de servicio. El estado es mantenido implícitamente a través de sub-sistemas con los cuales el servicio web interactúa. Implied Resource Pattern implementa la segunda opción. La administración del estado actual y de las instancias de recursos con estado es delegada a un componente externo. La implementación de WSRF implícitamente pasa la información de identificación del recurso cuando ocurre una interacción de mensajes entre un cliente y un WS- Resource. Por implícito se entiende que el cliente no tiene que incluir explícitamente un identificador de recursos en la solicitud. En su lugar, el identificador requerido está implícitamente asociado a un intercambio de mensajes. Implied Resource Pattern es un conjunto de convenciones sobre tecnologías de servicios web, particularmente XML, WSDL y WS-Addressing. Estas convenciones permiten que el estado de un recurso que participa en Implied Resource Pattern sea definido y asociado con la descripción de la interfase de un servicio web. El estado del recurso es definido en términos de un documento resource properties. Entonces podemos usar el término WS-Resource para describir el par servicio web y documento resource properties.[cff+04] Veamos una de las principales convenciones. WS-Addressing estandariza la forma en que las direcciones de los servicios web son representadas. Tal representación es conocida como Endpoint Reference (EPR). Un EPR puede contener, además de la dirección endpoint del servicio web, otros metadatos asociados con el servicio web tales como, información de descripción del servicio y reference properties, los cuales ayudan a ampliar la calificación de uso de la dirección del servicio web. Las reference properties del EPR juegan un rol importante en Implied Resource Pattern. Un EPR que es descrito siguiendo Implied Resource Pattern puede incluir un elemento hijo ReferenceProperties que define el recurso con estado a ser utilizado en la ejecución de todos los intercambios de mensajes realizados utilizando este EPR. Este tipo de EPR se denomina WS-Resource-qualified endpoint reference. Un mensaje de solicitud dirigido a un servicio web designado por un WS-Resource-qualified endpoint reference deberá incluir la información ReferenceProperties del EPR, según lo especificado por WS-Addressing.[CFF+04] 35

37 De esta forma, WSRF usa WS-Resource-qualified endpoint reference para representar un network-wide pointer a un WS-Resource. Un WS-Resource-qualified endpoint reference puede ser devuelto como resultado de un mensaje de solicitud a un servicio web factory, para crear un nuevo WS-Resource o, alternativamente, de la evaluación de una consulta de búsqueda en un servicio de registro, o como resultado de una solicitud a una aplicación web específica. Resumiendo, en WSRF un EPR con un identificador de recurso con estado es conocido como WS-Resource-qualified endpoint reference. El identificador de recurso apunta a un recurso con estado utilizado cuando el servicio web es invocado. La creación de un identificador de recurso es análoga a crear una nueva instancia de un WS-Resource. Una nueva instancia de un WS-Resource puede ser creada a través de un servicio web WS-Resource Factory o alguna otra aplicación. Crear una nueva instancia de un WS-Resource involucra lo siguiente: 1. Crear una nueva instancia del recurso. 2. Asignar un nuevo identificador a la nueva instancia. 3. Crear una nueva asociación entre la nueva instancia del recurso y el correspondiente servicio web. Debido a que el identificador del recurso con estado está incluído en el WS- Resource-qualified EPR, no se requiere al cliente que tenga conocimiento específico de la ubicación del servicio web ni del identificador del recurso. El diagrama en la Figura 3.3 representa cómo un WS-Resource-qualified endpoint reference se ve involucrado cuando un cliente interactúa con un WS-Resource. La especificación WS-Addressing determina que el elemento ReferenceProperties del EPR, debe ser enviado como parte de cualquier mensaje que sea dirigido a un servicio web identificado por un EPR. En el ejemplo de la Figura 3.3, el cliente mantiene un EPR que apunta a un servicio (ficticio) en la ubicación e identifica un recurso con estado B. Dado que este EPR tiene un identificador de recurso en la sección ReferenceProperties, recordamos que se tratan entonces de un WS- Resource-qualified endpoint reference. Cuando el cliente invoca la operación DoSomethingRequest sobre el web service porttype, la información contenida dentro de la seccción ReferenceProperties del documento EPR XML es enviada como parte del header SOAP. El servicio web extrae el valor del identificador de recurso B y ubica el correspondiente recurso con el que debe trabajar y completa la DoSomethingRequest. Si inspeccionamos el cuerpo del mensaje SOAP vemos que, para la solicitud del cliente DoSomethingRequest solo se pasa los parámetros específicos de la operación (someparameter). El identificador de recurso no es pasado explícitamente por el cliente en la solicitud. Esta es la clave en Implied Resource Pattern. 36

38 Figura 3.3: Usando un WS-Resource-qualified endpoint reference 3.3. Especificaciones WS-Resource Framework Como se mencionó anteriormente WSRF mantiene toda la funcionalidad de OGSI 1.0. La refactorización de OGSI resulto en cinco especificaciones WSRF y la familia de especificaciones WS-Notification. Cada una de las especificaciones se encarga de un conjunto de funcionalidades. Esto facilita la composición flexible de varias funcionalidades de manera incremental de acuerdo a las necesidades del implementador. A coninuación enumeramos y posteriormente describimos brevemente las cinco especificaciones definidas por WSRF: WS-ResourceLifetime WS-ResourceProperties WS-RenewableReferences WS-ServiceGroup 37

39 WS-BaseFaults WS-ResourceLifetime Esta especificación aborda tres aspectos importantes de un WS-Resource como ser ciclo de vida, creación de nombres, identidad y destrucción. WS-Resource Factory Pattern WSRF no define cuál es el intercambio de mensaje que debe realizarse para crear nuevos WS-Resoruce. Un WS-Resource podrá ser creado a través de cualquier mecanismo, o a través del uso de un patron de uso para servicios web, este último denominado WS-Resource factory por la especificación WS-ResourceLifetime. Un WS- Resource factory es un servicio web capaz de crear nuevos WS-Resource, devolviendo de mínima como resultado de una llamada de creación un endpoint reference, el cual apunta al nuevo WS-Resource creado. El modo en que el servicio WS-Resource factory mantiene dicha nueva referencia puede variar, no necesariamente será almacenado como un EPR. En principio un existen muchos servicios web que pueden devolver un EPR como respuesta a un intercambio de mensaje, pero sólo será considerado una operación de WS-Resource factory si resulta en la creación de un nuevo WS-Resource cuyo EPR es el retornado. Identidad WS-Resource Desde el punto de vista de la implementación de un WS-Resource, mencionamos en la sección que el recurso con estado componente de un WS-Resource, se identifica a través del uso de un identificador de recurso en la sección ReferenceProperties del EPR que identifica al WS-Resource. Esta clase de EPR se denomina WS-Resourcequalified EPR. Es importante destacar, que la forma y contenido del identificador de recurso, está completamente encapsulado en la implementación del WS-Resource. El servicio web, componente de un WS-Resource puede construir una dirección para el WS-Resource, incluyendo un identificador del recursos con estado en el EPR. Luego este WS-Resource-qualified EPR estará disponible para otras entidades del sistema distribuido, que podrán utilizarlo para dirigir solicitudes al WS-Resource. El servicio web, componente del WS-Resource, interpreta el identificador de recurso, dependiente de la implementación, enviado implícitamente con cada solicitud, de modo de elegir el recurso con estado apropiado sobre el cual se ejecutará la solicitud recibida. Por otra parte, desde el punto de vista de un solicitante de servicio que obtiene acceso a un WS-Resource-qualified endpoint reference, no deberá tratar de interpretar el contenido de la seeción ReferenceProperties que contiene el identificador de recurso. Como dijimos es dependiente de la implementación y no es necesario que el solicitante tenga conocimiento del mismo. Insistiendo en lo implícito de esta información. Hasta el momento, no hay adoptada una especificación sobre servicios web que defina la identidad de recursos con estado. Tampoco existe una que defina los medios por 38

40 los cuales un solicitante puede obtener la identidad del estado con recurso.[cff+04]. En parte estos son los motivos por los cuales no es necesario, actualmente, que el solicitante conozca la identificaión del recurso cone estado, ya que la dependencia de la implementación hace que dicha información no tenga demasiado sentido. En caso de que en un futuro se pretenda exponer la identidad del recurso con estado de un WS-Resource a un solicitante, dicha identidad deberá ser portable, perteneciente a un espacio de nombre convenido. La portabilidad es importante pues permite transmitir la identidad entre aplicaciónes. El hecho de convenir un espacio de nombres, permite resolver ambigüedades cuando las identidades provienen de diferentes fuentes. Actualmente, un solicitante que recibe un WS-Addressing endpoint reference puede transmitirlo a otros servicios, con la seguridad de que el receptor puede invocar operaciones involucrando a la instancia WS-Resource. Este es uno de los fundamentos de WS-Addressing.[CFF+04] Destrucción de WS-Resource Un solicitante que pide la creación de un nuevo WS-Resource a un servicio WS- Resource factory, típicamnete estrá solo interesado en dicho WS-Resource por un período de tiempo finito, luego del cual debería ser posible destruir el WS-Resource de modo que los recursos de sistema o aplicación asociados sean liberados. WSRF estandariza dos tipos de administración del tiempo de vida para destrucción: destrucción inmediata y planificada. Destrucción inmediata: en este caso, el solicitante debe poseer el WS-Resourcequalified endpoint reference del WS-Resource que pretende destruir de forma inmediata, al cual se le enviará el mensaje solicitando su destrucción. En base al identificador de recurso del WS-Resource-qualified EPR se destruirá el recurso con estado apropiado. Observemos que la destrucción del recurso con estado, componente del WS-Resource, destruye efectivamente (por definición) al WS- Resource. Cualquier intento de intercambio de mensajes con el WS-Resource destruido, dará como respuesta un mensaje de falla Unknown Resource. El intercambio de mensajes involucrados en la solicitud de destrucción se encuentra definido en la especificación WS-ResourceLifetime. Destrucción planificada: en este caso, el solicitante puede no desear una destrucción inmediata y sincrónica del WS-Resource, ya sea por el simple hecho de no desearlo o, por la imposibilidad futura de hacerlo, quizá por una eventual desconección del solicitante del entorno distribuido, en el momento en que se pretende destruir el WS-Resource. Sea por la razón que fuere, es posible planificar la destrucción del WS-Resource en un tiempo futuro. Nuevamente, utilizando el WS-Resource-qualified endpoint reference un solicitante puede en principio establecer un tiempo de terminación planificado y luego, de ser necesario, también podrá renovarlo. Cuando se alcanza el tiempo de terminación el WS-Resource se auto-destruye, sin la necesidad de un intercambio de mensajes sincrónico con este momento. La especificación WS-ResourceLifetime define el intercambio de 39

41 mensajes para establecer y subsecuentemente renovar el tiempo de terminación planificado del WS-Resource, tambié define el modo de determinar el tiempo de terminación planificado actual (consulta). Un servicio WS-Resource factory podría ser capaz de negociar un tiempo de terminación planificado, en el momento de creación de un nuevo WS-Resource. Luego, los solicitantes autorizados podrán utilizar el WS-Resource-qualified EPR para establecer un tiempo diferente (anterior o posterior) al establecido inicialmente, por medio del envío de un mensaje al WS-Resource. Una vez alcanzado el tiempo de destrucción, se produce la liberación de recursos y la invalidez de WS-Resource-qualified EPR, al igual que en el caso de destrucción inmediata WS-ResourceProperties Esta especificación define el tipo y valores de aquellos componentes del estado del WS-Resource, que pueden ser vistos y modificados por un solicitante a trvés de la interfase del servicio web asociado. Las ideas principales son las siguientes: El WS-Resource tiene un documento XML denominado resource property definido utilizando XML schema (ver Apéndice B). Los solicitantes de servicio pueden determinar el tipo del WS-Resource recuperando la definición WSDL porttype, por medios estándares. Los solicitantes pueden utiliza intercambios de mensajes con el servicio web para leer, modificar, y consultar el documento XML que representa el estado del WS-Resource. Utilizaremos el término resource property para referirnos a un componente individual del estado de un WS-Resource. Por otra parte, llamamos al documento XML que describe el tipo del recurso con estado, componente del WS-Resource, como WS- Resource properties document. Cada resource property es representada como un elemento XML dentro del documento WS-Resource properties. WS-Resource properties document Este documento representa el estado del WS-Resource y define la estructura a la cual serán dirigidas las consultas y mensajes de actualización, por parte de los solicitantes. Cualquier operción que modifica algúna de las resource property, deberá ser reflejada en la implementación actual del estado del WS-Resource. El documento WS-Resource properties es descrito utilizando XML schema. Específicamnete, el documento WS-Resource properties es expresado como una declaración de elemento global XML (GED, de sus siglas en inglés) en algún espacio de nombres, que comprende un conjunto de referencias GEDs de las resource property individuales. Por ejemplo, consideremos un recurso con estado C. Si el estado de C consta de las resource property p1,p2 y p3, entonces el documento WS-Resource properties, llamado ExampleResourceProperties, puede ser definido como sigue: 40

42 <xs:schema targetnamespace=" xmlns:tns=" xmlns:xs=" > <xs:element name="p1" type= /> <xs:element name="p2" type= /> <xs:element name="p3" type= /> <xs:element name="exampleresourceproperties"> <xs:complextype> <xs:sequence> <xs:element ref="tns:p1" /> <xs:element ref="tns:p2" /> <xs:element ref="tns:p3" /> </xs:sequence> </xs:complextype> </xs:element>... </xs:schema> Cualquier solicitante de servicio podrá obtener este archivo en orden a analizar el tipo del estado con recurso C. El punto aquí es, cómo sabe el solicitante que el nombre GED ExampleResourceProperties define el documento WS-Resource properties del WS-Resource. Esta cuestión está resuelta al declarar el archivo WS-Resource properties en la definición de interfase WSDL porttype del servicio web, componente del WS-Resource. Como mencionamos anteriormente, esta declaracón se lleva a cabo utilizando la sección ResourceProperties, como se muestra en el siguiente ejemplo: <wsdl:definitions targetnamespace=" xmlns:wsdl=" xmlns:xs=" xmlns:wsrp= " xmlns:tns=" > <wsdl:types> <xs:schema> <xs:import namespace=" schemalocation=""/> </xs:schema> </wsdl:types> 41

43 <wsdl:porttype name="someporttypename" wsrp:resourceproperties="tns:exampleresourceproperties" > <operation name=" </wsdl:porttype> </wsdl:definitions> Composición de WS-Resource property Las interfases de servicios web asociadas con las distintas especificaciones relacionadas a los WS-Resource, han sido diseñadas de tal forma que sea posible componerlas. En WSDL 1.1 el diseñador de la interfase del servicio web compone la interfase haciendo copy-paste de las operaciones definidas en los portypes constituyentes utilizados en la composición. Además es posible adicionar las propiedades de los WS-Resource definidas en el documento WS-Resource properties de varios portypes constituyentes para producir un documento WS-Resource properties final. La composición de documento WS-Resource properties puede lograrse adicionando declaraciones adicionales de elementos XML, usando el atributo xs:ref, como se muestra en el siguiente ejemplo: <xs:element name="exampleresourceproperties"> <xs:complextype> <xs:sequence> <xs:element ref="tns:p1" /> <xs:element ref="tns:p2" /> <xs:element ref="tns:p3" /> <xs:element ref="xxxx:someadditionalresourceproperty" xmlns:xxxx= /> </xs:sequence> </xs:complextype> </xs:element> Este documento WS-Resource properties fue construido combinado los elementos resource property del documento WS-Resource properties del recurso con estado C, con un elemento resource property (SomeAdditionalResourceProperty) definido en algún otro espacio de nombres. Accediendo a los valores de WS-Resource property El estado de un WS-Resource puede ser leído, modificado y consultado a través de intercambio de mensajes estándares de servicios web. Estos intercambios están definidos en la especificación WS-ResourceProperties y deberán incluirse como operaciones WSDL en cualquier porttype que utilice el atributo wsrp:resoruceproperties para declarar un documento WS-Resource properties. 42

44 Una operación básica será la de consulta de un valor resource property, en este caso el intercambio de mensajes consiste en solo una solicitud y la consecuente respuesta. Será necesario identificar el WS-Resource a través del WS-Resource-qualified EPR e identificar el resource property específico por medio del nombre calificado de su GED (global element declaration, en XML). Una extensión a esta funcionalidad es la de consultar el valor de mĺtiles resource properties. La operación get de WS-ResourceProperties es la que implementa las funciones mencionadas en el párrafo anterior. get permite al solicitante obtener el valor de una o más resource property. El mensaje de solicitud es el siguiente: <wsrp:getmultipleresourceproperties> <wsrp:resourceproperty>qname <wsrp:resourceproperty>+ </wsrp:getmultipleresourceproperties> En respuesta, el solicitante recibirá un documento XML cuyos elementos contiene los valores de las resource properties especificadas en QName del mensaje de solicitud. Por ejemplo el siguiente es un mensaje de consulta de la resource property p1 perteneciente al recurso con estado C. <soap:envelope> <soap:header> <tns:resourceid> C </tns:resourceid> </soap:header> <soap:body> <wsrp:getmultipleresourceproperty> <wsrp:resourceproperty>tns:p1</wsrp:resourceproperty> </wsrp:getmultipleresourceproperty> </soap:body> </soap:envelope> Por su parte el WS-Resource responderá con un mensaje que contenga el valor de la resource property llamada p1 del WS-Resource. A continuación se ve un ejemplo de este caso: <soap:envelope> <soap:body> <wsrp:getmultipleresourcepropertyresponse> <p1>xyz</p1> </wsrp:getmultipleresourcepropertyresponse> </soap:body> </soap:envelope> La especificación WS-ResourceProperties define además la operación set, la misma permite que los valores de las WS-Resource properties sean insertados, actualizados y borrados. A continuación se muestra una pseudo-sintaxis para un mensaje de solicitud set : 43

45 <wsrp:setresourceproperties> { <wsrp:insert > {any}* </wsrp:insert> <wsrp:update > {any}* </wsrp:update> <wsrp:delete ResourceProperty=QName /> }+ </wsrp:setresourceproperties> La especificación WS-ResourceProperties también define los medios por los cuales un sólicitante puede construir expresiones de consulta sobre las resource properties. Y por último también define los medios por los cuales un solicitante puede suscribirse a notificaciones acerca del cambios en los valores de WS-Resource properties. Esto se hace definiendo un uso particular de las capacidades definidas en la familia de especificaciones WS-Notifications WS-RenewableReferences La especificación WS-RenewableReferences define los mecanismos que permiten renovar un endpoint reference que se convierte en inválido. Estos mecanismos permiten que dicho EPR sea una referencia estable y persistente a un WS-Resource que permite que el mismo estado sea accedido repetidamente a través del tiempo (no expira en forma instantánea)[cff+04]. Un EPR puede contener más que una simple dirección de un servicio web, por ejemplo puede contener políticas establecidas por la autoridad que crea el EPR. Luego la renovación de un EPR puede deberse a una inconsistencia provocada por un cambio en la dirección o, por un cambio que la autoridad que crea el EPR impone a las políticas de uso que gobiernan el intercambio de mensajes con el servicio web WS-ServiceGroup La especificación WS-ServiceGroup se encarga de definir los medios por los cuales colecciones de servicios web heterogéneos por referencia son representados y administrados. Del mismo modo, esta especificación nos permite definir colecciones de WS- Resources, por ejemplo para implementar operaciones colectivas sobre dichas colecciones. La especificación permite expresar reglas, restricciones y clasificaciones sobre los miembros posibles de un ServiceGroup esto se logra utilizando el modelo de resource property definido por WS-ResourceProperties. La interfase definida por un WS-ServiceGroup probablemente será compuesta con otras interfases des servicios web que definen operaciones más especializadas sobre los miembros del grupo. 44

46 WS-BaseFaults La especificación WS-BaseFaults define una base con tipos de fallas que serán utilizados el retornar una falla en el intercambio de mensajes con un servicio web. Si bien no hay nada específico acerca de WS-Resource en esta especificación, es utilizado no obstante, por todas las restantes especificaciones de WS-Resource Framework para dar consistencia a las dallas retornadas por las operaciones en estas especificaciones. [CFF+04] WS-Notification Hemos mencionamos como parte de la refactorización OGSI 1.0 la familia de especificaciones WS-Notifications, la cual se compone de tres especificaciones cuya funcionalidad será brevemente comentadas a continuación: WS-BaseNotification Describe los roles básicos, conceptos y patrones requeridos para permitir a un suscriptor registrar su interés en recibir mensajes de notificación de un productor. Un suscriptor registra su interés en recibir mensajes de notificación de uno o más tópicos, despachando un mensajes subscribe. En respuesta, el suscriptor recibirá un WS-Resource-qualified EPR que posee el endpoint a un subscription WS-Resource. El subscription WS-Resource modela la relación entre el suscriptor y el productor y, utiliza las especificaciones WS-ResourceProperties y WS-ResourceLifetime para administrar esta relación. WS-Topics Define un mecanismo para organizar y categorizar tópicos. Los tópicos son mecanismos para organizar mensajes de notificación, de modo que los suscriptores puedan convenientemente entender qué tipo de notificación se encuentran disponibles para suscribirse. Estos tópicos están representados mediante descripciones XML. WS-BrokeredNotification Define la interfase con un NotificationBroker que implementa un servicio intermediario para administrar suscripciones para otras entidades en el sistema que producen mensajes de notificación y no son en sí mismas proveedoras de servicios. La Figura 3.4 provee una visión general de WS-Resource Framework y cómo se relaciona con otras especificaciones de servicios web. Este diagrama es la reestructuración OGSI expuesta en la Figura WS-Resource Framework y Globus Toolkit 4 WS-Resource Framework introduce la noción de WS-Resource como base para la construcción de servicios Grid. Cuando un WS-Resource es empaquetado como un Grid Archive (GAR) y desplegado en el container de GT4, este es reconocido por el container de GT4 como un servicio web válido que sigue WSRF. Esto es sinónimo de Grid Service. 45

47 Figura 3.4: WS-Resource Framework y otras especificaciones En la Figura 3.5 se muestra varios escenarios de despliegue de servicios web dentro de un container GT4. Las áreas sombreadas del diagrama representan los componentes de la infraestructura de container de GT4 que permiten desplegar servicios diferentes. Existen varios componentes en GT4 que están implementados como WSRF web services dentro del container de GT4. A un nivel alto, los pasos involucrados para implementar un WSRF web service para desplegarlo dentro de un container de GT4, son los siguientes: 1. Definir la interfase del servicio. Significa prepara el archivo WSDL que define las operaciones de nuestro WSRF service, y puede incluir definiciones de las propiedades de recursos. 2. Implementar el servicio. Se refiere a desarrollar el código Java para las operaciones del WSRF service y propiedades asociadas si las hubiera. 3. Definir los parámetros de despliegue. Se refiere a preparar un archivo Web Service Deployment Descriptor (WSDD) para nuestro servicio, que define varios aspectos de la configuración del mismo. 4. Compilar y generar el archivo GAR. La compilación y creación del archivo GAR involucra la creación de los archivos con los stubs apropiados para manejar mensajería SOAP y empaquetar el servicio en un formato requerido por el container de GT4. 5. Desplegar el servicio. 46

48 Figura 3.5: WS-Resource Framework y otras especificaciones 47

49 Capítulo 4 Seguridad en Grid 4.1. Introducción Como ya hemos mencionado el software grid estará conformado por varios componentes, los cuales cumplen diversas funciones, tales como servicios de información acerca de los recursos disponibles, administración de datos, schedulers de ejecución de trabajos en el grid y seguridad entre otros. Este último será muy importante, y es el de interés en el desarrollo de este capítulo. Una aplicación grid será una aplicación que corre sobre el software de grid, haciendo uso de los recursos que el grid dispone. El sistema de software grid o middleware será el que facilita el desarrollo de aplicaciones de este tipo y maneja la estructura subyacente. Como vemos, la tecnología grid pretende aunar recursos separados o no geográficamete, incluso pertenecientes a diferentes organizaciones o dominios administrativos. Dado este planteo, se hace más que evidente la necesidad de implementar una infraestructura de seguridad que permita a aquellos participantes del grid controlar el uso de sus recursos (donados al grid) y, además, que de al usuario confianza, acerca de la autenticidad de los recursos a los cuales puede acceder a través del grid. Por ejemplo, un participante del grid querrá estar seguro de que quienes corran procesos en su máquina (ciclos de cpu donados al grid) son usuarios debidamente autenticados ante el grid Requerimientos de la seguridad grid Definimos una organización virtual (VO) como un grupo dinámico de individuos, grupos u organizaciones que definen las condiciones y las reglas para compartir recursos. Una aplicación grid podrá expandirse a múltiples dominios administrativos(ya que una VO puede expandirse en múltiples dominios administrativos). Cada uno de estos dominios tiene sus propias reglas y condiciones las cuales habrá que respetar. Se requiere de una infraestructura de seguridad para cumplir con las políticas de nivel local a un dominio y, con las políticas definidas por las organizaciones virtuales. 48

50 The Security Architecture por Open Grid Services by Nagaratnam, et. al., 2002 resume básicamnete los desafíos de seguridad en un entorno grid: Integración Se requiere que la infraestructura de seguridad del grid se integre con las infraestructuras de seguridad existentes a través de las plataformas y hosting environment. Se requiere que la arquitectura de seguridad global sea independiente de la implementación y extensible a la incorporación de nuevos servicios. Interoperatividad Los grid-services que atraviesan múltiples dominios y hosting environment, necesitan ser capaces de interactuar unos con otros para permitir que los dominios intercambien mensajes, permitir a cada parte especificar políticas de seguridad aplicadas a conversaciones seguras, y proveer mecanismos para identificar un usuario de un dominio en otro dominio. Relaciones confiables Una solicitud de grid-service puede expandirse a múltiples dominios de seguridad. Los dominios de seguridad involucrados en cumplir esta solicitud requieren el establecimiento de relaciones confiables unos con otros. Dada la naturaleza dináminca del grid, es impráctico establecer relaciones confiables punto a punto, previo a la ejecución de una aplicación. En un nivel más alto podemos definir los requerimientos de seguridad como sigue: Autenticación: proveer interfases para incorporar diferentes mecanismos de autenticación y medios para dar a conocer el mecanismos utilizado. Delegación: Proveer mecanismos para permitir la delegación de derechos de acceso de los solicitantes a los servicios, mientras se asegura que los derechos de acceso delegados están restringidos a las tareas que se pretenden realizar. Single Logon: Se refiere a relevar a una entidad autenticada de re-autenticarse por un cierto período de tiempo cuando se solicitan acceso subsecuentes a los recursos del grid. Extensión y renovación de credenciales: capacidad para renovar las credenciales del solicitante si una operación de una aplicación grid tarda más en completarse que el tiempo de vida de la credencial. Autorización: habilidad para controlar el acceso a los componentes del grid basados en las políticas de autorización. Privacidad: permitir la definición e imposición de políticas de seguridad tanto por parte de los solicitantes de servicio como de los servidores de los mismos. 49

51 Confidencialidad: protege la confidencialidad del transporte subyacente y el contenido de los mensajes, y entre componentes OGSA-compliant 1, ya sea en mecanismos punto a punto o en mecanismos de almacenamiento y reenvío. Integridad de mensajes (cambios en mensajes detectados por receptor) Intercambio de políticas (negociación segura entre solicitantes de servicio y proveedores de los mismos) Logging seguro: provee la base para no-repudio y auditoría que permite a los servicios asignar estampillas de tiempo y log de varios tipos de información sin interrupción o alteración de esta información por agentes adversos. Assurance: provee el medio para calificar el nivel de seguridad que puede esperarse en un hosting environment. El nivel de aseguramiento de seguridad indica los tipos de servicios de seguridad provistos por un entorno. Esta información es necesaria para decidir si instalar, o no, un servicio en un host de acuerdo al nivel de seguridad que este experimenta. Manageability: Este requerimiento se refiere principalmente a varias características de administración de servicios de seguridad, tales como administración de identidades, políticas, y demás. Bloqueo de firewalls: habilidad para atravesar firewalls sin comprometer el control local de las políticas del firewall, de manera de lograr cross-domain grid computing environment. Asegurar la infraestructura OGSA: se refiere a asegurar los componentes del núcleo OGSA Globus Toolkit 4 Dentro de los componentes del middleware grid, uno de gran relevancia es el componente de seguridad. Globus utiliza distintos estándares para dar forma a este componente. A continuación, describiremos brevemente alguno de estos, para dar base al desarrollo sobre el componente de seguridad GT4 específicamente Certificados X.509 Un certificado digital es en esencia un documento electrónico que vincula una clave pública con un dado usuario, dando validez a la relación entre dicha clave y el usuario. Estos certificados estarán firmados digitalmente por una autoridad certificante o de certificación (CA), en la cual el usuario del certificado confía. GT4 se basa en estándares abiertos y la Infraestructura de Clave Pública (PKI sus siglas en ingés) no será la exepción, ya que GT4 la construye en base a certificados 1 OGSA-compliant (Open Grid Service Architecture) 50

52 que respetan el estándar X.509 (Internet Engineering Task Force - IETEF). Este estándar es parte de las recomendaciones X.500 que definen un servicio de directorio. En el marco de X.509, el directorio sirve como un repositorio de certificados de clave pública. El formato de los certificados X.509 es un estándar de facto en lo que a certificados digitales respecta. X.509 sólo define la sintaxis de los certificados, por lo que no está atado a ningún algoritmo en particular. Los certificados incluirán los siguientes campos: Versión Número de serie (valor único dentro de la CA firmante) Identificador del algoritmo empleado para la firma digital Nombre del certificador Período de validez Nombre del sujeto Clave pública del sujeto (clave + identificador del algoritmo) Identificador único del certificador Identificador único del sujeto Extensiones (versión 3) Firma digital de todo lo anterior con clave privada del certificador (hash + identificador del algoritmo). Como se menciono un certificado válido etará firmado por un certificador en el cual el usuario del certificado confía directamente o bien puede establecer su autenticidad. De esta manera se establece una estructura jerárquica de certificadores, en la que quién ocupe la raíz de la jerarquía deberá contar con la confianza de toda la comunidad que utiliza los certificados. [Luc] Normalmente las claves públicas de los certificadores de mayor nivel serán publicadas de manera de poder constatar con facilidad la validez de los certificados firmados por estos (directorio). El mecanismo empleado para conseguir un certificado X.509 consiste en generar una par de claves, una pública y otra privada, y luego enviar a la autoridad certificante una solicitud de certificado. Esta incluirá principalmente nuestra clave pública y nuestra identificación. La autoridad certificante verifica la validez de la información recibida y, si es correcta, crea un certificado (respetando el formato propuesto por X.509). Por último se envía el certificado al solicitante del mismo. La implementación técnica de los certificados, es tal que se considera extremadamente difícil alterar cualquier parte del certificado sin ser detectado. La firma de la autoridad certificante provee un chequeo de integridad para el certificado digital.[jmf+05] 51

53 Protocolo SSL y TLS El protocolo SSL (Secure Socket Layer) desarrollado por Netscape y TLS (Transport Layer Security) son estándares en esencia iguales. Su objetivo es establecer conexiones seguras a través de Internet, basndose en el uso de certificados. SSL se constituye en una capa de codificacíon de mensajes previo a que estos salgan a la red. Cuando dos aplicaciones en distintos lugares, quieren comunicarse, luego de establecida la comunicación, todo el tráfico entre ellas pasará por la capa SSL. Esto es, en el extremo emisor los mensajes serán codificados por SSL antes de ser enviados, y en extremo receptor los mensajes son decodificados por la capa SSL previo a la entrega de los mismos a la aplicación destinataria. TLS (RFC 2246, versión 3.0 de SSL) mejora algunas características de SSL original. Una comunicación SSL o TLS consta fundamentalmente de dos fases: 1. Handshaking: Identificación mutua de las partes. Normalmente se hace en base al intercambio de certificados X.509. Tras el intercambio de claves públicas, las partes eligen una clave se sesión para cifrado simétrico. 2. Fase de comunicación: Intercambio de información codificada con la clave de sesión acordada en el handshake. Para concluir, la principal ventaja de incorporar SSL/TLS es liberar a las aplicaciones de llevar a cabo las operaciones criptográficas antes de enviar/recibir información.[luc] Fundamentos de seguridad Los servicios más importantes en la seguridad son: autenticación, control de acceso y enriptación. Conceptos relacionados a estos son: integridad de datos, confidencialidad de datos y administración de calves. La Infraestructura de Seguridad Grid (GSI) provisto como parte de Globus Toolkit y la Infraestructura de Clave Pública (PKI) proveen un framework técnico para soportar seguridad en grid con cinco capacidades: autenticación de usuarios, confidencialidad de datos, integridad de datos, no repudio, y administración de claves Términos importantes en la seguridad grid Conceptos importantes serán: Encriptación simétrica Encriptación asimétrica Secure Socket Layer\Transport Layer Security (SSL\TLS)(vistos en una sección anterior) Infraestructura de Clave Pública (PKI) 52

54 Autenticación mutua: en lugar de usar un repositorio LDAP 2 para almacenar las claves públicas, dos partes que quieren comunicarse usan sus claves públicas almacenadas en sus certificados digitales para autenticarse una con otra.(ver 4.4.2, pág. 64) Encripción simétrica Algunos algoritmos de encritación simétrica son: DES, AES y Triple-DES. Son utilizados para intercambiar información en forma confidencial, basándose en el uso de una clave secreta, compartida entre las partes involucradas en el intercambio. Encripción asimétrica Ejemplo: RSA. Normalmente se usa para la transmisión segura de claves privadas de sesión por su lentitud de encripción frente a los sistemas simétricos. Se basa en el uso de un par de claves por parte involucrada, una pública y otra privada. Agrega la capacidad de incorporar firma digital a los mensajes. La autoridad certificante - CA Las principales responsabilidades de la CA son: Identificar afirmativamente las entidades que solicitan certificados Emitir, remover y archivar certificados Proteger el servidor de la CA Mantener un espacio de nombres único para los propietarios de certificados Servir certificados firmados a aquellos que los necesiten para autentificar entidades Actividad de logging (registro). Dentro de algunos entornos PKI, una Autoridad Registrante (RA) trabaja en conjunto con la CA. La RA es responsable de aprobar o rechazar solicitudes de certificados de claves públicas (valida la información enviada por el usuario) y reenviar la información a la CA. Simple CA provista por Globus Toolkit maneja las funciones tanto de CA como de la RA. A medida que el número de certificados se incrementa estas funciones normalmente se encuentran separadas. Antes de que la CA pueda firmar cualquier certificado, debe hacer lo propio con ella misma de modo de que su identidad quede representada por su propio certificado. Para hacer esto la CA realiza los siguientes pasos: 2 LDAP (Lightweight Directory Access Protocol) es un protocolo de software para permitir a cualquiera ubicar organizaciones, individuos, y otros recursos tales como archivos y dispositivos en una red, ya sea en Internet o en una intranet de una corpotación. LDAP no incluye características de seguridad. 53

55 1. La CA genera aleatoriamente su propio par de claves. 2. La CA protege su clave privada. 3. La CA crea su propio certificado. 4. La CA firma el certificado con su clave privada. Todos estos items se llevan a cabo durante la ejecución del script setup-simple-ca, provisto por GT4, en el host que se desea cumpla el rol de autoridad certificante de nuestro dominio. Al ejecutarlo comienza la creación de la autoridad certificante en el host, visualizándose lo siguiente: C e r t i f i c a t e A u t h o r i t y S e t u p This script will setup a Certificate Authority for signing Globus users certificates. It will also generate a simple CA package that can be distributed to the users of the CA.... Como se menciona en la salida del script, adicionalmente a crear los archivos y directorios necesarios para crear la CA, se crea un paquete de instalación del certificado de CA para todos aquellos hosts que queramos incorporar al dominio de dicha autoridad certificante. La clave privada de la CA La CA firma cada certificado digital emitido dentro del grid. Si alguien obtiene la clave privada de la CA podría suplantar a cualquiera dentro del entorno. Es importante proveer al servidor CA con todos los mecanismos de seguridad disponibles. Esto se logra restringiendo los permisos de acceso sobre el archivo que almacena la clave privada, al usuario globus (este usuario se crea con fines de instalación, no es un usuario grid real). Al ejecutar el script setup-simple-ca, vemos que: The private key of the CA is stored in /home/globus/.globus/simpleca/ /private/cakey.pem The public CA certificate is stored in /home/globus/.globus/simpleca/ /cacert.pem Verificando los permisos de estos archivos en el cluster perteneciente al grupo de investigación LISiDi, observamos: [root@c01 ~]#cd /home/globus/.globus/simpleca/private [root@c01 private]# ls -la -rw globus globus 963 Apr 12 19:59 cakey.pem [root@c01 private]# cd.. [root@c01 simpleca]# ls -la -rw-r--r-- 1 globus globus 2717 Apr 12 19:59 cacert.pem Adicionalmente, GT4 agrega mayor seguridad a la clave privada, solicitando una frase de paso o pass-phrase durante la creación de la CA con el script 54

56 setup-simple-ca, que debe ser ingresada cada vez que se usa la clave privada junto con el certificado. De esta forma la obtención de la clave privada no es suficiente para poder suplantar la identidad de la CA. Certificación cruzada de CAs Cada CA provee certificados a un grupo fijo de usuarios. Si dos organizaciones virtuales (VO) necesitan comunicarse deben lograr confianza mutua, esto puede requerir que las CAs de ambas VO, confíen la una en la otra o participen de una certificación cruzada. Los hosts grid de diferentes dominios o VOs necesitarán confiar en los certificados de cada una, de esta manera los roles y la relación entre las CAs de cada dominio o VOs debe ser definida. El propósito de crear tales relaciones de confianza el lograr eventualmente un PKI global e interoperable y agrandar la infraestructura grid. El proceso de certificación cruzada utilizado por GT4 consiste básicamente en el intercambio y posterior instalación del paquete que contiene el certificado de CA en la que se desea confiar (esto, en caso de haberse utilizado SimpleCA provista por GT4, pudiendo variar el procedimiento si se utiliza una CA distinta, típicamete en ambientes de producción). El paquete de instalción en cuestión es el creado al ejecutar el script setup-simple-ca, y es el mismo que se utiliza para incorporar nuevos hosts al dominio de una dada CA (ej. de nombre del paquete creado por el script globus_simple_ca_hash_setup-0.18.tar.gz). Ver Figura 4.1 a continuación. Figura 4.1: Esquema de certificación cruzada Para instalar dicho paquete basta con correr los scripts gpt-build, gpt-postinstall y setup-gsi pasando como parámetro el paquete. En este caso debe tenerse la precaución de no pasar como parámetro a setup-gsi la opción -default, pues esto establecería a la CA remota como la CA por defecto de nuestro dominio. Finalizada la instalación del certificado, ya se está en condiciones de verificar la autenticidad de cualquier certificado firmado por la CA agregada como confiable. 55

57 Para verificar que efectivamente la CA por defecto siga siendo la local y no la nueva CA remota, se utiliza el comando grid-default-ca -list, que lista las CA instaladas en el host y cuál de ellas es la que se usa por defecto, además nos permite cambiar la CA default del dominio a cualquiera de las listadas. Como paso final del proceso de certificación cruzada, es necesario autorizar a los usuarios del dominio de la nueva CA incorporada como confiable, es decir, es necesario establecer cuáles son los permisos de acceso, ejecución, etc. Este proceso se lleva a cabo a través de un mapeo, implementado mediante un archivo llamado grid-mapfile, y es el mismo mecanismo utilizado para los usuarios locales, se explicará en más detalle en la sección 4.4.1, pág. 60. Administración de una CA propia Si bien la autoridad certificante provista por GT4 es completamente funcional se recomienda que para ambientes en producción se recurra a soluciones PKI comerciales, eliminando la responsabilidad de manejar su propia CA. Otra razón por la que no es conveniente administrar una CA propia, esta dada por la dificultad en demostrar nuestra confiabilidad como autoridad certificante ante el resto del mundo, por ejemplo durante el proceso de certificación cruzada. Certificados digitales Un concepto central en autenticación GSI (Grid Security Infrastructure, implementación particular de la infraestructura de seguridad provista con GT4) es el de certificado. Cada usuario y servicio en el grid es identificado via un certificado, el cual contiene información vital para identificar y autenticar al usuario o servicio.[sec] Estos certificados asocian un recurso grid con su clave pública. Cuando el certificado está firmado por una CA en la que se confía, este es considerado una prueba electrónica de identidad. Cuando un cliente grid quiere comenzar una sesión con un receptor grid, este no adjunta su clave pública sino su certificado digital. Si el certificado está firmado por una CA en la que el receptor confía, entonces este podrá confiar en que la clave pública contenida en el certificado pertenece efectivamente al emisor. Cuando usted se comunica con alguna otra parte en el grid, el receptor usará su clave pública para desencriptar el ID de sesión SSL (clave de sesión privada), el cual es usado para encriptar toda la información transferida entre computadoras del grid. Los pasos para obtener un certificado de la CA son los siguientes: 1. El usuario que requiere el certificado genera un par de claves. 2. El usuario firma su propia clave pública y cualquier información adicional. Firmar la clave pública demuestra que el usuario posee de hecho la clave privada que corresponde a la clave pública. 3. La información firmada es comunicada a la CA. 56

58 4. La CA verifica que el usuario efectivamente posee la clave privada correspondiente a la clave pública recibida (esto no verifica la identidad real del solicitante). 5. La CA (u opcionalmente la RA) necesita verificar la identidad del usuario. Esto puede hacerse por distintos métodos (mail, face to face,etc). También podrá usar registros propios o del sistema para verificar la identidad. 6. Luego de la positiva identificación del usuario, la CA crea el certificado firmando la clave pública y la información del solicitante (en particular la identidad). Luego el certificado será enviado (posiblemente previo paso por la RA) al solicitante. En el caso de GT4, los dos primeros incisos se llevan a cabo mediante el script grid-cert-request. En este proceso se solicita un pass-phrase que protegerá la clave privada del par de claves creadas, además obviamente de la protección brindada por el mecanismo de permisos del sistema operativo. Este script genera un archivo que contiene la solicitud. Para agregar un nodo al grid Globus, se necesitan dos tipos de certificados, los certificados de usuario, para permitir el acceso de los mismos al grid; y los certificados de host, para autenticar el host en sí mismo como parte del grid y como potencial proveedor de recursos. En el caso de los certificados de usuario, el archivo de solicitud creado se denomina usercert_request.pem y se encuentra en el subdirectorio oculto.globus en el home del usuario. Por otra parte, la solicitud del certificado de host se llama hostcert_request.pem y se encuentra en el directorio /etc/grid-security. En la Figura 4.2 se muestra un ejemplo de solicitud de certificado X.509, en este caso particular se trata de la solicitud de certificado de host: Como se ve en la figura, se indica en la solicitud un subject, dicho string esta en la forma de Distinguished Name (DN ), y será el unique subject o nombre único en base al cual, la CA construirá el certificado. Este DN, identifica de manera única el certificado y será el nombre del poseedor del certificado (en el caso de la figura será el nombre del host), dentro del grid Para el envío de la solicitud, GT4 no provee ningún mecanismo especial, por lo que deberá transmitirse por mail, scp (secure copy), o cualquier protocolo de transferencia de archivos. La verificación que hace la CA sobre la solicitud es solo de integridad de la misma. La CA provista por GT4, crea un certificado en base a la solicitud recibida, y lo firma mediante el script grid-ca-sign. El envío del certificado al solicitante, nuevamente será a partir de cualquier protocolo de transferencia. En el caso del certificado de usuario, el archivo con el certificado firmado por la CA, llamado usercert.pem deberá quedar almacenado en $HOME/.globus, por otra parte el certificado de host hostcert.pem, quedará almacenado en /etc/grid-security. A continuación se muestran los permisos de los certificado de usuario (usuario auser1) y de la clave privada del mismo: 57

59 Figura 4.2: Solicitud de certificado ~]# cd /home/auser1/.globus ls -la -rw-r--r-- 1 auser1 auser Apr 19 12:53 usercert.pem -r auser1 auser1 963 Apr 19 13:04 userkey.pem Por otra parte los permisos del certificado y clave privada del host son idénticos, a no ser por el propietario que en este caso será el usuario globus. Diferentes tipos de certificados Dentro del entorno grid existen certificados de usuarios del grid y certificados de servidores de grid. Usuario: el certificado de usuario identificará su nombre de usuario dentro del grid. Servidor: si se planea correr programas PKI-enables en su servidor, se necesitará registrar un certificado de servidor. Este certificado de servidor registrará el nombre de dominio calificado de su servidor en su certificado. Para que su certificado funcione, su nombre DNS calificado debe corresponderse con el certificado 58

60 Figura 4.3: Esquema de solicitud y emisión de certificados digital. Por ejemplo, si el nombre del servidor es cs.uns.edu.ar, el certificado de servidor deberá indicar en su subject: /CN=Service/cs.uns.edu.ar PKI directory services Dentro de algunos entornos PKI, las claves firmadas son publicadas en un directorio público para una recuperación sencilla. En lugar de tener clientes manejando autenticaciones mutuas, un servidor externo es responsable de manejar el proceso de autenticación. Un ejemplo de este mecanismo es MyProxy Server Infraestructura de seguridad grid - GSI Describiremos brevemente, los mecanismos básicos usados por la Infraestructura de Seguridad Grid provista por Globus Toolkit Consiguiendo acceso al grid Para crear un entorno grid usando componentes GSI, será necesario conseguir, en principio, la clave pública de la CA que autoriza los certificados del grid. Esto se logra instalando en cada host del grid un archivo de instalacicón, creado por la CA. (ver 4.3.4, pág. 53) Durante la ejecución de este script se observa: 59

61 The distribution package built for this CA is stored in /home/globus/.globus/simpleca//globus simple ca ebb88ce5 setup-0.18.tar.gz This file must be distributed to any host wishing to request certificates from this CA. La instalación en cada host de este archivo involucra los scripts gpt-build, gpt-postinstall y setup-gsi -default. La opción -default indica que la CA que se está instalando será la que se use por defecto como autoridad certificante para ese host. A continuación se crean en cada host los conjuntos de claves para criptografía asimétrica, se crean las solicitudes de certificados y se envían los mismos a la CA para su firma. (ver 4.3.4, pág. 56) Autenitcación y autorización Cuando se pretende entablar una comunicación con una aplicación en un host remoto del grid, se requieren mecanismos de autenticación y autorización. Es decir, se require determinar si tenemos o no acceso, y dado el caso que lo tengamos, determinar cuáles son las acciones permitidas. Para autenticación y autorización, GSI provee distintas funciones. A continuación se describen los pasos para que un usuario (o aplicación) en el host A, sea autenticado y autorizado en el host B. 1. El usuario o aplicación en A envía su certificado a B. 2. El host B obtiene la clave pública de A del certificado recibido, y la utiliza para obtener el subject del certificado. 3. El host B genera un número pseudoaleatorio y lo envía a A. 4. El host A recibe el número, lo encripta con su clave privada y lo reenvía a B. 5. B desencripta, con la clave pública de A, el valor recibido y verifica de esta forma que A efectivamente posee la clave privada correspondiente a esa clave pública. 6. En los incisos anteriores se llevó a cabo la autenticación, ahora veamos cómo se establece la autorización. El certificado a sido autenticado y el subject del certificado es mapeado a un nombre de usuario local. El subject es de la forma Distinguished Name (DN), por ejemplo en el cluster del grupo de investigación LISiDi, el DN del certificado de uno de los usuarios (auser1) es: /O=Grid/OU=GlobusTest/OU=simpleCA-c01.cs.uns.edu.ar /OU=cs.uns.edu.ar/CN=auser1. El mapeo DN a usuario local se lleva a cabo a través de un archivo protegido en /etc/grid-security llamado grid-mapfile, y cuyas entradas son del tipo DN UsuarioLocal. Es decir, el usuario grid definido por el subject del certificado, es autorizado por B para actuar como un usuario local en el host B. 60

62 Figura 4.4: Host A autenticado y autorizado en host B Delegación Supongamos que creamos una aplicación y distribuimos los jobs en máquinas remotas y dejamos que a su vez éstos distribuyan sus hijos a otras máquinas bajo su política de seguridad. Para estos casos se utiliza la función de delegación. Esta función de delegación, se constituye en la creación de un proxy en la máquina remota. Este proxy actuará en nombre del propietario del job, emitiendo solicitudes a terceros hosts, en su favor. Creación de un Proxy Supongamos una aplicación en el host A que requiere la creación de un proxy en el host B, los pasos involucrados para crear dicho proxy son los siguientes: 1. Crear una comunicación confiable entre el host A y el host B. 2. La aplicación en A solicita al host B que cree un proxy para delegarle su autoridad. 3. El host B crea la solicitud para el certificado de su proxy, y lo envía de vuelta al host A. 4. El host A firma la solicitud para crear su certificado de proxy usando su clave privada y se la envía de vuelta al host B. 5. El host A envía su certificado al host B. 61

63 Acción de Proxy 1. El proxy envía el certificado original de A y el certificado de proxy al host C. 2. El host C consigue la clave pública a través del procedimiento de validación en cadena: a) El host C consigue el subject y clave pública de A, del certificado original con la clave pública de la CA, con la cual está firmado el certificado original. b) El host C consigue el subject y clave pública del proxy usando la clave pública obtenida en el paso anterior c) El subject es el DN (Distinguished Name). El DN del proxy y el del original, solo difieren en la última porción del string, el DN proxy = DN original + /CN = proxy. En orden a validar el certificado del proxy, C sólo tendrá que chequear que eliminando este último string los DN de ambos certificados son iguales. Si es validado, su proxy es autenticado por el host C y podrá actuar en favor de su creador. 3. El proxy encripta un mensaje de solicitud usando su clave privada y la envía al host C. 4. El host C desencripta el mensaje encriptado usando la clave pública del proxy y obtiene la solicitud. 5. El host C corre la solicitud bajo la autoridad de un usuario local. El usuario es especificado usando un archivo de mapeo, el cual representa el mapeo entre usuarios de grid y usuarios locales. En GT4, este archivo es el archivo grid-map-file que se encuentra en el directorio /etc/grid-security Gráficamente el proceso se muestra en la Figura 4.5. El procedimiento de la figura representa una delegación remota, en la que un usuario crea un proxy en una máquina remota. Existe también un procedimiento para la creación de un proxy en forma local, para la cual GT4 usa el script grid-proxy-init y el demonio gatekeeper, esta forma de delegación se verá mas adelante (ver 4.4.1, pág. 62). Una cuestión importante de observar, es que cuando se crea un proxy, la clave privada del mismo reside en la máquina remota y por lo tanto el super-usuario de esa máquina tiene acceso a esta clave. Esta credencial delegada puede ser susceptible de ataques. En orden a evitar esto, es recomendable que el proxy siga políticas restringidas de su propietario. La estandarización de esta restricción de proxy está a cargo de GSI Work Group of the Grid Forum Security Area. Delegación local Este mecanismo es usado para conseguir un certificado proxy de sesión usando su certificado de usuario de largo termino. El certificado proxy es usado para autenticar al usuario y programas de usuario ante recursos del grid. Este certificado se crea usando el script grid-proxy-init de 62

64 Figura 4.5: Procedimiento de delegación - creación de proxy GT4. Este certificado debe ser creado antes de que los jobs puedan correr en el grid. El certificado proxy es un certificado de sesión con un tiempo de vida corto, el cual es firmado por el certificado del usuario que lo crea. El motivo detrás de este modelo es proveer un mecanismo single sign-on, por el cual un usuario puede loguearse en el grid y realizar varias operaciones sin utilizar su certificado de largo término y por ende sin tener que ingresar su pass-phrase exponiendo su clave privada una y otra vez. El script de Globus que implementa este single sign-on es grid-proxy-init. Este modelo funciona porque se crea una jerarquía de certificados confiables. La jerarquía es como sigue: 1. El recurso grid remoto confía en la CA, esto debido a que el recurso contiene el certificado de la CA en /etc/grid-security/certificates. 2. El recurso grid remoto puede autenticar el certificado de usuario porque está firmado digitalmente por la CA. 63

65 3. El recurso grid remoto puede autenticar el certificado proxy de usuario porque está firmado digitalmente por el certificado de usuario. El comando grid-proxy-init usa las librerías de SSL para crear el certificado que será almacenado en /tmp/<filename> donde <filename> es igual a x509up u< uid >, donde uid es igual al uid (user identifier) del usuario que corrió grid-proxy-init. Los permisos de este archivo son solo de lectura y escritura para el owner del mismo. El certificado proxy es de tiempo de vida corto (por defecto doce horas). El certificado proxy, como todo certificado X.509, contiene un nombre único y una clave pública. El nombre distinguido o subject único es el nombre único del certificado primario concatenado al string CN=proxy. Esta información puede observarse con los comandos grid-cert-info y grid-proxy-info. El archivo x509up u< uid > contiene dos componentes adicionales al sujeto del proxy. Uno de ellos es la clave privada del certificado del proxy y el otro es el certificado de usuario. La clave privada del certificado de proxy está protegida únicamente por los permisos del archivo x509up u< uid >. La clave privada del usuario permanece encriptada en el archivo /$HOME/.globus/userkey.pem, y solo puede ser accedida mediante scripts que solicitan pass-phrase. A continuación se muestra un ejemplo de la ejecución de grid-proxy-init, para la delegación local del usuario auser1: [auser1@c01 ~]$ grid-proxy-init Your identity: /O=Grid/OU=GlobusTest/ OU=simpleCA-c01.cs.uns.edu.ar/OU=cs.uns.edu.ar/CN=auser1 Enter GRID pass phrase for this identity: Creating proxy... Done Your proxy is valid until: Mon Jul 10 23:10: Comunicaciónes grid seguras En Globus Toolkit 4, por defecto las comunicaciones subyacentes están basadas en autenticación mutua usando certificados y SSL\TLS (ver 4.3.2, pág. 52). Las funciones SSL\TLS provistas por OpenSSL encriptan todos los datos transferidos entre grid hosts. Junto con la autenticación mutua, proveen en conjunto los servicios básicos de seguridad de autenticación y confidencialidad. Autenticación mutua Si dos partes tiene certificado, y si ambas confían en las CAs que firmaron los certificados de la una y la otra (ver 4.3.4, pág. 55), entonces las dos partes pueden probarse la una a la otra que ellas son quién dicen ser. Esto es conocido como autenticación mutua. GSI usa Secure Socket Layer (SSL) para su protocolo de autenticación mutua.[sec] El paquete OpenSSL provisto con Globus Toolkit es usado para crear un túnel encriptado usando SSL\TLS entre clientes y servidores del grid. 64

66 La autenticación mutua se hace basada en certificados digitales X.509 en lugar de usar un repositorio de claves. Este proceso es documentado bajo el SSL handshake. SSL handshake Este handshake es responsable de determinar la configuración de SSL e intercambiar las claves públicas, base para el proceso de autenticación mutua. El proceso es el siguiente: 1. El cliente contacta al servidor para iniciar una sesión segura por medio del uso del ID X.509 del certificado digital. 2. El cliente envía automáticamente información que el servidor necesita para comunicarse con el cliente vía SSL (versión de SSL, etc.). 3. El servidor responde automáticamente envíando al cliente el certificado digital del sitio y la información referente a SSL (versión etc.). 4. El cliente examina la información en el certificado digital recibido y verifica: a) El certificado del servidor es válido y posee una fecha válida. b) La CA que despachó y firmó el certificado del servidor, es una CA confiable cuyo certificado es poseído por el cliente. c) La clave pública de la CA despachante, constituída en el cliente, valida la firma digital del servidor. d) El nombre de dominio especificado por el certificado del servidor coincide con el nombre de dominio actual del servidor. 5. Si el servidor puede ser correctamente autenticado, el cliente genera un clave de sesión única para encriptar todas las comunicaciones con el servidor grid usando cifrado simétrico. 6. El usuario encripta la clave generada con la clave pública del servidor y la envía al mismo. 7. El servidor desencripta la clave de sesión recibida con su clave privada. 8. El cliente envía un mensaje al servidor indicándole que los mensajes futuros estarán encriptados por la calve de sesión. El servidor grid envía un mensaje al cliente indicando lo mismo. 9. Se ha establecido una sesión SSL segura. SSL usará cifrado simétrico de ahora en adelante y hasta el fin de la sesión. 10. Hasta aquí el servidor se ha autenticado con el cliente enviando su certificado digital, para que la autenticación se de en ambos sentido, falta que el cliente realice el mismo proceso de autenticación partiendo del envío de su certificado digital al servidor. 11. Una vez completada la sesión, la clave de sesión es eliminada. 65

67 Otras comunicaciones grid Si no se tiene acceso físico al cliente o servidor grid, es necesario que obtener acceso remoto al grid. Para lograr que esta comunicación sea segura es conveniente el uso de un Secure Shell, como SSH en lugar del conocido telnet, que no provee encripción en las comunicaciones Consideraciones adicionales de seguridad Además de la Infraestructura de Seguridad Grid (GSI) planteada por Globus Toolkit, existen muchos otros componentes que forman parte de la infraestructura de seguridad que resguardan el grid. Si bien estos componentes se consideran opcionales, son considerados estándares en muchas redes de producción. A continuación se mencionan algunos de estos componentes Seguridad física El acceso físico a las computadoras que conforman el grid, debe ser controlado. Si las computadoras se encuentran en una habitación abierta y sin control, de nada sirve cuán seguro sea el diseño de las aplicaciones o el método de intercambio de informaicón, ya que por ejemplo, puede ser fácilmente interrumpida la operación apagando la computadora, o desconectándola de la red. El servidor de certificados, o Autoridad Certificante debe encontrarse en una habitación con acceso restringido únicamente al/a los adminstrador/es de la misma. Por otra parte deberá tener alimentación contínua de manera de estar disponible todo el tiempo, por esto es conveniente que la computadora que almacena la CA tenga una fuente de alimentación auxiliar UPS, para cuando el suministro de energía de la red local se ve interrumpido. Para máxima seguridad, el segmento de red donde se encuentran los PKI-servers más sensible, debería estar aislado física y lógicamente del resto de la red. Idealmente, la separación se implementa mediante un firewall que solo permite tráfico relacionado a PKI. Normalmente, el tráfico PKI se reduce al uso de unos pocos puertos TCP/IP Seguridad del sistema operativo La revisión contínua de la configuraciín del sistema operativo es importante. Pretende verificar la correcta implementación de las políticas de seguridad, y eliminar componentes inseguros. Entre los puntos a revisar acerca de la configuración podemos nombrar los siguientes: Remover procesos innecesarios de los servidores. Remover usuario y grupos innecesarios. Verificar y promover el uso de passwords seguros. 66

68 Realizar update de los servidores. Restringir el acceso a los directorios que contienen información relativa a la seguridad, tal como el directorio /.globus en un entorno GT4. Implementar logging y auditoría en el servidor. Implementar protección anti-virus Otros sistemas complementarios Como se mencionó anteriormente el uso de firewalls dentro de un diseño grid ayuda a restringir el acceso a las computadoras, evitando gran parte de comunicaciones potencialmente inseguras y logrando una mejor implementación de las políticas de seguridad. Otro tipo de sistema que es recomendable instalar para aumentar la seguridad, es un sistema de detección de intrusos (IDS). Este software permite generar distintas alertas y acciones cuando suceden determinado hechos, por ejemplo el intento de logueo de personas no autorizadas, la modificación de archivos, la comunicación entre determinados hosts, y demás Políticas y procedimiento de seguridad PKI En un entorno grid, el desarrollo de procedimientos y políticas que complementen la infraestructura de seguridad implementada, cobra gran importancia dado que se puede estar tratando con redes fuera de nuestro control. Estas políticas aportan a la buena administración de los controles de seguridad Autoridad certificante La versión de prueba de autoridad certificante incluída con GT4, provee el software necesario para cumplir con las funciones básicas, desafortunadamente no contempla ningún aspecto acerca de implementación de políticas. Cuando se necesita una CA para ambientes de producción se recomienda recurrir a una solución comercial que incluya lo necesario para poder implementar y administrar políticas y procedimientos de seguridad Algunos cuestionamientos a Globus/GSI Las mayores debilidades de la implementación de la infraestructura de seguridad de GT4, GSI, están relacionadas a problemas de escalabilidad. El mecanismo de autorización de GT4, basado en el archivo grid-mapfile, sufre de graves problemas a medida que el número de usuarios crece. Cada proveedor de recursos deberá ingresar una entrada en el grid-mapfile por cada usuario que este 67

69 autorizado a utilizar dicho recurso, esto se debe hacer manualmente (configuración estática) resultando en un proceso sumamente tedioso y poco flexible.[chi] Por otra parte, el uso de certificados para la autenticación de usuarios también presenta problemas, principalmente derivadas del hecho de que los certificados no fueron diseñados con este fin. Como ejemplo, cuando se determina que es necesario revocar un certificado y negarle la autorización a algún usuario, el procedimiento involucrado no es para nada automático ni instantáneo, lo cual no es bueno desde el punto de vista de la seguridad, además de ser poco flexible y poco escalable. A continuación se presenta una propuesta alternativa al mecanismo de autenticación de usuarios Propuesta ASCI El departamento Accelerated Strategic Computing Initiative (ASCI) es un proyecto multi-laboratorio patrocinado por el Departamento de Energía (DOE) del gobierno de U.S., propone como método de autetnticación de usuarios sobre la red, al sistema Kerberos V5, basados en el hecho que PKI fue diseñado para firmar y encriptar datos y no para autenticar usuarios. Lo cual trae aparejado ciertas complicaciones.[mjd] Globus Toolkit esta construido sobre una capa de abstracción de seguridad, llamada Generic Security Service Application Program Interface (GSSAPI). Kerberos V5 soporta GSSAPI. Más aún, los desarrolladores Globus anticiparon desde un principio que la portabilidad a Kerberos sería una característica importante, y fueron cuidadosos en el diseño para lograr esa portabilidad. El entorno de seguridad ASCI ASCI utiliza PKI inter-site para encripción y firma de objetos, pero no para autenticación de usuarios a través de la red, para lo cual usa Kerberos. Básicamente ASCI se compone de varios sitios, cada uno de los cuales ha implementado una celda DCE 3 (Distributed Computing Environment)y se produce la unión de las celdas mediante cross-cell authentication. Mediante este esquema, un usuario puede loguearse en su home-cell, conseguir una credencial Kerberos/DCE, y usarla para acceder recursos y datos locales o en otros sitios. El entorno ASCI cuenta con varias aplicaciones adaptadas a Kerberos/DCE, como ser SSH con autenticación Kerberos, GSSAPI FTP, DFS (file system distribuido), Generalized Security Framework (GSF) para agregar seguridad Kerberos/DCE en aplicaciones que usan CORBA, IIOP, RMI, etc. La infraestructura de seguridad DCE/Kerberos ASCI ha probado ser un sistema robusto, escalable, adaptable, y administrable para proveer un acceso inter-site seguro. El esquema a continuación (Figura 4.6) muestra las capas de la infraestructura de seguridad ASCI, en las capas superiores la seguridad se provee de manera más transparente que en las capas inferiores. 3 DCE es un entorno que facilita la creación de aplicaciones distribuidas. Su componente de seguridad está basado en el sistema Kerberos. Su principal diferencia con este es la unión del servidor de autenticación y el servidor de tickets en un único servidor de seguridad. 68

70 Figura 4.6: Capas de la infraestructura de seguridad ASCI Generic Security Service Application Program Interface (GSSAPI) GSSAPI es el factor común entre el sistema de seguridad subyacente a Globus y la infraestructura Kerberos. GSSAPI es un estándar de IETEF que especifica cómo dos partes pueden adquirir credenciales de seguridad y usarlas para establecer un contexto compartido seguro sobre canales de comunicación no confiables. La estricta adherencia de Globus al uso de GSSAPI en todas sus llamadas, hace que en teoría sea posible portar aplicaciones que usan GSI, a cualquier infraestructura de seguridad que provea GSSAPI. Algunos sistemas de seguridad que proveen interfase GSSAPI son Kerberos, DCE, Globus/GSI, entre otros. GSSAPI se encuentra sobre una variedad de protocolos de red. Para que un cliente y un servidor que usan GSSAPI puedan interoperar deberán utilizar protocolos y mecanismos compatibles (ej. misma versión Kerberos, etc.). Uno de los propósitos más importantes de GSSAPI es proveer una abstracción simplificada para seguridad. Por ejemplo, el handshake GSSAPI del lado del cliente es el siguiente: 1. La aplicación asume que el usuario o procesos esta logged in, por ejemplo a través de grid-proxy-init o kinit. 2. La aplicación invoca gss_acquire_cred() para conseguir un credential handle, para manejar un objeto. 3. La aplicación invoca gss_init_sec_context(), el resultado de esta operación puede variar, cuando el código sea COMPLETED, la aplicación tiene un contexto seguro en el cual puede firmar y encriptar subsecuentes mensajes. De esta manera el programador no necesita ocuparse de los detalles arcanos de las claves y certificados, o con protocolos complejos como el SSL handshake, o adquisisión de tickets Kerberos. Si bien la abstracción es importante, el propósito principal de GSSAPI es proveer una capa de portabilidad. GSSAPI da soporte para Kerberos y para GSI, pero además esa diseñada para crear e incorporar nuevos protocolos. 69

71 4.8. Algunas conclusiones Se han presentado las necesidades básicas de una infraestructura de seguridad para un sistema grid. En particular se describió la implementación propuesta por Globus para dicha infraestructura, alguna de sus limitaciones y una variante propuesta por ASCI. De todo lo anterior podemos concluir que si bien la implementación propuesta por Globus Toolkit comprenden las necesidades básicas a cubrir en lo que a seguridad respecta, algunos de sus componentes deberán ser reemplazados en ambientes de producción (como el caso de SimpleCA) y, otros deberán ser reevaluados para obtener una mejora en cuestiones de escalabilidad, como es el caso del sistema de autenticación de usuarios. Líneas futuras de investigación pueden estar orientadas a la evaluación de nuevos sistemas de autenticación de usuarios que se adapten al la masividad inherente al concepto de grid. 70

72 Capítulo 5 Gestión de Datos en un entorno Grid Globus Toolkit provee un numero de componentes para hacer manejo de datos. A continuación se dará información detallada de los componentes que se encargan de esta función en las siguientes secciones. Los componentes disponibles para manipulación de datos caen en dos categorías básicas: Translación de datos y Replicación de datos. Hay dos componentes relacionados con el movimiento de los datos en Globus Toolkit: la herramienta Globus GridFTP y el servicio Globus Reliable File Transfer (RFT). En cuanto a componentes de Replicación de Datos, tenemos al Replica Location Service (RLS) GridFTP GridFTP es un protocolo definido por la recomendación GFD.020 del Global Grid Forum, las RFC 959, RFC 2228, RFC 2389 y anteriormente por un borrador del grupo de trabajo IETF FTP. Este protocolo provee una forma segura, robusta, rápida y eficiente para transferir datos (especialmente grandes volúmenes de ellos). Globus Toolkit provee la implementación mas usada comúnmente de este protocolo, aunque existen otras implementaciones (principalmente ligados a sistemas internos propietarios). Globus Toolkit provee: una implementación de servidor llamada globus-gridftp-server, un cliente de linea de comandos llamado globus-url-copy y un conjunto de librerías de desarrollo. Si se quiere acceder a datos que otros pusieron a disposición, se necesita usar un cliente de GridFTP. El cliente de Globus es capaz de acceder a datos por medio de un amplio rango de protocolos (http, https, ftp, gsiftp y file). Como observamos anteriormente, este no es un cliente interactivo, sino una interface de linea de comandos, adecuado para hacer scripting. 71

73 El formato general de invocación al cliente es el siguiente: globus-url-copy source_url destination_url Las URLs de origen/destino serán normalmente una de las siguientes: file:///path/to/my/file si se está accediendo a un archivo en el sistema de archivos accesible para el host en el que se está corriendo el cliente. gsiftp://hostname/path/to/remote/file si se está accediendo a un archivo desde un servidor GridFTP. Con este cliente nos alcanza para poner/obtener un archivo en un servidor GridFTP, y para mover archivos entre servidores GridFTP (Third party transfer). Por ejemplo, el siguiente comando: globus-url-copy gsiftp://remote.host.edu/path/to/file \ file:///path/on/local/host puede transferir un archivo desde una máquina (servidor) remota a una ubicación localmente accesible especificada en la segunda URL. Mientras que: globus-url-copy file:///path/on/local/host \ gsiftp://remote.host.edu/path/to/file hace la tarea inversa, esto es, enviar un archivo localmente accesible a un servidor GridFTP remoto. Por último, se podría hacer lo siguiente: globus-url-copy gsiftp://remote.host1.edu/path/to/file \ gsiftp://remote.host2.edu/path/to/file hace una transferencia entre el servidor GridFTP en el host1 y el servidor GridFTP en el host2. Es importante saber que es necesario tener un certificado para usar el comando globus-url-copy Experiencia con GridFTP en el LISiDi Se prob el comando globus-url-copy en el cluster del Laboratorio de Investigación en Sistemas Distribuidos (LISiDi) en la Universidad Nacional del Sur, mediante la experiencia que detallaremos en el resto de esta sección. En primer lugar es necesario instalar GridFTP en los nodos del grid. Como está instalación fue realizada de forma automática durante la instalación del Globus Toolkit, continuamos con la configuración del servidor. Como primera medida, nos aseguramos que el nombre de servicio gsiftp estuviera asignado al puerto TCP 2811 en el archivo /etc/services, como muestra la figura

74 Figura 5.1: Puerto TCP asociado al servicio. De no haber estado esta linea en /etc/services, hubieramos tenido que agregarla manualmente para que el servidor de GridFTP hubiera funcionado. Luego creamos el archivo /etc/xinetd.d/gsiftp con el contenido mostrado en la figura 5.2. Figura 5.2: Contenido del archivo /etc/xinetd.d/gsiftp. Como último paso de configuración, reiniciamos el demonio xinet con el comando service xinetd restart. Si no se reporta ningún error, el servidor de GridFTP estará listo para recibir un pedido de agregar/copiar un archivo. También se hubiera podido iniciar el servidor tipeando globus-gridftp-server -S en la linea de comandos. Una vez configurado esto, estamos en condiciones de ejecutar el comando globusurl-copy para realizar una transferencia. Para ello, seguimos los siguientes pasos: 1. Logearse en un nodo grid (por ejemplo c01.cs.uns.edu.ar del cluster) como un usuario con certificado de usuario grid (por ejemplo auser1 ). 2. Tipear en la consola grid-proxy-init para autenticarse (respondiendo al correspondiente passphrase) y crear el certificado de proxy (ver figura 5.3). 3. Tipear el comando globus-url-copy especificando la dirección origen y destino del archivo. En la figura 5.4 se muestra un ejemplo ejecutado en el cluster donde se crea un archivo con un contenido arbitrario y se copia en otro archivo en el mismo host, pero utilizando al servidor GridFTP (en lugar de hacerlo con el comando cp de Linux) 4. Intentamos una transferencia third-party involucrando un servidor en otro nodo (en este ejemplo, c09.cs.uns.edu.ar). En la figura 5.5 se muestra la creación del 73

75 Figura 5.3: Salida del comando grid-proxy-init. Figura 5.4: Prueba local de globus-url-copy. archivo y la transferencia desde c01 hasta c09 con su correspondiente verificación. Figura 5.5: Transferencia third party con globus-url-copy Reliable File Transfer (RFT) Aunque globus-url-copy y GridFTP en general es un conjunto de herramientas bastante poderoso, posee características que no siempre son óptimas. Primero, el protocolo GridFTP no es un protocolo de web service (no emplea SOAP, WSDL, etc). Segundo, GridFTP requiere que el cliente mantenga una conexión con un socket al servidor durante la transferencia. Para transferencias largas esto puede no ser conveniente, por ejemplo si se está ejecutando desde una laptop. Aunque globus-urlcopy usa las características de robustez de GridFTP para recuperarse de fallas remotas (fallas en la red o en un servidor, entre otras), una falla en el cliente en la máquina del 74

76 cliente significa que la recuperación no es posible debido a que la información necesaria para la recuperación es mantenida en la memoria del cliente. Lo que es necesario para manejar estas situaciones es una interfaz de servicio basada en protocolos de web services que preserve el estado de la transferencia en almacenamiento estable. El componente que implementa Globus para esta situación es el servicio Reliable File Transfer (RFT). RFT es un componente WSRF que provee planificación de jobs como funcionalidad para los movimientos de datos. Usa mensajes SOAP estándar sobre HTTP para delegar y manejar un conjunto de transferencias third party GridFTP. Simplemente, se provee una lista de URLs de origen y destino, y luego el servicio escribe la descripción de job correspondiente en una base de datos y luego mueve los archivos en beneficio del usuario. Se proveen métodos para consultar el estado de la transferencia, o se pueden usar herramientas WSRF (también provistas por Globus) para subscribirse a notificaciones de eventos de cambio de estado. Globus provee la implementación que es contenida en el contenedor de web services y un cliente muy sencillo, aunque también existen clases de Java disponibles para desarrollo. Se debe proveer un archivo con la descripción de las transferencias a realizar. Un ejemplo de este tipo de archivo se puede encontrar en la siguiente ruta: $GLOBUS_LOCATION/share/globus_wsrf_rft_client/ Mas adelante, mostraremos un ejemplo completo de este archivo, junto con la explicación de la transferencia ejecutada usando el cliente de comando de linea rft Problemas comunes y sus soluciones Trucos Siempre tener un proxy valido antes de usar clientes RFT de linea de comando. Asegurarse de proveer al cliente de opciones adecuadas, y especialmente para el tiempo de terminación del servicio, así el recurso generado para realizar la transferencia no es destruido antes de finalizar las transferencias. Por defecto este tiempo es de 60 minutos. Tolerancia a fallas y recuperación RFT usa PostgreSQL para crear puntos de inspección (checkpoints), usando una forma de marcas de recuperación hacia las cuales se puede restaurar el estado de la transferencia en caso de ocurrir una falla temporal en la transmisión. Se ha testeado la capacidad de recuperación de RFT ante casos de caidas de servidor en la fuente y/o destino durante una transferencia, fallas en la red, falla en el contenedor (cuando la máquina corriendo el contenedor se cae), fallas del sistema de archivos, y otros casos mas. A continuación se muestra una descripción mas detallada de la tolerancia de fallas y recuperación: 75

77 Fallas en la fuente o el destino de GridFTP: En este caso RFT vuelve a intentar la transferencia hasta alcanzar una cantidad configurable máxima de intentos. Si una falla ocurre en el medio de una transferencia, RFT toma la última marca de reinicio que es almacenada en la base de datos por esa transferencia y la usa para retomar la transferencia desde el punto en que fallo en lugar de volver a comenzar desde el comienzo del archivo. Esta falla es tratada a nivel del contenedor, esto es, todos los transferencias yendo desde o hacia ese servidor serán retrocedidas y reintentadas. Fallas en la red: A veces esto ocurre debido a una sobrecarga en la red o por alguna otra razón, los paquetes se pierden o las conexiones expiran. Esta falla es considerada una falla temporal y RFT reintenta la transferencia para ese caso en particular y no para todas las transferencias del contenedor como sucedía en el caso anterior. Fallas en el contenedor: Este tipo de fallas ocurre cuando la máquina corriendo el contenedor se cae o cuando el contenedor es reiniciado mientras existen transferencias activas Testeo del RFT en el LISiDi Luego de haber configurado y testeado el componente de GridFTP, estamos en condiciones de configurar y utilizar el servicio de RFT de GT4.0. RFT será usado por WS-GRAM que será explicado en el capítulo siguiente. Como primer paso necesitamos configurar el PostgreSQL que es el servidor de base de datos que utiliza el RFT de GT4.0. para almacenar los estados de las transferencias en curso. Si no se tiene instalado el PostgreSQL es necesario instalarlo primero. En laboratorios en Sistemas Distribuidos de otras universidades de nuestro pais se ha podido utilizar RFT con MySQL, pero para ello es necesario modificar el archivo XML que especifica el driver JDBC que permite la conección con la base de datos, que por defecto viene para ser usado con PostgreSQL. Comenzamos iniciando el servidor de base de datos ejecutando, como usuario root el siguiente comando: service postgresql start Si se quiere evitar iniciar el servidor cada vez que se reinicia el sistema, se puede tipear a continuación el siguiente comando: chkconfig postgresql on RFT requiere que PostgreSQL acepte conexiones desde la red. Para esto fue necesario editar el archivo de configuración para permitir conexiones desde la red. Para la versión 8 de PostgreSQL (que es la usada por el cluster del LISiDi) la edición consiste en descomentar la linea que dice listen_addresses = * para permitir otras 76

78 conexiones que no sean con localhost (ver figura 5.6). Pero si se usa la versión 7 de PostgreSQL, la modificación de este archivo consiste en cambiar el valor de false a true en la variable tcpip_socket. Figura 5.6: Linea a modificar en el /var/lib/pgsql/data/postgresql.conf También es necesario agregar una linea con la siguiente forma en el archivo /var/lib/pgsql/data/pg_hba.conf: host all all (IP addr of RFT host) trust en la sección de conexiones locales IPv4 como se muestra en la figura 5.7. Figura 5.7: Linea a agregar en pghba.conf Luego de esto se debe reiniciar el servidor de PostgreSQL con el comando service postgresql restart. Ahora, para poder ejecutar el comando rft fue necesario crear una base de datos en cada uno de los hosts del cluster y también las tablas correspondientes. 77

79 Para crear la base de datos que RFT usa en PostgreSQL seguimos los siguientes procedimientos: 1. Como usuario postgres ejecutamos el siguiente comando para crear la base de datos RFT: createdb rftdatabase 2. Creamos las tablas usando los scripts incluidos en el Globus Toolkit 4 como muestra la figura 5.8. Figura 5.8: Creación de las tablas 3. Registramos el usuario Globus como superusuario en el servidor de PostgreSQL como se muestra en la figura 5.9. Figura 5.9: Creación del usuario globus Para verificar que el RFT fue instalado exitosamente completamos el siguiente procedimiento: 1. Nos logeamos en un nodo grid (por ejemplo, c01.cs.uns.edu.ar) como usuario globus. 2. Iniciamos un contenedor seguro, como se muestra en la figura

80 Figura 5.10: Ejecución de un container seguro 3. En otra consola, nos logeamos como un usuario con certificados de usuario grid (en este ejemplo, auser1 ). Además es necesario autenticarse para acceder al contenedor con el comando grid-proxy-init. 4. Creamos un archivo de descripción de RFT como el que se muestra en la figura 5.11 en la página Creamos el archivo a transferir con cierto contenido y ejecutamos el comando rft para realizar la transferencia como se puede apreciar en la figura 5.12 en la página 81, incluida la comprobación de que el archivo llegó al otro host (c09.cs.uns.edu.ar en este caso) Replica Location Service (RLS) RLS es una herramienta que provee la habilidad de mantener el rastro de una o mas copias, o réplicas, de archivos en un entorno Grid. Esta herramienta, que es incluida en el Globus Toolkit, es especialmente útil para usuarios y aplicaciones que necesitan encontrar donde están localizados los archivos existentes en el Grid. RLS es un registro simple que mantiene el rastro de donde existen las réplicas sobre un sistema de almacenamiento físico. Los usuarios o servicios registran los archivos en RLS cuando son creados. Luego de esto, los usuarios pueden consultar los servidores de RLS para encontrar esas réplicas. 79

81 Figura 5.11: Archivo de descripción rfttest.xfr Es un registro distribuido, esto es, consiste de múltiples servidores en diferentes sitios. Distribuyendo el registro RLS, se puede incrementar el escalamiento del sistema en conjunto y almacenar mas mapeos de los que sería posible en un catálogo centralizado. También se evita crear un único punto de falla en el sistema de manejo de datos en el Grid. Sin embargo, si se desea, RLS se puede implementar como un servidor centralizado. Antes de explicar RLS en detalle, es necesario definir un par de términos: Un nombre de archivo lógico es un identificador único para el contenido de un archivo. Un nombre de archivo físico es la locación de una copia del archivo en un sistema de almacenamiento. Estos términos son ilustrados en la figura 5.13 en la página 82. El trabajo de RLS es mantener asociaciones, o mapeos, entre nombres lógicos de archivos y uno o mas nombres físicos de réplicas correspondientes al archivo. Un usuario puede proveer un nombre lógico de archivo a un servidor RLS y pedir por todas los nombres físicos de archivo registrados de las réplicas. El usuario también puede consultar al servidor RLS para buscar el nombre lógico de archivo asociado con una locación física de un archivo particular. 80

82 Figura 5.12: Salida del comando rft Además, RLS permite a los usuarios asociar atributos o información descriptiva (como tamaño o checksum) con un nombre lógico o físico de archivo registrado en el catálogo. Los usuarios también pueden consultar al RLS basados en estos atributos Un ejemplo usando RLS Un ejemplo de un sistema que usa RLS como parte de su infraestructura de manipulación de datos es el proyecto LIGO (Laser Interferometer 1 Gravitational Wave Observatory). Los científicos de LIGO tienen instrumentos en dos sitios que están destinados a detectar la existencia de ondas gravitatorias. Durante una corrida de experimentos científicos, cada sitio de instrumentos LIGO produce millones de archivos de datos. Los científicos en los otros ocho sitios quieren copiar estos grandes conjuntos de datos a sus sistemas de almacenamiento locales así pueden ejecutar análisis científicos sobre esos datos. Por lo tanto, cada archivo de datos LIGO puede estar replicado hasta en diez locaciones físicas en el Grid. LIGO establece servidores RLS en cada sitio para registrar mapeos locales y para recolectar información acerca de mapeos en otros sitios LIGO. Para encontrar una copia de un archivo, un científico solicita el archivo al sistema de manejo de datos de LIGO, llamado Lightweight Data Replicator (LDR). LDR consulta el RLS para encontrar si hay una copia local del archivo; si no es así, RLS le dice al sistema de manejo de datos donde existe el archivo en el Grid. Luego, el sistema LDR genera una solicitud para copiar el archivo al sistema de almacenamiento local y registra la nueva copia en su servidor RLS local. 1 Un interferómetro es un instrumento que bifurca los rayos de luz para producir interferencia y medir así la distancia a los astros 81

83 Figura 5.13: Ejemplo de la asociación entre un nombre lógico de un archivo y tres réplicas en distintos sitios de almacenamiento Componentes del Replica Location Service El diseño de RLS consiste de dos tipos de servidores: el Local Replica Catalog (LRC) y el Replica Location Index (RLI). El LRC almacena mapeos entre nombres lógicos para los items de datos y las localizaciones físicas de las réplicas asociadas a ese nombre lógico. Los clientes consultan el LRC para descubrir réplicas asociadas a un nombre lógico. El escenario RLS mas simple consiste de un simple LRC que actúa como un registro de mapeos para uno o mas sistemas de almacenamiento. Para un escenario RLS distribuido, se provee también un servidor de alto nivel RLI. Cada servidor RLI recolecta información sobre los mapeos de nombres lógicos almacenados en uno o mas LRCs. Un RLI también responde a las consultas sobre esos mapeos. Cuando un cliente quiere descubrir réplicas que pueden existir en múltiples locaciones, el cliente presentará esa consulta a un servidor RLI en lugar de a un Catálogo Local de Réplicas (RLC) individual. Como respuesta a una consulta, el RLI devolverá una lista de todos los LRCs que conoce que contiene mapeos para el nombre lógico contenido en la consulta. El cliente, luego, consulta a estos LRCs para encontrar las locaciones físicas de esas réplicas. La figura 5.14 ilustra un escenario distribuido para RLS. La información es enviada desde los LRCs a los RLIs usando protocolos de actualización de estado suave (softstate). Cada RLC periódicamente envía información sobre sus mapeos de nombres lógicos a un conjunto de RLIs. Los RLIs recolectan esta información de mapeos y responden a las consultas respetando estos mapeos. La información en los RLIs expira y es refrescada periódicamente por subsecuentes actualizaciones. Una ventaja de usar estos protocolos de actualización es que si un RLI falla y luego reanuda su operación, su contenido puede ser reconstruido usando estas actualizaciones. Debido a que cada LRC puede contener millones de mapeos de nombres lógicos, las actualizaciones desde LRCs a RLIs pueden tornarse grandes. Enviarlas a través de 82

84 Figura 5.14: Ejemplo de un RLS distribuido la red puede ser lento, especialmente en un area grande; cuando las actualizaciones arriban a un RLI, pueden consumir espacio considerable allí. Una opción para hacer estas actualizaciones mas eficiente es comprimir su contenido. Hay disponibles varias estrategias de compresión. El esquema que fue elegido para RLS está basado en el filtro de compresión de Bloom. Cada LRC periódicamente crea un mapa de bits que resume su contenido aplicando una serie de funciones hash a cada nombre lógico registrado en el LRC y seteando los correspondientes bits en el mapa de bits Opciones de Configuración Se determina el desempeño y la confiabilidad de un RLS distribuido por el numero de Catálogos de Réplicas Locales (LRC) y de servidores de índice de Localización de Réplicas (RLI) y la forma en que se configuran las actualizaciones entre LRCs y RLIs. Por ejemplo, se mejora la confiabilidad configurando el sistema de forma que cada LRC actualiza múltiples RLIs. En la práctica, las implementaciones actuales de sistemas RLS son relativamente pequeños. Por ejemplo, el proyecto LIGO establece servidores RLS en diez sitios. Para implementaciones en esta escala el servicio RLS es a menudo desarrollado en una configuración totalmente conectada, con un LRC y un servidor RLI en cada sitio, y con todos los LRCs enviando actualizaciones a todos los RLIs. Esta configuración tiene la ventaja de que cada sitio tiene una imagen completa de las réplicas en el sistema distribuido. Para sistemas grandes, sin embargo, esta configuración es improbable que escale bien debido a que requiere enviar un numero grande de actualizaciones entre los servidores y almacenarlas en cada RLI. Por ejemplo, en un sistema con cientos de sitios RLS, una configuración totalmente conectada podría requerir que cada sitio envíe y reciba cientos de actualizaciones. En estos sistemas grandes es probable que el mismo esté particionado de forma que cada RLI pueda recibir actualizaciones solo de un subconjunto de los LRCs. Idealmente, el manejo de un RLS distribuido podría ser automatizado y autoconfigurado, de forma que los LRCs y los RLIs se descubran entre si y las actualizaciones entre ellos sean redistribuidas automáticamente para balancear la carga cuando los 83

85 servidores se unan o dejen el sistema. Mientras se están estudiando estos enfoques para manejo automatizado de la membresía, la implementación actual de RLS usa una configuración simple y estática de servidores LRC y RLI. Un administrador puede manualmente cambiar el patrón de actualizaciones entre los servidores RLS y los servicios de Consistencia de Réplicas RLS es una herramienta medianamente simple que provee registración y descubrimiento de archivos. Tiene la intención de ser solo una parte de un sistema global de manejo de datos en Grids. Aquellos que consideran si conviene usar RLS deben entender que funcionalidad provee el sistema y cual no. Una de las suposiciones mas comunes que los nuevos usuarios hacen sobre RLS es que, cuando una nueva réplica es registrada en RLS, el sistema chequea para asegurarse que la entrada registrada es una réplica válida de un archivo existente. En realidad, RLS no realiza estos chequeos de correctitud o consistencia sobre las nuevas entradas. RLS permite a los usuarios registrar mapeos entre nombres lógicos y localizaciones físicas sin ninguna verificación de que los archivos físicos que se están registrando como réplicas sean en realidad copias de algún otro archivo. Asimismo, si las réplicas registradas son modificadas de forma que ya no son copias válidas de algún otro archivo, RLS no detectará estos cambios ni tomará acción alguna. En lugar de ello, RLS confía en el manejo de datos de nivel superior o en los servicios de consistencia que realizan estas funciones. Existen varias razones para esta elección de diseño. Una es la simplicidad y la eficiencia de proveer un registro en el que no sea requerido realizar controles de consistencia sobre los archivos registrados, que puede ser costoso en tiempo. Por ejemplo, un servicio que garantiza consistencia puede calcular sumas de verificación para todas las réplicas y verificar que coincidan. Proveer garantías de consistencia, por consiguiente, crea sobrecarga adicional para el sistema que puede limitar su desempeño. En la práctica, proveer una verificación de consistencia de alto nivel durante la registración de réplicas no es requerido por muchas aplicaciones debido a que a menudo solo un pequeño conjunto de usuarios altamente confiables es habilitado para publicar datos. Estos usuarios privilegiados no necesitan verificar que los archivos registrados son en realidad réplicas porque los usuarios controlan el proceso entero de publicación. Ellos típicamente necesitan publicar un gran número de archivos rápidamente y no toleran sobrecargas extras asociadas con la realización de operaciones de consistencia como el cálculo de sumas de comprobación en cada registración de archivos. Otra razón para no forzar la consistencia en las réplicas en RLS es que los usuarios pueden tener diferentes definiciones de lo que constituye una réplica válida. Para algunos usuarios, las réplicas son una copia exacta byte a byte de alguna otra. Para otros, dos archivos pueden ser considerados réplicas si hay diferentes versiones del mismo archivo o si los archivos contienen el mismo contenido pero en diferente formato, por ejemplo, versiones comprimidas y no comprimidas del mismo archivo. Es por eso que en RLS se deja la libertad de elección en la definición de réplica. Por estas razones se deja el control de consistencia a servicios de nivel superior, que pueden realizar estos chequeos antes o después que las réplicas son registradas en 84

86 RLS. Si estos servicios encuentran que réplicas registradas son inválidas, removerán los mapeos de réplica asociados a la misma de RLS OGSA-DAI El proyecto OGSA-DAI (Open Grid Service Architecture - Data Access and Integration) está relacionado con la construcción de un middleware para asistir con el acceso y la integración de los datos provenientes de fuentes de datos separadas via el Grid. Es un componente técnico preliminar. Esto es, la implementación es funcional, pero no necesariamente completa, y su impelmentación e interfaces pueden cambiar en el futuro. OGSA-DAI provee un marco de trabajo para el servicio de datos puro en Java para acceder e integrar recursos de datos (como Bases de datos relacionales, de archivos y XML) sobre Grids. Hacia ese fin, OGSA-DAI: Expone capacidades intrínsecas (como la habilidad de realizar consultas SQL sobre un recurso relacional o evaluar declaraciones XPath sobre colecciones XML) a través de interfaces basadas en web services, permitiendo de esta manera a los recursos de datos ser incorporados fácilmente como ciudadanos de primer clase en los grids. Permite que funcionalidad adicional sea implementada en el servicio (como la transformación de datos saliendo de un recurso de dato) de manera de evitar movimientos de datos innecesarios. Provee una forma compacta de manejar potenciales interacciones múltiples con un servicio dentro de un único pedido via un documento XML, llamado documento de ejecución (perform document) donde los datos pasan entre diferentes conjuntos de actividades que operan sobre el flujo de datos saliendo de, o yendo hacia, un recurso de dato. Permite a los desarrolladores agregar fácilmente o extender funcionalidades dentro de OGSA-DAI. El documento de ejecución, y el marco de trabajo subyacente, son extensibles permitiendo agregar funcionalidad adicional, o personalizando funcionalidad existente, y aún opera dentro del mismo marco de trabajo Facilita la provisión de capacidades de integración de datos desde varias fuentes para obtener la información requerida. La distribución WSRF de OGSA-DAI fué diseñada para trabajar con el Globus Toolkit 4; una distribución WS-I también está disponible en el sitio web de OGSA- DAI ( que está diseñado para trabajar con las versiones de la infraestructura de servicios web UK OMII. Finalmente, también está disponible una distribución basada en OGSI de OGSA-DAI para trabajar con las versiones de GT3.2. Una cosa para observar es que estas versiones mencionadas no están diseñadas para interoperar. A continuación se nombrarán las características nuevas en la versión GT4.0: 85

87 El acceso a los datos es provisto via un OGSA-DAI data service. Para los que han usado previamente la versión OGSI, este servicio mezcla las capacidades de los servicios GDSF (Grid Data Service Factory) y GDS (Grid Data Service) los roles de metadatos y configuración del GDSF y los aspectos de procesamiento de metadatos y documentos de ejecución. Cada servicio de datos expone cero o mas recursos de servicio de datos. Un recurso de servicio de datos maneja exposición de, e interacción con un recurso de dato. Ofrece capacidades análogas a un GDS en la versión OGSI de OGSA- DAI. Permite que múltiples recursos de datos sean accedidos a través de un solo servicio. Los identificadores de recurso de servicio de datos, disponible desde la referencia WS-Addressing endpoint del servicio de datos, permite a un cliente apuntar a un recurso de servicio de dato específico. Se provee una operación listresources() para que un servicio de datos liste todos los identificadores de los recursos de servicio de dato que expone. Los identificadores devueltos por un servicio de datos pueden ser usados por el cliente para obtener metadatos y otra información, acerca del recurso de servicio de datos correspondiente a ese identificador. El acceso a los metadatos (como por ejemplo, esquema de base de datos usado, estado de requerimiento, etc.) es provisto por una implementación de la especificación WS-ResourceProperties. El acceso a información de versión del servicio de datos OGSA-DAI está disponible a través de la operación getversion(). Una versión WSRF del OGSA-DAI GridDataTransport porttype soporta entrega asíncrona entre servicios de datos. OGSA-DAI depende del componente de GT4.0 Java WS Core para su funcionamiento. En cuanto a software externo (Third Party Software) al GT4.0, tenemos que necesita de Java y Jakarta ANT 1.5. Por último, dependiendo del recurso de dato subyacente que el OGSA-DAI exponga pueden ser necesarios drivers JDBC correspondiente para el acceso a bases de datos relacionales como MySQL, PostgreSQL, SQLServer, Oracle y DB2 ; o los drivers XMLDB correspondientes para bases de datos XML como por ejemplo XIndice; o un motor de busqueda contra archivos planos como Jakarta Lucene. Para finalizar, en cuanto a los estándares asociados a OGSA-DAI, diremos que, en esencia, OGSA-DAI usa el componente Java WS Core de Globus Toolkit; por lo tanto cualquier estándar que se aplica al mismo es aplicable de igual forma a OGSA-DAI. Además, el marco de trabajo que se utiliza está basado en una especificación GGF DAIS presentada en el GGF 7: Especificación de servicios de datos en Grid. 86

88 5.5. Data Replication Service (DRS) El DRS, al igual que OGSA-DAI, es un componente preliminar provisto por el Globus Toolkit 4.0. Es un servicio de alto nivel de manejo de datos que está construido sobre la base de dos componentes de manejo de datos de Globus: el servicio RFT y el RLS. La función del DRS es asegurar que un conjunto especificado de archivos existe en un sitio de almacenamiento. El DRS comienza consultando RLS para descubrir donde existen los archivos deseados en el Grid. Después que los archivos son localizados, el DRS crea una solicitud de transferencia que es ejecutada por RFT para crear replicas locales de esos archivos de dato. Después que la transferencia se completa, DRS registra las nuevas réplicas con RLS. DRS es implementado como un Web service y cumple con las especificaciones WSRF. Cuando se recibe una solicitud DRS, este crea un WS-Resource (llamado recurso replicador ) que es usado para mantener el estado sobre cada archivo que está siendo replicado, incluyendo que operaciones sobre el archivo han sido exitosas o han fallado. 87

89 Capítulo 6 Administración de ejecución 6.1. Introducción GRAM Las herramientas y componentes de administración de ejecución, se encargan del inicio, monitoreo, administración, planificación y/o coordinación de los cómputos remotos. GT4 soporta la interfase de Grid Resource Allocations and Management (GRAM) como mecanismo básico para estos propósitos. El servidor GRAM de GT4 es implementado normalmente en conjunto con el servicio de delegación y RTF (Reliable File Transfer) para soportar data staging, delegación de credenciales y, monitoreo y administración del cómputo de una manera integrada. Se proveen las APIs para el cliente en C, Java y Phyton, así como también herramientas de línea de comandos. [GRAMuser] GT4 incluye dos implementaciones diferentes de GRAM: WS GRAM, construida sobre la tecnología de servicios web y es la implementación recomendada para lograr mayor escalabilidad y además porque es la que provee soporte para los mecanismos WS-security. Pre-WS GRAM es la implementación anterior, introducida con la versión dos de Globus Toolkit. Los recursos de computación Grid están operados normalmente bajo el control de planificadores locales, los cuales implementan políticas de asignación y prioridad mientras que optimizan la ejecución de todos los trabajos despachados para lograr una mayor eficiencia y performance total. GRAM no es un planificador de recursos, sino un programa que en base a protocolos permite la comunicaicón con un amplio rango de planificadores locales usando formato de mensajes estándar. WS GRAM es un grid service que permite la ejecución remota y la administración del estado de los trabajos. Cuando un cliente quiere ejecutar un trabajo, la solicitud es enviada a un host remoto en un mensaje SOAP (Simple Object Access Protocol), en donde será manejada por el servicio WS GRAM. Dicho servicio es capaz de enviar estas solicitudes a los planificadores locales tales como Platform LSF o Altair PBS. El servicio WS GRAM retorna información acerca del estado de los trabajos utilizando WSNotification. [JMF+05] 88

90 WS GRAM puede colaborar con el servicio RFT (Reliable File Transfer) para instanciar archivos requeridos por los trabajos, con este fin deberán delegarse al servicio RTF credenciales válidas mediate el servicio de Delegación Tipos de trabajos Usualmente los trabajos que los usuarios ejecutan pueden requerir instanciación coordinada de datos dentro del recurso en el que se ejecutará y previo a la ejecución del mismo, y fuera de dicho recurso a continuación de la finalización de la ejecución. Algunos usuarios, particularmente los interactivos, se benefician de el acceso a los archivos de datos de salida mientras el trabajo está corriendo. Tambiés con frecuencia es necesario tener la capacidad de monitorear el estado de ejecución de los trabajos despachados. Para trabajos en los que una o mas de las características mencionadas son necesarias GRAM es una solución. GRAM no está pensado para servir como interfase para llamadas a procedimientos remotos (RPC) a aplicaciones que no requieren muchas de las características mencionadas anteriormente, más aun el modelo de su interfase y su implementación puede ser demasiado costoso para tales usos. El servicio WS GRAM reduce su costo a medida que la tecnología de servicios web subyacente mejora, aun así sus protocolos involucran múltiples etapas para soportar estas características avanzadas, que son innecesarias en aplicaciones RPC simples. El entorno WSRF subyacente utilizado por WS GRAM deberá ser considerado como una solución en sí mismas para aplicaciones lightweight compartidas. En otras palabras, si una aplicación requiere el transporte de entradas y salidas modestas, es de tipo stateless y será invocada múltiples veces, entonces es una buena candidata a ser expuesta directamente como web-service Componentes de la arquitectura GRAM no tiene estructura monolítica sino que se compone de múltiples componentes. GRAM Service suite: la administración de trabajos con GRAM hace uso de múltiples servicios: Los servicios de administración de trabajos representan, monitorean y controlan todo el ciclo de vida del trabajo. Estos servicios son software específico de job-management provistos por la solución GRAM. Los servicios de transferencia de archivos soportan el file staging hacia y desde el recurso de cómputo. GRAM hace uso de servicios existentes en lugar de proveer soluciones redundantes. Los servicios de delegación de credenciales son utilizados para controlar la delegación de derechos entre los elementos de la arquitectura GRAM, basados en los requerimientos de las aplicaciones de los usuarios. Nuevamente, GRAM hace uso de una infraestructura más general en lugar de proveer una solunción redundante. 89

91 Modelo de servicio: en el caso de WS GRAM, el entorno de desarrollo de software de Globus Toolkit y en particular el núcleo WSRF, es utilizado para implementar las comunicaciones distribuidas y el estado de servicio. Por otra parte en el caso de pre-ws GRAM, se utilizan el demonio gatekeeper y la librería GSI para comunicaciones y servicio de despacho. Adaptadores para planificadores: GRAM provee una arquitectura de scripts para permitir la extensión con adaptadores para lograr el control de una variedad de planificadores locales. Estos adaptadores son scripts escritos en el lenguaje de programación Perl, implementan el despacho específico del sistema, detección de terminación de trabajo, cancelación de trabajos y (opcionalmente) detreminación del estado de salida de trabajos Seguridad Operación segura: WS GRAM utiliza la funcionalidad de WSRF para proveer autenticación sobre las solicitudes de administración de trabajos, así como también para proteger a las solicitudes de trabajo de interferencia maliciosa, mientras que pre-ws GRAM utiliza GSI y sockets seguros directamente. El uso de GRAM no reduce la habilidad del administrador de sistemas a controlar el acceso a sus recursos. Tampoco reduce la seguridad de los trabajos de usuario corriendo en un dado recurso de computo. Dominio de protección del sistema local: para proteger a los usuarios unos de otros, los trabajos son ejecutados en contextos de seguridad local apropiados, por ejemplo bajo ID Unix de usuarios específicos basado en los detalles de la solicitud y las políticas de autorización. Delegación y administración de credenciales: un cliente puede delegar algunos de sus derechos al servicio GRAM, por ejemplo para que GRAM pueda acceder datos en un elemento de almacenamiento remoto como parte de la ejecución de trabajos. Adicionalmente el cliente puede delegar derechos para uso del trabajo a ejecutar en sí mismo. Con pre-ws GRAM estas dos formas de delegación son inseparables, mientas que WS GRAM provee control separado para cada propósito. Auditoria: para asistir en las funciones de contabilidad así como también para mitigar el abuso o malfuncionamiento, GRAM utiliza varias técnicas de logging y auditoria para gravar la historia del despacho de trabajos y operaciones críticas del sistema Administración de trabajos Despacho de trabajos confiable: WS GRAM provee una semántica de despacho de trabajos de a lo sumo una vez. Un cliente es capaz de chequear y redespachar un trabajo en orden a abordar errores de comunicacón transitorios 90

92 sin riesgo de correr más de una copia del trabajo. De modo similar, pre-ws GRAM provee un mecanismo de despacho de dos fases para despacho y commit de un trabajo a correr. Cancelación de trabajos: mientras que muchos trabajos se ejecutarán hasta completarse, GRAM provee mecanismos a los clientes para cancelar sus trabajos en cualquier punto de su ciclo de vida Administración de datos Instanciación de datos confiable: WS GRAM soporta transferencias de archivos confiables y de alta performance entre el recurso de cómputo y elementos de almacenamiento externos antes y después de la ejecución de trabajos. Monitoreo de salida: GRAM soporta un mecanismo para transferir incrementalmente el archivo de salida desde el recurso de cómputo, mientras el trabajo está corriendo. WS GRAM utiliza un nuevo mecanismo para transmitir un número arbitrario de archivos en esta forma, mientras que pre-ws GRAM solo soporta la transferencia incremental de la salida estándar del trabajo y de errores del mismo Coordinación de tareas Trabajos paralelos: algunos trabajos se componen de varias subtareas que se ejecutan en paralelo. Estas tareas son despachadas con frecuencia a hardware que soporta cómputo paralelo para aumentar el throughput. Task rendezvous: algunos entornos de programación paralela como MPI, proveen mecanismos para que todas las tareas pertenecientes a una misma computación paralela puedan encontrarse las unas a las otras. GRAM provee un mecanismo para task rendezvous (punto de encuentro de tareas) el cual puede ser utilizado por los trabajos cuando no cuentan con alguna solución más apropiada. Este mecanismo puede ser utilizado directamente por el código de aplicación o mediante librerías del middleware, es decir librerías que están diseñadas para presentar un modelo simplificado de programación WS GRAM Web Service Grid Resource Allocation and Management (WS GRAM) comprende un conjunto de servicios web que siguen el estánar WSRF 1, implementando una solución al problema de admninistración de trabajos descrito en la sección anterior. Esta solución es específica para sistemas operativos que siguen el modelo de seguridad y programación de los sistemas Unix. 1 Véase Capítulo 3 91

93 Aproximación a los componentes de la arquitectura WS GRAM combina el servicio de administración de trabajos y adaptadores del sistema local con otros servicios componentes de GT4 para dar soporte a la administración de trabajos con file staging coordinado. Figura 6.1: Componentes WS GRAM y esquema de file staging El corazón de la arquitectura de servicios GRAM es un conjunto de servicios web diseñados para incorporarse en el núcleo del entorno WSRF de Globus Toolkit. A continuación se mencionan algunos de estos servicios: ManagedJob: cada trabajo despachado es expuesto como un recurso distinto, calificador del servicio genércio ManagedJob. El servicio provee una interfase para monitorear el estado del trabajo o para terminarlo (terminando el recurso ManagedJob ). El comportamiento del servicio, esto es, la implementación del adaptador del planificador local, es seleccionada según el tipo especializado de recurso. ManagedJobFactory: cada elemento de cómputo, mientras es accedido por un planificador local, es expuesto como un recurso distinto calificador del servicio genércio ManagedJobFactory. El servicio provee una interfase para crear recursos ManagedJob del tipo apropiado para realizar un trabajo en un planificador local Pasos principales del protocolo Los componentes de la solución WS GRAM están organizados de tal modo de dar soporte a un rango de características opcionales que en conjunto crean diferentes 92

94 escenarios de uso. Estos escenarios se comprenden en profundidad al estudiar el intercambio de los protocolos involucrados, sinembargo a un nivel más alto podemos considerar las actividades principales del cliente, relacionadas con un trabajo WS GRAM como una secuencia parcialmente ordenada, la cual se grafica en la Figura 6.2. Figura 6.2: Actividad del cliente relacionada a un trabajo WS GRAM Creación de trabajos: el componente principal de WS GRAM es el recurso ManagedJob creado por una invocación a ManagedJobFactory::createManagedJob. Un cliente de WS GRAM debe crear un trabajo que luego atravesará un ciclo de vida y eventualmente completará su ejecución y el recurso será destruido (este ciclo básico está representado en la Figura 6.2 por los nodos blancos). Credenciales opcionales para staging: opcionalmente, el cliente puede solicitar actividades de staging antes o después del trabajo. Si estas son solicitadas en la llamada de creación, entonces se deberá incluir en la entrada a dicha llamada credenciales EPRs 2 delegadas, de esta manera la operación de delegación debe realizarse antes de invocar a createmangedjob cuando el staging está habilitado (representado en la Figura 6.2 por los nodos azules). Dos campos de credenciales deben ser inicializados: las credenciales de staging y transferencia, las cuales pueden referirse a distintas o la misma credencial. La credencial de staging le da a WS GRAM el derecho de interactuar con el servicio RFT, mientras que la credencial de transferencia le da a RFT el derecho de interactuar con el servidor GridFTP. Credenciales opcionales de los trabajos: opcionalmente, el cliente puede solicitar que la credencial sea almacenada en la cuenta del usuario para que pueda ser 2 Endpoint Reference, almacena información para llamar a un servicio. El EPR más simple usualmente es una URL, pero también puede ser mucho más complejo tal como almacenar un identificador de mensaje, una dirección a la cual responder u otras propiedades. 93

95 utilizada por el proceso del trabajo. Cuando esto es solicitado en la llamada de creación del trabajo, nuevamente una credencial EPR delegada apropiada es pasada como entrada a dicha llamada. Del mismo modo que para staging, la credencial debe ser delegada antes de la llamada a creación del trabajo (representado en la Figura 6.2 por el nodo verde claro). Refresco opcional de credenciales: opcionalmente, las credenciales delegadas para staging, transferencia o uso de procesos pueden ser refrescadas (ante una eventual expiración) utilizando la interfase del servicio de Delegación. Esta operación puede realizarse sobre cualquier credencial EPR válida (representado en la figura por el nodo verde oscuro). Congelamiento de proceso de limpieza, opcional para recolección de la salida: si el cliente deseara el acceso directo a los archivos de salida escritos por el trabajo (en opocición a esperar la etapa de stage-out en la que se produce la transferencia de los archivos de salida desde el host donde se ejecutó el trabajo), el cliente deberá solicitar que el proceso de limpieza de archivos sea congelado hasta que se lo libere. Esto le da al cliente la oportunidad de recoger todos los datos pendientes o buffereados luego de que el trabajo se complete pero antes de que los archivos de salida sean eliminados (representado por los nodos rozados de la Figura 6.2). El congelamiento y liberación del proceso de limpieza no es necesario si el cliente no va a acceder a archivos que están planificados para limpieza en la solicitud de trabajo, ya sea porque el cliente no está accediendo a ningún archivo o porque los archivos que está accediendo permanecerán en el host donde se ejecuta el trabajo luego de la terminación de ManagedJob. Destrucción de ManagedJob: bajo casi todas las circunstancias, los recursos ManagedJob serán eventualmente destruidos luego de que la limpieza del trabajo haya concluido. Los cliente pueden acelerar este paso a través de una solicitud explícita de destrucción o mediante la manipulación del tiempo de ejecución planificado. La mayoría de los administradores de sistema establecerán un tiempo máximo de demora por defecto para un recurso ManagedJob luego del cual ocurrirá la purga automática de los recursos ManagedJob Componentes de Globus Toolkit utilizados por WS GRAM Reliable File Transfer (RFT): el servicio RFT de GT4 es invocado por WS GRAM a los efectos de file staging antes y después de la computación de los trabajos. La integración con RFT provee un administración de file staging más robusta que la solución ad-hoc presentadas en versiones previas de GRAM. RFT tiene mejor soporte para retry, restart y un control fino de estas capacidades. 94

96 GridFTP: este servidor es requerido para acceder a elementos de almacenamiento remoto así como también a sistemas de archivos accesibles por el elemento de cómputo encargado del trabajo. El servicio web RFT actúa como la llamada third-party client para el servidor GridFTP, en orden a administrar las transferencias de datos entre elementos de almacenamiento remoto y el sistema de archivo del elemento de cómputo. Si bien no es necesario que GridFTP sea implementado en el mismo host/nodo en el que se encuentra el servicio WS GRAM, el staging solo será posible sobre el subconjunto del sistema de archivos que es compartido por el servidor GridFTP y que se encuentra registrado en el servicio WS GRAM. De tal modo, si no existe tal servidor el staging será deshabilitado en ese elemento de cómputo. GridFTP también se utiliza para monitorear el contenido de los archivos escritos por el trabajo durante su ejecución. El protocolo estándar de GridFTP es utilizado por un cliente para controlar eficiente y confiablemente el estado de los archivos y recoger incrementalmente el nuevo contenido a medida que estos crecen. Este método soporta streaming del contenido de cualquier archivo accesible mediante GridFTP. La integración con GridFTP reemplaza la forma anterior que utilizaba el protocolo de transferencia GASS (Globus Access to Secondary Storage). Este cambio es ventajoso tanto desde el punto de vista del incremento en performance y confiabilidad en staging de datos, así como también en la reducción de código redundante en el código base de GRAM. Delegation: este servicio es utilizado por los clientes para delegar credenciales dentro del entorno de hosting correcto, para uso de los servicios WS GRAM o RFT Componentes externos utilizados por WS GRAM Planificadores de trabajos locales: puede requerirse un planificador local opcional en orden a administrar los recursos del elemento de cómputo. WS GRAM tiene la habilidad de crear trabajos de tiempo compartido usando el método estándar de UNIX fork(), pero los elementos de cómputo de gran escala están bajo el control de planificadores tales como Altair PBS, Platform LSF, IBM Loadleveler, etc. sudo: la utilidad estándar de facto, sudo de UNIX es usada por WS GRAM para ganar acceso a cuentas de usuario sin que WS GRAM requiera privilegios de super-usuario en el sistema. El comando sudo es utilizado para ejecutar el adaptador de WS GRAM, en el contexto del usuario que lo invoca; este adaptador realiza las operaciones dependientes del sistema específico necesarias para inicializar y correr trabajos de usuario. La utilidad sudo no solo provee a WS GRAM una forma sencilla de correr programas en nombre de otro usuario sin necesidad de tener privilegios root, 95

97 sino que también provee control de granularidad fina para que el administrador de sistemas pueda restringir cuáles cuentas de usuario son destinos WS GRAM válidos así como también provee auditoria segura sobre todas las acciones solicitadas por WS GRAM. Este mecanismo reemplaza el componente gatekeeper que posee privilegios de root, en la implementación Pre-WS GRAM en orden a evitar que el entorno WSRF completo corra con estos privilegios. Este cambio provee mejoras en la seguridad, a expensas de una implementación un tanto más compleja, y está motivado por el incremento relativo en el tamaño del código base de WS GRAM y WSRF en comparación al tradicional Gatekeeper Componentes internos utilizados por WS GRAM Scheduler Event Generator: este programa componente provee la capacidad de monitoreo de trabajos para el servicio WS GRAM. Módulos plugin proveen una interfase entre el Scheduler Event Generator y los planificadores locales. Fork Starter: este programa comienza y monitorea los procesos de trabajo para servicios WS GRAM que no tienen planificador local. El starter ejecuta las aplicaciones de usuario y luego espera por su terminación. Registra el tiempo de comienzo y fin de ejecución, y el estado de salida de todos los procesos que inicia. Esta información es utilizada por el Scheduler Event Generator para disparar eventos ante los cambios de estado de los procesos Seguridad Operación segura: WS GRAM utiliza invocaciones a servicios web seguras, provisto por el núcleo WSRF de Globus Toolkit, para todos los mensajes de administración de trabajos y administración de archivos. Esta seguridad incluye autenticación de clientes, mensajes a prueba de alteraciones, y opcionalmente privacidad del contenido de los mensajes. Dominio de protección del sistema local: los trabajos de usuario son ejecutados dentro de cuentas de usuario UNIX. Los mecanismos de auteticación de WS GRAM permiten al administrador controlar a cuáles cuentas locales un cliente grid puede despachar trabajos. WS GRAM utiliza el comando UNIX sudo para acceder a las cuentas de usuario luego de determinar que el cliente tiene Grid tiene el derecho a acceder a dicha cuenta. Adicionalmente, el administrador puede utilizar políticas de control de asignación y acceso en el planificador local para restringir aún mas el acceso a los recursos de cómputo local a clientes específicos y usuarios UNIX. Delegación y administración de credenciales: como se mencionó en la Sección 6.1.3, un cliente puede opcionalmente delegar algunos de sus derechos a WS GRAM y sus servicios relacionados, en orden a facilitar file staging. Adicionalmente el cliente puede delegar derechos para uso del proceso creado en 96

98 sí mismo. Si no se realiza delegación alguna, el staging es deshabilitado y el trabajo no tendrá la habilidad de solicitar operaciones Grid privilegiadas. Auditoria: WS GRAM posee cuatro tipos de soporte para auditoria. WSRF core message logging: puede obtenerse un logging detallado de los mensajes subyacentes del cliente si tal logging se habilita en la configuración del container. WS GRAM custom logging: WS GRAM genera información de logging específica del dominio, sobre las solicitudes de trabajo y condiciones excepcionales. Local scheduler logging: para sistemas que utilizan planificadores locales batch, todas las facilidades de contabilidad y logging de ese planificador permanecen disponibles para el administrador para rastrear los trabajos despachados ya sea a través de WS GRAM o directamente a través del planificador. Local system logging: el uso de sudo para invocar operaciones en favor del usuario permite al administrador registrar todas las operaciones de bajo nivel del sistema solicitadas por WS GRAM, utilizando el soporte de auditoria nativo de sudo. Visión general del protocolo Como se mencionó anteriormente, el protocolo WS GRAM está centrado alrededor de la creación de un recurso ManagedJob que posee estado, mediante la operación createmanagedjob() de ManagedJobFactory. Un trabajo de tipo batch puede involucrar solo esta operación de creación invocada por el cliente, con todos los restantes pasos del ciclo de vida del trabajo ocurriendo automáticamente en el servidor. Un número de elementos de protocolo opcionales se encuentran disponibles para escenarios más complejos. Extendiendo la visión conceptual del protocolo mencionada en la Sección 6.2.2, se presentan a continuacióm algunos de los principales métodos involucrados en la interacción con los servicios que en conjunto llevan a cabo la ejecución de los trabajos. DelegationFactory::requestSecurityToken: este paso (opcional) permite al cliente delegar credenciales que serán requeridas para la operación correcta de WS GRAM, RFT o el proceso de usuario en sí mismo. Tales credenciales son utilizadas solo cuando son referenciadas en solicitudes de trabajos subsecuentes y bajo las condiciones propuestas por la configuración de WS GRAM y RFT para hacer uso de DelegationFactory. Delegation::refresh: este paso (opcional) permite al cliente actualizar las credenciales ya establecidas en el paso requestsecuritytoken. ManagedJobFactory::getResourceProperty y getmultipleresourceproperties: este paso (opcional) permite al cliente recuperar información acerca del planificador 97

99 y los trabajos asociados con un recurso factory particular antes o después de la creación del trabajo. Las propiedades de recursos delegationfactoryendpoint y stagingdelegationfactoryendpoint son ejemplos de información que puede ser necesario obtener antes de la creación de un proceso. ManagedJobFactory::createManagedJob: este paso es necesario y establece el recurso ManagedJob con estado que implementa el procesamiento de trabajo descrito en la solicitud de entrada. ManagedJob::release: este paso (opcional) permite a un ManagedJob continuar a través de los estados de su ciclo de vida cuando ha sido previamente congelado o planificado para congelarse de acuerdo a los detalles de la solicitud de trabajo original. ManagedJob::setTerminationTime: este paso (opcional) permite al cliente replanificar la terminación automática de modo que difiera de la que originalmente se especificó durante el proceso de creación del ManagedJob. ManagedJob::destroy: este paso (opcional) permite al cliente abortar explícitamente un trabajo y destruir el recurso ManagedJob en el caso de que el tiempo planificado de terminación automático no sea adecuado. Si el trabajo se ha completado (con o sin éxito) esta operación sólo destruirá el recurso asociado al trabajo. Si el trabajo no se ha completado, se realizarán los pasos adecuado para purgar el proceso del planificador y para realizar operaciones de limpieza antes de setear el estado del trabajo a fallado. ManagedJob::subscribe: este paso (opcional) permite a los clientes suscribirse para notificaciones de estado (en particular estado del ciclo de vida) de un recurso ManagedJob. Para lograr la mejor tiempo de reacción es posible establecer la suscripción inicial en la operación de creación del trabajo, sin round-trip de comunicación adicionales. ManagedJob::getResourceProperty y getmultipleresourceproperties: este paso (opcional) permite al cliente consultar el estado (en particular el estado del ciclo de vida) del recurso ManagedJob. Existen distintas variantes del protocolo básico esquematizado en la sección que plantean escenarios de despacho más o menos complejos, para mayor información acerca de estas variantes se puede recurrir a: Experiencia en el laboratorio LISiDi Las configuraciones y pruebas mencionadas en las próximas dos secciones fueron llevadas a cabo en el cluster del grupo de investigación LISiDi del Departamento de Ciencias e Ingeniería de la Computación de la Universidad Nacional del Sur. Este cuenta con nueve máquinas en las que se instaló Globus Toolkit

100 Configurando WS GRAM Una vez realizado el proceso de instalación de GT4 es poco lo que resta configurar para que el servicio WS GRAM funcione correctamente. Durante este proceso se resolvieron las siguientes dependencias con WS GRAM: Credenciales del host: es necesario contar con los certificados de host para correr los servicio asociados a WS GRAM, dentro del entorno WSRF (ver Capítulo 4, página 56). Autorización a través de Gridmap de las cuentas de usuario Grid: en orden a autorizar a un usuario a interactuar con los servicios de GRAM, la configuración de seguridad debe mapear el Distinguished Name (DN) del usuario Grid al nombre de usuario en el sistema donde los servicios GRAM corren (ver Capítulo 4, página 60) Funcionamiento de sudo: el comando sudo de UNIX debe funcionar correctamente. Mas adelante se muestran las reglas de autorización agregadas al archivo sudoers que determina el funcionamiento de sudo, estas reglas permiten a WS GRAM ejecutar los adaptadores locales en las cuentas de usuarios GRAM autorizados. Planificador local: WS GRAM depende de mecanismos locales para comenzar y controlar jobs. Incluído en el software WS GRAM se encuentra un planificador Fork, el cual no requiere la instalación de software especial para ejecutar jobs en el host local. Para permitir a WS GRAM ejecutar y administrar jobs con un planificador batch distinto, el software del mismo deberá ser instalado y configurado previo a la implementación y operación de WS GRAM. Los adaptadores para planificadores WS GRAM (interfases con los planificadores batch) incluidos en GT4 son: PBS4, Condor5 y LSF6.[GRAMadmin] Dependencia con RFT: WS GRAM depende de RFT para staging de archivos y cleanup (ver Capítulo 5). Una vez resueltas estas dependencias solo resta setear el entorno para el comando sudo utilizado por WS GRAM. Para esto es necesario contar con permisos root y como tal ejecutar el comando visudo que permite editar el archivo sudoers en forma segura. Este archivo indica básicamente la lista de usuarios y cuáles comandos están habilitados a ejecutar cada uno de ellos. Al ejecutar visudo, deberán agregarse las siguientes líneas:...(informacion no relevante omitida) # Globus GRAM entries globus ALL=(auser1) NOPASSWD: /usr/local/globus-4.0.1/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.1/libexec/globus-job-manager-script.pl * 99

101 globus ALL=(auser1) NOPASSWD: /usr/local/globus-4.0.1/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.1/libexec/globus-gram-local-proxy-tool * 3 Cada una de estas entradas indica que el usuario globus desde cualquier host puede correr los comandos mencionados pero solo como auser1 y sin necesidad de ingresar password, por ejemplo invocando el comando sudo -u auser1 comando, como usuario globus Visión del usuario de WS GRAM Se abordan a continuación la función del servicio GRAM desde el punto de vista del usuario, en especial la implementación en la versión 4 de Globus Toolkit. Se plantearan diferentes escenarios de uso de dicho servicio, a continuación se menciona algunos de los principales comandos provistos por Globus Toolkit, involucrado en la ejecución de los ejemplos subsiguientes. globusrun-ws: Es un cliente WS GRAM de línea de comando para despacho y monitoreo de trabajos GRAM. Este comando esta escrito en el lenguaje de programación C. Da soporte para despacho, monitoreo y cancelación de trabajos GRAM tanto múltiples como simples. Permite la delegación automática de credenciales o suministradas por el usuario grid-proxy-init: permite la creación de un certificado proxy de corto plazo a partir del certificado de largo termino del usuario grid (más información ver Capitulo 4, página 48). globus-credential-delegate y globus-credential-refresh: permiten la administración de credenciales en hosts remotos. Funcionalidades incorporadas en GT4 Como se mencionó anteriormente, GRAM posee ciertas funcionalidades que pueden ser aprovechadas para crear distintos escenarios por parte de los usuarios, en especial la implementación presentada en GT4 (WS GRAM) ofrece algunas funcionalidades inexistentes en versiones anteriores como ser la implementación de una semántica a lo sumo una vez por parte del servicio WS GRAM, para la ejecución de trabajos. De este modo se evita la duplicación de ejecución de trabajos. Dicha funcionalidad es abordada utilizando ID de despacho que, si bien por defecto el comando globusrun-ws genera (uuid), puede opcionalmente ser provistos por el usuario en la línea de comandos. 3 Las entradas deben expresarse en una sola línea, aquí se dividió con propósitos de edición 100

102 Por otra parte se ofrece la posibilidad de congelar y liberar un dado proceso para lograr streaming out de la salida en un estado intermedio en el ciclo de vida del mismo, será especificado en el archivo de descripción del trabajo, en el que se indica el estado específico en donde se pretende congelar el proceso, esto provocará el congelamiento del proceso de limpieza dándole la oportunidad al usuario de recolectar la salida del trabajo ocurrida hasta el momento. El esquema de descripción de trabajos XML además permite especificar un multijob, esto es un trabajo que en sí mismo está compuesto de múltiples trabajos ejecutables. La utilidad de esta funcionalidad es más que obvia, ejecutar trabajos en paralelo vinculados bajo un mismo objetivo, bajo el supuesto de que cada subjob corre en un elemento de computo diferente. Algunos escenarios Para las pruebas a continuación se utilizó la cuenta de usuario auser1 y los permisos asociados a la misma. Por otro lado también se asume que se encuentran corriendo el container con los servicios Grid necesarios en los hosts sobre los cuales se efectuaran los despachos. En principio es imperativo contar con una credencial válida a la hora de interactuar con WS GRAM de lo contrario se denegará cualquier solicitud de servicio. Para obtener la credencial en cuestión será necesario invocar el comando grid-proxy-init: Figura 6.3: Generación de certificado proxy de sesión Como ejemplo inicial se despachará un trabajo simple a nivel local, para esto invocamos el comando globusrun-ws. En este caso la invocación no necesita la creación previa de un archivo de descripción del trabajo. El uso del argumento -c indica a globusrun-ws que el argumento a continuación es el ejecutable que se pretende correr y los siguientes son los parámetros del mismo. En la Figura 6.4 se observa la ejecución de un trabajo utilizando los argumentos mencionados. El comando touch crea un archivo vacío con el nombre indicado, verificamos que efectivamente fue creado por la invocación anterior listando el contenido del directorio $HOME del usuario auser1. Ver Figura 6.5. Ahora bien, el mismo trabajo puede ser corrido en el host local, o en un host/servicio remoto utilizando el contact string y el argumento -F en la línea de comandos, dicho argumento causa la construcción de un EPR usando métodos ad-hoc depen- 101

103 Figura 6.4: Ejemplo de ejecución local de un comando simple Figura 6.5: Comprobación de la ejecución del trabajo despachado dientes de los detalles de implementación de GT. El contact string es de la forma [protocol://]{hostname hostaddr}[:port][/service] Por defecto se asume: En el ejemplo en la Figura 6.6 se corre el mismo comando del ejemplo previo pero en un host remoto (la dirección IP local es ) Figura 6.6: Ejemplo de ejecución de un comando simple ejecutado remotamente Nuevamente comprobamos la correcta ejecución del trabajo despachado, en este caso primero nos logueamos como auser1 en la máquina con IP (por ejemplo a través de ssh) y luego listamos el contenido del $HOME del usuario. Ver Figura

104 Figura 6.7: Comprobación de la ejecución del trabajo despachado El siguiente paso es utilizar un archivo de descripción del trabajo. En la Figura 6.8, se observa el despacho de un trabajo utilizando un archivo de descripción ejemplo simple.xml con el siguiente contenido: <job> <executable>/bin/echo</executable> <argument>esto es un ejemplo </argument> <argument>globus anduvo aqui</argument> <stdout>${globus_user_home}/stdout</stdout> <stderr>${globus_user_home}/stderr</stderr> </job> Para este caso se utilizará el argumento -f en la invocación de globusrun-ws, causando que la descripción del trabajo sea leída del archivo xml pasado como parámetro. Figura 6.8: Ejemplo utilizando un archivo de descripción Comprobamos la correcta ejecución del trabajo listando el directorio $HOME del usuario auser1 y mostrando el contenido del archivo stdout creado por dicha ejecución. Ver Figuras 6.9 y Otra posibilidad es la ejecución de un multijob, en este caso el esquema XML (archivo de descripción del trabajo) expresa más de un trabajo o job, a los cuales nos referiremos como subjobs. Esta variante es útil para agrupar varios trabajos y despacharlos como un todo a una instalación GRAM remota. 103

105 Figura 6.9: Comprobación de la ejecución del trabajo despachado Figura 6.10: Contenido del archivo creado por la ejecución Los subjobs son despachados al job factory service en el orden en que aparecen en el archivo de descripción. Dentro del archivo de descripción de multijob, cada subjob deberá tener su propio factoryendpoint, de este modo se logra la ejecución uno a uno de los subjobs en diferentes hosts. El servicio factory al cual se despacha el multijob actúa como un escalón intermedio entre el cliente y las factories que finalmente ejecutarán los subjobs. A continuacíon se muestra un archivo de descripción XML de un multijob. <?xml version="1.0" encoding="utf-8"?> <multijob xmlns:gram=" xmlns:wsa=" <job> <factoryendpoint> <wsa:address> </wsa:address> <wsa:referenceproperties> <gram:resourceid>fork</gram:resourceid> </wsa:referenceproperties> </factoryendpoint> <executable>/bin/hostname</executable> <stdout>${globus_user_home}/stdout.multi1</stdout> <stderr>${globus_user_home}/stderr.multi1</stderr> <count>2</count> </job> <job> <factoryendpoint> <wsa:address> 104

106 </wsa:address> <wsa:referenceproperties> <gram:resourceid>fork</gram:resourceid> </wsa:referenceproperties> </factoryendpoint> <executable>/bin/hostname</executable> <stdout>${globus_user_home}/stdout.multi2</stdout> <stderr>${globus_user_home}/stderr.multi2</stderr> <count>1</count> </job> </multijob> La ejecución y comprobación de la misma, mediante el uso de la línea de comando en el cluster LISiDi se presentan a continuación en la Figura Figura 6.11: Ejecución y comprobación de multijob La opción -J es utilizado para delegar las credenciales a cada host GRAM. Como último escenario, se ejecutará un trabajo que hace uso de stage in y stage out de archivos. El esquema seguido por la ejecución es el mostrado en la Figura El archivo de descripción de trabajo en este caso es el siguiente: <?xml version="1.0" encoding="utf-8"?> <job xmlns:gram=" xmlns:wsa=" <factoryendpoint> <wsa:address> 105

107 Figura 6.12: Esquema de ejecución utilizando staging </wsa:address> <wsa:referenceproperties> <gram:resourceid>fork</gram:resourceid> </wsa:referenceproperties> </factoryendpoint> <executable>/tmp/copied_echo</executable> <argument>ejemplo con Staging ejecutado en host c09</argument> <stdout>${globus_user_home}/stdout_filestaging</stdout> <stderr>${globus_user_home}/stderr_filestaging</stderr> <filestagein> <transfer> <sourceurl>gsiftp:// //bin/echo</sourceurl> <destinationurl> gsiftp:// //tmp/copied_echo </destinationurl> </transfer> </filestagein> <filestageout> <transfer> <sourceurl> gsiftp:// /${globus_user_home}/stdout_filestaging </sourceurl> 106

108 <destinationurl> gsiftp:// /tmp/stdout_desdec09 </destinationurl> </transfer> <transfer> <sourceurl> gsiftp:// /${globus_user_home}/stderr_filestaging </sourceurl> <destinationurl> gsiftp:// /tmp/stderr_c09 </destinationurl> </transfer> </filestageout> <filecleanup> <deletion><file> gsiftp:// /tmp/copied_echo </file></deletion> <deletion><file> gsiftp:// /${globus_user_home}/stdout_filestaging </file></deletion> <deletion><file> gsiftp:// /${globus_user_home}/stderr_filestaging </file></deletion> </filecleanup> </job> Por último se muestra en la Figura 6.13 se muestra la ejecución y comprobación utilizando el archivo de descripción anterior. El parámetro -S en la llamada a globusrunws es utilizado para delegar las credenciales a cada host durante el staging. Figura 6.13: Ejecución utilizando staging 107

109 Capítulo 7 Monitoring and Discovery System (MDS) 7.1. Introducción En un ambiente grid, el conjunto de recursos disponibles para usar por una organización virtual puede cambiar frecuentemente: nuevos recursos y servicios pueden ser agregados mientras que otros mas viejos pueden ser sacados, o las propiedades de algún recurso o servicio pueden cambiar (por ejemplo, un servidor de datos puede ser actualizado con un equipo de mayor capacidad, diferentes tazas de acceso y diferentes protocolos de acceso). Debido a que estos sistemas son tan diferentes por naturaleza, el descubrimiento (el proceso de encontrar recursos adecuados para realizar una tarea) puede ser un tarea significante. De forma similar, el monitoreo (el proceso de observar recursos y servicios y rastrear su status para propósitos tales como arreglar problemas o llevar control del consumo) puede ser mas complicado en Grids debido al dinamismo y la naturaleza distribuida de estos ambientes [SDM+05]. Casos de uso típicos de monitoreo y descubrimiento incluyen proveer datos para que un broker de recursos pueda localizar elementos de computación apropiados para un trabajo, o notificar a los administradores de sistema cuando ocurren cambios en la carga del sistema o en la espacio disponible en disco con el fin de detectar posibles anomalías en la performance. El sistema de Monitoreo y Descubrimiento (MDS de su sigla en Inglés) es el conjunto de componentes que Globus Toolkit provee para monitorear y descubrir recursos y servicios sobre grids. El sistema permite a los usuarios descubrir qué recursos son considerados parte de una organización virtual (VO) y monitorear los mismos. Los servicios MDS proveen interfases de consulta y reserva a recursos permitiendo definirlos con una precisión arbitraria. Asi como también interfases sensibles a eventos que puedan ser configuradas para tomar acción cuando se dan ciertas condiciones problemáticas establecidas previamente. MDS4 es la implementación WS de MDS (MDS4), incluída en el Globus Toolkit 4. Se distingue de sistemas previos por su uso intensivo de interfaces y comportamientos definidos en las especificaciones WS-Resource Framework y WS-Notification, y por 108

110 su profunda integración con, esencialmente, cada componente del Globus Toolkit [SDM+05]. Los servicios incluídos en MDS4, adquieren su información a través de una interfaz extensible que puede ser usada para: consultar servicios WSRF por información sobre propiedades de recursos, ejecutar un programa para adquirir datos, o interactuar con sistemas de monitoreo de terceras partes (o sea, con intermediarios). Los recursos y servicios en un Grid pueden anunciar una gran cantidad de datos que pueden ser usados con múltiples propósitos. MDS4 está diseñado para dirigir las necesidades de un sistema de monitoreo en Grid. Como tal, no es un sistema de manejo de eventos, como NetLogger 1, o un monitor de cluster en si mismo, como es Ganglia 2, pero puede actuar de interface con sistemas de monitoreo mas detallados y con archivos, y puede publicar datos concisos usando interfaces estándar Detalles de MDS4 Figura 7.1: Organización reloj de arena de los protocolos usados por MDS4 MDS4 se basa fuertemente en capacidades provistas por las especificaciones WSRF y WS-Notification; ciertamente, puede verse MDS4 por encima de todo como un caso de uso de estas especificaciones, que definen los mecanismos usados para describir 1 ver 2 una herramienta de monitoreo para cluster. Ver 109

111 fuentes de información, acceden a información via consultas y subscripciones, y que manejan tiempos de vida de la información. Como muestra la figura 7.1 en la página 109, MDS4 puede ser pensado como un reloj de arena [Gloa05], que define protocolos estándar para acceso y entrega, y esquemas estándar para representación de la información. Debajo del cuello del reloj de arena, MDS4 hace de interfaz a diferentes fuentes de información locales, traduciendo sus diversos esquemas a esquemas XML apropiados (basados sobre estándares como el esquema GLUE siempre que es posible). Por encima del cuello del reloj de arena, varias herramientas y aplicaciones pueden ser construídas para tomar ventaja de las interfaces uniformes para la consulta, subscripción y notificación a una amplia variedad de fuentes de información, web services, y otras herramientas de monitoreo Estándares de Web Services usados por MDS4 Los recursos y servicios de computación grid pueden anunciar una gran cantidad de datos para distintos casos de uso. Al tratar con un toolkit de protocolos mezclados es claro que la mejor forma de levantar una infraestructura de monitoreo es tener interfaces básicas y funcionalidad de monitoreo como parte de cada servicio de una manera estándar. De esta manera, el monitoreo básico y el descubrimiento de datos podría formar parte del núcleo de cada servicio y no una excepción a la regla. Así, varios estándares web services han surgido para dirigir las interfaces para interactuar con datos de servicio, incluyendo registración, consulta, e identificación (naming): WS-ResourceProperties define un mecanismo por el cual los Web Services pueden describir y publicar conjuntos de información sobre un recurso. Los tipos de propiedades de recursos son definidos en el WSDL (Web Service Definition Languaje) del servicio, y las propiedades de recursos en si mismas pueden ser obtenidas en forma de documentos XML, usando operaciones WS-ResourceProperties de consulta. WS-BaseNotification define una interfaz de subscripción/notificación para acceder a información sobre propiedades de recursos. WS-ServiceGroup define un mecanismo para agrupar recursos y/o servicios relacionados como grupos de servicios Servicios MDS4 El componente central en MDS es el Index Service, que recolecta información sobre recursos Grid y hace esta información disponible. Es similar al registro UDDI 3, sin embargo no tiene las limitaciones estáticas de este enfoque y permite que el último valor para cada elemento de dato se almacene temporalmente para mejorar la performance de las consultas. El Index Service interactúa con fuentes de datos via interfaces WS-ResourceProperties y WS-BaseNotification. Cualquier servicio basado 3 ver término en el Apéndice B 110

112 en WSRF puede poner a disposición su información como propiedades de recurso, sin embargo el Index Service recolecta información de muchas fuentes y las publica en un solo lugar. Las propiedades de recursos pueden ser consultadas por nombre o via consultas XPath. La administración del Index Service es hecha via WS-ServiceGroup; las entradas de grupo de servicios describen los mecanismos y parámetros asociados usados para recolectar datos y mantener estos. Pueden haber muchos índices disponibles para un usuario Grid. Cada contenedor tiene un Index Service por defecto que mantiene el rastro sobre los recursos creados dentro del container. Además, sitios y organizaciones virtuales a menudo mantienen el rastro de todos los contenedores, recursos y servicios que están disponibles para el sitio o VO en un Index Service. Los usuarios solo necesitan saber la localización de un Index Service adecuado para poder descubrir y monitorear los recursos y servicios que este indexa. Los Index Services de MDS4 tienen un número de características que a veces sorprenden a los usuarios nuevos, pero que son necesarias debido a la escalabilidad en Grid y a cuestiones de políticas: Los Index Services pueden organizarse de jerarquías, pero no existe un único índice global que provea información sobre cada recurso sobre el grid. Esto es deliberado, como cada organización virtual tiene diferentes políticas sobre quién puede acceder a sus recursos. Ninguna persona en el mundo es parte de cada organización virtual. La presencia de un recurso en un índice no garantiza la disponibilidad del recurso para los usuarios de ese índice. Un índice provee una indicación de que ciertos recursos son propensos de ser utilizables, pero la última decisión sobre si los recursos pueden ser usados se deja a la negociación directa entre el usuario y el recurso. Un usuario que decidió acceder a un recurso basado en información de MDS puede encontrar que no está autorizado cuando va a querer utilizarlo. Esto significa que MDS no necesita seguir información de políticas (algo difícil de hacer de forma concisa) y que los recursos no necesitan revelar sus políticas públicamente. MDS tiene un modelo de consistencia suave. La información publicada es reciente, pero no se garantiza que sea la última. Esto permite que se reduzca la carga causada por actualizaciones al costo de tener información ligeramente vieja. Este retraso no es un problema en la práctica (por ejemplo, es generalmente aceptable saber la cantidad de espacio en disco libre en un sistema hace 5 minutos en lugar de hace 2 segundos). Cada registración dentro de un Index Service está sujeta al manejo del tiempo de vida. Las registraciones tienen tiempo de expiración y deben ser renovadas periódicamente para indicar la continuidad de la existencia del recurso. Esto permite a cada índice a mantenerse limpio, con las entradas vencidas desapareciendo automáticamente cuando cesa de renovar sus registraciones. 111

113 En el caso mas común de uso, el servidor de índice en esencia replica datos que fueron hechos disponibles originalmente por otro servicio. Actualmente, sin embargo, el servidor de índice no recolecta datos de esta manera pues podría estar forzando las políticas de control de acceso de estos servidores remotos. Para protegerse contra el riesgo de que un servidor de índice permita un acceso mas generoso que el que el publicador original del dato pretende, se recomienda que los servidores de índice puedan correr en uno de dos modos: un índice público, en el cual todos los datos del índice son recolectados a través de consultas anónimas y el acceso es concedido a todos, y un índice personal, en el cual todos los datos del índice son recolectados usando credenciales delegadas por un individuo y el acceso es restringido a ese mismo individuo. El servicio MDS-Trigger, el otro servicio de alto nivel distribuido como parte de MDS4, recolecta información y la compara contra un conjunto de condiciones definidas en un archivo de configuración. Cuando se cumple una condición, se toma una acción determinada, como por ejemplo mandar un al administrador del sistema cuando el espacio en disco en un servidor alcanza cierto umbral. Esta funcionalidad, inspirada en una capacidad similar de Hawkeye, a probado ser útil en la solución de problemas para proyectos como por ejemplo, el Earth Science Grid (ESG). Testeo del MDS4 en el LISiDi Para probar el correcto funcionamiento del componente MDS4 en el cluster de 9 máquinas que posee el Laboratorio de Investigación en Sistemas Distribuidos (LISiDi) de la Universidad Nacional del Sur, corrimos un procedimiento de testeo para verificar la correcta configuración que es realizada de forma automática durante el proceso de instalación del Globus Toolkit 4. Anteriormente dijimos que cada contenedor en Globus posee por defecto un servicio de índice, así que comprobaremos la correcta configuración del MDS4 realizando las siguientes operaciones: 1. Logearse en un nodo grid como usuario Globus. 2. Iniciar un contenedor seguro con el siguiente comando: globus-start-container 3. En otra consola, logearse en el nodo grid con un usuario que tenga certificado de usuario grid. 4. Crear un certficado de proxy con el comando: grid-proxy-init este paso puede evitarse si ya se ha ejecutado anteriormente este comando y el certificado de proxy creado aun no ha expirado. 5. Correr el comando que se muestra en la figura 7.2 en la página 113; si se muestra por pantalla una lista de servicios, entonces MDS4 está bien configurado. 112

114 Figura 7.2: Salida del comando wsrf-query Aggregator Framework Las implementaciones de los servicios MDS-Index y MDS-Trigger son especializaciones de un aggregator framework mas general, un framework 4 de software para construir servicios que recolectan y procesan datos. Los servicios construidos sobre este framework son llamados aggregator services. Tales servicios tienen tres propiedades en común. Primero, recolectan información via aggregator sources. Una aggregator source es una clase en Java que implementa una interface (definida como parte del aggregator framework) para recolectar datos formateados a XML. MDS4 soporta tres tipos de aggregator source. Una Query source usa mecanismos de WS-ResourceProperty para consultar un servicio WSRF por información de propiedades de recurso. Una Subscription source recolecta datos de un servicio via subscripción/notificación WSRF. Finalmente, una Execution source ejecuta un programa provisto por el administrador para recolectar información. La figura 7.3 en la página 114 resume como la información fluye a través del aggregator framework. Segundo, los aggregator services usan un mecanismo de configuración común para mantener información acerca de cuáles aggregator sources usar y sus parámetros asociados, que generalmente especifica qué dato obtener y de dónde. El WSDL del aggregator framework define un tipo de acceso WS-ServiceGroup que mantiene información 4 ver término en el Apéndice B 113

115 Figura 7.3: Flujo de información a través del aggregator framework de MDS4 de configuración y datos. Los programas de clientes administrativos usan mecanismos de registración WS-ServiceGroup estándar para registrar estos accesos a grupos de servicios en el Aggregator Service. Tercero, los aggregator services se mantienen limpios, esto es, cada registración tiene un tiempo de vida; si la registración expira sin ser renovada, esta registración y sus datos asociados son removidos del servidor Proveedores de Información Los datos que una aggregator source publica en su aggregator service es siempre obtenida desde un componente externo llamado proveedor de información. En el caso de Query source o Subscription source, el proveedor de información es un servicio complaciente a WSRF del cual los datos son obtenidos via mecanismos WS- ResourceProperty o WS-Notification, respectivamente. En el caso de una Execution source, el proveedor de información es un programa ejecutable que obtiene sus datos a través de algún mecanismo específico del dominio. Existen implementados varios proveedores de información en GT4 resumidos a continuación. En todos los casos el esquema es un documento XML estándar. Para 114

116 Hawkeye, Ganglia y GRAM, se publica información usando el mapeo XML del esquema GLUE: Hawkeye Information Provider: Un proveedor de información que recoge datos Hawkeye 5 sobre recursos Condor pool usando el mapeo XML del esquema GLUE y reporta estos datos a un servicio WS GRAM, que los publica como propiedades de recurso. Esta información incluye: datos básicos del host (nombre e ID) información del procesador tamaño de la memoria nombre del sistema operativo y la versión datos del sistema de archivos datos de la carga del procesador otros datos básicos del host usados por Condor. Ganglia Information Provider: Un proveedor de información que recoge datos de cluster desde recursos corriendo Ganglia usando el mapeo XML del esquema GLUE y reporta estos datos a un servicio WS GRAM, que los publica como propiedades de recurso. Esta información incluye: datos básicos del host (nombre e ID) tamaño de la memoria nombre del sistema operativo y la versión datos del sistema de archivos datos de la carga del procesador otros datos básicos del host usados por Condor. WS GRAM: El componente de servicio de submisión de trabajos (jobs) de GT4. Este servicio WSRF publica información sobre el planificador local, incluyendo: información de la cola numero de CPUs disponibles y libres información de conteo de trabajos algunas estadísticas de memoria. Servicio RFT (Reliable File Transfer): Uno de los componentes de servicio de transferencia de archivos de GT4. Este servicio WSRF publica: datos de estado del servidor estado de transferencia de un archivo o conjunto de archivos 5 un servicio de monitoreo para Condor Pools. Ver 115

117 número de transferencias activas alguna información de estado sobre recursos corriendo el servicio. Community Authorization Service (CAS): Estos servicios WSRF publican información identificando la organización virtual a la que sirven. Replica Location Service (RLS): Este componente de GT4 localiza las réplicas en el sistema de almacenamiento físico (basado en las registraciónes de los usuarios) para futuras consultas. Cualquier otro servicio WSRF que publique propiedades de recurso Interfaz de usuario WebMDS Figura 7.4: Screenshoot de WebMDS WebMDS es una interfaz web hacia información de propiedades de recursos WS- RF que puede ser usado como un front-end amigable al usuario para el Index Service. WebMDS usa peticiones estándar para obtener propiedades de recurso y aplica transformaciones XSLT para formatear esta información y mostrarla. Los administradores del sitio web pueden adaptar sus propias versiones (deployment) WebMDS usando opciones de forma HTML y creando sus propias transformaciones XSLT, de forma de poder mostrar los resultados en diversos formatos. En la figura 7.4 en la página 116 se aprecia una imagen de como se puede presentar WebMDS al usuario a través de un web browser como Firefox o Internet Explorer. 116

118 7.4. MDS2 El Servicio de Monitoreo y Descubrimiento MDS2 [ZFS03] es el servicio de información usado en versiones anteriores de Globus Toolkit. Usa un framework extensible para manejar información estática y dinámica sobre el status de un Grid computacional y todos sus componentes: redes, nodos de computadora, sistemas de almacenamiento, instrumentos, etc. MDS2 está construido sobre la base del protocolo LDAP (Lightweight Directory Access Protocol). MDS2 fue usado primeramente para direccionar el problema de la selección de recursos, particularmente, como un usuario identifica el host o el conjuntos de hosts sobre el cual correr una aplicación. Está diseñado para proveer un mecanismo estándar para publicar y descubrir información de status de recursos y configuración. Al igual que MDS4, MDS2 provee una interfaz uniforme y flexible a los datos recogidos por proveedores de información de nivel mas bajo. También se puede restringir el acceso a los datos usando credenciales GSI (Grid Security Infrastructure). MDS2 tiene una estructura jerárquica (ver figura 7.5 en página 117) que consiste de tres componentes principales. Un servicio GIIS (Grid Index Information Service) provee un directorio de agregación de datos de nivel bajo. Un servicio GRIS (Grid Resource Information Service) corre sobre un recurso y actúa como una compuerta de contenido modular para un recurso. Los proveedores de información (IPs, por Information Providers) hacen de interfaz para cualquier servicio de recolección y luego se comunica con un GRIS. Cada servicio se registra con otros usando un protocolo de estado suave (soft-state) que permite la limpieza dinámica de recursos muertos (que no están mas registrados, similar a como pasa con MDS4). Cada nivel también hace uso de caché para minimizar la transferencia de datos y amenguar el overhead en la red. Figura 7.5: La arquitectura MDS2 117