Meta Planificación por Adelantado en Grids Heterogéneos. Luis Tomás Carmen Carrión Blanca Caminero

Meta Planificación por Adelantado en Grids Heterogéneos Luis Tomás Carmen Carrión Blanca Caminero Dept. de Sistemas Informáticos Universidad de Castilla-La Mancha {luistb,carmen,blanca}@dsi.uclm.es Resumen Un Grid es un sistema extremadamente heterogéneo y distribuido en el que además los recursos presentan un comportamiento dinámico. Debido a esto es muy difícil proporcionar calidad de servicio (QoS) en este tipo de entornos puesto que el tiempo para completar la ejecución de un trabajo es muy variable. El objetivo principal de este trabajo es proporcionar QoS en entornos Grid mediante meta-planificación por adelantado de los trabajos. Este artículo presenta una técnica para gestionar el estado de ocupación de los recursos basada en una estructura de árboles rojonegro. Además, no se requiere tener un conocimiento a priori de la duración de los trabajos a ejecutar diferenciándolo de otros trabajos en los que dicha información si que es necesaria. La evaluación del rendimiento de las técnicas implementadas se realiza sobre un entorno Grid real, lo que ilustra la eficiencia de la propuesta para proporcionar la QoS requerida. 1. Introducción En los entornos Grid los recursos están en diferentes dominios y bajo diferentes políticas de acceso. Esto hace que la búsqueda y uso de recursos sea una tarea difícil de afrontar por parte de los usuarios. Además, en entornos Grid de gran escala dicha tarea no es manualmente abordable. Por consiguiente, la infraestructura Grid debe proporcionar los servicios necesarios para una planificación automática que se encargue de la selección de recursos y del proceso de negociación con éstos de forma transparente al usuario. Este sistema es conocido como meta-planificador [1]. Por lo tanto, la QoS recibida por el usuario depende de la funcionalidad y rendimiento del sistema meta-planificador. Sin embargo, la naturaleza dinámica y heterogénea de los recursos del Grid, así como las diferentes características de las diferentes aplicaciones, complican el proceso de planificación. Además, generalmente el meta-planificador no tiene el control total de los recursos, ni incluso el conocimiento sobre el estado de éstos [2], complicando aún más el proceso de planificación. Una idea fundamental para solventar estos problemas es asegurarse de que un determinado recurso estará disponible cuando un determinado trabajo lo requiera. Esto plantea la necesidad de reservar o planificar el uso de los recursos por adelantado [3]. Una reserva por adelantado se puede definir como la delegación restrictiva o limitada de una determinada capacidad de un recurso durante un periodo de tiempo predeterminado [4]. El objetivo de este tipo de reservas es proporcionar QoS asegurando que los trabajos cumplirán las QoS solicitadas, lo que además incrementa la predictibilidad del sistema. Sin embargo, estas reservas no siempre son factibles puesto que no todos los recursos las permiten, o existen ciertos tipos de recursos, como el ancho de banda a través de internet, que pertenecen a más de un dominio administrativo, lo que dificulta gravemente su reserva o incluso la imposibilita. Esta es la razón por la que se propone un algoritmo de planificación por adelantado para tratar el problema de la planificación de trabajos. Esta planificación por adelantado se basa

