MetaPlanificación por Adelantado en Grids Heterogéneos Luis

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.
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.
2.
3.
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
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 (Tini ) y el
tiempo en el que tiene que haber acabado su
Figura 2: Representación geométrica [13, 5].
ejecución (Tf in ). 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 Tini o antes,
mientras que la región R2 representa aquellos
huecos que empiezan después de Tini .
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 _Execi 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 GridWay 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-14475C04-03”; conjuntamente por la JCCM y el Fondo
Social Europeo a través del proyecto “FSE 20072013”; 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�34):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.