Repositorio Institucional de Documentos

Framework para el despliegue automático de workflows científicos en entornos Grid Proyecto Fin de Carrera Ingeniería Informática Autor Sergio Hernández de Mesa Directores Francisco Javier Fabra Caro Pedro Javier Álvarez Pérez-Aradros Grupo de Integración de Sistemas Distribuidos y Heterogéneos (GIDHE) Departamento de Informática e Ingeniería de Sistemas Escuela de Ingeniería y Arquitectura Universidad de Zaragoza Curso 2010/2011 Septiembre 2011 RESUMEN Framework para el despliegue automático de workflows científicos en entornos Grid La heterogeneidad de las infraestructuras de computación existentes para el despliegue y ejecución de workflows científicos, junto con la complejidad de los workflows utilizados en Grid, producen que el proceso de scheduling sea una tarea muy complicada. Un enfoque que ayuda a resolver esta tarea es la utilización de un broker de recursos, pero esto provoca que las infraestructuras Grid asociadas estén fuertemente acopladas con el middleware subyacente. Por tanto, la integración de diferentes middlewares representa un desafío que sigue abierto. En este proyecto se presenta un enfoque flexible para el despliegue de workflows científicos en entornos Grid heterogéneos. La propuesta realizada se fundamenta en la utilización de un sistema de coordinación basado en el modelo de Linda y un conjunto de mediadores que abstraen al sistemas de los detalles de los diferentes middlewares utilizados. Como resultado, la infraestructura permite ejecutar workflows científicos en diferentes entornos Grid de forma completamente transparente para el usuario. Además, la infraestructura desarrollada proporciona mecanismos que permiten escalar y extender la misma fácilmente, haciendo que el sistema sea adecuado para una gran variedad de escenarios. Asimismo, el framework resuelve algunos de los problemas actuales en lo referente al modelado de workflows científicos. Los lenguajes de modelado utilizados en la actualidad son muy dependientes del sistema de gestión de workflows utilizado, dificultando la utilización del mismo en otros entornos y la compartición de los experimentos. Como solución, la infraestructura propuesta permite integrar diferentes entornos de modelado utilizando un lenguaje independiente del entorno de ejecución para describir las tareas que constituyen un workflow. Las prestaciones del sistema se han analizado y evaluado en términos de rendimiento y escalabilidad, comparando los resultados obtenidos con otro sistema de gestión de workflows científicos como es el caso de Taverna. Finalmente se presenta un caso de estudio correspondiente al First Provenance Challenge, por su importancia dentro del campo de las ciencias de la vida, y que sirve para demostrar la viabilidad de la propuesta desarrollada. Además, se proporcionan diferentes implementaciones del problema, mostrando la flexibilidad del sistema en lo que respecta a la utilización de diferentes entornos de modelado. Taverna y las redes de referencia se utilizan para modelar los workflows, y se integran varios grids de forma transparente, desplegando el workflow en las infraestructuras disponibles: Hermes, Aragrid, Piregrid y Amazon EC2. Agradecimientos Quiero agradecer a mis directores, por darme la oportunidad de involucrarme en este maravilloso proyecto y por la dedicación tanto profesional como personal que me han brindado, ha sido inmejorable. A mis padres y a mi hermana, por su apoyo durante este proyecto y durante toda la carrera. A mis compañeros de laboratorio, por las largas horas que hemos pasado juntos y todo lo que hemos disfrutado en esas cuatro paredes. A mis compañeros de carrera, por todos los buenos momentos que hemos pasado durante estos años, tanto dentro como fuera del CPS, y por todos los que quedan. Al resto de amigos y familia, por el apoyo brindado y por interesaros por mi proyecto aunque no os enteraseis de nada. A Natalia por todo. Índice Capítulo 1 - Introducción......................................................................................................1 1.1 - Contexto general...................................................................................................................1 1.2 - Motivación............................................................................................................................3 1.3 - Objetivos de este proyecto.....................................................................................................4 1.4 - Organización de la memoria...................................................................................................6 Capítulo 2 - Puesta en contexto............................................................................................9 2.1 - Computación Grid..................................................................................................................9 2.2 - Computación Cloud...............................................................................................................9 2.3 - Workflows científicos...........................................................................................................10 2.4 - Sistemas de gestión de workflows científicos.........................................................................11 2.5 – El modelo de coordinación Linda..........................................................................................12 2.6 - MyExperiment.....................................................................................................................13 Capítulo 3 - Estado del arte................................................................................................15 3.1 - Herramientas de modelado de workflows científicos...............................................................15 3.2 - Herramientas de despliegue y ejecución de workflows científicos.............................................16 3.3 - Comparación de los diferentes sistemas.................................................................................21 Capítulo 4 - Modelado e implementación.............................................................................23 4.1 - Arquitectura del sistema.......................................................................................................23 4.2 - Modelado de workflows científicos........................................................................................27 4.3 - Registros del sistema............................................................................................................30 4.4 - Broker de coordinación.........................................................................................................32 4.5 - Componente de gestión de fallos...........................................................................................35 4.6 - Componente de movimiento de datos...................................................................................38 4.7 - Mediadores..........................................................................................................................40 Capítulo 5 -Evaluación del sistema.......................................................................................43 5.1 - Métricas de evaluación.........................................................................................................43 5.2 - Definición de experimentos...................................................................................................43 5.3 - Resultados...........................................................................................................................44 5.4 - Conclusiones........................................................................................................................45 Capítulo 6 - Caso de estudio: First Provenance Challenge.....................................................47 6.1 - Objetivos.............................................................................................................................47 6.2 - Definición del problema........................................................................................................47 6.3 - Modelado del problema........................................................................................................48 6.4 - Conclusiones........................................................................................................................51 Capítulo 7 - Conclusiones y trabajo futuro...........................................................................53 7.1 - Trabajo futuro.....................................................................................................................53 7.2 - Conclusiones a nivel personal................................................................................................54 Anexo I - Gestión del proyecto............................................................................................57 I.1 - Metodología de desarrollo.....................................................................................................57 I.2 - Fases del proyecto................................................................................................................57 I.3 - Gestión de tiempo y esfuerzo.................................................................................................59 I.4 - Supervisión del proyecto........................................................................................................62 I.5 - Herramientas de gestión utilizadas.........................................................................................62 Anexo II - Tecnologías utilizadas.........................................................................................65 Anexo III - Manual de usuario.............................................................................................67 III.1 - Instalación del sistema........................................................................................................67 III.2 - Configuración del sistema....................................................................................................68 III.3 - Utilización del sistema........................................................................................................70 Anexo IV - Registros del sistema.........................................................................................73 IV.1 - Características comunes......................................................................................................73 IV.2 - Registro de Grids................................................................................................................75 IV.3 - Registro de Grids fiables.....................................................................................................76 IV.4 - Registro de usuarios...........................................................................................................77 IV.5 - Registro de aplicaciones......................................................................................................79 Anexo V - Broker de coordinación.......................................................................................83 V.1 - Comunicación entre los componentes del sistema..................................................................83 V.2 - Identificación de los trabajos................................................................................................86 V.3 - Interfaz de programación.....................................................................................................87 Anexo VI - Componente de gestión de fallos........................................................................89 VI.1 - Arquitectura general del componente..................................................................................89 VI.2 - Tipos de errores y acciones correctoras................................................................................91 VI.3 - Gestor de fallos..................................................................................................................93 VI.4 - Motor de reglas..................................................................................................................94 VI.5 - Registro de recursos fiables.................................................................................................99 VI.6 - Diagrama de clases...........................................................................................................100 Anexo VII - Componente de movimiento de datos..............................................................101 VII.1 - Descripción del problema y solución utilizada....................................................................101 VII.2 - Descripción del componente.............................................................................................103 Anexo VIII - Mediadores...................................................................................................109 VIII.1 - Arquitectura general de un mediador...............................................................................109 VIII.2 - Job Manager..................................................................................................................111 VIII.3 - Middleware Adapter........................................................................................................112 VIII.4 - Internal Resource Registry...............................................................................................113 VIII.5 - Job Monitor...................................................................................................................113 VIII.6 - Mediador de Condor.......................................................................................................113 VIII.7 - Mediador de gLite..........................................................................................................114 VIII.8 - Mediador de Amazon EC2..............................................................................................116 Anexo IX - Evaluación del sistema.....................................................................................119 IX.1 - Métricas de evaluación......................................................................................................119 IX.2 - Definición de experimentos................................................................................................119 IX.3 - Resultados........................................................................................................................126 IX.4 - Conclusiones.....................................................................................................................129 Anexo X - Caso de estudio: First Provenance Challenge.....................................................131 X.1 - Concepto de provenance....................................................................................................131 X.2 - Aparición del First Provenance Challenge...........................................................................132 X.3 - Objetivos del First Provenance Challenge............................................................................132 X.4 - Definición del problema.....................................................................................................133 X.5 - Modelado del problema......................................................................................................136 Glosario............................................................................................................................141 Bibliografía.......................................................................................................................143 Referencias bibliográficas............................................................................................................143 Referencias Web........................................................................................................................144 Índice de figuras Figura 1: Arquitectura general del sistema........................................................................................23 Figura 2: Formato de tupla utilizado para describir un trabajo..........................................................29 Figura 3: Formato utilizado para una tupla de lectura.......................................................................30 Figura 4: Arquitectura genérica de los componentes que implementan los registros............................32 Figura 5: Ejemplo de tuplas utilizadas para el despliegue de trabajos.................................................33 Figura 6: Algoritmo para la política de emparejamiento competitivo..................................................33 Figura 7: Arquitectura del componente de gestión de fallos...............................................................35 Figura 8: Traza de eventos del componente de gestión de fallos........................................................36 Figura 9: Tipos de errores identificados en el sistema........................................................................37 Figura 10: Identificación de un fichero. a) Identificación con URI 'file'. b) Identificación con URI 'sftp'. .......................................................................................................................................................39 Figura 11: Árbol de decisión para las URIs.......................................................................................39 Figura 12: Arquitectura general de un mediador...............................................................................40 Figura 13: Gráfica que muestra la sobrecarga del framework al aumentar el número de tareas en paralelo............................................................................................................................................45 Figura 14: Gráfica que compara Taverna y el framework en términos de escalabilidad........................45 Figura 15: Imágenes cerebrales de alta resolución resultado de la ejecución del First Provenance Challenge,........................................................................................................................................48 Figura 16: Modelo del workflow científico del First Provenance Challenge con Renew........................49 Figura 17: Modelo del workflow científico del First Provenance Challenge con Taverna. a) Modelo general del workflow. b) Modelo concreto para el subworkflow align_warp....................................57 Índice de tablas Tabla 1: Herramientas de gestión de workflows científicos en Grids. Modelado .................................16 Tabla 2: Herramientas de gestión de workflows científicos en Grids. Despliegue y ejecución................20 Tabla 3: Acciones correctoras para los diferentes tipos de errores......................................................38 4. Debe ser flexible desde el punto de vista de los usuarios que pueden acceder al sistema. El framework puede ser utilizado por diferentes usuarios que pueden tener permisos de acceso a diferentes entornos de ejecución. Por tanto, el sistema debe ser capaz de gestionar los diferentes usuarios existentes junto con los diferentes recursos accesibles por parte de cada usuario. Existen diversas formas de implementar esta funcionalidad, como los perfiles de usuario o las políticas de personalización de usuario. •Adaptabilidad y tolerancia a cambios dinámicos en el entorno. El framework debe ser capaz de adaptarse a las condiciones cambiantes del entorno en lo que se refiere a usuarios existentes, infraestructuras disponibles y aplicaciones definidas. De esta forma, debe ser posible definir nuevos usuarios, entornos de ejecución y aplicaciones sin que la ejecución del sistema se vea afectada. •Gestión de los fallos encontrados. El sistema debe ser capaz de gestionar los fallos que aparezcan al ejecutar un workflow, ya sean fallos motivados por un error en el modelo o por un fallo en la infraestructura de computación. •Incorporación con los entornos de computación disponibles. El framework debe incorporar las diferentes infraestructuras Grid de computación disponibles como son el caso de Hermes, Piregrid y Aragrid. Además, debe permitir la inclusión de infraestructuras de computación confiables, en las que se garantiza que no van a existir fallos en los recursos de computación. En el caso que nos ocupa se utilizará Amazon EC2 (Amazon Elastic Compute Cloud) [W9] como infraestructura confiable. •Independencia entre la capa de modelado y la capa de despliegue y ejecución. El modelado de workflows debe ser independiente de la infraestructura concreta en la que se va a ejecutar el mismo. •Compatibilidad con otras herramientas de modelado de workflows científicos. Gracias a la independencias entre la capa de modelado y la capa de ejecución, el sistema debe ser capaz de desplegar workflows modelados con otra herramienta diferente. •Facilidad de utilización y configuración. La configuración y utilización del sistema debe ser sencilla. No debe ser necesaria la intervención de una persona especializada en el manejo de la infraestructura para configurar el sistema o para ejecutar los workflows. 1.4 - Organización de la memoria El resto de esta memoria se organiza de la siguiente forma: •Capítulo 2. Puesta en contexto. Se describen los conceptos fundamentales propios del contexto en el que se enmarca el proyecto. •Capítulo 3. Estado del arte. Se analizan los diferentes sistemas existentes en la actualidad y se realiza una comparación exhaustiva de los mismos. •Capítulo 4. Modelado e implementación. Se presenta el diseño y la implementación del sistema. •Capítulo 5. Evaluación del sistema. Se analiza el sistema desde el punto de vista de rendimiento y escalabilidad, comparando el mismo con otros sistemas existentes. 6 | Sergio Hernández de Mesa •Capítulo 6. Caso de estudio: First Provenance Challenge. Se proporciona un caso de estudio en el área de la obtención de imágenes cerebrales de alta resolución. •Capítulo 7. Conclusiones y trabajo futuro. Se ofrecen las conclusiones, tanto a nivel técnico como personal, a las que se ha llegado tras la realización del proyecto. Asimismo, se describen posibles líneas futuras de trabajo. Adicionalmente, se incluyen una serie de anexos que ofrecen información adicional para completar los contenidos ofrecidos en la memoria principal: •Anexo I - Gestión del proyecto. Se describe la metodología de trabajo utilizada, la gestión del tiempo y el esfuerzo y las herramientas de gestión utilizadas. •Anexo II - Tecnologías utilizadas. Se enumeran las principales tecnologías utilizadas durante el desarrollo de este proyecto, añadiendo una breve descripción de las mismas e indicando en qué parte del sistema se han utilizado. •Anexo III - Manual de usuario. Se proporciona el manual de usuario que describe como instalar y utilizar el sistema. •Anexo IV - Registros del sistema. Se detallan los aspectos más relevantes de los registros de información utilizados en el sistema. Se proporcionan los esquemas que deben seguir los ficheros de configuración y ejemplos de los mismos. •Anexo V - Broker de coordinación. Se describen las modificaciones realizadas en el broker de coordinación utilizado. •Anexo VI - Componente de movimiento de datos. Se detalla el componente de movimiento de datos, indicando su utilidad y detalles acerca de la implementación del mismo. •Anexo VII - Componente de gestión de fallos. Se detalla el componente de gestión de fallos, indicando los fallos que son gestionados, las políticas de recuperación ante dichos fallos y detalles sobre la implementación del componente. •Anexo VIII - Mediadores. Se detallan los aspectos más relevantes de la utilización e implementación de los diferentes mediadores utilizados. •Anexo IX - Evaluación del sistema. Se analiza el sistema desde el punto de vista de rendimiento y escalabilidad, comparando el mismo con otros sistemas de gestión de workflows científicos. •Anexo X - Caso de estudio: First Provenance Challenge. Se proporciona un caso de estudio en el área de la obtención de imágenes cerebrales de alta resolución. Además, se incluyen dos secciones adicionales tras los anexos: •Glosario: Listado de términos y abreviaturas utilizadas frecuentemente en esta memoria junto con su significado. •Bibliografía: Listado de referencias bibliográficas y referencias web utilizadas en esta memoria. 7 Capítulo 1 – Introducción | 8 | Sergio Hernández de Mesa Capítulo 2 - Puesta en contexto Hay una gran cantidad de términos y conceptos necesarios para comprender el contexto de este proyecto y las diferentes magnitudes del mismo. En este capítulo, vamos a explicar los más relevantes para facilitar la comprensión tanto de la memoria como del proyecto en general. 2.1 - Computación Grid La computación Grid es un paradigma de computación distribuida en el cual un conjunto de recursos altamente heterogéneos y geográficamente distribuidos se engloban de forma transparente para trabajar como uno solo. De esta forma, se logra la visión de tener un solo computador muy potente, con recursos muy elevados, tanto en lo que respecta a potencia de cálculo como a memoria o a capacidad de almacenamiento. En general, este tipo de sistemas son sistemas de alta disponibilidad y de propósito general que dan servicio a un gran número de usuarios. Los usuarios que tienen características, intereses y objetivos comunes forman una organización virtual (Virtual Organization, VO) y definen su propia forma de compartir información. Las VOs facilitan la compartición de contenidos entre sus usuarios, de una forma segura, sin que los usuarios de otras VOs tengan acceso a dichos contenidos. Una de las características clave de este tipo de infraestructuras es la heterogeneidad de los recursos que la componen. Un grid puede estar compuesto por ordenadores de muy diversas características utilizando diferentes Sistemas Operativos. Otro aspecto clave es la naturaleza dinámica de este tipo de sistemas. Los recursos que componen el Grid varían constantemente, haciendo que las características del mismo estén en continuo cambio. Debido a las dos circunstancias anteriores, los sistemas Grid están sujetos a la aparición de fallos. Los cambios que surgen en el entorno de computación pueden provocar fallos en los trabajos que se están ejecutando en el Grid, por ejemplo, si el trabajo se está ejecutando en un nodo que se desconecta del Grid. Asimismo, debido al elevado número de usuarios que acceden al Grid, es posible que el trabajo de un usuario sea expulsado de un nodo para ejecutar en el mismo un trabajo de otro usuario con mejor prioridad. Los tres aspectos anteriores hacen necesaria la utilización de un middleware que gestione la ejecución de trabajos en la infraestructura. Un middleware es un sistema que se encarga de englobar y gestionar todos los servicios y recursos que ofrece el Grid bajo una única interfaz común. Algunos de los aspectos principales de los que se encarga el middleware son: gestión dinámica de los recursos, despliegue de los trabajos en los diferentes nodos del Grid, gestión de los fallos producidos, control de acceso y seguridad, etc. 2.2 - Computación Cloud La computación Cloud o computación en la nube es un nuevo paradigma de computación que para muchos corresponde con la evolución natural de la computación Grid. Este nuevo paradigma se basa en el ofrecimiento de servicios y aprovisionamiento de recursos de computación a través de Internet bajo demanda y de una forma flexible, adaptable y altamente configurable. 9 Capítulo 2 – Puesta en contexto | Una de las principales diferencias de la computación Cloud respecto a la computación Grid es que, en este nuevo paradigma, el usuario no conoce la ubicación real de los recursos computacionales que está utilizando si no que en su lugar trabaja en una máquina virtual que puede corresponder a cualquiera de los recursos del proveedor del servicio de Cloud. La principal ventaja que aporta es la posibilidad de solicitar recursos bajo demanda de una forma flexible. El usuario solicita recursos de computación para satisfacer las necesidades que tiene en un momento determinado, pagando solamente por el consumo efectuado y no de una forma global. De esta forma, el usuario puede ejecutar sus experimentos en una infraestructura que se adapta a las necesidades del mismo provocando un mejor aprovechamiento de los recursos. Por contra, uno de sus principales problemas es que la información gestionada por el usuario también se almacena en la nube, es decir, en los servidores del proveedor. Esto implica que ahora el usuario se hace dependiente del proveedor del servicio de Cloud ya que éste almacena su información. Otro de los problemas que presenta esta aproximación es que, al almacenar el proveedor la información y gestionar la misma, el usuario pierde el control sobre su información con los consiguientes problemas de seguridad y propiedad que esto conlleva. La computación Cloud está teniendo un gran éxito en el mundo empresarial. Sin embargo, la adopción en el ámbito científico es todavía muy baja por la falta de infraestructuras que permitan la gestión de workflows científicos en infraestructuras de computación Cloud y por el coste asociado de este nuevo paradigma. Por ello, su utilización actual se limita a cubrir necesidades puntuales para poder cumplir fechas límites. 2.3 - Workflows científicos Un workflow se define como un conjunto de tareas, de cualquier tipo, conectadas entre sí en un determinado orden de acuerdo a las dependencias existentes entre las mismas. Dentro del ámbito de la computación, estas tareas se refieren a actividades computacionales o a otro workflow de las mismas características. En el ámbito de las ciencias de la vida los workflows se denominan workflows científicos y se caracterizan por estar compuestos por un gran número de tareas, computacionalmente muy costosas, y un manejo complejo de los datos involucrados. Los workflows se han establecido como una de las herramientas principales para representar los experimentos realizados por los investigadores de los diferentes campos de las ciencias de la vida. Sin embargo, no existen lenguajes, metodologías o herramientas estándares para su modelado. Por tanto, han surgido una gran variedad de alternativas para el mismo, complicándose enormemente compartir los modelos realizados entre diferentes investigadores. Por su parte, los sistemas de gestión de workflows científicos ofrecen su propio lenguaje de modelado. Por cuestiones de simplicidad, los usuarios utilizan el lenguaje asociado al sistema de gestión que les permite ejecutar sus experimentos debido a que la traducción entre lenguajes de modelado no es siempre sencilla e introduce un paso extra en el proceso. Esto provoca que los modelos sean muy dependientes del sistemas y, en consecuencia del Grid en el que se ejecuten los mismos, complicando su reutilización por parte de otras personas. Los workflows se pueden clasificar en dos grandes grupos: workflows dirigidos por el control y workflows dirigidos por los datos. En los primeros, las interacciones entre las diferentes tareas que forman el workflow definen las dependencias entre las mismas. En los 10 | Sergio Hernández de Mesa segundos, las dependencias representan el flujo de los datos entre las tareas que producen los mismos y las tareas que los consumen. Asimismo, también existen lenguajes híbridos que mezclan características de ambos grupos. No existe un consenso sobre que tipo de workflows son mejores, si no que suele depender del tipo de problema o del dominio de aplicación del mismo. El problema reside en que en muchas ocasiones el lenguaje proporcionado por el sistema no es adecuado para representar el workflow lo que da lugar a problemas en el modelado del mismo. 2.4 - Sistemas de gestión de workflows científicos Los sistemas de gestión de workflows ofrecen herramientas y servicios para modelar, desplegar y ejecutar workflows científicos de un modo automático. El objetivo principal de estos sistemas consiste en facilitar la labor del usuario abstrayendo al mismo de la complejidad inherente que presentan los recursos físicos en los que se despliegan las tareas. Con ese mismo objetivo, estos sistemas automatizan algunas tareas como el movimiento de datos que hay que realizar entre los recursos para permitir la ejecución de las tareas, la obtención de los logs o registros de ejecución de las tareas ejecutadas o la coordinación de las diferentes tareas de acuerdo a las dependencias establecidas por el usuario en el modelo. Este tipo de sistemas surgió como respuesta a las necesidades de los científicos a la hora de ejecutar sus experimentos en infraestructuras de computación de alto rendimiento. En este tipo de entornos de ejecución, la coordinación de las diferentes tareas de un workflow o el movimiento de datos entre los diferentes nodos de la infraestructura se vuelve un aspecto complicado. Asimismo, los sistemas de gestión de workflows científicos también intentan facilitar la labor del usuario automatizando procesos repetitivos como puede ser la visualización de los resultados o la recuperación de los logs de ejecución. Para entender este tipo de sistemas, es necesario conocer cómo es el usuario que utiliza los mismos. Normalmente los usuarios son científicos de diferentes campos de las ciencias de la vida como biología, geología, genética, astronomía, etc. En general, los científicos de estos campos tienen un bajo conocimiento de aspectos informáticos. Esto se traduce en que en general el científico no está dispuesto a realizar un esfuerzo extra para aprender como se utilizan diferentes sistemas y valorar cuál es el más adecuado para sus intereses. En su lugar, en general, los científicos se limitan al aprendizaje y utilización de un único sistema. Por tanto, un requisito fundamental en el desarrollo de estos sistemas es la simplicidad en lo que se refiere a la interacción con el usuario, ya que este es un aspecto clave para el mismo. Por esta razón, en general, los sistemas de gestión de workflows científicos proporcionan interfaces gráficas para componer los mismos de una forma sencilla e intuitiva. Sin embargo, esto provoca que los workflows desarrollados no puedan ser utilizados por otros sistemas, lo que dificulta la compartición de los mismos. Debido a esto, algunos sistemas se han orientado hacia un grupo determinado proporcionando servicios avanzados orientados al desarrollo de workflows dentro de ese campo de aplicación, es el caso de Taverna [W8] que está orientado al campo de la bioinformática. Este último aspecto es una de las claves de la existencia de numerosos sistemas de gestión de workflows científicos y de que no haya ningún sistema que se haya impuesto al resto. 11 Capítulo 2 – Puesta en contexto | Por otra parte, como contraposición a la sencillez que buscan los sistemas en la interacción con los usuarios, estos sistemas utilizan técnicas complejas para coordinar y ejecutar los workflows. Las infraestructuras de computación son altamente heterogéneas y se gestionan a través de middlewares muy diferentes, esto provoca que los sistemas de gestión de workflows sean muy dependientes del entorno de ejecución y hace necesario la utilización de mecanismos complicados para permitir la automatización de los diferentes aspectos ya comentados. A su vez, esto introduce un problema adicional: la configuración de los sistemas en lo que respecta al entorno de ejecución es muy compleja y requiere de personal especializado, lo que dificulta la puesta en marcha del sistema. Las diferentes alternativas que han aparecido siguen todas la misma filosofía: proporcionar un lenguaje de modelado sencillo de utilizar y que a la vez permita modelar workflows científicos complejos y sacar el máximo rendimiento posible de la infraestructura de computación a la hora de desplegar y ejecutar los workflows. Sin embargo, precisamente por esto surgen dos grandes problemas: •El modelado de los workflows es altamente dependiente del sistema. Como consecuencia, la compartición de workflows y la ejecución del mismo workflow en otra infraestructura se vuelve muy complicada. •El acoplamiento entre el sistema de gestión de workflows científicos y la infraestructura de computación es muy alto. De esta forma, la configuración del sistema en la infraestructura es compleja, la migración del sistema de una infraestructura a otra es difícil y la integración de diferentes infraestructuras de computación dentro del mismo sistema no es posible. En el Capítulo 3 se realiza una comparación de los sistemas de gestión de workflows científicos más destacables de acuerdo a sus características más relevantes. 2.5 – El modelo de coordinación Linda El modelo de coordinación Linda, propuesto originalmente por Carriero y Gelernter [B4, B5], se basa en el principio de comunicación generativa, es decir, en el consumo de una serie de estructuras pasivas de datos (tuplas, similares al concepto de listas en el lenguaje LISP) que son producidas por los participantes involucrados en la coordinación. Linda se compone de un espacio global de tuplas o pizarra y un conjunto de procesos que acceden al espacio de tuplas utilizando un conjunto reducido de operaciones atómicas: una operación out de escritura de tuplas en el espacio, una operación in para realizar la lectura destructiva de tuplas del espacio y una operación rd para realizar la lectura no destructiva. Las operaciones de lectura reciben como parámetro un patrón y devuelven una tupla del espacio que coincide con la descripción dada en el patrón, bloqueando al proceso invocante durante su ejecución. El éxito del modelo de coordinación Linda en los entornos de sistemas distribuidos se ha debido, principalmente, a su conjunto reducido de operaciones, a su característica de coordinación basada en los datos, y en la comunicación desacoplada en el tiempo entre procesos que pueden cooperar entre sí sin tener que adaptarse o anunciarse. En el caso de las operaciones de lectura, se pueden utilizar comodines que sustituyan tuplas enteras o atributos. Al utilizar un patrón sin comodines existirá un emparejamiento si 12 | Sergio Hernández de Mesa hay una tupla exactamente igual en el espacio de tuplas. Si, por el contrario, se utiliza un patrón con comodines, se pueden utilizar diferentes políticas de emparejamiento (políticas de matching) para determinar si existe concordancia. Las dos políticas más habituales son: •Emparejamiento fuerte. Los comodines del patrón sólo pueden corresponderse en la tupla emparejada con elementos atómicos (números enteros, número reales, cadenas, etc.) no con otras tuplas. •Emparejamiento débil. Los comodines del patrón pueden emparejarse tanto con elementos atómicos como con otras tuplas. Existen diversas implementaciones, tanto centralizadas como distribuidas, del modelo de coordinación Linda. En este proyecto utilizaremos WS-PTRLinda [B9], una implementación realizada en el marco del grupo GIDHE [W1] que utiliza las redes en redes [B6], la herramienta Renew [B7] y que se basa en la implementación anterior del grupo, RLinda [B2, B10]. 2.6 - MyExperiment Uno de los aspectos fundamentales para los investigadores es la adquisición y compartición de conocimiento. El trabajo de investigación consiste, en muchas ocasiones, en buscar técnicas, herramientas y datos y combinarlos para dar solución a algún problema determinado. El desarrollo de Internet y el crecimiento de la comunidad investigadora han provocado que exista una mayor cantidad de información en la red y que sea muy fácil acceder a la misma. Sin embargo, todavía existen barreras que limitan la compartición, principalmente de herramientas, ejemplos y resultados entre investigadores. De la misma forma, el grado de comunicación y colaboración entre los diferentes investigadores es todavía muy escaso. Para dar solución a estos problemas nace myExperiment [B8, W8], una red social para investigadores que fomenta la compartición de toda clase de información: publicaciones, workflows científicos, datos, resultados, logs de ejecución, etc. Actualmente (Agosto de 2011) cuenta con más de 3000 miembros, 200 grupos, 1000 workflows, 300 ficheros y 100 packs (conjuntos completos de información). El principal objetivo de esta comunidad es eliminar las barreras existentes en el mundo de la investigación. Uno de los principales avances que introduce es la oportunidad de compartir los experimentos realizados junto con sus datos, resultados y logs de ejecución (en los denominados packs), permitiendo al resto de investigadores acceder no sólo a su técnica o método si no también al experimento que lo muestra y con el que se han presentado los resultados. Esto fomenta la compartición, la reutilización y la comprobación de que los resultados son correctos. Asimismo, myExperiment da la oportunidad de crear grupos y comunidades y entablar una comunicación fluida con los diferentes investigadores de la comunidad. MyExperiment ha sentado las bases para lo que muchos consideran una nueva forma de investigación que regirá el mundo de la investigación científica, por lo menos en el ámbitos de las ciencias de la vida, en los próximos años. De hecho, ya han surgido algunos proyectos colaborativos basados en esta idea como, por ejemplo, SALAMI [W11], un proyecto multidisciplinar para el análisis de grandes cantidades de información musical. 13 Capítulo 2 – Puesta en contexto | 14 | Sergio Hernández de Mesa Capítulo 3 - Estado del arte La heterogeneidad de las infraestructuras de computación, la propia complejidad de los workflows científicos y la diversidad de áreas de aplicación de los mismos han provocado la existencia de una gran variedad de herramientas para modelar, desplegar y ejecutar workflows en entornos Grid. En este apartado, vamos a analizar los sistemas más empleadas y comúnmente aceptados dentro de la comunidad científica de acuerdo a las taxonomías presentadas en [B11, B12]. Se abordarán los diferentes enfoques existentes desde el punto de vista del modelado de workflows científicos y desde el punto de vista del despliegue y ejecución de dichos workflows. Esto corresponde con la visión que tanto los usuarios finales como los desarrolladores tienen de este tipo de infraestructura. Finalmente compararemos dichos sistemas de acuerdo a la clasificación realizada. 3.1 - Herramientas de modelado de workflows científicos Desde el punto de vista del modelado, los diferentes sistemas pueden clasificarse de acuerdo a las siguientes características: •Estructura . Un workflow científico está formado por una serie de tareas que deben ejecutarse en un cierto orden, de acuerdo a las dependencias existentes entre las mismas, ya sean éstas dependencias de datos o dependencias de control. A nivel conceptual, existen dos representaciones posibles: 1. Estructura de grafo acíclico dirigido (DAG). Estos workflows se caracterizan porque sólo permiten operaciones de secuencia, elección y paralelización, no permiten la utilización de bucles. 2. Estructura de grafo. Estos workflows se caracterizan por permitir la utilización de cualquier tipo de estructura de control, bucles incluidos. •Modelo . En lo que hace referencia al modelo o especificación del workflow, existen dos posibilidades: un modelo abstracto o un modelo concreto. 1. En un modelo abstracto, el workflow se define independientemente de la plataforma de ejecución. 2. En un modelo concreto, las tareas del workflow están ligadas a recursos físicos concretos en los que se ejecutarán posteriormente. •Sistema de composición . Respecto al sistema de composición de los workflows, podemos dividir los sistemas en sistemas de composición automática y sistemas dirigidos por el usuario. 1. Los sistemas automáticos generan workflows automáticamente a partir de una serie de requisitos indicados por el usuario. 2. Los sistemas dirigidos por el usuario requieren la edición directa del workflow. Dentro de este grupo, se pueden identificar dos técnicas de composición: 1. Técnicas basadas en representación textual, ya sea mediante un lenguaje de marcado tipo XML u otro tipo de lenguaje. 15 Capítulo 3 – Estado del arte | conocimiento completo del estado de los recursos y la capacidad de tomar decisiones de acuerdo a ese conocimiento. La naturaleza distribuida y heterogénea de los Grids complica enormemente el proceso de crear y actualizar esta base de conocimiento. Como consecuencia, los brokers se integran, o al menos están fuertemente ligados, con el middleware del Grid y, por tanto, no es trivial migrar un broker de un middleware a otro [B3]. Por otra parte, el scheduling dinámico se aprovecha del conocimiento actualizado del entorno de ejecución pero no es consciente de la estructura completa del workflow y sus implicaciones de cara a conseguir una distribución óptima de las tareas. Independientemente del tipo de scheduling, se pueden utilizar técnicas de simulación para evaluar y determinar cuál es la estrategia óptima de despliegue para cada problema [B14, B15]. En cualquier caso, existen propuestas intermedias que buscan aprovechar las ventajas de ambos tipos de scheduling [B15, B16]. El sistema de coordinación de los diferentes sistemas de workflows ha sido tradicionalmente basado en grupos para facilitar y fomentar la compartición de información entre los diferentes miembros de una misma VO. Sin embargo, existen nuevas apuestas que optan por utilizar un espacio compartido. Por ejemplo, el sistema Gridbus utiliza un modelo de coordinación basado en Linda para comunicar eventos entre los diferentes componentes del sistema [B13]. Las ventajas fundamentales de esta alternativa residen en la flexibilidad del mecanismo y en que permite desacoplar los elementos del sistema haciéndolos menos dependientes del entorno concreto de ejecución. En lo referente al movimiento de datos no hay un consenso en lo que respecta a la mejor alternativa para realizar el mismo. En general, los sistemas tienden a utilizar modelos dirigidos por el usuario por la dificultad de conocer la ubicación exacta de los datos. Los grandes avances en este aspecto han surgido por la introducción de protocolos de transferencia específicos para infraestructuras Grid, como GridFTP [B17]. Debido a la naturaleza de los Grids, la posibilidad de que la ejecución de una tarea falle, ya sea por un fallo en el nodo, un fallo de la red u otra circunstancia, es un aspecto a tener en cuenta. Existen una serie de técnicas sencillas como volver a ejecutar la tarea, ya sea en ese mismo nodo o en otro diferente, que son adoptadas en la mayoría de los casos ya que permiten la recuperación del fallo de forma satisfactoria en muchas ocasiones. Sin embargo, otras veces la naturaleza del fallo requiere de mecanismos más complejos como generar un workflow de recuperación que permita volver a ejecutar el mismo desde el punto en el que falló. Finalmente, otro mecanismo posible consiste en utilizar algún tipo de scheduling basado en seguridad que ante una ejecución problemática vuelva a ejecutar la tarea en un recurso de computación fiable. 22 | Sergio Hernández de Mesa Capítulo 4 - Modelado e implementación En este capítulo se analizarán los aspectos más relevantes de las fases de análisis, diseño e implementación del sistema. Para ello se explicará la arquitectura utilizada en el sistema y se detallaran cada una de las capas que componen la misma, así como los diferentes componentes desarrollados. 4.1 - Arquitectura del sistema En la figura 1 se muestra la arquitectura del sistema. Como puede observarse, se compone de tres capas diferentes: la capa de modelado, la capa de ejecución y la capa de infraestructuras de computación. Figura 1: Arquitectura del sistema. 23 Capítulo 4 – Modelado e implementación | Capa de modelado En primer lugar, la capa de modelado ofrece una serie de herramientas para programar workflows científicos, ya sea a través de Taverna [W8] u otro sistema de gestión de workflows existente o bien a través de Renew [B7]. Este aspecto es muy importante porque en el ámbito de las ciencias de la vida, los usuarios de este tipo de sistemas suelen tener dificultades a la hora de aprender nuevos lenguajes o técnicas de modelado. Por tanto, al permitir al usuario utilizar su lenguaje de modelado habitual, dotamos al sistema de una mayor usabilidad, ya que no se requiere que el usuario aprenda un nuevo lenguaje de modelado, si no que puede utilizar el lenguaje con el que trabaja habitualmente. La primera de las alternativas que ofrecemos para el modelado de workflows científicos es la utilización de algún sistema de gestión de workflows ya existente, como por ejemplo Taverna. Este aspecto es realmente novedoso y no se presenta en los sistemas de gestión existentes. En nuestro caso, surge como algo natural gracias a que la capa de modelado y la capa de ejecución se encuentran desacopladas, por lo que cualquier sistema de modelado puede utilizar la infraestructura de ejecución desarrollada. Para ello, el broker de recursos ofrece una interfaz de servicios Web que permite la incorporación del sistema a otro entorno ya existente. La segunda alternativa propuesta es la utilización de las reference nets o redes de referencia, una subclase de las redes de Petri de alto nivel, para modelar workflows científicos desde la perspectiva del paradigma de las redes-en-redes [B6]. La utilización de las redes de Petri como lenguaje de modelado de workflows ya ha sido estudiada y sus beneficios se muestran en [B18]. Asimismo, algunas ventajas adicionales son: la posibilidad de modelar workflows de forma independiente a la infraestructura de computación y la posibilidad de modelar cualquier tipo de workflow, tanto orientado a datos como orientado al control, gracias a la potencia del formalismo. Para esta alternativa, se propone la utilización de Renew como herramienta de modelado. Algunas de las principales ventajas que nos proporciona Renew con respecto a otras herramientas de modelado es: •Independencia de la plataforma. Renew es una herramienta desarrollada en Java por lo que nos proporciona independencia de la plataforma en la que vamos a trabajar. Este aspecto es fundamental ya que necesitamos una herramienta que pueda ser utilizada en la heterogeneidad de sistemas utilizados por los usuarios. •Interfaz gráfico y manejo intuitivo. A diferencia de otras herramientas de modelado de workflows científicos, Renew nos proporciona un interfaz gráfico para modelar los mismos. Además, se trata de un interfaz muy intuitivo y fácil de utilizar, lo que hace de Renew una alternativa estupenda para el ámbito en el que nos encontramos, en el que los usuarios son poco experimentados y necesitan de mecanismos sencillos que les permitan trabajar cómoda y rápidamente. •Incorporación de un motor de ejecución. Renew incorpora un motor que nos permite realizar la ejecución efectiva y directa del sistema modelado. De esta forma, además de modelar el sistema, podemos comprobar que hemos realizado el modelado correctamente de forma empírica. Otra opción muy interesante es la simulación temporizada, en lugar de ejecutar el modelo. 24 | Sergio Hernández de Mesa •Posibilidad de ejecutar código Java. Otra de las características clave que hacen de Renew una herramienta perfecta para el sistema desarrollado, es la posibilidad de ejecutar código Java embebido dentro del sistema modelado (Renew soporta un amplio subconjunto de instrucciones de Java). Esta característica nos va a permitir interactuar de una forma sencilla y natural con el resto de componentes del sistema sin necesidad de utilizar herramientas intermedias o de modificar la herramienta utilizada. Finalmente, otra alternativa sería traducir el modelo desarrollado, por ejemplo, con Taverna, a reference nets. Este aspecto no introduce una gran complejidad pudiendo realizarse esa traducción de forma manual. Además, como posible trabajo futuro se plantea el desarrollo de un plugin que realice esta traducción de forma automática. Capa de ejecución La capa de ejecución es la encargada de permitir la ejecución de los diferentes trabajos definidos en el modelo del workflow científico en los recursos de computación. En un primer paso, el entorno de ejecución de Renew, o del sistema de gestión utilizado para modelar los experimentos, permite ejecutar de forma efectiva el modelo desarrollado. En esta primera versión del framework, el entorno de ejecución de Renew utiliza directamente las interfaces de programación del broker de mensajes, en lugar de utilizar la interfaz de servicio Web del mismo por cuestiones de simplicidad y eficiencia (en esta versión todos los componentes se encuentran en la misma máquina). En cualquier caso, esta segunda posibilidad será desarrollada en el futuro y puede ser utilizada actualmente si todos los componentes están en la misma máquina. La coordinación y comunicación entre los diferentes componentes de un sistema de gestión de workflows científicos se ha solventado tradicionalmente utilizando componentes que se encuentran muy acoplados unos con otros. Además, este acoplamiento afecta tanto a los componentes de nivel de ejecución del sistema como a los componentes encargados del modelado de los problemas. De esta forma, la integración de nuevos componentes tiene un impacto muy grande en todo el sistema, dificultando enormemente esta tarea. El uso de un broker de mensajes basado en el modelo de coordinación Linda aporta un nuevo enfoque en este aspecto. Linda promueve la coordinación entre los diferentes componentes a través de tuplas que son depositadas y extraídas de un espacio compartido. Además, cada componente puede estar distribuido, es decir, puede encontrarse en una máquina diferente y utilizar Linda para comunicarse con el resto de componentes del sistema. Esta característica permite desacoplar los diferentes elementos que forman el sistema haciendo que el mismo sea más flexible y adaptable. En nuestro caso hemos utilizado como broker de mensajes WS-PTRLinda [B2, B9], una implementación del modelo de coordinación Linda del grupo de investigación GIDHE [W1]. Las principales mejoras que aporta esta implementación son la adición al modelo de Linda de una capa de temporización, permite que las tuplas sólo sean válidas durante un período de tiempo determinado, y una capa de persistencia, permite almacenar las tuplas en una base de datos. Asimismo, WS-PTRLinda incluye una capa que permite interaccionar con el sistema como un servicio web SOAP o REST, haciendo que el mismo sea accesible desde cualquier punto. 25 Capítulo 4 – Modelado e implementación | La utilización de Linda nos permite conectar al sistema un número variable de componentes que aporten diferentes funcionalidades. Posibles componentes serían un componente que gestione los fallos que se produzcan al ejecutar los trabajos, un componente de monitorización que permita obtener información detallada de los trabajos que se están ejecutando o un componente de scheduling avanzado que permita realizar el despliegue de los trabajos en base a diferentes parámetros y configuraciones. En esta primera versión se ha desarrollado el componente de gestión de fallos para ilustrar cómo se pueden integrar diferentes componentes en el sistema. Se eligió implementar este componente por su importancia dentro del ámbito de la computación Grid. La aparición de fallos es un elemento habitual debido a la naturaleza de las infraestructuras de computación y a la complejidad de los workflows científicos. Estos fallos pueden deberse tanto a errores en el modelado del workflow científico, fallos propios de la aplicación que se está ejecutando o fallos provocados por la propia infraestructura. Los errores que pueden aparecer son de naturaleza muy diversa, produciéndose por una mala definición del trabajo que se quiere ejecutar, un error propio del trabajo que se está ejecutando o un fallo de la infraestructura. Por ejemplo, si un nodo del grid falla, todos los trabajos que se estén ejecutando en el nodo fallarán. Por tanto, la gestión de estos fallos es un aspecto crítico que no puede ser obviado y que hay que gestionar de una manera adecuada. Capa de infraestructuras de computación La capa de más bajo nivel es la capa de infraestructuras de computación. Esta capa representa los diferentes grids en los que se van a ejecutar los trabajos. Como ya se ha comentado a lo largo de esta memoria, las infraestructuras de computación utilizadas en él ámbito científico son altamente heterogéneas. Por tanto, para gestionar de una manera automática y transparente para el usuario la ejecución de las tareas en los recursos disponibles, se utiliza un conjunto de mediadores que interactúan con el middleware del grid. Estos mediadores se encargan de la ejecución de los trabajos junto con un componente que mueve los datos necesarios entre los diferentes grids e incluso entre los grids y servidores externos. La utilización de un conjunto de mediadores permite que el sistema pueda integrar cualquier tipo de grid, independientemente del middleware que utilice. Para ello, sólo es necesario implementar un mediador que gestione y controle la ejecución de los trabajos en ese entorno de ejecución concreto, gracias a que la descripción de los trabajos y la coordinación de los componentes es independiente de la infraestructura de computación. En nuestro caso, hemos desarrollado un mediador para el middleware Condor y otro mediador para el middleware gLite, ya que son los middlewares de computación que gestionan las infraestructuras grid a las que tiene acceso el grupo de investigación GIDHE. La implementación de un nuevo mediador, que gestione la ejecución en otro sistema, puede realizarse de forma similar a la utilizada para implementar los mediadores ya desarrollados, incluyendo las particularidades de ejecución que presente ese sistema. Por otro lado, uno de los aspectos más importantes de los que se encarga un middleware es de realizar el movimiento de los datos entre los diferentes recursos del grid. La necesidad de este movimiento viene determinada por la abstracción de que todo el grid es un 26 | Sergio Hernández de Mesa único supercomputador. Para lograr la misma, el movimiento de los datos necesarios para ejecutar un trabajo debe ser completamente automático y transparente para el usuario. El auge de las infraestructuras de computación Grid ha propiciado la aparición de protocolos de transferencia de ficheros especializados. Este es el caso de GridFTP [B17] que rápidamente se ha establecido como estándar para el movimiento de datos dentro del grid. En nuestro caso, el problema cambia significativamente. El sistema desarrollado no pretende sustituir al middleware utilizado en el grid, si no englobar diferentes middlewares para integrar varios grids. Esto nos permite aprovechar las características de los middlewares como es el caso de la gestión de los datos dentro de los recursos del grid. Por tanto, nuestro problema se refiere al movimiento de datos entre diferentes grids de forma automática. 4.2 - Modelado de workflows científicos El objetivo fundamental del sistema en lo que se refiere al modelado de workflows científicos aborda dos cuestiones fundamentales. En primer lugar, se pretende conseguir que el modelado sea independiente del entorno de ejecución utilizado. En segunda lugar, se pretende que el sistema sea capaz de utilizar modelos realizados con diferentes lenguajes de modelado. Para conseguir el primero de los objetivos hay aspectos clave como permitir identificar los trabajos de forma estándar, mientras que para el segundo objetivo es fundamental el modelo arquitectural del sistema que permite que los componentes del mismo se encuentren desacoplados. Interoperabilidad con diferentes herramientas de modelado Hay una gran variedad de sistemas de workflows científicos más o menos asentados en la comunidad científica. Además, los usuarios de los mismos suelen tener dificultades a la hora de aprender el funcionamiento de un nuevo sistema y se muestran reacios a aprender nuevos lenguajes de modelado. Por ello, uno de nuestros objetivos fundamentales ha sido permitir ejecutar workflows científicos modelados con diferentes técnicas y herramientas. En este aspecto, el uso de Linda como sistema de coordinación nos abstrae del sistema y lenguaje de modelado utilizado ya que la introducción en el sistema de las tuplas que describen los trabajos es independiente del contexto en el que se generan las mismas. El broker WS-PTRLinda, a través de su interfaz de servicios web, nos facilita las operaciones de escritura, lectura destructiva y lectura no destructiva del modelo de coordinación Linda. Sin embargo, la utilización directa de esta interfaz no es conveniente por dos razones fundamentales. En primer lugar, la utilización directa de esta interfaz implica que el usuario tiene que ser consciente de aspectos internos del sistema, como las palabras claves usadas para identificar las tuplas en los componentes (estos aspectos se abordan en la sección siguiente). En segundo lugar, es necesario comprobar que las tuplas utilizadas en las operaciones están bien formadas y no contienen errores. Por tanto, se ha desarrollado una clase que ofrece tres operaciones para facilitar la labor del usuario. Se trata de la clase Broker que proporciona los siguientes métodos estáticos para facilitar la utilización de la infraestructura desde cualquier sistema de modelado: 27 Capítulo 4 – Modelado e implementación | •out(tupla). Esta operación permite desplegar un trabajo con el formato especificado introduciendo la tupla indicada en el broker. En caso de que la tupla no esté bien formada, se generará una tupla de error que será tratada por el componente de gestión de fallos. Se trata de una operación no bloqueante de forma que es necesario utilizar una operación in posteriormente para recuperar el fin del trabajo. •in(patrón). Esta operación permite recuperar el fin de un trabajo. Además, realiza tareas adicionales, como almacenar el log del trabajo, de forma completamente transparente al usuario. •outIn(tupla). Esta operación permite desplegar un trabajo al igual que la operación out con la diferencia de que en este caso se trata de una operación bloqueante. Esta operación engloba una primera operación out y una segunda operación in. En las anteriores operaciones se utiliza la operación de lectura destructiva para recuperar las tuplas del broker. La razón de la utilización de lectura destructiva se debe a que no tiene sentido que la tupla que describe un determinado trabajo continúe en el broker de mensajes una vez que la misma ha sido tratada por el mediador correspondiente. Definición de los trabajos El broker Linda utiliza la tupla como elemento de comunicación. Por tanto, es indispensable que las tuplas utilizadas para describir los trabajos a ejecutar utilicen un lenguaje de descripción totalmente independiente de la infraestructura de ejecución. Para la elaboración de dicho formato se ha seguido el formato JSDL [W20], un estándar para la especificación de tareas, particularmente en entornos grid promovido por el Open Grid Forum [W22]. De esta forma, el formato utilizado para la descripción de las tuplas aborda cuatro aspectos fundamentales: 1. Descripción del trabajo. La primera cuestión se refiere a la descripción tanto del trabajo como de los ficheros involucrados en la ejecución del mismo. En este aspecto se deben definir cuatro elementos: •Nombre de la aplicación utilizado para identificar la misma. •Argumentos utilizados para la ejecución de la aplicación (pueden ser nulos). •Lista de ficheros de entrada separados por un espacio en blanco (puede ser nula). •Lista de ficheros de salida separados por un espacio en blanco (puede ser nula). 2. Descripción de la entrada y salida de la aplicación. En las tareas ejecutadas en infraestructuras Grid no se permite la interacción con el usuario a través de la pantalla y el teclado. Para permitir la interacción se utilizan ficheros. Para ello debe indicarse: •Fichero utilizado como entrada estándar (puede ser nulo). •Fichero utilizado como salida estándar (puede ser nulo). •Fichero utilizado como salida de error (puede ser nulo). 28 | Sergio Hernández de Mesa 3. Requisitos de calidad de servicio. Para definir los requisitos de calidad de servicio se contempla la utilización de dos campos: •Fecha límite en la que debe finalizar la tarea. •Presupuesto máximo que puede ser utilizado para ejecutar la tarea. 4. Entorno de ejecución. En este último campo se incluye la información relativa al entorno utilizado para la ejecución de la aplicación. Los aspectos a indicar son: •Usuario que desea ejecutar el trabajo. •Infraestructura de computación utilizada para ejecutar el trabajo. Si no se especifica ninguna infraestructura (a través de la cadena vacía o la cadena “null”) el sistema elegirá una de las posibles de acuerdo a las características de la aplicación. En la figura 2, puede observarse el formato de una tupla utilizada para describir un trabajo según las especificaciones anteriores: [ [aplicación, argumentos, lista ficheros entrada, lista ficheros salida], [entrada estándar, salida estándar, salida de error], [fecha límite, presupuesto], [usuario, Grid] ] Figura 2: Formato de tupla utilizado para describir un trabajo. Para que la representación sea independiente de la infraestructura es necesario indicar la localización exacta de los ficheros involucrados en la ejecución del trabajo. Para ello se utiliza la URI que identifica el recurso. Este aspecto se detalla en la sección 4.7, de este mismo capítulo. Identificación de los trabajos Como se ha comentado anteriormente, hay dos formas de realizar el despliegue de un trabajo. La primera de ellas es asíncrona, realizando una operación out seguida de una operación in. La segunda forma es síncrona, utilizando la operación outIn. Sin embargo, existe un problema a la hora de realizar este despliegue, la semántica de Linda no establece mecanismos para sincronizar las operaciones in y out que corresponden a un mismo trabajo. Para realizar esta identificación se valoraron tres alternativas: •Utilizar un identificar numérico. La utilización de un identificador numérico que permita correlar las operaciones de escritura y lectura es una solución sencilla al problema. Sin embargo, esta alternativa presenta el problema de que es necesario asignar dicho identificador desde el propio sistema de modelado, delegando esta responsabilidad al usuario. Esto hace que no sea una opción viable ya que nuestro objetivo es que la identificación sea transparente al usuario. Además, esto podría limitar la interoperabilidad del sistema con otros lenguajes de modelado si los mismos no permiten incluir esta característica de una forma sencilla. •La segunda alternativa consistía en utilizar la misma tupla tanto para la operación de lectura como para la operación de escritura. Esta alternativa permite identificar claramente cuáles son las operaciones relacionadas. Sin embargo, se descartó la misma porque se utiliza mucha información para identificar la tupla. 29 Capítulo 4 – Modelado e implementación | •La tercena alternativa se basa en la opción anterior. En esta alternativa se busca utilizar un identificador de longitud mínima en la tupla de lectura para identificar el trabajo al que hace referencia. Dicho identificador está formado por el usuario que despliega el trabajo y los ficheros de salida generados en el mismo (tanto la lista de ficheros de salida como la salida estándar y la salida de error). Finalmente, se eligió la tercera alternativa porque no implica un trabajo extra para el usuario y es más simple que la segunda opción ya que necesita indicar menos información, favoreciendo también que el modelo sea más claro y legible. Hay que mencionar que tanto la opción elegida como la segunda opción presentan el problema de que no aseguran la unicidad, ya que el usuario podría desplegar varios trabajos iguales o que utilizarán los mismos ficheros de salida. Sin embargo, este problema no es crítico porque no tiene sentido que el mismo usuario ejecute a la vez trabajos que utilicen los mismos ficheros de salida ya que la información de los diferentes trabajos se sobreescribiría perdiendo los resultados. El identificador definido se utiliza en la operación de lectura in que detecta el final de un trabajo. Además de dicho identificador debe añadirse un comodín (carácter ?) que recupere el estado de finalización del trabajo. Este campo se utiliza para detectar si el trabajo ha finalizado correctamente o si ha finalizado con algún tipo de error de cara a permitir y facilitar el tratamiento y la detección de errores en el modelo. En la figura 3, se muestra el formato que debe ser utilizado para una operación de lectura. [ usuario, lista de ficheros de salida, salida estándar, salida de error, ? ] Figura 3: Formato utilizado para una tupla de lectura. 4.3 - Registros del sistema Existen diferentes maneras de gestionar la información relativa al funcionamiento de un sistema de gestión de workflows. Algunos sistemas optan por almacenar determinada información y acceder a la misma cuando la necesitan, otros optan por no almacenar la información y realizar consultas al middleware para obtener la misma cuando la necesitan. Independientemente de la alternativa utilizada, existe información que es necesario almacenar ya que no puede ser obtenida bajo demanda, como los usuarios que tienen acceso a la infraestructura, por lo cual la utilización de registros de información se hace obligatoria. El framework propuesto debe manejar información referente a los grids disponibles, tanto fiables como normales, usuarios que pueden ejecutar en los grids y aplicaciones que puede ejecutar cada grid. Por tanto, se hace necesaria la utilización de diferentes almacenes para los diferentes tipos de información tratada. Las características que deben tener estos almacenes de información vienen dictadas por los objetivos del proyecto. En primer lugar, se necesita que el sistema sea flexible y adaptable frente a cambios en el entorno. Por tanto, debe ser posible modificar la información contenida en estos registros en tiempo de ejecución sin que afecte a la utilización del sistema. Asimismo, el sistema debe ser fácil de configurar, por lo que un usuario cualquiera debe ser capaz de configurar el mismo rellenando correctamente los registros del sistema. Para facilitar las 30 | Sergio Hernández de Mesa cuestiones de configuración se proporcionan scripts que permiten configurar los diferentes almacenes de una forma sencilla. Estos scripts permiten insertar nueva información, modificar la existente y eliminar la información actual. Su utilización puede consultarse en el Anexo III - Manual de Usuario. En lo que respecta a almacenar la información de usuarios, aplicaciones y grids, queda claro que ésta debe almacenarse de forma separada ya que se trata de información muy diferente. Sin embargo, separar la información relativa a los grids fiables y la información relativa a los grids normales no estaba tan claro. Finalmente, se decidió separar la información ya que se considera que es información de distinto tipo. Además, separar la misma va a permitir realizar una gestión de la información más sencilla, tener un acceso más eficiente a la misma y personalizar cada tipo de información por separado de acuerdo a sus necesidades. Para almacenar la información se decidió utilizar ficheros XML por cuestiones de simplicidad y facilidad en cuanto a manejo de la información y compartición de la misma. Una característica que se introduce en los ficheros para facilitar la comprensión de los mismos por parte del usuario, es que no se permiten elementos optativos, todos los elementos son obligatorios, es decir, no puede haber elementos que no aparezcan en el fichero de configuración. Sin embargo, sí que se permite que haya determinados atributos con un valor indefinido. Cuando se quiere expresar esta característica se utiliza el carácter '*' o la cadena 'null' para representar que el valor del atributo es indefinido. A pesar de que cada tipo de registro trata diferente tipo de información, en todos los registros se incluye un campo para almacenar opciones personalizadas. Este campo se utiliza para indicar opciones personalizadas para la ejecución de una determinada aplicación, todas las aplicaciones de un usuario en un grid o todos los trabajos realizados al grid, dependiendo del registro que se trate. Esta característica proporciona al usuario una mayor flexibilidad, pudiendo adaptar la ejecución de cada trabajo de una forma más precisa si lo desea. Estas opciones deben proporcionarse en un formato que sea entendible por el middleware del grid ya que no se realiza ningún tratamiento de las mismas, si no que se añaden directamente. Como existe la posibilidad de que estas opciones personalizadas se solapen, se impone el siguiente mecanismo de prioridad: las opciones menos prioritarias son las indicadas en el registro del usuario, después las indicadas en el registro del grid y, finalmente, las más prioritarias son las específicas de la aplicación. Por tanto, si en algún momento dichas opciones se contradicen se tomará la alternativa fijada por el registro con mayor prioridad. En cualquier caso, la configuración propia del trabajo indicada por el mediador tiene mayor prioridad que las opciones personalizadas de los registros para impedir comportamientos erróneos o malévolos. En lo que se refiere al diseño de los registros, se utiliza un componente diferente para gestionar cada uno de ellos si bien todos son análogos. La arquitectura de estos componentes se presenta en la figura 4. En lo que respecta al nombre de cada uno de los subcomponentes, la palabra Element se sustituye por la palabra adecuada dependiendo del componente del que se trate. El componente ElementDiscovery es el encargado de consultar la información almacenada en el registro permitiendo consultar por un elemento determinado o por toda la lista de elementos. Por su parte, los elementos ElementRegister y ElementEraser son los que permiten añadir y modificar y eliminar información del registro, respectivamente. 31 Capítulo 4 – Modelado e implementación | ejecución normal del workflow indicando en el log que no se ha podido recuperar el mismo. Número de fallo Acción correctora 1, 2, 3, 4, 10, 11, 12, 13, 17 Abort 5, 6, 7, 8, 9, 16 Restart 14, 15 Continue without output 18 Continue without log Tabla 3: Acciones correctoras para los diferentes tipos de errores. Se puede consultar más información sobre este componente en el Anexo VI – Componente de gestión de fallos. 4.6 - Componente de movimiento de datos La inclusión de diferentes grids bajo un mismo sistema plantea el problema del movimiento de datos entre los mismos, el cual se dificulta porque el usuario no conoce a priori en qué grid va a ser ejecutado su trabajo. Además, no se puede conocer la infraestructura de ejecución hasta el momento exacto en el que se va a ejecutar el trabajo, complicando enormemente el movimiento de los datos. La primera cuestión que era necesaria resolver antes de definir cómo se iba a realizar el movimiento de datos era la identificación de los mismos. Se valoraron tres alternativas: •Identificar los datos como si fueran datos locales. Esta primera alternativa tenía como objetivo identificar los datos sin tener en cuenta los recursos, permitiendo que los mismos se ubicaran en cualquiera de los grids definidos. El principal beneficio que presenta esta alternativa es que abstrae al usuario de definir el grid en el que se encuentra un dato. Por contra, esta alternativa implica que el sistema tenga que buscar el dato en todos los grids usados, con el aumento de complejidad y la pérdida de eficiencia consecuente, y presenta el problema de que no es posible saber qué fichero es el correcto si existen ficheros con el mismo nombre en diferentes grids. Este último aspecto hizo que se descartara la idea. •La segunda alternativa consistía en especificar, con algún tipo de lenguaje propio, tanto el propio dato como el recurso en el que se encuentra el mismo. Sin embargo, esta alternativa fue descartada porque uno de los objetivos del proyecto es facilitar la compartición de workflows científicos por lo que la utilización de un lenguaje propio no era una alternativa viable. •La tercera alternativa planteada, y que fue elegida finalmente, fue la utilización de URIs [W23] para identificar de forma única los datos. El uso de URIs, es una forma estándar de identificar datos en entornos distribuidos y heterogéneos por lo que representa la mejor alternativa para nuestro propósito. Además, esta opción nos da la posibilidad de utilizar datos que se encuentren en servidores externos de cualquier tipo con lo que no limitamos los datos que pueden ser utilizados a datos que se encuentren en los Grids definidos. 38 | Sergio Hernández de Mesa La utilización de URIs planteaba el problema de que el usuario debe ser consciente del protocolo de transferencia que debe ser usado para transferir el fichero. Para facilitar este aspecto se introducen dos características. En primer lugar, para el caso de que el usuario esté seguro de que los ficheros se encuentran en el grid en el que se va a ejecutar una tarea, se permite utilizar simplemente la ruta del fichero. En segundo lugar, se permite identificar un fichero con el esquema o protocolo file. La utilización de este formato permite al usuario no indicar el usuario del grid y el protocolo de transferencia, siendo estos recuperados del registro de usuarios y del registro de grids del sistema. Un ejemplo de cómo identificar un fichero con estos dos mecanismos puede observarse en la figura 10. a) file://hermes.cps.unizar.es/~/ejemplo.txt b) sftp://[email protected]/~/ejemplo.txt Figura 10: Identificación de un fichero. a) Identificación con URI 'file'. b) Identificación con URI 'sftp'. Asimismo, se permite la utilización de comodines para definir la ruta de un fichero o grupo de ficheros dentro de un grid. Por ejemplo, en la figura 1 se ha utilizado el carácter '~' para definir que el fichero 'ejemplo.txt' se encuentra en el home del usuario. Esta característica permite definir de una forma sencilla y potente un grupo de ficheros utilizando solamente una URI. Finalmente, en la figura 11 se incluye el árbol de decisión utilizado para definir el comportamiento que debe ser seguido ante las diferentes descripciones posibles. Figura 11: Árbol de decisión para las URIs Cuando se parsea una palabra, se comprueba en primer lugar que la palabra corresponde efectivamente a una URI. Si no es así, la palabra puede hacer referencia a un argumento o parámetro de la aplicación o a una ruta relativa y no se realiza ninguna modificación sobre la misma al no tener certeza de dicha circunstancia. Si la palabra se trata de una URI, se detecta si la misma corresponde a un fichero local o a un fichero remoto. En el caso de que se trate de un fichero remoto, se descarga el mismo y se obtiene la ruta absoluta del fichero dentro del grid en el que se ha descargado el fichero. Si por contra se trata de un fichero local, se obtiene 39 Capítulo 4 – Modelado e implementación | simplemente la ruta absoluta del mismo. Sin embargo, en este último caso, la palabra podría tener algún comodín y referirse a una lista de ficheros por lo que hay que detectar esta situación y, en el caso de que exista algún comodín, reemplazar el mismo por la lista de ficheros correspondiente. En el Anexo VII - Componente de movimiento de datos puede consultarse más información acerca del componente de movimiento de datos. 4.7 - Mediadores En la figura 12, se muestra el diseño arquitectural realizado para los mediadores, independientemente del middleware concreto con el que interactúa el mediador. En la figura puede observarse como el mediador está dividido en una serie de componentes. El primero de ellos es el que se conoce como Job Manager. Este componente se encarga de gestionar y coordinar la ejecución de los diferentes trabajos que son encargados al mediador. Las principales tareas de las que se encarga este componente son las siguientes: •Interactuar con el broker de mensajes Linda, para obtener los trabajos que hay que ejecutar en el grid y para escribir los resultados de los mismos en el broker. •Mover los datos generados por el trabajo a su ubicación final correspondiente, ya sea dentro del mismo grid o entre grids, utilizando para ello el componente de movimiento de datos. •Mantener una lista de los trabajos que se encuentran en ejecución. Esta lista indica la correspondencia entre los identificadores asignados por el grid concreto en el que se ejecuta un trabajo y el propio trabajo. Sirve saber qué trabajo ha finalizado en cada momento. Figura 12: Arquitectura general de un mediador 40 | Sergio Hernández de Mesa Por su parte, el Middleware Adapter se encarga de transformar la descripción del trabajo obtenida del broker, la cual es independiente del entorno de ejecución, en una descripción que pueda ser ejecutada por el middleware de la infraestructura grid. Asimismo, prepara los datos necesarios para poder ejecutar el trabajo y realiza el despliegue del mismo. Para recuperar los datos necesarios, se utiliza el componente de movimiento de datos, que es común a todos los mediadores. Mientras que, para realizar el despliegue del trabajo se utiliza una interfaz SSH que nos permite establecer una conexión segura con la infraestructura. Una vez desplegado el trabajo, el middleware utilizará internamente protocolos como GridFTP para mover los datos a su ubicación final dentro del grid. El Internal Resource Registry se utiliza a la hora de realizar la transformación comentada anteriormente. Este componente, obtiene información referente a la aplicación que se desea ejecutar y el usuario que va a ejecutar dicha aplicación utilizando la misma para definir el trabajo a ejecutar. El último componentes del mediador es el Job Monitor. La necesidad del mismo viene determinada por el comportamiento asíncrono del sistema, en el cual, un trabajo es lanzado pero no se sabe cuándo va a terminar el mismo. Para detectar el fin del trabajo se introduce este componente. La detección de la finalización del trabajo puede realizarse de diferentes formas dependiendo del middleware utilizado. Un mecanismo habitual que permite detectar la finalización de un trabajo es utilizar el correo electrónico. Cuando el trabajo finaliza, el middleware se encarga de enviar un correo electrónico a la dirección especificada al encargar la ejecución del trabajo. En otros middlewares, este mecanismo no está soportado por lo que es necesario utilizar un mecanismo de encuesta para detectar si un trabajo determinado ha finalizado. De esta forma, cuando un trabajo finaliza, se detecta esta situación con alguno de los mecanismos anteriores y se notifica de este hecho al Job Manager indicando el identificador utilizado por el grid para el trabajo que ha finalizado. Este identificador, permite recuperar al Job Manager los datos del trabajo, realizar el movimiento de los datos de salida, si es necesario, y notificar al broker de dicho evento. Otro aspecto importante que debe ser controlado por el mediador es todo lo relativo a la aparición de errores. Los errores pueden aparecer tanto antes de ejecutar el trabajo, debido a fallos en la definición del trabajo o en el movimiento de los datos necesarios, por ejemplo, como después de ejecutar el mismo, es el caso de errores de ejecución del trabajo o de movimiento de los datos de salida. Si se produce un fallo, el mediador debe detectar esta circunstancia y notificar al broker de mensajes del mismo para que el fallo sea gestionado por el componente de gestión de fallos. Se puede consultar más información sobre los mediadores en el Anexo VIII - Mediadores. 41 Capítulo 4 – Modelado e implementación | 42 | Sergio Hernández de Mesa Capítulo 5 -Evaluación del sistema La evaluación del rendimiento del sistema desarrollado es un aspecto fundamental para comprobar que se cumplen algunos de los objetivos marcados al inicio del proyecto. En nuestro caso, esta evaluación consiste en el análisis del rendimiento y la escalabilidad del sistema desarrollado y su comparación con otro sistema, como Taverna. 5.1 - Métricas de evaluación Los dos aspectos que vamos a evaluar son el rendimiento y la escalabilidad del sistema. En lo referente al rendimiento del sistema queremos medir la sobrecarga que introduce el sistema en referencia a la ejecución manual de los trabajos. En general, este no es un aspecto crítico en un sistema de gestión de workflows científicos ya que los trabajos desplegados son computacionalmente muy costosos y la introducción de una pequeña sobrecarga no es significativa. En cualquier caso, creemos que es importante conocer el rendimiento del sistema en cualquier situación y garantizar que la sobrecarga introducida por el sistema no es un aspecto crítico. Para ello realizamos dos tipos de experimentos: 1. En un primer experimento, queremos comprobar el rendimiento del sistema al ejecutar un trabajo de forma aislada. El objetivo de este experimento es comprobar la sobrecarga natural que introduce el sistema. 2. El segundo experimento busca comprobar el rendimiento del sistema cuando se ejecuta un trabajo en una situación en la que existe una gran carga en el sistema, en cuanto a número de trabajos pendientes de ejecución. Este experimento tiene el objetivo de comprobar si la existencia de una gran carga en el sistema afecta a la ejecución aislada de un trabajo por lo que también es importante para la escalabilidad del sistema. Por su parte, en lo que respecta a la escalabilidad del sistema, vamos a medir el rendimiento del broker cuando se somete al mismo a una gran carga en cuanto a número de trabajos que se ejecutan a la vez. Este aspecto es fundamental a la hora de determinar el número de trabajos que pueden ejecutarse al mismo tiempo sin que se reduzcan gravemente las prestaciones. Para ello, vamos a desplegar la misma tarea un gran número de veces de forma que haya un gran número de peticiones de lectura y peticiones de escritura a la vez. Tanto para medir el rendimiento del sistema como para medir la escalabilidad del mismo, realizaremos los experimentos con el objetivo de comparar el sistema desarrollado con Taverna, otro sistema de gestión de workflows científicos. Esta comparación aborda tanto las capas de modelado como la capa de ejecución del sistema por lo que se contemplan tres posibilidades: la utilización de Taverna de forma aislada, la integración de Taverna con el sistema desarrollado y la utilización de Renew como entorno de modelado del sistema. 5.2 - Definición de experimentos Para evaluar el sistema se han definido una serie de experimentos dedicados a medir los aspectos relatados anteriormente. En este apartado ofrecemos una breve descripción de los mismos, una descripción más completa aparece en el Anexo IX – Evaluación del sistema. 43 Capítulo 5 – Evaluación del sistema | El primer experimento consiste en la ejecución en serie de una tarea variando el número de repeticiones, midiendo el tiempo al inicio y al final del experimento y calculando la sobrecarga introducida por el sistema. Con este experimento buscamos medir el rendimiento de una tarea al ejecutarse de forma aislada en el sistema. El segundo experimento mide la sobrecarga introducida al ejecutar el sistema de forma aislada. Para ello se introducen un elevado número de trabajos en el broker y se procede de la misma forma que en el experimento anterior. El tercer experimento se utiliza para evaluar el sistema en cuanto a escalabilidad. Para ello se lanzan un elevado número de tareas en paralelo de forma que las mismas comienzan y terminan prácticamente a la vez, midiéndose el tiempo al inicio y al final del experimento y calculando la sobrecarga introducida. 5.3 - Resultados En este apartado se presentan los resultados correspondientes al experimento de escalabilidad al ser el más representativo de los realizados. El resultado, análisis y conclusiones del resto de experimentos puede consultarse en el Anexo IX – Evaluación del sistema. Los experimentos se han desarrollado desplegando el middleware desarrollado sobre un AMD Athlon 3500+ de 64 bits, 2.2GHz, 2GB de RAM y un subsistema de E/S SATA. El sistema operativo utilizado ha sido GNU/Linux Ubuntu, con un núcleo 2.6.35 optimizado para el hardware utilizado. Renew 2.2 se ha ejecutado sobre la versión 1.6.0r26 del Java SE Runtime Environment. Los experimentos se han ejecutado sobre el sistema con un único usuario, y los procesos innecesarios se han cerrado. La figura 13 muestra los datos de la sobrecarga introducida por el sistema en función del número de tareas que se ejecutan en paralelo. En la misma sólo se proporcionan los resultados utilizando el framework con Renew como entorno de modelado ya que con Taverna no es posible ejecutar de forma paralela tantos trabajos. Podemos observar como la sobrecarga introducida en el sistema al incrementar el número de trabajos que se ejecutan en paralelo crece rápidamente. El incremento de la sobrecarga sigue una tendencia polinómica de tercer grado, casi exponencial. La sobrecarga es aceptable hasta un número de 125 trabajos ejecutándose en paralelo y se dispara si intentamos ejecutar un mayor número de trabajos. Para comparar en cuanto a escalabilidad las herramientas de modelado Renew y Taverna realizamos un análisis más detallado de los resultados obtenidos hasta un máximo de 25 trabajos ejecutándose en paralelo. Los resultados de este análisis se muestran en la figura 14. Como se observa en la gráfica, el incremento de la sobrecarga limitando el número de tareas a 25 es lineal en Renew mientras que es polinómica de tercer grado en Taverna. Esto se debe a que los flujos paralelos en Taverna se han desarrollado de forma explícita, al no proporcionar un mecanismo nativo para definir tareas en paralelo de forma implícita, a través de bucles o similar. De esta forma, al incrementar el número de tareas el workflow se vuelve muy pesado en términos de memoria necesaria para gestionar y ejecutar el mismo provocando que se disparen las prestaciones. Asimismo, este aspecto también provoca que el modelado del workflow se ralentice enormemente y que la máquina se colapse. Por esta razón no se han podido realizar experimentos con un mayor número de tareas en paralelo utilizando Taverna. 44 | Sergio Hernández de Mesa Figura 13: Gráfica que muestra la sobrecarga del framework al aumentar el número de tareas en paralelo. Figura 14: Gráfica que compara Taverna y el framework en términos de escalabilidad. 5.4 - Conclusiones Como era de esperar, la sobrecarga del sistema crece enormemente al ejecutar un elevado número de tareas en paralelo. Esto se debe a que el broker se convierte en el cuello de botella del sistema al tener que atender un gran número de peticiones a la vez, siendo especialmente crítica la operación de lectura por la gran cantidad de tuplas que hay que comprobar. Las prestaciones se mantienen dentro de un límite aceptable hasta 125 tareas. En cualquier caso, la utilización de las redes de referencia permite introducir un gran nivel de paralelismo de forma natural mientras que los sistemas de gestión de workflows científicos actuales no suelen proporcionar mecanismos para proporcionar ese nivel de paralelismo. En el caso de Taverna, hay que incluir el paralelismo de forma explícita, no se pueden realizar construcciones genéricas que nos permitan llegar a altos niveles de paralelismo. En lo que se refiere a las prestaciones, esto implica que el rendimiento de Taverna al paralelizar un elevado número de tareas disminuye muy rápidamente. 45 Capítulo 5 – Evaluación del sistema | 46 | Sergio Hernández de Mesa Capítulo 6 - Caso de estudio: First Provenance Challenge Como caso de estudio se utilizó el workflow científico propuesto en el First Provenance Challenge[W24]. La elección del mismo se fundamenta en que es un workflow de referencia en la comunidad científica, por lo que ha sido muy estudiado y utilizado para la verificación de diferentes sistemas de gestión de workflows. Además, resulta un problema fácilmente escalable y que requiere del desplegado y ejecución de diversas tareas tanto de forma secuencial como paralela, por lo que resulta muy adecuado para demostrar la viabilidad de la solución propuesta. 6.1 - Objetivos Nuestro objetivo principal consiste en verificar el correcto funcionamiento de la herramienta desarrollada utilizando un workflow científico real. También queremos ilustrar la flexibilidad del framework desarrollado tanto en lo que respecta a la posibilidad de utilizar diferentes entornos de modelado como a la posibilidad de utilizar diferentes infraestructuras Grid de forma transparente. Con este propósito presentamos dos implementaciones diferentes una realizada con redes de referencia en Renew y otra realizada con Taverna. En estas implementaciones se utilizarán los recursos Grid a los que tiene acceso el grupo de investigación GIDHE: Aragrid, Piregrid y Hermes. 6.2 - Definición del problema Se plantea un workflow para crear “atlas” cerebrales de la población en base a imágenes de alta resolución del Centro de Datos de imágenes de resonancias magnéticas funcionales (fMRI) [W25]. Este workflow está compuesto de varios procedimientos, mostrados como óvalos naranjas, y datos que fluyen entre ellos, mostrados como rectángulos. Pueden distinguirse 5 fases o etapas en la ejecución del mismo. Cada una de las etapas se muestra en una misma franja horizontal. Los procedimientos utilizan la suite AIR[W26], para crear una imagen cerebral promedio a partir de una colección de imágenes tridimensionales de alta resolución, y la suite FSL [W27] para crear las imágenes bidimensionales de cada dimensión del cerebro que constituyen la salida del workflow. Las entradas del workflow son un conjunto de imágenes cerebrales (anatomy images) y una única imagen de referencia (reference image). Todas las imágenes anatómicas de entrada, son escáneres tridimensionales de un cerebro con diferente resolución. Para cada imagen se proporciona el fichero con la imagen y un fichero de cabecera con metadatos sobre la misma. Las etapas del workflow se describen a continuación: 1. Para cada imagen de entrada, el procedimiento align_warp compara la imagen de entrada y la imagen de referencia para determinar como debe alinearse la imagen de entrada con respecto a la imagen de referencia. La salida de cada proceso define una serie de parámetros que indican la transformación espacial a realizar sobre cada imagen. 2. Los procedimientos reslice realizan de forma efectiva la transformación indica en el paso anterior, utilizando los parámetros obtenidos como salida de align_warp. Como resultado se obtiene la imagen modificada. 47 Capítulo 6 – Caso de estudio: First Provenance Challenge | Asimismo otras líneas de trabajo futuro son las siguientes: •Incorporación de requisitos de calidad de servicio (QoS) a los trabajos y gestión de dichos requisitos. Para este punto se contempla la posibilidad de añadir nuevas políticas de emparejamiento que contemplen y satisfagan los requisitos de QoS. En este aspecto, también se propone la definición de políticas de emparejamiento dirigidas a Green computing. •Adición de nuevos componentes como un sistema de monitorización que permita conocer el estado de cada trabajo en cualquier momento y un componente de scheduling avanzado que permita realizar el despliegue de los trabajos de forma más potente a lo permitido en las políticas de emparejamiento. •Adición de nuevos mediadores al sistema para permitir la integración de un mayor número de infraestructuras de computación al sistema. •Obtención y gestión de la información de provenance o procedencia, es decir, de toda la información respecto de las tareas ejecutadas, las relaciones entre las mismas, los resultados generados, etc. •Realización de un plugin que permita traducir de forma automática workflows modelados con diferentes lenguajes a redes de referencia para permitir la integración directa de los mismos en Renew. •Utilización de frameworks de gestión específicos que faciliten las labores de despliegue de los trabajos en Amazon Elastic Compute Cloud (Amazon EC2) [W9] y añadan funcionalidades como monitorización completa de los mismos o balanceo de carga eficiente. 7.2 - Conclusiones a nivel personal Durante la realización de la carrera de Ingeniería Informática he recibido formación en los diferentes campos de interés de este área. Sin embargo, una de las carencias que he detectado durante estos cinco años ha sido la falta de asignaturas en las que se aborde el mundo de la investigación. Por ello, decidí realizar un proyecto que tuviera una alta carga de labor investigadora para conocer ese mundo y completar mejor mi formación. El proceso de búsqueda de información, lectura de artículos y análisis de las propuestas de otros autores son fases fundamentales del proceso de investigación. En un primer momento, estas fases pueden ser muy costosas llegando a dar la sensación de que no se está avanzando en el desarrollo del proyecto. Sin embargo, a medida que avanza con la investigación me he dado cuenta de que esta fase es muy enriquecedora ya que permite conocer la opinión y forma de afrontar un mismo problema por parte de otras personas. Además, analizar el trabajo de otros autores me ha permitido darme cuenta de la importancia de realizar un análisis crítico de los mismos. En un artículo el autor muestra su opinión y propuesta en relación a un aspecto determinado, sin embargo, ésta no tiene porque ser la mejor o puede estar equivocada por lo que es importante realizar un análisis propio. Otro aspecto muy importante ha sido la oportunidad de enfrentarme con un proyecto de magnitud y aplicación real lo que ha significado una gran oportunidad para evaluar mi 54 | Sergio Hernández de Mesa capacidad como ingeniero. La magnitud del proyecto, me ha permitido darme cuenta de la importancia de la planificación y la gestión del trabajo. Antes de empezar el mismo no consideraba esto un aspecto realmente importante, sin embargo, a lo largo del mismo me he dado cuenta de que es muy importante llevar el mejor control posible sobre todos los aspectos que involucran el desarrollo del proyecto. De la misma manera, la realización en solitario del proyecto me ha permitido mejorar en mi capacidad auto organizativa, mejorando mi la metodología de trabajo en las últimas semanas de desarrollo, lo que ha supuesto un incremento de la productividad a lo largo del mismo. En lo referente a la implementación, el proyecto me ha servido para mejorar mis aptitudes como programador y darme cuenta de la importancia de las fases de análisis y diseño. Al principio del proyecto me lanzaba a implementar ciertas cosas sin analizarlas y pensar en ellas demasiado lo que a la postre ha implicado tener que adaptar o rehacer parte del código desarrollado. Al final del proyecto, he conseguido analizar del problema de una manera más concienzuda, lo que me ha permitido a su vez diseñar la mejor solución para el mismo teniendo en cuenta todas las opciones posibles. Como resultado a la hora de implementar, esta fase ha sido mucho más sencilla. En definitiva, la experiencia ha sido muy enriquecedora y satisfactoria. La realización de este proyecto me ha permitido iniciarme en el mundo de la investigación, descubriendo además que se trata de un mundo apasionante y animándome a realizar el doctorado. Asimismo, creo que el proyecto me ha permitido desarrollarme profesionalmente mejorando mis aptitudes como ingeniero y completando mi formación. 55 Capítulo 7 – C onclusiones y trabajo futuro | 56 | Sergio Hernández de Mesa