602 XXI Jornadas de Paralelismo en planificar los trabajos a ejecutar en el futuro, seleccionando los recursos y los periodos de tiempo en los que se ejecutarán, pero sin hacer ninguna reserva física de éstos. Así, el reto clave de esta técnica es que es muy difícil decidir si un trabajo podrá ser ejecutado cumpliendo sus QoS solicitadas sin conocer el estado que los recursos presentarán en el futuro [5]. El algoritmo presentado en este artículo es consciente del comportamiento dinámico de los recursos del Grid, su uso y las características de los trabajos a ejecutar. Además, este estudio se centra en heurísticas poco costosas computacionalmente y que están basadas en computación geométrica. El uso de los recursos es gestionado usando arboles rojo-negro. Este trabajo presenta y evalúa dos técnicas para estimar la duración de los trabajos: basada en (1) una función lineal y (2) en log de ejecuciones. En (1), la misma función se usa para calcular la duración de los trabajos en todos los recursos, por tanto, son tratados como si fueran homogéneos. En cambio, en (2) se tiene en cuenta el recurso donde las ejecuciones previas tuvieron lugar, y por lo tanto, tiene en cuenta la heterogeneidad de los recursos. El artículo esta organizado de la siguiente forma. En la Sección 2 se muestran algunos trabajos relacionados con el desarrollado en este artículo. En la Sección 3 se muestra una visión general sobre la meta-planificación por adelantado. La Sección 4 explica las extensiones desarrolladas para gestionar la planificación por adelantado. En la Sección 5 se presentan los experimentos llevados a cabo para evaluar la propuesta implementada. Finalmente, algunas conclusiones y líneas de trabajo futuro son mostradas en la Sección 6. 2. Trabajo Relacionado La infraestructura necesaria para la gestión de recursos y otras tareas como la seguridad, distribución de información, accesos remotos, etc., son proporcionados por herramientas Grid como Globus [6] y Legion [7]. En cuanto a la reserva avanzada de recursos, Globus Architecture for Reservation and Allocation (GARA) [8] es uno de los primeros trabajos y define la arquitectura básica para la gestión de dichas reservas en los recursos. Desde entonces, dichas reservas avanzadas han sido estudiadas en numerosos contextos, como en entornos cluster (Maui Scheduler [9]). Entre los sistemas que permiten la reserva de recursos en un Grid encontramos Grid Capacity Planning [10], que proporciona a los usuario la posibilidad de hacer reservas de recursos mediante negociación, co-alojamientos y coste. Otro sistema importante es VIOLA, que incluye un entorno de meta-planificación que proporciona soporte para co-alojamiento para recursos computacionales y de red. A pesar de que el soporte para las reservas avanzadas en las infraestructuras Grid está bastante limitado, es una característica que deben poseer para poder ofertar garantías de QoS [8, 10]. Qu [11] describe un método para solucionar este problema añadiendo un gestor de reservas avanzadas sobre el meta-planificador local. Por otro lado, la penalización en el rendimiento que supone el uso de estas reservas (típicamente decremento de la utilización de los recursos) también ha sido estudiado en [12]. Nuestro trabajo es diferente de los mencionados porque se centra en meta-planificación por adelantado en vez de en reservas avanzadas, debido a que éstas no siempre son posibles. Este trabajo usa arboles rojo-negro para gestionar el uso de los recursos, lo que ha sido probado en [5, 13], pero en dichos trabajos se asume que existe un conocimiento a priori sobre la duración de los trabajos, lo que no es considerado en nuestra propuesta. Por esta razón nuestro trabajo tiene que desarrollar técnicas para la predicción del tiempo necesario para ejecutar un trabajo. 3. Meta-planificación por adelantado Como se ha comentado antes, no todos los recursos pueden ser reservados. Esta es la razón para usar meta-planificicación por adelantado en vez de reservas avanzadas para proporcionar QoS a los usuarios del Grid. De este modo, el sistema tiene en cuenta las decisiones hechas para tomar nuevas decisiones y no solapar ejecuciones. Así, si solo existiera carga del Grid

