Repositorio Institucional de Documentos

Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es Trabajo Fin de Máster Integración dinámica de entornos de computación heterogéneos para la ejecución de workflows científicos Autor Sergio Hernández de Mesa Director Pedro Álvarez Pérez-Aradros Escuela de Ingeniería y Arquitectura Departamento de Informática e Ingeniería de Sistemas Grupo de Integración de Sistemas Distribuidos y Heterogéneos (GIDHE) Junio 2012 Integraci´on din´amica de entornos de computaci´on heterog´eneos para la ejecuci´on de workflows cient´ıficos RESUMEN Los workflows cient´ıficos se caracterizan por estar compuestos por un elevado n´umero de tareas computacionalmente muy costosas. Las necesidades planteadas por este tipo de workflow hacen necesaria la utilizaci´on de entornos de computaci´on capaces de satisfacer estos requisitos de computaci´on. En este contexto, la computaci´on Grid ha emergido como un paradigma adecuado para la ejecuci´on de workflows cient´ıficos gracias a la capacidad computacional y las comunicaciones en red de estos entornos. No obstante, esta nueva “sociedad” compuesta por Grids y workflows cient´ıficos todav´ıa mantiene abiertos un amplio abanico de retos y dificultades. La posibilidad de ejecutar workflows programados en diferentes lenguajes sobre un mismo entorno de computaci´on, la integraci´on de entornos de computaci´on heterog´eneos bajo una misma infraestructura, y la posibilidad de ejecutar diferentes partes de un mismo workflow en diferentes entornos de computaci´on son algunos de los principales problemas existentes. Como primer paso para la resoluci´on de estos problemas, se desarroll´o una infraestructura que integra diferentes entornos de computaci´on heterog´eneos de forma transparente para el usuario y que permite ejecutar workflows programados en diversos lenguajes ampliamente aceptados por la comunidad cient´ıfica. De esta forma, se proporcion´o una infraestructura capaz de solucionar los retos anteriores. Un aspecto ortogonal a estos retos no considerado en la infraestructura propuesta es el proceso de asignaci´on de tareas a los recursos disponibles en los diferentes entornos integrados (meta-scheduling). Este proceso es clave para la definici´on de soluciones maduras y completas a los problemas expuestos. Para avanzar en el desarrollo de la soluci´on propuesta y mejorar la infraestructura, en esta Tesis Fin de M´aster se propone una estrategia de meta-scheduling basada en t´ecnicas de simulaci´on que permite asignar din´amicamente el entorno de ejecuci´on a utilizar en cada una de las tareas de un workflow. Para ello, se ha integrado en la infraestructura un metascheduler que, para cada tarea, selecciona el entorno de ejecuci´on m´as adecuado utilizando un algoritmo de optimizaci´on del tiempo de ejecuci´on. La informaci´on utilizada para esta toma de decisiones proviene de los resultados de simular la ejecuci´on de las tareas en los entornos de computaci´on disponibles. Para soportar este proceso, se ha dise˜nado un simulador gen´erico, adaptable y extensible basado en Alea. Para cada entorno de computaci´on, una instancia de este simulador ha sido customizada e integrada en la infraestructura. Asimismo, se ha definido una metodolog´ıa para la creaci´on de workloads din´amicos que permite simular las tareas en condiciones reales de carga. El uso de estos workloads y el propio dise˜no de los simuladores, capaces de capturar la complejidad inherente de los entornos de computaci´on, han permitido obtener un elevado grado de precisi´on en las simulaciones, tal y como se ha demostrado en la validaci´on experimental realizada. Como consecuencia, se ha conseguido mejorar el rendimiento de los workflows ejecutados. Finalmente, la viabilidad y beneficios de la soluci´on propuesta se muestran mediante su aplicaci´on a un workflow real en el dominio de la computaci´on cient´ıfica, el workflow de an´alisis Inspiral. Para este caso de uso, la utilizaci´on de la infraestructura con la estrategia de metascheduling propuesta ha permitido obtener una mejora del rendimiento de un 59% respecto a la ejecuci´on del workflow completo en el cluster Hermes del I3A y una mejora de un 111 % respecto a la ejecuci´on del workflow en el Grid AraGrid. i ´ Indice 1 Introducci´on 1 1.1 Problema a resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Objetivos ........................................ 5 1.4 Contexto del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Una infraestructura para la integraci´on din´amica de entornos de computaci´on 7 2.1 Capa de programaci´on de workflows ......................... 8 2.2 Capa de ejecuci´on de workflows ............................ 9 2.3 Capa de entornos de computaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Breve resumen de las aportaciones de la infraestructura . . . . . . . . . . . . . . 11 3Meta-scheduling basado en simulaci´on 13 3.1 Proceso de asignaci´on de tareas a entornos de computaci´on . . . . . . . . . . . . 13 3.2 Dise˜no de los simuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Metodolog´ıa para la creaci´on de workloads ...................... 17 3.4 Validaci´on de los simuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5 Meta-scheduler ..................................... 21 4 Caso de estudio: Inspiral 23 4.1 Workflow de an´alisis Inspiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Preparaci´on del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3 An´alisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5 Conclusiones y trabajo futuro 27 5.1 L´ıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Bibliograf´ıa 31 AA Framework for the Flexible Deployment of Scientific Workflows in Grid Environments 35 BA Simulation-Based Scheduling Strategy for Scientific Workflows 45 C Una soluci´on SOA para ejecutar workflows cient´ıficos en entornos Grid heterog´eneos 57 iii Cap´ıtulo 1 |Introducci´on El creciente inter´es de la comunidad cient´ıfica por automatizar de manera sistem´atica la ejecuci´on de sus experimentos ha supuesto el impulso definitivo a la computaci´on cient´ıfica y, en particular, a los workflows cient´ıficos. Este tipo de workflow presenta unas caracter´ısticas muy particulares que condicionan su ejecuci´on: est´an compuestos por actividades complejas desde el punto de vista de los recursos computacionales necesarios para su ejecuci´on, gestionan grandes vol´umenes de datos como entrada/salida de las tareas ejecutadas, y necesitan gestionar adecuadamente la disponibilidad de recursos hardware ysoftware heterog´eneos. Estas caracter´ısticas han alentado el uso de entornos de computaci´on tipo Grid para el despliegue y ejecuci´on de estos workflows, con el objetivo com´un de obtener el m´aximo aprovechamiento a colecciones de recursos heterog´eneos y distribuidos geogr´aficamente [1]. En este sentido, se ha avanzado notablemente en la comprensi´on de la naturaleza intr´ınseca de los workflows cient´ıficos y en los requisitos necesarios para su correspondiente ejecuci´on en entornos Grid. No obstante, a´un son numerosos los retos abiertos para este modelo de soluci´on. 1.1 Problema a resolver Algunos de los principales problemas existentes en el ´ambito de workflows cient´ıficos y entornos de computaci´on Grid son: la posibilidad de ejecutar workflows programados en diferentes lenguajes, la integraci´on de entornos de computaci´on heterog´eneos bajo una misma infraestructura, o la ejecuci´on de partes de un mismo workflow sobre diferentes entornos de ejecuci´on. Dentro de la l´ınea de investigaci´on del autor, se pretende proporcionar una soluci´on integrada a los problemas anteriores. Como primer paso, se desarroll´o un prototipo de infraestructura que permite integrar diferentes entornos de computaci´on heterog´eneos y ejecutar workflows programados independientemente del entorno de ejecuci´on y utilizando diferentes lenguajes. Este trabajo fue presentado por el autor de esta Tesis Fin de M´aster como Proyecto Fin de Carrera [2]. Sin embargo, la infraestructura desarrollada presenta limitaciones en la forma de asignar trabajos a diferentes entornos de ejecuci´on. Estas limitaciones (ver Cap´ıtulo 2) provocan que el tiempo de ejecuci´on de los workflows pueda verse penalizado en la mayor´ıa de las ejecuciones. En esta Tesis Fin de M´aster se intenta dar soluci´on al problema anterior mediante la definici´on de t´ecnicas avanzadas de asignaci´on de tareas a recursos y la utilizaci´on de informaci´on din´amica que ayude a seleccionar el entorno de ejecuci´on m´as adecuado para cada tarea. Utilizando estos mecanismos, partes de un mismo workflow podr´ıan ser ejecutadas en diferentes entornos, algo que a d´ıa de hoy no es posible con los sistemas existentes. Por tanto, este trabajo representa la evoluci´on natural del Proyecto de Fin de Carrera realizado previamente, proponiendo una soluci´on al tercero de los problemas comentados: la asignaci´on din´amica de tareas a entornos de computaci´on heterog´eneos. En todo caso, este trabajo no soluciona todos los problemas y retos existentes, sino que todav´ıa existen diferentes aspectos que deben ser estudiados e incorporados a la infraestructura (v´ease la secci´on 5.1). 1 Sergio Hern´andez de Mesa 1.2 Estado del arte Han surgido diferentes trabajos de investigaci´on que tratan de dar respuesta a los problemas anteriores dentro del contexto de programaci´on de workflows, construcci´on de entornos de ejecuci´on y desarrollo de arquitecturas que den soporte tanto a la programaci´on como a la ejecuci´on de workflows cient´ıficos. En esta secci´on, revisaremos los trabajos m´as relevantes exponiendo sus contribuciones principales. 1.2.1 Programaci´on de workflows cient´ıficos En la actualidad existe una amplia variedad de sistemas de gesti´on de workflows. La comparaci´on detallada de estos sistemas ha puesto de manifiesto las diferencias existentes entre las distintas aproximaciones desde el punto de vista de la programaci´on, despliegue y ejecuci´on de workflows [3, 4]. Esta heterogeneidad provoca que las propuestas actuales presenten un alto grado de acoplamiento entre los workflows cient´ıficos y los entornos Grid concretos sobre los que ser´an ejecutados. En otras palabras, los workflows cient´ıficos son programados para ser ejecutados en un Grid concreto. Este acoplamiento limita la flexibilidad de las soluciones y provoca, desde el punto de vista del programador de workflows cient´ıficos, una serie de dificultades que requieren ser resueltas. Entre estas dificultades destacan las siguientes: los workflows no son directamente portables entre diferentes entornos de ejecuci´on; resulta costoso programar nuevos workflows reutilizando workflows m´as simples programados en distintos lenguajes (esto dificulta el aprovechamiento de iniciativas como myExperiment1, un repositorio de workflows cient´ıficos de acceso p´ublico); es complejo programar workflows con fuertes requisitos de c´omputo para que distintas partes de su flujo puedan ser ejecutadas en diferentes entornos de ejecuci´on; el fuerte acoplamiento entre workflow y entorno de ejecuci´on provoca en la mayor´ıa de los casos que los administradores deban realizar tareas de configuraci´on costosas previas al despliegue del experimento; y resulta dif´ıcil integrar en estas soluciones paradigmas de computaci´on de inter´es que han aparecido recientemente y que permiten la optimizaci´on del uso de recursos en diferentes escenarios, como por ejemplo los denominados Green/Cloud Computing. Aunque no existe una soluci´on completa a las limitaciones previas, determinados trabajos abordan parcialmente alguna de ellas. Uno de los trabajos m´as destacados es el proyecto europeo SHIWA2(SHaring Interoperable Workflows for large-scale scientific simulations on Available DCIs). Su principal objetivo es el desarrollo de un conjunto de tecnolog´ıas de interoperabilidad que permitan compartir y reutilizar workflows entre comunidades de usuarios que habitualmente trabajen con distintos sistemas de gesti´on. Para la consecuci´on de este objetivo se desarrollan dos ideas b´asicas. En primer lugar, un workflow podr´ıa ser encapsulado como un servicio que es ejecutado sobre un entorno concreto. La interfaz del servicio abstraer´ıa los detalles concretos y facilitar´ıa su integraci´on en otros workflows (interoperabilidad de grano grueso). Y, en segundo lugar, la posibilidad de traducir un workflow cualquiera a una representaci´on com´un, llamada IWIR (Interoperable Workflow Intermediate Representation), y posteriormente disponer de herramientas que sean capaces de ejecutarla en distintos sistemas de gesti´on [5] (interoperabilidad de grano fino). Por otro lado, independientemente del lenguaje concreto utilizado para modelar los workflows, deben proporcionarse mecanismos para abstraer al usuario de los detalles de bajo nivel de interacci´on con los entornos de ejecuci´on y el lenguaje de representaci´on utilizado por el middlewares. Esto permitir´ıa al usuario centrarse en los detalles funcionales del workflow y 1http://www.myexperiment.org/ 2http://www.shiwa-workflow.eu/ 2 Cap´ıtulo 1. Introducci´on las relaciones existentes entre sus componentes [6], en lugar de en la interacci´on con el entorno de ejecuci´on. Para ello, existe una interesante iniciativa de estandarizaci´on, llamada JSDL (Job Submission Description Language) [7], que define una representaci´on est´andar para los trabajos que son ejecutables sobre un entorno tipo Grid. La composici´on de trabajos concretos establece un workflow; por tanto, una evoluci´on natural de esta especificaci´on ser´ıa hacia la definici´on de un lenguaje est´andar de workflows. En cualquier caso, el est´andar en su estado actual ha motivado la aparici´on de propuestas que, aprovechando la orientaci´on de servicios, facilitan la ejecuci´on de trabajos JSDL en entornos heterog´eneos [8, 9]. Una interfaz de servicio para el env´ıo de estos trabajos abstrae al programador de los detalles espec´ıficos del entorno de ejecuci´on responsable. Como ´ultimo paso para la soluci´on de los problemas comentados, la descripci´on de los workflows, adem´as de estar basada en lenguajes est´andar y ser portable, reutilizable e interoperable, debe ser completamente independiente del entorno de ejecuci´on empleado. Esto permitir´ıa que los workflows fueran ejecutados en entornos de ejecuci´on heterog´eneos sin que fuese necesario realizar cambios sobre el workflow, lo cual, a su vez, facilitar´ıa la reutilizaci´on y compartici´on de los workflows. Este tipo de soluci´on ha sido explorada en portales de computaci´on cient´ıfica como P-GRADE [10] mediante el empleo de un lenguaje de alto nivel y la traducci´on autom´atica del mismo al lenguaje concreto usado por el middleware correspondiente. 1.2.2 Entornos de computaci´on heterog´eneos para la ejecuci´on de workflows cient´ıficos El paradigma de computaci´on Grid surgi´o como respuesta a las elevadas necesidades computacionales de los experimentos cient´ıficos. Promet´ıa la puesta en funcionamiento de grandes entornos de computaci´on mediante la integraci´on y colaboraci´on de diferentes entornos distribuidos a nivel mundial [11]. Sin embargo, a d´ıa de hoy nos encontramos muy alejados de dicha perspectiva debido a varios problemas que dificultan enormemente la creaci´on de nuevos entornos de ejecuci´on basados en la integraci´on de entornos ya existentes. Por un lado, la heterogeneidad de los entornos de computaci´on Grid y la gran diversidad de sistemas middleware (Condor [12], Globus [13], gLite [14], etc.) que gestionen los mismos, dificultan el proceso de integraci´on. Por otro lado, los entornos de computaci´on existentes pertenecen a organizaciones y dominios administrativos diferentes que imponen barreras a su integraci´on, colaboraci´on y uso conjunto [15]. Estos problemas han limitado la aplicaci´on de las diferentes soluciones propuestas a escenarios en los que no existen barreras administrativas y escenarios con diferentes entornos de ejecuci´on homog´eneos o, al menos, con middlewares interoperables. La dificultad para superar los problemas anteriores, ha llevado a la b´usqueda de nuevas t´ecnicas que permitan crear entornos de computaci´on globales. Con este prop´osito ha surgido la computaci´on Cloud, o computaci´on en la nube, como una forma de ver la computaci´on como un servicio global [16]. Dentro de esta visi´on global, el Cloud se presenta como respuesta a numerosos problemas y necesidades a trav´es de diferentes paradigmas: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) y SaaS (Software as a Service). Para la ejecuci´on de workflows cient´ıficos, el paradigma IaaS propone la construcci´on de entornos de computaci´on basados en la provisi´on bajo demanda de m´aquinas virtuales. La aplicaci´on del mismo ha llevado al desarrollo de nubes de acceso p´ublico, o nubles p´ublicas, y nubes de acceso privado, o nubes privadas. Las nubes p´ublicas, como Amazon EC23(Amazon Elastic Cloud), corresponden a entornos de computaci´on en los que un proveedor de servicios Cloud ofrece una visi´on de recursos infinitos, proporcionando al usuario cualquier n´umero de recursos en forma de m´aquinas virtuales. De esta forma, el usuario puede cubrir sus necesidades pagando s´olo por los recursos que utiliza. 3http://aws.amazon.com/es/ec2/ 3 Sergio Hern´andez de Mesa y controlar la transferencia de los datos de entrada y de salida; y iv) insertar tuplas en el repositorio de mensajes con el resultado de la ejecuci´on de las mismas para que sea tratada por la componente adecuada. Se ha implementado un mediador para cada uno de los middlewares (Condor y gLite) utilizados por los entornos de computaci´on disponibles, los cuales son, adem´as, dos de los middlewares m´as utilizados en entornos Grid. En cuanto a las componentes de gesti´on, ´estas ofrecen diferentes funcionalidades encaminadas a gestionar el ciclo de vida de los workflows ejecutados. Se han desarrollado: una componente de gesti´on de fallos y una componente de movimiento de datos. El procedimiento de integraci´on de estas componentes es similar al utilizado en los mediadores. Cada componente de gesti´on interacciona con el repositorio de mensajes para retirar mensajes con la etiqueta asociada a esa componente y procesarlos. Por lo tanto, la utilizaci´on de estas componentes puede ser debida a la necesidad de un procesado concreto (p. ej. meta-scheduling) o como respuesta al resultado de otra componente (p. ej. gesti´on de fallos), permitiendo la composici´on din´amica de complejas cadenas de acci´on. Con la integraci´on de estas componentes, se consigue gestionar de forma completa el ciclo de vida de un worfklow. Pueden consultarse m´as detalles sobre las componentes de movimiento de datos y gesti´on de fallos en [2, 28]. A modo de ejemplo, para que el lector comprenda la interacci´on existente entre las componentes, mostraremos el proceso seguido para ejecutar una tarea. En primer lugar, la descripci´on de la tarea se almacena en el repositorio de mensajes. Los mediadores capaces de ejecutar dicha tarea compiten por su ejecuci´on. Como resultado la tarea es asignada a un entorno concreto (este proceso se detalla en el siguiente p´arrafo). Antes de ejecutar la tarea, el mediador solicita el movimiento de los datos de entrada necesarios. Una vez transferidos, el mediador env´ıa la tarea al Grid para que se ejecute. Cuando la tarea finaliza o falla, el mediador solicita el movimiento de los datos de salida a su ubicaci´on final, recupera el log de ejecuci´on e introduce dicha informaci´on en el repositorio de mensajes. Si la tarea ha finalizado correctamente se coloca la misma en el repositorio de mensajes hasta que es recuperada por el usuario. Si por contra, la tarea ha fallado, la componente de gesti´on de fallos obtiene la causa del fallo y toma alguna decisi´on al respecto, como por ejemplo, reejecutar la tarea en otro entorno o notificar al usuario del error que se ha producido. En caso de que la tarea sea reejecutada, se repite el proceso, mientras que si se decide avisar al usuario del fallo, se act´ua como si hubiera acabado correctamente e indicando el error. Por tanto, el proceso de scheduling de nuestra infraestructura se corresponde con el proceso anterior, en el que los mediadores compiten por ejecutar tareas. Este proceso se construye en base a la sem´antica de las operaciones de lectura definidas en el modelo Linda. As´ı, se establece que, cuando dos o m´as componentes realizan una operaci´on de lectura sobre una misma tupla, se selecciona una de las componentes de manera no determinista, siendo ´esta la que obtiene la tupla. De esta forma, el proceso de scheduling de la infraestructura consiste en que todos los mediadores capaces de ejecutar una tarea realizan una operaci´on de lectura sobre la tupla que contiene la informaci´on de la tarea, siendo el propio repositorio el que selecciona uno de los mediadores de manera no determinista. 2.3 Capa de entornos de computaci´on En lo que corresponde a los entornos de computaci´on, se han integrado: el cluster Hermes del Instituto de Investigaci´on en Ingenier´ıa de Arag´on (I3A)2, el cual es gestionado utilizando el middleware Condor; y dos Grids pertenecientes a la Iniciativa Grid Europea (EGI)3: 2http://i3a.unizar.es/ 3http://www.egi.eu/ 10 Cap´ıtulo 2. Una infraestructura para la integraci´on din´amica de entornos de computaci´on AraGrid4y PireGrid5, gestionados por el middleware gLite y administrados por el Instituto de Biocomputaci´on y F´ısica de Sistemas Complejos (BIFI)6. La principal diferencia del modelo de integraci´on propuesto, con respecto a otras soluciones [15, 18], reside en que la misma se realiza desde una perspectiva de usuario de los entornos de computaci´on y no desde un punto de vista de administrador. Este enfoque permite evitar las barreras administrativas que surgen a la hora de integrar entornos gestionados por diferentes organizaciones ya que, en nuestro caso, esta integraci´on es completamente transparente para el entorno de ejecuci´on. A su vez, el dise˜no desacoplado de la soluci´on permite aislar al usuario de los detalles de ejecuci´on referentes a cada entorno, siendo la infraestructura la encargada de lidiar con dicha complejidad. La capa de mediadores desarrollada, permite afrontar las diferentes caracter´ısticas de cada una de estos entornos y gestionar su heterogeneidad. De la misma manera, este dise˜no facilita la integraci´on de entornos de computaci´on (puede realizarse de forma din´amica) y la reutilizaci´on de los mediadores desarrollados para gestionar otros entornos gestionados por los mismos middlewares (el mediador de un middleware puede ser utilizado en cualquier entorno gestionado por dicho middleware). 2.4 Breve resumen de las aportaciones de la infraestructura En resumen, la orientaci´on a servicios de la infraestructura ofrece al usuario una visi´on de servicio de ejecuci´on de workflows y tareas computacionalmente costosas. De esta forma, se posibilita la ejecuci´on de workflows programados en diferentes lenguajes. Adem´as, el uso de JSDL, como lenguaje est´andar de descripci´on de tareas, permite programar los workflows de manera independiente del entorno de ejecuci´on. Internamente, la naturaleza abierta y flexible de la soluci´on propuesta se basa en el uso de un broker de recursos formado por un repositorio de mensajes basado en Linda y un conjunto de mediadores. El repositorio de mensajes facilita la integraci´on y sustituci´on de mediadores y componentes de gesti´on de forma din´amica. Los mediadores encapsulan la heterogeneidad de los diferentes entornos de computaci´on utilizados, desacoplan el broker de recursos de los detalles de los diferentes middleware de Grid, abstraen al usuario de la complejidad de los mismos y pueden ser reutilizados en entornos gestionados por un mismo middleware. El uso conjunto del repositorio de mensajes y los mediadores permite definir una pol´ıtica de competencia que posibilita la ejecuci´on de las tareas de los workflows en diferentes entornos de ejecuci´on utilizando las operaciones ofrecidas en el modelo Linda. Finalmente, la integraci´on de varias componentes de gesti´on permite mejorar la gesti´on del ciclo de vida de las tareas ejecutadas ofreciendo servicios de movimiento de datos y gesti´on de fallos. 4http://www.araGrid.es/ 5http://www.pireGrid.eu/ 6http://bifi.es/es/ 11 Cap´ıtulo 3 |Meta-scheduling basado en simulaci´on La infraestructura descrita en el cap´ıtulo anterior presenta una clara limitaci´on en cuanto al proceso de asignaci´on de tareas a entornos de computaci´on. En dicho proceso no se utiliza informaci´on sobre el estado de los entornos de computaci´on, si no que se utiliza un modelo no determinista Este modelo no utiliza ning´un tipo de informaci´on para decidir el entorno concreto a utilizar. Esto puede llevar a una mala utilizaci´on de los recursos y a la disminuci´on de las prestaciones del workflow. Para solucionar este problema, es necesario incluir en la infraestructura alg´un tipo de t´ecnica de meta-scheduling que tenga en cuenta informaci´on din´amica sobre el estado de los entornos de ejecuci´on y utilice dicha informaci´on para guiar el proceso de asignaci´on de tareas a entornos de computaci´on. En este cap´ıtulo, se detalla la estrategia de meta-scheduling propuesta, se muestran sus beneficios y se detalla el proceso de asignaci´on de tareas realizado al incorporar un metascheduler. Dicha estrategia utiliza t´ecnicas de simulaci´on para obtener datos que permitan tomar decisiones de meta-scheduling. Por tanto, debido a su importancia en el proceso, se detallan los aspectos fundamentales referentes a la simulaci´on como es el dise˜no de los simuladores, la metodlog´ıa de creaci´on de los workloads y la validaci´on de los resultados obtenidos. Finalmente, se proporcionan algunos detalles referentes a la implementaci´on del meta-scheduler. 3.1 Proceso de asignaci´on de tareas a entornos de computaci´on Como se indic´o en el cap´ıtulo anterior, la infraestructura soporta dos mecanismos de selecci´on del entorno a utilizar para ejecutar una tarea. El primero consiste en que el usuario indica el entorno de ejecuci´on en el modelo del workflow. La utilizaci´on de este scheduling est´atico y guiado por el usuario plantea dos problemas: en primer lugar, el usuario no suele tener informaci´on para determinar cu´al es el entorno m´as adecuado para ejecutar cada tarea, y en segundo lugar, el hecho de que la elecci´on sea est´atica (se realiza al comienzo de la ejecuci´on del workflow) implica que cuando se ejecuta cada tarea la situaci´on ser´a diferente de la inicial, y los criterios de selecci´on pueden haber variado. Por tanto, ´esta no es una alternativa adecuada para sacar el m´aximo partido a los entornos de computaci´on integrados y asegurar los requisitos de calidad de servicio solicitados por los usuarios. La segunda posibilidad es que sea el propio sistema el que asuma la responsabilidad de tomar dicha decisi´on. Para ello se propuso una estrategia de selecci´on en la que los mediadores compiten por ejecutar trabajos y se selecciona uno de ellos de forma no determinista. Esta estrategia presenta varios inconvenientes: •Los mediadores no consideran cuestiones de calidad de servicio (QoS) acerca de la ejecuci´on de los trabajos en el entorno que representan. Esto puede llevar a que una tarea se ejecute en un entorno inadecuado, degradando el rendimiento de todo el workflow. 13 Sergio Hern´andez de Mesa •Las decisiones de scheduling son adoptadas localmente por cada mediador. Por tanto, uno de ellos podr´ıa monopolizar la ejecuci´on de todos los trabajos llevando a una situaci´on de sobrecarga de uno de los entornos de computaci´on mientras el resto permanecen vac´ıos. Esto provocar´ıa que los trabajos se vieran afectados por elevados tiempos de espera en una situaci´on en la que existen recursos libres. •Los mediadores ignoran el estado actual de los recursos, la posible evoluci´on de los mismos y el comportamiento de los trabajos ejecutados en el entorno. De nuevo, esto puede llevar a que se ejecuten trabajos en condiciones en las que el entorno est´a sobrecargado o a la elecci´on de un entorno inadecuado para la ejecuci´on de un determinado trabajo, degradando las prestaciones y realizando un mal aprovechamiento de los recursos disponibles. Para solventar los inconvenientes anteriores, se propone incorporar en la infraestructura una estrategia de meta-scheduling basada en la utilizaci´on de t´ecnicas de simulaci´on [34]. La Figura 3.1 muestra las diferentes fases del proceso, el cual detallaremos a continuaci´on: 1. Inicialmente, las tareas pendientes (abstractas) de ejecuci´on, almacenadas en el repositorio de mensajes, son recuperadas por el meta-scheduler. 2. El meta-scheduler determina los entornos capaces de ejecutar dichas tareas y solicita a los mediadores correspondientes que simulen su ejecuci´on. 3. Al recibir la petici´on de simulaci´on, los mediadores obtienen el estado del entorno de ejecuci´on y construyen un workload que refleje el estado de la misma y su evoluci´on futura (la metodolog´ıa de construcci´on de los workloads se detalla en la secci´on 3.3). 4. Los mediadores realizan la simulaci´on de las tareas indicadas con el workload construido y devuelven el resultado al meta-scheduler. 5. Cuando el meta-scheduler ha recibido el resultado de todas las simulaciones, elige el entorno m´as adecuado en base a un algoritmo de optimizaci´on y almacena dicha informaci´on en la descripci´on de la tarea. De esta forma, la tarea se convierte en una tarea concreta. 6. Finalmente, el meta-scheduler env´ıa la tarea al repositorio de mensajes para que sea recuperada y ejecutada por el mediador correspondiente en el entorno seleccionado Esta soluci´on, basada en la utilizaci´on de un meta-scheduler que asigna trabajos a diferentes entornos en base a la informaci´on proporcionada por simuladores, permite mejorar el rendimiento de los workflows al tener en cuenta el estado actual y futuro de los entornos de computaci´on y aplicar algoritmos de optimizaci´on de los criterios deseados. Concretamente, en este caso se utiliza un algoritmo para optimizar del tiempo de ejecuci´on. En cualquier caso, el an´alisis de diferentes algoritmos de optimizaci´on queda fuera del alcance de este trabajo. 3.2 Dise˜no de los simuladores Para soportar el proceso anterior, es necesario extender los mediadores integrando un simulador dentro de los mismos. El simulador debe ser capaz de: i) modelar diferentes entornos de computaci´on incluyendo la organizaci´on de los recursos, sus caracter´ısticas (procesadores, memoria RAM, caracter´ısticas de la red) y la pol´ıtica de scheduling; ii) permitir la construcci´on din´amica de workloads que contengan las tareas a simular y tareas que representen la carga de fondo del sistema; y, finalmente iii) simular la ejecuci´on de tareas midiendo par´ametros como el 14 Cap´ıtulo 3. Meta-scheduling basado en simulaci´on Figura 3.1: Componente arquitectural para realizar meta-scheduling basado en simulaci´on. tiempo de ejecuci´on o el tiempo de cola. Asimismo, para facilitar el desarrollo de diferentes simuladores, el simulador debe proporcionar una interfaz com´un que sea independiente del entorno a simular. Por ´ultimo, siguiendo la l´ınea anterior, el dise˜no debe ser f´acilmente adaptable y reutilizable para construir nuevos simuladores. Para posibilitar la ejecuci´on de trabajos en nuestra infraestructura se han construido simuladores para entornos gestionados por Condor y gLite. La elecci´on de estos middlewares se debe a que son dos de los middlewares m´as empleados para gestionar entornos de computaci´on de tipo Grid, y a que son los utilizados por los entornos integrados dentro de la infraestructura propuesta. Como base para los simuladores desarrollados se ha utilizado Alea [35]. Alea es un simulador basado en eventos y construido sobre GridSim [36]. Alea extiende GridSim proporcionando un scheduler centralizado, mejorando algunas funcionalidades y aumentando la escalabilidad y la velocidad de la simulaci´on. Adem´as, Alea proporciona un entorno de experimentaci´on f´acil de configurar y utilizar, el cual ayuda en la adaptaci´on del simulador a nuevos entornos. La implementaci´on de Alea ha sido extendida como parte de este trabajo en aspectos como la posibilidad de definir requisitos de memoria, la definici´on de un modelo de Grid m´as completo o la definici´on de nuevas pol´ıticas de scheduling. A continuaci´on, abordaremos el dise˜no de un simulador de Condor y su reutilizaci´on para construir un simulador de gLite. 3.2.1 Dise˜no del simulador de Condor usado en Hermes Para ilustrar el dise˜no realizado, se va a detallar el dise˜no del simulador de Condor que se usa en el cluster Hermes. Hermes es un cluster de computaci´on alojado por el Instituto de Investigaci´on en Ingenier´ıa de Arag´on (I3A). Est´a formado por una gran variedad de recursos de computaci´on heterog´eneos y dispone de un total de 1308 procesadores y 2.56 TB de memoria RAM. En lo que respecta al dise˜nado realizado, el cual puede observarse en la Figura 3.2, como entrada se proporciona el workload que indica las tareas a simular y un modelo del Grid sobre el que se van a ejecutar las mismas; mientras que, como salida se indican los resultados de la simulaci´on de dichas tareas en el entorno indicado. Internamente, el simulador est´a formado por cuatro componentes fundamentales: la componente de carga de trabajos, la componente de carga de m´aquinas, el scheduler y el recolector de resultados. 15 Sergio Hern´andez de Mesa Figura 3.2: Dise˜no arquitectural del simulador de Condor. El workload se representa utilizando el formato GWF (Grid Workload Format) propuesto por el archivo de workloads de Grid [37]. Este workload es el que contiene las tareas a simular y agrupa tanto las tareas objetivo de la simulaci´on como otras tareas que modelan la carga de fondo del entorno. La metodolog´ıa de construcci´on de los workloads se detallar´a m´as adelante. El modelo del Grid corresponde a un fichero de texto que contiene la informaci´on de los nodos de computaci´on del Grid. La representaci´on usada en este modelo, se ha extendido para posibilitar la definici´on de modelos m´as detallados al usados por defecto en Alea. La representaci´on de cada nodo incluye el n´umero de m´aquinas que lo forman, el n´umero de CPUs por m´aquina, la cantidad total de memoria por m´aquina, la arquitectura de las m´aquinas del nodo, su sistema operativo y las caracter´ısticas de la red. Junto con este modelo, se incluye un modelo de fallos que permite reflejar cambios din´amicos en el entorno durante la simulaci´on (ca´ıdas de nodos y fallos de m´aquinas). La componente de carga de trabajos lee la descripci´on de los trabajos y se la env´ıa al scheduler. Este m´odulo ha sido extendido para soportar la definici´on de requisitos de memoria y el usuario y grupo, u organizaci´on virtual, correspondiente a cada trabajo. La componente de carga de m´aquinas es la responsable de obtener la descripci´on de los nodos del entorno de computaci´on. Este m´odulo se ha extendido para ser capaz de tratar toda la informaci´on proporcionada dentro del modelo del Grid (anteriormente s´olo se permit´ıa indicar el n´umero de m´aquinas y procesadores). El Scheduler es la componente m´as compleja y la ´unica que es necesario modificar para construir nuevos simuladores. La componente ha sido extendida para soportar la pol´ıtica de scheduling basada en prioridades de usuario que usa Condor. Esta pol´ıtica funciona del siguiente modo: cuando un trabajo llega al scheduler, el mismo es encolado en la cola de trabajos del usuario. Esta cola se ordena por la prioridad propia de los trabajos de ese usuario y el instante de llegada. Cuando el scheduler solicita la ejecuci´on de un nuevo trabajo, los trabajos se ordenan por la prioridad de su usuario, seleccion´andose el trabajo con mayor prioridad de todos los 16 Cap´ıtulo 3. Meta-scheduling basado en simulaci´on disponibles. Entonces, se seleccionan las m´aquinas que tienen suficientes recursos (procesadores y memoria) para ejecutar ese trabajo y las m´aquinas que podr´ıan tener los recursos solicitados si expulsasen alguno de los trabajos que est´an ejecutando en ese momento. Estas m´aquinas son seleccionadas como candidatas potenciales para ejecutar el nuevo trabajo. Cuando se ha completado la lista de candidatas potenciales, la misma se ordena de acuerdo a m´ultiples criterios (preferencias del trabajo, preferencias de la m´aquina, etc.) para encontrar el recurso m´as adecuado. En el caso de que no haya ning´un recurso disponible el trabajo vuelve a ser encolado en la cola del usuario y el scheduler intenta ejecutar otro trabajo. Finalmente, cuando se ha podido seleccionar un trabajo y un recurso adecuado para su ejecuci´on, el trabajo es enviado al recurso actualiz´andose el estado del mismo. Si para posibilitar la ejecuci´on del trabajo en dicho recurso es necesario expulsar un trabajo, el scheduler se encarga de reencolar dicho trabajo para que pueda ser ejecutado en otro momento. Finalmente, el recolector de resultados es la componente encargada de almacenar los resultados de la simulaci´on y proporcionarlos como salida. Cuando un trabajo es enviado a un recurso, es expulsado o una m´aquina falla, el recolector de resultados almacena dicha informaci´on. Asimismo, cuando un trabajo finaliza su ejecuci´on correctamente, el recolector almacena la informaci´on relativa al mismo en el fichero de salida de la simulaci´on. Para cada trabajo, se indica el tiempo de llegada, el tiempo que ha permanecido el mismo en la cola, el tiempo de ejecuci´on, el recurso en el que se ha ejecutado y el n´umero de expulsiones que ha sufrido. 3.2.2 Dise˜no del simulador de gLite usado en AraGrid La Figura 3.3 muestra la arquitectura del simulador de gLite utilizado en AraGrid. AraGrid es un Grid regional gestionado por el Instituto de Biocomputaci´on y F´ısica de Sistemas Complejos (BIFI). Est´a formado por cuatro sites que se encuentran geogr´aficamente distribuidos en diferentes facultades (dos sites en Zaragoza, uno en Huesca y otro en Teruel). En total, el Grid dispone de 1728 procesadores y 4 TB de memoria RAM repartidos de forma homog´enea entre los diferentes sites. Gracias a la extensibilidad y facilidad de uso del simulador desarrollado, se ha podido reaprovechar el simulador de Condor para la elaboraci´on del simulador de gLite. De esta forma, la construcci´on de este nuevo simulador ha sido r´apida y sencilla. En consecuencia, el dise˜no del simulador de gLite es an´alogo al del simulador de Condor presentado anteriormente (Figura 3.2). Si comparamos los dise˜nos arquitecturales de ambos simuladores (Figuras 3.2 y 3.3), se puede ver como s´olo ha sido necesario modificar el scheduler ya que gLite utiliza un pol´ıtica de scheduling jer´arquica, diferente de la de Condor. En dicha pol´ıtica, los trabajos enviados son gestionados por un scheduler global que env´ıa los mismos a alguno de los schedulers locales dependiendo de los requisitos del trabajo, su ranking, la ocupaci´on de los sites que forman el Grid y los recursos a los que puede acceder la organizaci´on virtual del usuario que env´ıa el trabajo. Por su parte, los schedulers locales de los diferentes sites utilizan una pol´ıtica FCFS [38] (First Come First Serve) para ejecutar los trabajos dentro de los recursos del site. 3.3 Metodolog´ıa para la creaci´on de workloads La creaci´on de los workloads utilizados para reflejar el estado de cada entorno y su evoluci´on es un aspecto clave en el proceso de simulaci´on. Su elaboraci´on se realiza mediante el an´alisis de informaci´on hist´orica de un largo per´ıodo de tiempo (en nuestro caso se han utilizado logs de 1 a˜no) y considerando s´olo los momentos representativos; por ejemplo, las horas de carga pico de los d´ıas laborables en los meses de mayor utilizaci´on del entorno de ejecuci´on [39]. Se asume que cuantos m´as datos se tengan en cuenta, m´as realista y representativo ser´a el workload generado. 17 Sergio Hern´andez de Mesa Figura 3.3: Dise˜no arquitectural del simulador de gLite con detalle de uno de los schedulers locales. Una vez extra´ıdos los datos relevantes se utilizan t´ecnicas de regresi´on y ajuste de curvas para construir modelos probabilistas que modelen diferentes aspectos como el tiempo de ejecuci´on, el tiempo de cola o los recursos utilizados. La importancia de utilizar un workload apropiado ha sido identificada en varios trabajos [40, 41]. Los trabajos anteriores proponen la generaci´on de un ´unico workload que considere ´unicamente momentos de carga extrema o carga media del entorno de computaci´on. Entonces, el workload obtenido se utiliza para customizar la configuraci´on del entorno y obtener una mejora de sus prestaciones en la situaci´on elegida (extrema o media) [39]. Sin embargo, con fines de simulaci´on, estas aproximaciones no son v´alidas ya que debe considerarse el estado real de los recursos. Si se utiliza un workload medio o extremo como entrada del simulador, los resultados de la simulaci´on no se ajustar´an al comportamiento obtenido en la ejecuci´on real de las tareas al no realizarse la misma en condiciones de carga reales. En consecuencia, como la informaci´on proporcionada por los simuladores se utiliza para tomar decisiones de meta-scheduling, el uso de un workload no representativo puede llevar a tomar malas decisiones de meta-scheduling que degraden las prestaciones del workflow en lugar de mejorar las mismas. Nuestra propuesta consiste en construir varios workloads que representen diferentes situaciones representativas y que dependan de la carga de los recursos (carga baja, carga media y carga alta), la fecha (d´ıas laborables y festivos) y el momento del d´ıa (ma˜nana, tarde y noche). De esta forma, cuando se va a realizar una simulaci´on se obtiene el estado actual del entorno de ejecuci´on y se selecciona el workload m´as adecuado. Adem´as, a la informaci´on del workload se le a˜nade la informaci´on de los trabajos que se encuentran actualmente en ejecuci´on y encolados obteniendo un workload que representa el estado actual del entorno y su evoluci´on. De forma detallada, el proceso que se lleva a cabo cuando el meta-scheduler solicita que se simule la ejecuci´on de una tarea es el siguiente: 18 Cap´ıtulo 3. Meta-scheduling basado en simulaci´on 1. Cuando un mediador recibe una petici´on de simulaci´on, construye un workload que describe las tareas que se deben simular. 2. A continuaci´on, el mediador consigue informaci´on sobre el estado del entorno de computaci´on y los trabajos que se encuentran en ejecuci´on actualmente o est´an encolados. 3. Con la informaci´on del estado de los recursos, se adapta el modelo predefinido del Grid a la situaci´on actual, incluyendo los fallos existentes en los recursos. 4. Con la informaci´on de los trabajos que se est´an ejecutando o est´an en la cola y teniendo en cuenta la fecha actual, se selecciona el workload m´as adecuado a la situaci´on actual. 5. Al workload anterior se le a˜nade la informaci´on de las tareas que se est´an ejecutando actualmente y las que se encuentran encoladas. Con esto se obtiene un workload que representa el estado actual y la evoluci´on futura del entorno. 6. Cuando se han creado los dos workloads (el workload con las tareas a ejecutar y el workload con el estado del entorno de ejecuci´on), se combinan los mismos para crear un ´unico workload que sirve como entrada del simulador. 7. Se realiza la simulaci´on utilizando el workload anterior. 8. Cuando la simulaci´on acaba, el mediador obtiene los resultados y filtra los mismos para proporcionar ´unicamente al meta-scheduler los resultados referentes a las tareas objetivo de la simulaci´on. La implementaci´on de este proceso se encapsula dentro del mediador. ´ Este se encarga de obtener informaci´on acerca del estado del entorno de ejecuci´on y realizar diferentes procesados de la informaci´on obtenida para adaptar el modelo del entorno de computaci´on a la situaci´on actual y construir el workload de entrada. Para facilitar la realizaci´on de las simulaciones, los simuladores ofrecen una interfaz com´un independiente de los detalles concretos del simulador y un formato com´un para la descripci´on de los datos de entrada y salida. 3.4 Validaci´on de los simuladores El objetivo de los simuladores desarrollados es utilizar los mismos como herramienta de decisi´on en el proceso de meta-scheduling. Por tanto, la validaci´on de los resultados proporcionados por los mismos es fundamental para verificar la viabilidad y utilidad de la soluci´on [42]. Para ello, se ha comparado la utilizaci´on de los recursos, la duraci´on de los trabajos y los tiempos de cola en el entorno real y en el entorno simulado. La Figura 3.4 muestra una comparaci´on de la utilizaci´on media del cluster Hermes (gestionado por Condor), extra´ıda de los logs de ejecuci´on del ´ultimo a˜no, y la utilizaci´on obtenida de la simulaci´on de esos mismos trabajos. La comparaci´on se presenta en un ciclo diario, con el eje horizontal indicando la hora del d´ıa y el vertical mostrando el porcentaje de utilizaci´on de recursos. Como se puede observar, los resultados del entorno simulado son muy similares a los obtenidos en el escenario real. Ambas gr´aficas muestran la misma tendencia, siendo los resultados de la simulaci´on ligeramente inferiores. En t´erminos del error incurrido en la simulaci´on, en media el error es del 15.09 % con una desviaci´on t´ıpica del 8.03 %. Para validar el indicador de rendimiento de los trabajos se exploran las m´etricas de tiempo de ejecuci´on y tiempo de cola. La Figura 3.5 muestra la comparaci´on de ambos par´ametros mediante las correspondientes funciones de probabilidad acumulada. En ambos casos, se muestra el eje horizontal en escala logar´ıtmica para dotar a las gr´aficas de una mayor claridad. La Figura 3.5-a 19 Sergio Hern´andez de Mesa Por tanto, queda claro que la utilizaci´on de la infraestructura permite realizar un mejor aprovechamiento de los recursos, lo que lleva a una mejora de las prestaciones de los workflows ejecutados. Esta mejora se observa independientemente del tipo de tarea a ejecutar, ya que la informaci´on proporcionada por los simuladores permite inferir el entorno en el que los trabajos se ejecutar´an m´as r´apido al pasar menos tiempo encolados y verse menos afectados por las expulsiones. 26 Cap´ıtulo 5 |Conclusiones y trabajo futuro El trabajo realizado de forma previa a la elaboraci´on de esta Tesis Fin de M´aster se ha encaminado a resolver diferentes problemas en el ´ambito de ejecuci´on de workflows cient´ıficos en entornos de computaci´on din´amicos [2, 28, 34, 29]. Por su parte, este Trabajo Fin de M´aster ha permitido avanzar en el desarrollo de la soluci´on propuesta. Concretamente, ha permitido mejorar el proceso de selecci´on del entorno m´as adecuado para ejecutar cada tarea. En cualquier caso, todav´ıa quedan diferentes retos abiertos en este campo, los cuales ser´an abordados durante el desarrollo de la tesis doctoral del autor. En este cap´ıtulo, se pretende dar una visi´on general de algunas de las posibles l´ıneas de trabajo futuro abiertas. Estas l´ıneas incluyen la mejora de diferentes aspectos de la infraestructura y la integraci´on en la misma de nuevas caracter´ısticas que a˜nadan distintas funcionalidades. Finalmente, se presentan las conclusiones obtenidas en esta Tesis Fin de M´aster. 5.1 L´ıneas futuras En primer lugar, uno de los aspectos a mejorar en la infraestructura presentada es la gesti´on de los fallos que se producen al ejecutar trabajos en entornos de computaci´on tipo Grid. ´ Estos pueden deberse a diferentes causas como errores en la programaci´on del workflow, fallos propios de la aplicaci´on que se ejecuta o fallos debidos al propio entorno de ejecuci´on. Para lidiar con estos fallos, se ha incluido una componente de gesti´on de fallos que trata los mismos de forma general. Sin embargo, ser´ıa deseable incluir un modelo de gesti´on de fallos que permita realizar un tratamiento m´as personalizado de los mismos a diferentes niveles. Una posible soluci´on ser´ıa utilizar un sistema de gesti´on de fallos jer´arquico. De esta forma, los propios mediadores deber´ıan ser capaces de tratar fallos relacionados con su entorno de ejecuci´on. Por su parte, la componente de gesti´on de fallos gen´erica se encargar´ıa de los fallos que no pueden ser tratados por los mediadores y ofrecer´ıa pol´ıticas de m´as alto nivel para la reejecuci´on de trabajos en otros entornos o la utilizaci´on de workflows sustitutos [45]. Por tanto, la utilizaci´on de un sistema jer´arquico de fallos permitir´ıa realizar un mejor tratamiento de los fallos ya que los mediadores pueden tener m´as informaci´on que la componente de gesti´on del fallo concreto que se ha producido y reducir la sobrecarga del broker en el caso de que los fallos puedan ser tratados por el mediador. Otro punto delicado de la infraestructura de integraci´on planteada es el broker de coordinaci´on que gestiona los trabajos a ejecutar en los entornos disponibles. Dependiendo del n´umero de workflows cient´ıficos que est´en siendo ejecutados y su complejidad, este broker podr´ıa estar sujeto a situaciones de sobrecarga e, incluso, a potenciales fallos. En ambos casos, las consecuencias ser´ıan cr´ıticas desde el punto de vista de la soluci´on de integraci´on que se propone. Una posible soluci´on ser´ıa el uso, durante estas situaciones, del servicio de colas Amazon 27 Sergio Hern´andez de Mesa SQS1(Amazon Simple Queue Service), como alternativa m´as flexible al uso de Linda. Otra posibilidad ser´ıa utilizar un sistema de coordinaci´on distribuido que incrementase la escalabilidad y tolerancia a fallos de la infraestructura [46]. Tambi´en se pretende mejorar la pol´ıtica de meta-scheduling basada en simulaci´on propuesta en este trabajo. Dicha mejora pretende aumentar la precisi´on de la simulaci´on contemplando aspectos como el movimiento de datos entre diferentes entornos. Asimismo, se plantea mejorar el proceso de generaci´on de workloads. Generalmente, la construcci´on de workloads se realiza de forma manual debido a su elevada complejidad y a la dificultad para decidir el modelo estad´ıstico que mejor se ajusta a los datos. Sin embargo, ser´ıa deseable utilizar alg´un tipo de t´ecnica que permita generar workloads de forma autom´atica sin que el usuario tenga que intervenir en el proceso [47]. Esto permitir´ıa refinar los workloads en base a los nuevos datos obtenidos en cada ejecuci´on y liberar al administrador de dicha tarea. Para mejorar el proceso de asignaci´on de tareas a infraestructuras, adem´as de mejorar la precisi´on de los simuladores, se pretende mejorar el propio meta-scheduler. Para ello, se plantea explorar y comparar algoritmos de meta-scheduling que usen diferentes modelos y t´ecnicas algor´ıtmicas como modelos econ´omicos [48], algoritmos gen´eticos [49] o algoritmos basados en inteligencia animal [50, 51]. El objetivo de esta comparaci´on es determinar bajo que condiciones los algoritmos ofrecen un mayor rendimiento y permiten optimizar la soluci´on propuesta. Un aspecto muy importante ligado a los algoritmos de meta-scheduling es la definici´on de par´ametros de calidad de servicio (QoS) y acuerdos de nivel de servicio (SLAs) [52]. En este punto, se plantea la utilizaci´on de algoritmos de negociaci´on de contratos para cumplir los par´ametros de calidad de servicio solicitados por el usuario [53]. Tambi´en se pretende dar soporte a requisitos de calidad de servicio que no est´en ´unicamente basados en m´etricas de rendimiento, si no tambi´en en otros aspectos menos habituales, pero que tambi´en son demandados por la comunidad de workflows cient´ıficos [54], es el caso de requisitos de coste o requisitos de tolerancia a fallos. Otro aspecto clave en el ´ambito de los workflows cient´ıficos es el denominado provenance [55], la recolecci´on de datos que permitan reproducir los experimentos, compartir dichos experimentos y reutilizar las t´ecnicas, herramientas y metodolog´ıas empleadas. En este punto, se plantea el registro de toda la informaci´on referente al proceso de ejecuci´on de los workflows y la utilizaci´on de est´andares (XES2, OPM [56]) para almacenar dicha informaci´on y permitir la generaci´on autom´atica de workflows que faciliten las cuestiones anteriores. De cara a dotar al framework de un mayor n´umero de recursos computacionales, se plantea integrar entornos de computaci´on basados en Cloud que permitan obtener recursos bajo demanda y ayuden a satisfacer la calidad de servicio requerida por el usuario. En esa misma l´ınea, se pretende desarrollar nuevos mediadores que permitan integrar nuevos entornos de computaci´on incluyendo Grids gestionados por diferentes middlewares (ARC [57], UNICORE [58], etc.), entornos de computaci´on voluntaria y ef´ımera a trav´es de sus respectivos middlewares (p. ej. BOINC [59]) o clusters de computaci´on basados en la utilizaci´on de tarjetas gr´aficas. Finalmente, se pretende aplicar la infraestructura desarrollada a la resoluci´on de problemas computacionalmente costosos ya sea dentro del ´ambito acad´emico o empresarial. Para ello, se pretenden establecer acuerdos de colaboraci´on con otros grupos de investigaci´on y con empresas y la realizaci´on de estancias en centros de investigaci´on de referencia internacional. 1http://aws.amazon.com/es/sqs/ 2http://www.xes-standard.org/ 28 Cap´ıtulo 5. Conclusiones y trabajo futuro 5.2 Conclusiones En este trabajo se ha presentado una estrategia de meta-scheduling basada en el uso de t´ecnicas de simulaci´on. Adem´as, se ha integrado un meta-scheduler que implementa dicha estrategia en una infraestructura que permite ejecutar workflows cient´ıficos, programados en diferentes lenguajes, en varios entornos de computaci´on heterog´eneos. Esta soluci´on ha permitido abordar uno de los principales retos existentes en el ´ambito de la ejecuci´on de workflows cient´ıficos: la posibilidad de ejecutar diferentes partes de un mismo workflow en diferentes entornos de computaci´on, obteniendo una mejora en el rendimiento global del workflow. Finalmente, por medio de un caso de uso real en el ´ambito de la computaci´on cient´ıfica se ha validado experimentalmente la viabilidad de la soluci´on y sus beneficios. Para guiar el proceso de meta-scheduling se han utilizado t´ecnicas de simulaci´on, algo que no hab´ıa sido todav´ıa explorado para este prop´osito. Esta soluci´on, ha permitido tener en cuenta diferentes par´ametros importantes para la toma de decisiones como la carga actual y esperada de los entornos de ejecuci´on o la pol´ıtica de scheduling utilizada en cada uno de ellos. El desarrollo de un simulador gen´erico, el cual ha sido dise˜nado para ser f´acilmente reproducible y adaptable, ha permitido desarrollar simuladores para diferentes entornos de computaci´on de forma sencilla. Asimismo, el desarrollo de una metodolog´ıa para la construcci´on din´amica de worklodas ha permitido simular las tareas en condiciones de carga reales, mejorando la precisi´on de los resultados obtenidos en las simulaciones. Por tanto, la soluci´on propuesta se ha mostrado como una estrategia v´alida y efectiva al ser capaz de abordar la complejidad inherente de los diferentes entornos de computaci´on proporcionando resultados muy parecidos a los obtenidos en el entorno real. Este aspecto ha sido comprobado mediante la validaci´on experimental de la t´ecnica. Este trabajo ha establecido las bases para un modelo de scheduling din´amico, transparente para el usuario y que trata de aprovechar todos los recursos disponibles para mejorar el rendimiento de los workflows. En cualquier caso, no se trata de un trabajo cerrado o finalizado, sino que se han abierto nuevas posibilidades y l´ıneas de trabajo futuro. La utilizaci´on de diferentes algoritmos de meta-scheduling que no s´olo optimicen el tiempo de ejecuci´on, si no que permitan satisfacer varios tipos de requisitos de calidad de servicio y el establecimiento de acuerdos de nivel de servicio que garanticen al usuario un nivel m´ınimo de servicio son algunos de los aspectos que podr´ıan incluirse en la soluci´on presentada. Finalmente, el trabajo de investigaci´on ha dado lugar a tres publicaciones cient´ıficas, con revisi´on por pares, en dos congresos internacionales: el III International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING 2012) y el II International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2012); y un congreso nacional: las VIII Jornadas de Ciencia e Ingenier´ıa de Servicios (JCIS 2012), todos ellos de referencia en los diferentes campos abordados (computaci´on Grid, simulaci´on y servicios de computaci´on, respectivamente). 29 Bibliograf´ıa [1] I. Foster and C. Kesselman, The Grid 2: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers Inc., 2003. [2] S. Hern´andez, J. Fabra, and P. ´ Alvarez, “Framework para el despliegue autom´atico de workflows cient´ıficos en entornos grid,” Proyecto Fin de Carrera, Universidad de Zaragoza, 2011. [3] J. Yu and R. Buyya, “A taxonomy of workflow management systems for Grid computing,” Journal of Grid Computing, vol. 3, no. 3-4, pp. 171–200, 2005. [4] M. Rahman, R. Ranjan, R. Buyya, and B. Benatallah, “A taxonomy and survey on autonomic management of applications in grid computing environments,” Concurrency and Computation: Practice and Experience, vol. 23, no. 16, pp. 1990–2019, 2011. [5] K. Plankensteiner, J. Montagnat, and R. Prodan, “IWIR: a language enabling portability across grid workflow systems,” in Proceedings of the 6th workshop on Workflows in support of large-scale science, ser. WORKS ’11, New York, NY, USA, 2011, pp. 97–106. [6] I. Foster, “Service-Oriented Science,” Science, vol. 308, no. 5723, pp. 814–817, 2005. [7] A. Anjomshoaa, F. Brisard, M. Drescher, D. Fellows, A. Ly, S. Mcgough, D. Pulsipher, and A. Savva, “Job Submission Description Language (JSDL) Specification, Version 1.0,” Global Grid Forum, Tech. Rep., 2005. [8] A. Kulshrestha and G. Allen, “Service oriented architecture for job submission and management on grid computing resources,” in High Performance Computing (HiPC), 2009 International Conference on. IEEE, 2009, pp. 13–19. [9] J. Mulerikkal and P. Strazdins, “An soa approach to high performance scientific computing: Early experiences,” in High Performance Computing (HiPC), 2010 International Conference on, 2010, pp. 1 –10. [10] Z. Farkas and P. Kacsuk, “P-GRADE Portal: A generic workflow system to support user communities,” Future Generation Comp. Syst., vol. 27, no. 5, pp. 454–465, 2011. [11] F. Berman, G. Fox, and A. J. G. Hey, Grid Computing: Making the Global Infrastructure a Reality, T. Hey, Ed. New York, NY, USA: John Wiley & Sons, Inc., 2003. [12] D. Thain, T. Tannenbaum, and M. Livny, “Distributed computing in practice: the Condor experience: Research articles,” Concurrency and Computation: Practice and Experience, vol. 17, no. 2-4, pp. 323–356, 2005. [13] I. Foster and C. Kesselman, “Globus: A Metacomputing Infrastructure Toolkit,” The International Journal of Supercomputer Applications and High Performance Computing, vol. 11, no. 2, pp. 115– 128, 1997. [14] E. Laure, C. Gr, S. Fisher, A. Frohner, P. Kunszt, A. Krenek, O. Mulmo, F. Pacini, F. Prelz, J. White, M. Barroso, P. Buncic, R. Byrom, L. Cornwall, M. Craig, A. D. Meglio, A. Djaoui, F. Giacomini, J. Hahkala, F. Hemmer, S. Hicks, A. Edlund, A. Maraschini, R. Middleton, M. Sgaravatto, M. Steenbakkers, J. Walk, and A. Wilson, “Programming the Grid with gLite,” in Computational Methods in Science and Technology, 2006. 31 Sergio Hern´andez de Mesa [15] A. Iosup, T. Tannenbaum, M. Farrellee, D. Epema, and M. Livny, “Inter-operating grids through delegated matchmaking,” Sci. Program., vol. 16, no. 2-3, pp. 233–253, 2008. [16] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, “Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility,” Future Gener. Comput. Syst., vol. 25, no. 6, pp. 599–616, 2009. [17] A. Oleksiak, A. Tullo, P. Graham, T. Kuczynski, J. Nabrzyski, D. Szejnfeld, and T. Sloan, “HPC- Europa: Towards uniform access to European HPC infrastructures,” in 6th IEEE/ACM International Conference on Grid Computing (GRID 2005). IEEE, 2005, pp. 308–311. [18] A. Kert´esz and P. Kacsuk, “GMBS: A new middleware service for making grids interoperable,” Future Generation Computer Systems, vol. 26, no. 4, pp. 542–553, 2010. [19] I. Rodero, F. Guim, J. Corbalan, L. L. Fong, Y. G. Liu, and S. M. Sadjadi, “Looking for an evolution of grid scheduling: Meta-brokering,” 2007. [20] M. Rahman, R. Ranjan, and R. Buyya, “Cooperative and decentralized workflow scheduling in global grids,” Future Gener. Comput. Syst., vol. 26, no. 5, pp. 753–768, 2010. [21] K. Leal, E. Huedo, and I. M. Llorente, “A decentralized model for scheduling independent tasks in federated grids,” Future Generation Computer Systems, vol. 25, no. 8, pp. 840 – 852, 2009. [22] M. Heidt, T. D¨ornemann, K. D¨ornemann, and B. Freisleben, “Omnivore: Integration of grid metascheduling and peer-to-peer technologies,” in Proceedings of the 2008 Eighth IEEE International Symposium on Cluster Computing and the Grid, ser. CCGRID ’08. Washington, DC, USA: IEEE Computer Society, 2008, pp. 316–323. [23] J. Yu and R. Buyya, “A novel architecture for realizing grid workflow using tuple spaces,” in Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, ser. GRID ’04. Washington, DC, USA: IEEE Computer Society, 2004, pp. 119–128. [24] E. Elmroth and J. Tordsson, “An interoperable, standards-based grid resource broker and job submission service,” in Proceedings of the First International Conference on e-Science and Grid Computing, ser. E-SCIENCE ’05. Washington, DC, USA: IEEE Computer Society, 2005, pp. 212– 220. [25] L. Adzigogov, J. Soldatos, and L. Polymenakos, “EMPEROR: An OGSA Grid Meta-Scheduler Based on Dynamic Resource Predictions,” Journal of Grid Computing, vol. 3, pp. 19–37, 2005. [26] R. M. Piro, A. Guarise, G. Patania, and A. Werbrouck, “Using historical accounting information to predict the resource usage of grid jobs,” Future Generation Computer Systems, vol. 25, no. 5, pp. 499 – 510, 2009. [27] H. Li, D. Groep, and L. Wolters, “Mining performance data for metascheduling decision support in the grid,” Future Gener. Comput. Syst., vol. 23, no. 1, pp. 92–99, 2007. [28] J. Fabra, S. Hern´andez, P. ´ Alvarez, and J. Ezpeleta, “A framework for the flexible deployment of scientific workflows in grid environments,” To appear in The Third International Conference on Cloud Computing, GRIDs, and Virtualizations (CLOUD COMPUTING 2012), 2012. [29] S. Hern´andez, J. Fabra, P. ´ Alvarez, and J. Ezpeleta, “Una soluci´on soa para ejecutar workflows cient´ıficos en entornos grid heterog´eneos,” To appear in the VIII Jornadas de Ciencia e Ingenier´ıa de Servicios (JCIS 2012), 2012. [30] O. Kummer, “Introduction to petri nets and reference nets,” Sozionik Aktuell, vol. 1, pp. 1–9, 2001. [31] D. Hull, K. Wolstencroft, R. Stevens, C. Goble, M. R. Pocock, P. Li, and T. Oinn, “Taverna: a tool for building and running workflows of services.” Nucleic acids research, vol. 34, no. Web Server issue, pp. W729–732, 2006. [32] B. Lud¨ascher, I. Altintas, C. Berkley, D. Higgins, E. Jaeger, M. Jones, E. A. Lee, J. Tao, and Y. Zhao, “Scientific workflow management and the Kepler system,” Concurrency and Computation: Practice and Experience, vol. 18, no. 10, pp. 1039–1065, 2006. 32 Bibliograf´ıa [33] N. Carriero and D. Gelernter, “Linda in context,” Commun. ACM, vol. 32, no. 4, pp. 444–458, 1989. [34] S. Hern´andez, J. Fabra, P. ´ Alvarez, and J. Ezpeleta, “A simulation-based scheduling strategy for scientific workflows,” To appear in the Second International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2012), 2012. [35] H. R. Dalibor Klus´acek, “Alea 2 – job scheduling simulator,” in Proceedings of the 3rd International ICST Conference on Simulation Tools and Techniques (SIMUTools 2010). ICST, 2010. [36] A. Sulistio, U. Cibej, S. Venugopal, B. Robic, and R. Buyya, “A toolkit for modelling and simulating data grids: an extension to gridsim.” Concurrency and Computation: Practice and Experience, vol. 20, no. 13, pp. 1591–1609, 2008. [37] A. Iosup, H. Li, M. Jan, S. Anoep, C. Dumitrescu, L. Wolters, and D. H. Epema, “The grid workloads archive,” Future Generation Computer Systems, vol. 24, no. 7, pp. 672 – 686, 2008. [38] V. Hamscher, U. Schwiegelshohn, A. Streit, and R. Yahyapour, “Evaluation of job-scheduling strategies for grid computing,” in Proceedings of the First IEEE/ACM International Workshop on Grid Computing, ser. GRID ’00. Springer-Verlag, 2000, pp. 191–202. [39] D. Feitelson, “Workload modeling for performance evaluation,” in Performance Evaluation of Complex Systems: Techniques and Tools. Berlin / Heidelberg: Springer, 2002, pp. 114–141. [40] E. Medernach, “Workload analysis of a cluster in a grid environment,” in Job Scheduling Strategies for Parallel Processing, ser. Lecture Notes in Computer Science, D. Feitelson, E. Frachtenberg, L. Rudolph, and U. Schwiegelshohn, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2005, vol. 3834, ch. 2, pp. 36–61. [41] H. Li, D. Groep, and L. Wolters, “Workload characteristics of a multi-cluster supercomputer.” Springer Verlag, 2004, pp. 176–193. [42] R. G. Sargent, “Verification and validation of simulation models,” in Proceedings of the 2010 Winter Simulation Conference – WSC 2010, 2010, pp. 166–183. [43] F. Dong and S. G. Akl, “Scheduling algorithms for grid computing : State of the art and open problems,” Components, vol. 202, no. 4, pp. 1–55, 2006. [44] I. J. Taylor, E. Deelman, D. B. Gannon, and M. Shields, Workflows for e-Science: Scientific Workflows for Grids. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2006. [45] S. Hwang and C. Kesselman, “A flexible framework for fault tolerance in the grid,” Journal of Grid Computing, vol. 1, pp. 251–272, 2003. [46] J. Fabra, P. ´ Alvarez, and J. Ezpeleta, “DRLinda: A Distributed Message Broker for Collaborative Interactions Among Business Processes,” in E-Commerce and Web Technologies, ser. Lecture Notes in Computer Science, G. Psaila and R. Wagner, Eds. Springer Berlin / Heidelberg, 2007, vol. 4655, pp. 212–221. [47] A. Iosup, O. Sonmez, and D. Epema, “DGSim: Comparing Grid resource management architectures through trace-based simulation,” in Proceedings of the 14th international Euro-Par conference on Parallel Processing, ser. Euro-Par ’08. Berlin, Heidelberg: Springer-Verlag, 2008, pp. 13–25. [48] R. Buyya, D. Abramson, J. Giddy, and H. Stockinger, “Economic models for resource management and scheduling in grid computing,” Concurrency and Computation: Practice and Experience, vol. 14, no. 13-15, pp. 1507–1542, 2002. [49] Y. Gao, H. Rong, and J. Z. Huang, “Adaptive grid job scheduling with genetic algorithms,” Future Generation Computer Systems, vol. 21, no. 1, pp. 151 – 161, 2005. [50] H. Liu, A. Abraham, and A. E. Hassanien, “Scheduling jobs on computational grids using a fuzzy particle swarm optimization algorithm,” Future Generation Computer Systems, vol. 26, no. 8, pp. 1336 – 1343, 2010. [51] W.-N. Chen and J. Zhang, “An ant colony optimization approach to a grid workflow scheduling problem with various qos requirements,” Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, vol. 39, no. 1, pp. 29 –43, 2009. 33 Sergio Hern´andez de Mesa [52] R. Sakellariou, “Job scheduling on the grid: Towards sla-based scheduling,” Computer, vol. 16, p. 207–222, 2008. [53] V. Stantchev and C. Schr¨opfer, “Negotiating and enforcing qos and slas in grid and cloud computing,” in Advances in Grid and Pervasive Computing, ser. Lecture Notes in Computer Science, N. Abdennadher and D. Petcu, Eds. Springer Berlin / Heidelberg, 2009, vol. 5529, pp. 25–35. [54] Y. Gil, E. Deelman, M. Ellisman, T. Fahringer, G. Fox, D. Gannon, C. Goble, M. Livny, L. Moreau, and J. Myers, “Examining the challenges of scientific workflows,” Computer, vol. 40, no. 12, pp. 24 –32, 2007. [55] S. B. Davidson and J. Freire, “Provenance and scientific workflows: challenges and opportunities,” in Proceedings of the 2008 ACM SIGMOD international conference on Management of data, ser. SIGMOD ’08. New York, NY, USA: ACM, 2008, pp. 1345–1350. [56] L. Moreau, B. Clifford, J. Freire, J. Futrelle, Y. Gil, P. Groth, N. Kwasnikowska, S. Miles, P. Missier, J. Myers, B. Plale, Y. Simmhan, E. Stephan, and J. V. den Bussche, “The open provenance model core specification (v1.1),” Future Generation Computer Systems, vol. 27, no. 6, pp. 743 – 756, 2011. [57] M. Ellert, M. Grønager, A. Konstantinov, B. K´onya, J. Lindemann, I. Livenson, J. Nielsen, M. Niinim¨aki, O. Smirnova, and A. W¨a¨an¨anen, “Advanced resource connector middleware for lightweight computational grids,” Future Generation Computer Systems, vol. 23, no. 2, pp. 219 – 240, 2007. [58] D. W. Erwin, “UNICORE—a grid computing environment,” Concurrency and Computation: Practice and Experience, vol. 14, no. 13-15, pp. 1395–1410, 2002. [59] D. Anderson, “BOINC: a system for public-resource computing and storage,” in Grid Computing, 2004. Proceedings. Fifth IEEE/ACM International Workshop on, 2004, pp. 4 – 10. 34