Tecnología grid 603 en los recursos, esto podría ser suficiente para proporcionar QoS ya que no habría solape de ejecuciones en los recursos si las predicciones se hacen con la suficiente precisión. Sin embargo, desde el punto de vista de las aplicaciones del Grid, todas las tareas, las de los usuarios locales y las de los usuarios del Grid, suponen carga en el recurso. Los algoritmos para la planificación por adelantado necesitan ser lo suficientemente eficientes como para adaptarse a los cambios dinámicos en cuanto a la disponibilidad de los recursos y a las fluctuaciones de demanda por parte de los usuarios. Además, tienen que tener en cuenta la heterogeneidad de los recursos debido a que es una característica de los entornos Grid. Esto nos lleva a usar técnicas de computación geométrica para desarrollar algoritmos de planificación que eficientemente encuentren los recursos y periodos de tiempo adecuados para ejecutar cada trabajo. Este estudio está centrado en trabajos simples que no tienen dependencias entre ellos. En este tipo de trabajos el usuario proporciona tanto los ficheros de entrada como los ejecutables necesarios. Sin embargo, mediante el start time y el deadline se pueden generar flujos de trabajos con dependencias temporales. Teniendo en cuenta estas premisas, el proceso de meta-planificación por adelantado sigue los siguientes pasos: 1) El usuario hace una petición para ejecutar un trabajo con una determinada QoS, en este caso, start time y deadline del trabajo. 2) El meta-planificador ejecuta un algoritmo de búsqueda para seleccionar el recurso y el periodo de tiempo para ejecutar el trabajo. 3) Si no es posible alojar el trabajo se comienza un proceso de comunicación con otros metaplanificadores para alojar el trabajo en otros dominios administrativos. 4) Si aún así no es posible alojar el trabajo, se abre un proceso de negociación con el usuario para renegociar la QoS que necesita el trabajo, o descartar el trabajo en el caso de que el usuario no quiera cambiar dichos requerimientos de QoS. Figura 1: The Scheduler in Advance Layer SAlayer). 4. Implementación Esta propuesta se implementa como una extensión al meta-planificador GridWay [1]. Es una capa intermedia entre los usuarios y el meta-planificador, llamada Scheduling in Advance Layer SA-layer) (ver Figura 1). SAlayer usa funcionalidad proporcionada por GridWay como descubrimiento y monitorización de recursos, envío de trabajos y monitorización de su ejecución,.... Esta capa además almacena información sobre la ejecución de las aplicaciones (en DB Executions), y sobre el estado de los recursos y la red a través del tiempo (en DB Resources). Además, un nuevo parámetro ha sido añadido a GridWay, llamado JOB INFORMATION, para que el usuario pueda indicar las características del trabajo a ejecutar. En primer lugar el usuario fija el tamaño total de los ficheros de entrada y salida, en caso de que conozca dicha información. Y en segundo lugar se fijan otras características del trabajo, como los argumentos de entrada de la aplicación, haciendo más precisa la estimación sobre el tiempo de ejecución de dicho trabajo. De este modo, el tiempo de ejecución de un trabajo en un determinado recurso se calcula mediante una predicción teniendo en cuenta tanto las características del trabajo como las del recurso en el que se ejecutaría. Esta implementación gestiona el uso de los recursos dividiendo el tiempo en slots de un minuto. Así, el uso futuro de los recursos es planificado alojando los trabajos en los recursos, en un tiempo específico y usando un número determinado de slots. De este modo, se nece-

604 XXI Jornadas de Paralelismo sitan políticas de alojamiento para encontrar los slots de tiempo más adecuados para cada trabajo (implementadas en el módulo Gap Management), estructuras de datos adecuadas para manejar eficientemente toda la información necesaria (Data structure en Figura 1) y algoritmos que lleven a cabo la estimación sobre la duración de los trabajos en los recursos (implementados en el módulo Predictor). 4.1. Gestión de huecos La manera de alojar los trabajos en los slots de tiempo tiene influencia en cuantos trabajos pueden ser planificados. Esto se debe a la fragmentación generada entre los trabajos planificados. Se pueden desarrollar diferentes métodos para buscar y alojar los trabajos teniendo en cuenta los trabajos ya planificados y obteniendo diferentes resultados en cuanto a fragmentación generada y número de trabajos planificados. En nuestra primera aproximación, se ha desarrollado una política First Fit que selecciona el primer hueco libre que sea adecuado para alojar el trabajo. 4.2. Data structure La estructura de datos usada para mantener la información acerca de los slots de tiempo libres en cada uno de los recursos es un aspecto clave de la implementación. Una estructura de datos adecuada nos permite obtener unos mejores tiempos de ejecución, reduciendo la complejidad de los algoritmos y por lo tanto, haciéndolo más escalable. La estructura de datos usada en este trabajo son los arboles rojo-negro [5, 13]. El objetivo de usar este tipo de arboles es desarrollar técnicas que identifiquen los periodos de tiempo factibles para alojar los trabajos de una manera eficiente y sin tener que explorar todos los posibles slots libres de los recursos. El módulo Gap Management (ver Figura 1 1) gestiona la estructura de datos. Dicho módulo representa la información que contiene el árbol en forma geométrica. Así, cada trabajo se representa mediante un punto en el plano, como se puede ver en la Figura 2. Las coordenadas del trabajo son el tiempo en el que el trabajo puede empezar a ejecutarse (T ini) y el tiempo en el que tiene que haber acabado su Figura 2: Representación geométrica [13, 5]. ejecución (T fin ). P representa el tiempo en el que como muy temprano puede empezar a ejecutarse el trabajo, mientas que P representa el último. Los puntos etiquetados representan los slots libres (huecos), siendo sus coordenadas el tiempo de inicio y fin de dichos huecos. Todos los puntos por encima y a la derecha de la línea que une P y P son posibles huecos que podrían alojar el trabajo. Como Castillo explica en [5, 13], los arboles pueden ser divididos en dos regiones, llamadas R1 y R2 (ver Figura 2. La región R1 representa los huecos que empiezan en T ini o antes, mientras que la región R2 representa aquellos huecos que empiezan después de T ini. Por otro lado, un trabajo planificado puede crear como mucho dos nuevos huecos: uno entre el inicio del hueco y el del trabajo (leading gap), y otro entre el fin del trabajo y el del hueco (trailing gap). Cuando los trabajo se alojen en la región R2, no se producirá ningún leading gap. Esta es la razón que nos lleva a buscar los huecos en primer lugar en la región R2, y si no hay ningún hueco factible en dicha región, buscar en la región R1. 4.3. Predictor Las predicciones acerca del tiempo de ejecución de los trabajos son difíciles de obtener debido a las diferencias de rendimiento entre los recursos del Grid y debido a que dichas características de rendimiento pueden variar de unas aplicaciones a otras. Las técnicas para realizar dichas predicciones incluyen aplicar modelos estadísticos a los históricos de ejecuciones previas [14] y heurísticas basadas en las características de los trabajos y los recursos [15, 16]. Basado en esto, el algoritmo pro-

Tecnología grid 605 puesto por Castillo [5, 13] es extendido para tener en cuenta la heterogeneidad de los recursos Grid. Este trabajo compara el uso de log históricos de ejecuciones y de una función lineal para calcular el tiempo necesario para ejecutar un trabajo en un determinado recurso. La función lineal no tiene en cuenta los diferentes rendimientos de los recursos, sólo los parámetros de entrada y salida de los trabajos y el conocimiento sobre su comportamiento. De este modo, usando este tipo de predicción todos los recursos son tratados como homogéneos. Por otro lado, usando logs de datos, la heterogeneidad de los recursos se tiene en cuenta. Con este método, la media de la duración de ejecuciones previas del mismo tipo de trabajos en el recurso seleccionado es usada para calcular el número de slots necesarios para dicho trabajo en dicho recurso. De esta forma, las predicciones de la duración de los trabajos se calculan para cada aplicación y para cada host del sistema, pero sólo cuando se encuentra un hueco factible en un recurso. Así, no es necesario calcular los tiempos para todos los recursos, lo que sería muy ineficiente. Por otro lado, en este trabajo, dos aplicaciones son consideradas del mismo tipo cuando además tienen los mismos parámetros de entrada y salida, en términos de número, tamaño y tipo. Esta técnica tiene en cuenta la heterogeneidad de los recursos del Grid y no asume que los usuarios tiene un conocimiento a priori de la duración de los trabajos en los recursos, como se asume en [5, 13]. Ambas formas de estimar los tiempos de ejecución de los trabajos son presentadas y evaluadas a continuación. 5. Evaluación de prestaciones Esta sección describe los experimentos realizados para medir el rendimiento de la propuesta y los resultados obtenidos. 5.1. Entorno de pruebas La evaluación de la implementación realizada ha sido llevada a cabo en un entorno Grid real. Este entorno esta formado por recursos localizados en dos edificios pertenecientes a la Universidad de Castilla La-Mancha (UCLM). En Figura 3: Características de la Carga de Trabajo. un edificio se encuentra la máquina que lleva a cabo las tareas de planificación y varios recursos computacionales. En un segundo edificio se encuentra otro recurso computación, un cluster de 88 cores. Todas estas máquinas pertenecen al mismo dominio administrativo (UCLM) pero están localizados en diferentes subredes. Hay que resaltar que dichas máquinas pertenecen a otros usuarios, por lo que tienen su propia carga local. 5.2. Carga de trabajo usada Para modelar la carga de trabajo se ha usado uno de los test incluidos en los benchmarks GRASP [17], llamado 3node. Este test consiste en enviar un fichero desde un nodo fuente a uno de computación, el cuál realiza una búsqueda de patrones, generando un fichero solución con el número de aciertos. Finalmente dicho fichero se envía a un nodo destino. Además, este test acepta dos parámetros que permiten hacerlo mas intenso computacionalmente (parámetro compute_scale) y/o más demandante de red (parámetro output_scale). Existen otros parámetros a tener en cuenta en la carga usada para medir el rendimiento (ver Figura 3). T _max_reservation representa el adelanto con el que se puede llevar a cabo una decisión de planificación por adelantado; T _Exec i el tiempo necesario para ejecutar el trabajo i; SchedulingW indow muestra el intervalo de tiempo en el que el trabajo tiene que ser ejecutado; con los dos últimos parámetros se obtiene el Laxity, que representa como de estricto es el usuario al enviar sus trabajos; y ArrivalRatio representa el tiempo medio entre el envío de trabajos. Para esta evaluación, tanto el compute_scale como el output_scale toman valores entre 0 y 20, con media de 10. El T _max_reservation se pone a 0 porque el SA-layer (con ambas técnicas de predicción) es comparado con GridWay que no permite ha-

606 XXI Jornadas de Paralelismo cer planificaciones por adelantado. El Laxity varia entre 0 y 10 minutos, con media de 5 minutos. Finalmente, el ArrivalRatio varia desde 1 a 4 trabajos por minuto. Los resultados mostrados son la media de 5 ejecuciones. 5.3. Evaluación del rendimiento Esta sección muestra la comparación entre SAlayer, con las dos formas de calcular los tiempos necesarios para la ejecución de los trabajos, y el meta-planificador GridWay original. Para evaluar el rendimiento de ambas técnicas de estimación del tiempo de ejecución se usan varias estadísticas. Desde el punto de vista del usuario se usan las siguientes: Scheduled job rate que representa el porcentaje de trabajos aceptados, es decir, aquellos cuyo deadline puede ser cumplido [13]; y QoS not fulfilled que contabiliza el número de trabajos rechazados, más el número de trabajos que fueron inicialmente aceptados pero que finalmente sus ejecuciones fueron retrasadas, no cumpliendo con sus deadlines. Desde el punto de vista del sistema se usan otras dos métricas: Overlap que contabiliza el número de minutos que se alarga la ejecución de un trabajo sobre la estimación calculada; y Waste que representa el número de minutos que no son usados para ejecutar ningún trabajo puesto que el meta-planificador los reservó para otro trabajo que finalmente acabo su ejecución antes del tiempo estimado. Los resultados de esta evaluación se muestran en la Figura 4. La Figura 4 (a) representa el porcentaje de trabajos aceptados debido a que el meta-planificador tiene suficientes slots libres para alojarlos con las QoS solicitadas. Usando SA-layer, cuantos más trabajos hay en el sistema, mayor número de trabajos son rechazados. Por otro lado, usando del Grid- Way original, todos los trabajos son siempre aceptados ya que no existe ninguna capa que decida si es posible o no ejecutar dichos trabajos cumpliendo con las QoS requeridas. Para tasas de envío de trabajos bajas (1 trabajo/min.), la tasa de aceptación es la misma para ambas formas de estimar los tiempos de ejecución. Sin embargo, cuando dicha tasa de submisión es mayor, usar log de datos para estimar los tiempos de ejecución obtiene mejores resultados, puesto que puede aceptar un mayor número de trabajos debido a que la estimación es mejor y diferente para cada recurso del sistema. Esta diferente estimación para cada recurso hace la predicción mas precisa y por lo tanto habrá menos overlap y waste que usando la función lineal (como se observa en las Figuras 4 (c) y (d)). Además, usando la estimación basada en log de datos se puede aceptar un mayor número de trabajos puesto que se necesita reservar un menor número de slots por cada trabajo. La Figura 4 (b) muestra el número de trabajos que no se ejecutan con la QoS solicitada, incluyendo los trabajos rechazados y los que acaban su ejecución después del deadline. De nuevo, cuantos más trabajos hay en el sistema, mayor es el número de trabajos que no se ejecutan con la QoS requerida. En este caso, esto también es cierto para GridWay. De hecho, GridWay se comporta peor que SA-layer. Esto se debe a que usando SA-layer hay varios trabajos que no se aceptan puesto que el sistema estima que no es posible ejecutarlos con la QoS solicitada. De este modo, la ejecución de estos trabajos no interfiere con la de los ya aceptados. Por otro lado, usando log de datos se consigue un mejor rendimiento al hacer la estimación más precisa y ajustada a cada recurso, y por consiguiente, hay un menor número de trabajos que no se ejecutan con la QoS necesitada. Las Figuras 4 (c) y (d) representan el tiempo medio de overlap y waste, respectivamente, usando la función lineal y los logs de datos. Debido a que GridWay no hace ninguna predicción sobre la duración de los trabajos, dicha información no está representada en estas gráficas. En ellas se puede ver que las estimaciones que usan log de datos son mucho más precisas ya que tienen un menor overlap y waste. Teniendo un menor overlap, habrá menos trabajos aceptados que no cumplan las QoS requeridas, lo que explica los resultados mostrados en la Figura 4 (b). Por otro lado, teniendo un menor waste, un mayor número de trabajos pueden ser aceptados ya que cada trabajo necesita reservar menos slots para su ejecución,

Tecnología grid 607 (a) Accepted job (b) QoS not fulfilled (c) Tiempo de Overlap (d) Tiempo de Waste Figura 4: Comparación de los métodos de estimación del tiempo de ejecución de los trabajos. lo que también explica los resultados mostrados en la Figura 4 (a). Finalmente, como puede concluirse de las gráficas de la Figura 4, la mejor opción es usar log de datos para estimar los tiempos de ejecución puesto que este método tiene en cuenta la heterogeneidad de los recursos del Grid. Por otro lado, dichos resultados también destacan la importancia de usar planificación por adelantado para poder proporcionar una mayor QoS a los usuarios del Grid. 6. Conclusiones Hay muchos trabajos que intentan proporcionar QoS en entornos Grid mediante reservas avanzadas. Sin embargo, estas reservas no son siempre posibles. Esta es la razón por la que se propone realizar meta-planificación por adelantado para proveer QoS. En ella se selecciona el recurso y el periodo temporal en el que se ejecutará el trabajo pero sin llevar a cabo ninguna reserva física del recurso. Este tipo de planificación permite estimar si un trabajo puede ser ejecutado cumpliendo con las QoS solicitadas, pero requiere enfrentarse a muchos retos, como el de desarrollar algoritmos de planificación eficientes y escalables o estudiar como predecir el tiempo necesario para ejecutar un trabajo en el futuro. En este trabajo se presenta una comparación entre usar o no planificación por adelantado. Dicha comparación enfatiza la importancia de usar dicho tipo de planificación para poder proporcionar la QoS requerida por los usuario. Por otro lado, también se muestra una comparación entre un método homogéneo (basado en una función lineal) y otro heterogéneo (basado en logs de ejecuciones) de calcular el tiempo necesario para la ejecución de un trabajo. Dicha comparación pone de manifiesto la importancia de tener en cuenta la heterogeneidad de los recursos en la estimación de los tiempos de ejecución de los trabajos. El método basado en log de datos lleva a cabo unos cálculos más precisos, permitiendo ejecutar más trabajos cumpliendo con sus requerimientos de QoS. El desarrollo e implementación de nuevos

608 XXI Jornadas de Paralelismo algoritmos eficientes y escalables son el reto de nuestra investigación. De este modo, como trabajo futuro se plantea incluir nuevos parámetros en la estimación de los tiempos de ejecución, como predicción del estado de los recursos o tener en cuenta la confianza en éstos y en las predicciones hechas. Otro reto de nuestro trabajo es proporcionar un método de replanificación que permita realojar trabajos ya planificados para aceptar otros con unos requerimientos de QoS más restrictivos. Agradecimientos Este trabajo ha sido apoyado conjuntamente por el MEC Español y la Comisión Europea fondos FEDER) a través de los proyectos Consolider Ingenio-2010 CSD2006-00046 y TIN2009-14475- C04-03 ; conjuntamente por la JCCM y el Fondo Social Europeo a través del proyecto FSE 2007-2013 ; y por la JCCM a través de los proyectos PBI08-0055-2800 y PII1C09-0101-9476. Referencias [1] E. Huedo, R. S. Montero, and I. M. Llorente. A modular meta-scheduling architecture for interfacing with pre-ws and WS Grid resource management services. Future Generation Computing Systems, 23 2):252 261, 2007. [2] Erik Elmroth and Johan Tordsson. An interoperable, standards-based grid resource broker and job submission service. In Proc. of the 1st Intl. Conference on e-science and Grid Computing e-science), Washington, DC, USA, 2005. [3] Anthony Sulistio. Advance Reservation and Revenue-based Resource Management for Grid Systems. PhD thesis, Department of Computer Science and Software Engineering, The University of Melbourne, Australia, 2008. [4] GWD-I, Global Grid Forum GGF). Advance reservations: State of the art. J. MacLaren, 2003. http://www.ggf.org. [5] Claris Castillo, George N. Rouskas, and Khaled Harfoush. Efficient resource management using advance reservations for heterogeneous grids. In Proc. of the Intl. Parallel and Distributed Processing Symposium IPDPS), Miami, USA, 2008. [6] The Globus Alliance. Web page at http:// www.globus.org, 2009. [7] Legion Project. Web page at http://legion. virginia.edu/, 2009. [8] Alain Roy and Volker Sander. Grid Resource Management, chapter GARA: A Uniform Quality of Service Architecture, pages 377 394. Kluwer Academic Publishers, 2003. [9] Maui Cluster Scheduler. Web page at http://www.clusterresources.com/ products/maui/, 2009. [10] Mumtaz Siddiqui, Alex Villazón, and Thomas Fahringer. Grid capacity planning with negotiation-based advance reservation for optimized QoS. In Proc. of the 2006 Conference on Supercomputing SC 06), Tampa, USA, 2006. [11] Changtao Qu. A grid advance reservation framework for co-allocation and co-reservation across heterogeneous local resource management systems. In Proc. of 7th Intl. Conference on Parallel Processing and Applied Mathematics PPAM), Gdansk, Poland, 2007. [12] W Smith, Ian Foster, and V Taylor. Scheduling with advanced reservations. In Proc. of the 14th Intl. Parallel and Distributed Processing Symposium IPDPS), Washington, DC, USA, 2000. [13] Claris Castillo, George N. Rouskas, and Khaled Harfoush. On the design of online scheduling algorithms for advance reservations and QoS in grids. In Proc. of the Intl. Parallel and Distributed Processing Symposium IPDPS), Los Alamitos, USA, 2007. [14] Peter A. Dinda. The statistical properties of host load. Scientific Programming, 7 3-4):211 229, 1999. [15] Agustín Caminero, Omer Rana, Blanca Caminero, and Carmen Carrión. Performance evaluation of an autonomic networkaware metascheduler for Grids. Concurrency and Computation: Practice and Experience, 21 13):1692 1708, 2009. [16] Hai Jin, Xuanhua Shi, Weizhong Qiang, and Deqing Zou. An adaptive meta-scheduler for data-intensive applications. Intl. Journal of Grid and Utility Computing, 1 1):32 37, 2005. [17] G. Chun, H. Dail, H. Casanova, and A. Snavely. Benchmark probes for grid assessment. In Proc. of 18th Intl. Parallel and Distributed Processing Symposium IPDPS), Santa Fe, New Mexico, 2004.