Incorporando Información de Red en el Metaplanificador GridWay

Transcripción

1 Castellón, Septiembre Incorporando Información de Red en el Metaplanificador GridWay Luis Tomás, Agustín Caminero, Blanca Caminero, Carmen Carrión 1 Resumen La agregación de recursos distribuidos geográficamente en el contexto de una aplicación particular ha sido posible gracias al desarrollo de las tecnologías Grid. Dado que los Grids son entornos extremadamente distribuidos, también hay que tener en cuenta ciertos requisitos sobre la red de interconexión cuando se realizan tareas habituales como son la planificación, migración o monitorización de trabajos. Hay que destacar que los usuarios, servicios y datos necesitan comunicarse entre sí sobre las redes, por tanto la red debería usarse de forma eficiente. Sin embargo, la mayoría de los esfuerzos existentes para proporcionar QoS en Grids no tienen en cuenta aspectos relacionados con la red, centrándose en carga de procesadores y accesos a discos. Los autores han propuesto anteriormente un marco para llevar a cabo una metaplanificación de grid consciente de la red. La utilidad de esta aproximación ha sido demostrada por medio de simulaciones. En este trabajo, se presenta y evalúa una implementación de un metaplanificador como prueba de concepto, desarrollada como una extensión sobre el metaplanificador GridWay. La extensión planteada aprovecha la información de la red a la hora de realizar la planificación de los trabajos. Los resultados muestran que el tiempo de respuesta percibido por los usuarios del Grid se reduce cuando los datos sobre el estado de la red se emplean en la planificación de trabajos. Palabras clave Computación Grid, metaplanificación, redes, Calidad de Servicio (QoS) I. Introducción LOS sistemas Grid son entornos muy variables, compuestos por una serie de organizaciones independientes que comparten sus recursos. Durante la pasada década, la Computación Grid ha surgido como una tecnología que ha hecho posible muchas aplicaciones intensivas en datos y/o en cálculo. A través del empleo de tecnologías Grid, es posible agregar recursos dispersos y heterogéneos para resolver varios tipos de aplicaciones paralelas en ciencia, ingeniería y comercio [1]. Un ejemplo ampliamente conocido de tales aplicaciones es la infraestructura mundial basada en Grid, desplegada para el procesamiento de los datos generados por los experimentos con el LHC en el CERN [2]. Los usuarios del Grid deberían percibir alguna calidad de servicio (QoS) en las prestaciones de sus aplicaciones, en términos de tiempo de respuesta o de número de trabajos finalizados por unidad de tiempo [3]. Sin embargo, esto es muy difícil de conseguir debido a la gran cantidad de redes interconec- 1 Instituto de Investigación en Informática de Albacete (I 3 A), Universidad de Castilla-La Mancha, {luistb,agustin,blanca,carmen}@dsi.uclm.es 0 Trabajo parcialmente financiado por el MEC y la Comisión Europea (fondos FEDER) bajo los proyectos Consolider Ingenio-2010 CSD y TIN C04-02 ; por la JCCM y el Fondo Social Europeo bajo el proyecto FSE ; y por los proyectos regionales PBC , PBC tadas que forman parte de un Grid [4]. Conseguir una QoS entre extremos es a menudo difícil, ya que si no se emplea reserva de recursos es complicado satisfacer cualquier garantía sobre la QoS. Sin embargo, en el caso de aplicaciones que necesitan una respuesta con ciertos requisitos temporales (por ejemplo, visualización colaborativa [5]), el Grid debe proporcionar a los usuarios algún grado de seguridad acerca del uso de los recursos. Éste es un tema no trivial, especialmente cuando se aborda desde la perspectiva de la QoS de red [4]. GARA [4], NRSE [16], G-QoSM [3], GNRB [17], and VIOLA [18] son algunas de las propuestas que podemos encontrar en la literatura orientadas a proveer QoS de red en sistemas Grid. No obstante, es un tema complejo no resulto, en el que no existe uniformidad de criterios. El objetivo de la investigación llebada a cabo por los autores es proporcionar QoS de red haciendo uso de una metaplanificación eficiente. Un metaplanificador es una entidad que se ocupa de los intereses de los usuarios en un Grid, tal como GridWay [6] o Condor/G [7]. Un usuario proporciona al metaplanificador un patrón de trabajo (job template), y desde ese instante, el metaplanificador se ocupará de interactuar con el Grid para conseguir que el trabajo se ejecute (selección de recursos, transferencias de datos, autentificación, monitorización de trabajos y migraciones). De entre los muchos aspectos que deben ser tenidos en cuenta a la hora de diseñar metaplanificadores, los autores están centrando su investigación en la selección de los recursos de computación donde se han de ejecutar los trabajos de los usuarios. Tal y como se mostrará más adelante, los metaplanificadores actuales toman sus decisiones de planificación en función de la potencia de cálculo (y utilización) de los recursos disponibles. Así, un metaplanificador puede decidir que el recurso más apropiado para ejecutar un trabajo es el más potente. Pero si existe algún enlace sobrecargado en el camino entre el recurso y las fuentes de datos, otros recursos menos potentes pero con una conexión de red menos cargada, pueden ser más adecuados para ejecutar dicho trabajo. En este caso, un recurso menos potente podría ser una mejor elección. Este escenario es todavía más dañino para las aplicaciones Grid que necesitan acceder a cantidades ingentes de datos de entrada desde sitios remotos, proporcionan análisis de los datos para una visualización remota, o intercambian datos entre máquinas distantes [1]. Entonces, es evidente que los requisitos de comunicación de este tipo de aplicaciones están sujetos a las restricciones de la red, que tienen un Actas de las XIX Jornadas de Paralelismo, pp , ISBN:

2 506 XIX Jornadas de Paralelismo impacto directo sobre las prestaciones finales de las aplicaciones. De aquí que el estado de la red deba ser tenido en cuenta cuando se realiza el proceso de selección de recursos [4]. El tema de interés de este trabajo es la mejora de las prestaciones de las aplicaciones a través del uso de información relativa a la red cuando se ejecutan decisiones de planificación. Los autores ya han desarrollado un marco de referencia con este propósito [8]. Entre otras, incluye una entidad denominada Grid Network Broker, GNB, integrada con el metaplanificador, que proporciona decisiones de planificación de trabajos basadas en información acerca del estado de la red. En este trabajo, se presenta una implementación de tal entidad como prueba del concepto, extendiendo el metaplanificador GridWay. También se incluyen algunos experimentos que muestran la bondad de esta aproximación. La Sección II describe brevemente el marco general de metaplanificación. Después, en la Sección III se comentan las extensiones implementadas sobre el metaplanificador GridWay. Seguidamente, se presentan los experimentos realizados en la Sección IV y, para finalizar la Sección V extrae las conclusiones y el trabajo futuro. II. Un marco para la metaplanificación Las aplicaciones de comunicación intensiva y de tiempo real requieren servicios de intermediación de QoS con el fin de proporcionar reservas garantizadas de capacidad de red junto con recursos computacionales. Los autores han propuesto en [8] una arquitectura flexible para la gestión de recursos de Grid, que está enfocada a garantizar los requerimientos de QoS especificados por la aplicación. Uno de los puntos claves de la arquitectura es una entidad denominada Grid Network Broker or GNB. Esta entidad chequeará el estado de la red y creará tanto reservas de red como asignaciones de servicios con el fin de proporcionar QoS de red a aplicaciones Grid. Nuestro escenario se muestra en la Figura 1 y consta de las siguientes entidades [9]: Usuarios, cada uno con varios trabajos; recursos de computación, por ejemplo, clusters de ordenadores; routers; GNB (Grid Network Broker), un metaplanificador consciente de la red; GIS (Grid Information Service), que mantiene una lista de recursos disponibles; monitor de recurso (por ejemplo Ganglia [10]), que proporciona información detallada sobre el estado de los recursos; BB (Bandwidth Broker), como por ejemplo [11], que está a cargo del dominio administrativo, y tiene acceso directo a los routers. BB puede proporcionar reservas de enlaces de red, y puede conocer la topología de la red entre dos puntos extremos. Fig. 1. Escenario de ejemplo. La interacción entre componentes de la arquitectura es como sigue: (1) Los usuarios le piden al GNB un recurso para ejecutar sus trabajos. Son los usuarios los que proporcionan las características de los trabajos. (2) El GNB acumula las peticiones y después de un intervalo de tiempo dado realiza dos operaciones por cada petición. Primero, realiza la planificación de esa petición de trabajo a un recurso computacional, y segundo, contacta al BB para que realiza un Control de Admisión de Conexión (CAC). (3) El GNB hace uso del GIS con el fin de obtener la lista de recursos disponibles, y entonces obtiene su nivel de carga actual del monitor de recurso. (4) El GNB hace uso del BB para desarrollar operaciones que requieran la red. El BB debería implementar algunas funciones para chequear si una transmisión se puede enrutar a través de un enlace específico. Al hacer que el BB tenga esta funcionalidad, aseguramos la independencia y autonomía de cada dominio administrativo. La arquitectura del GNB incluye los siguientes módulos (ver Figura 2): Fig. 2. Arquitectura del GNB. La Interface de usuario permite a los usuarios emitir peticiones al GNB. Más exactamente, un usuario puede solicitar al GNB que le asigne un recurso computacional para ejecutar su trabajo. El Planificador selecciona el recurso donde ejecutar el trabajo, atendiendo a diferentes criterios. Para ello, el Planificador obtiene la lista de los recursos disponibles facilitada por el módulo GIS. Distintos algoritmos de planificación pueden ser implementados. Los autores han propuesto varios de ellos en [8]. Estos algoritmos siempre tienen en cuenta la red a la hora de tomar decisiones de planificación. Además, en [9] los autores proponen un planificador que incorpora técnicas de computación autónoma. El Interfazce de BB trata con el BB, de forma que desarrolla tareas tales como el CAC. Cuando se implemente el CAC, el BB comprueba si una nueva conexión puede admitirse a través del camino de red entre el usuario y el recurso. De esta forma, los enlaces entre un usuario y un recurso dado (previamente seleccionado por el módulo Planificador) se pueden chequear. El BB también se comunica con los routers extremos, así como con los routers de núcleo del dominio. Los routers tiene la habilidad de manejar el tráfico de aplicación, por lo que tienen que ser configurados por el BB (por ejemplo, emitiendo comandos relacionados con la configuración de Diff- Serv) con el fin de aplicar la prioridad de reenvío adecuada a cada tipo de tráfico. Al hacer que el BB tenga estas funcionalidades, nos aseguramos de que se conserve la independencia y autonomía de cada dominio admisnistrativo. El Interface interdominio facilita la comunicación

3 Castellón, Septiembre con GNBs de otros dominios administrativos vecinos con el fin de encontrar recursos adecuados, no dispinibles en el dominio local. Toda la información que el GNB gestiona y usa se debe almacenar en el módulo Base de datos. Por ejemplo, información de la configuración de recursos (tipo CPU y velocidad, memoria RAM y disco, etc.) El propósito del Monitor de red es ejecutar periódicamente tests en la red de forma que la información sobre la carga actual y condiciones de retardos se puedan almacenar en la base de datos. Las pruebas realizadas hasta el momento bajo simulación con la herramienta GridSim [8] nos han permitido validar la arquitectura propuesta descrita anteriormente. Ahora, en este trabajo se desarrolla una implementación funcional del metaplanificador GridWay [6] integrando información de red. Se ha elegido este mataplanificador principalmente porque su código fuente está disponible, y debido al hecho de que se trata de un proyecto Globus [13]. También se han explotado sus capacidades para añadir nuevos criterios para desarrollar el filtrado y ordenación de los recursos candidatos. El trabajo realizado en GridWay se explica a continuación. III. Extensiones sobre GridWay El metaplanificador GridWay [6] permite la compartición de recursos computacionales a gran escala, de manera fiable y eficiente, gestionados por diferentes sistemas de gestión de recursos locales, y a través de una sola organización o dispersas entre varios dominios administrativos. GridWay es un proyecto Globus, adhiriéndose a la filosofía y directrices de Globus para la colaboración en el desarrollo. Los usuarios dispuestos a enviar trabajos a la infraestructura Grid gestionada por GridWay necesitan generar una plantilla de trabajo. Esta plantilla es un fichero de texto (con extension.jt ) que incluye la información necesaria para la ejecución del trabajo, como los nombres de los ficheros de entrada, salida y ejecutables, así como otros parámetros de control relacionados con la planificación, rendimiento, tolerancia a fallos o selección de recursos, entre otros. Más detalles en [14]. El trabajo presentado aquí se centra en como Grid- Way selecciona los recursos para ejecutar los trabajos. Los parámetros relacionados con esta cuestión dentro de la plantilla de trabajo son REQUIREMENTS y RANK. Estos dos parámetros permiten a los usuarios especificar el criterio a usar para seleccionar los recursos más apropiados para ejecutar sus trabajos. Esto se lleva a cabo en dos pasos (ver Algorithm 1). Algorithm 1 Selección de recursos en GridWay 1: Siendo S = conjunto de recursos cononcidos por GridWay 2: S R = {s S / s cumplen las condiciones de REQUIRE- MENTS} 3: retorna s S R / s S R, RANK(s ) > RANK (s) La etiqueta REQUIREMENTS es procesada primero. Dentro de esta etiqueta, el usuario puede especificar los requisitos mínimos que el trabajo necesita para ejecutarse. De esta manera, actúa como un filtro de todos los recursos conocidos por el GridWay. Como resultado de dicho filtro, sólo los recursos que satisfacen las condiciones de REQUIREMENTS son considerados en el siguiente paso. Luego, con la etiqueta RANK, se especifican las características tomadas en cuenta a la hora de ordenar los recursos. Esto significa que todos los recursos que cumplen lo especificado en REQUIREMENTS son ordenados siguiendo el criterio especificado con la etiquetarank (por ejemplo, el conjunto de recurso es ordenado en función de su cantidad de memoria RAM libre). Para ambas etiquetas se pueden especificar varias características, como el tipo de CPU, sistema operativo, velocidad de CPU, cantidad de memoria libre, etc. Muchos de estos valores se consiguen a través del modulo GIS de Globus, mientras que otros (específicamente los dinámicas, como la cantidad de RAM libre) son monitorizados a través de Ganglia. Entre los parámetros soportados por GridWay no hay ninguno relacionado con las condiciones de la red. Por tanto, las modificaciones introducidas tienen como objetivo incluir en GridWay la posibilidad de usar información sobre el estado de las conexiones de red cuando se llevan a cabo las operaciones de planificación. En primer lugar, ha sido necesario integrar el cálculo del estado de las interconexiones hacia cada recurso perteneciente al Grid. En segundo lugar, se ha añadido una etiqueta adicional con dicha información para que pueda ser usada en los procesos de planificación de trabajos. Las partes no sombreadas en la Figura 3 muestran las extensiones introducidas en GridWay. Fig. 3. Extensiones introducidas a GridWay. El estado de las conexiones de red se ha medido como el ancho de banda disponible entre el nodo que lanza los trabajos y cada uno de los nodos de la infraestructura Grid. Con este fin, se ha usado la herramienta iperf [12] que hace una estimación del ancho de banda disponible. Se envían una serie de paquetes, de un cierto tamaño, a través del puerto especificado y durante un cierto tiempo (variable, 10 seg. por defecto). Dos etiquetas adicionales (NET PORT y NET TIME) han sido añadidas en el fichero de configuración de GridWay (GW LOCATION/etc/gwd.conf) para poder especificar el puerto y el tiempo usados por la herramienta iperf, respectivamente. El ancho de banda calculado mediante iperf es integrado en la planificación de GridWay definiendo un nuevo atributo llamado BANDWIDTH. La información generada por iperf es almacenada en este nuevo atributo. La variable BANDWIDTH puede ser usada tanto en las expresiones aceptadas por REQUIREMENTS como por RANK, por esto, los recursos disponibles pueden ser filtrados y ordenados teniendo en cuenta el ancho de banda desde el nodo planificador hacia cada uno de ellos.

4 508 XIX Jornadas de Paralelismo Por lo tanto, si la variable BANDWIDTH es incluida en la etiqueta RANK, la lista de nodos es ordenada de mayor a menor ancho de banda. Así, el planificador tendrá este factor en cuenta. Por esto, es seleccionado el primer nodo de la lista resultante, es decir, el nodo cuya conexión con el nodo planificador (el que ejecuta GridWay) tiene un mejor ancho de banda. Si la variable BANDWIDTH se incluye en la etiqueta REQUIREMENTS, se refiere al límite. En otras palabras, significa que el ancho de banda disponible desde el nodo GridWay hacia el recurso tiene que ser mayor que, menor que, igual que un cierto valor. La lista de nodos obtenida es filtrada por ese patrón, y de esta forma, el planificador sólo enviará trabajos a aquellos nodos que satisfagan esa condición. Es importante destacar que varios parámetros pueden ser combinados dentro de la expresión RANK. Se pueden asignar también diferentes pesos a cada uno de los parámetros, por esto, es posible modificar la importancia relativa de cada uno de ellos. Por ejemplo, de esta manera un usuario puede dar mayor influencia al parámetro BANDWIDTH, en el caso de que el trabajo conlleve un gran uso de la red. Adicionalmente, el administrador puede influir en el uso que hacen los usuarios de los recursos de acuerdo con varios criterios, además de evaluando la expresión RANK, como puede ser asignando prioridades a cada recurso, prohibiendo recursos con fallos persistentes, o desarrollando una estimación de tiempo de ejecución basada en la experiencia de uso de los recursos. La prioridad final de cada recurso puede ser expresada como una suma ponderada de cada criterio individual. En el trabajo presentado aquí, sólo será considerada la expresión RANK. Dichas opciones se configuran en el fichero de configuración del planificador GridWay (GW LOCATION/etc/sched.conf). Finalmente, cabe destacar que el único trabajo conocido por los autores destinado a incluir información de red en GridWay es [19]. En este caso, se modificó el mecanismo de computación interno de RANK para incluir información del ancho de banda y de la latencia. Esta información se obtenía haciendo uso de las herramientas iperf y Network Weather Service (NWS) [20]. El trabajo presentado aquí persigue la misma idea, pero permite además filtrar los recursos tal que se cumplan ciertas restricciones en las prestaciones de la red (i.e., a través del uso del parámetro BANDWIDTH sobre la expresión de REQUIREMENTS ). Además, haciendo use de esta implementación sobre GridWay el usuario puede combinar la información relativa a la red con cualquier otro parámetro soportado por GridWay, tanto en la parte de REQUIREMENTS como en el RANK, permitiéndose un mejor mapeo entre las necesidades de un trabajo y los recursos disponibles. IV. Experimentos y resultados La validación funcional de la planificación teniendo en cuenta la información de la red, descrita anteriormente, se ha realizado sobre un entorno Grid controlado. Los resultados se presentan en esta sección. A. Descripción de la plataforma de pruebas El banco de pruebas está compuesto por cuatro máquinas de la misma subred, AulasunX.uclm.es con X [1, 4], y dos máquinas adicionales, Grid- WayI3A.uclm.es y Globus1.uclm.es, pertenecientes al mismo dominio administrativo, pero localizadas en subredes diferentes. La Tabla I resume las principales características de los recursos computacionales. La máquina GridWayI3A.uclm.es lleva a cabo las tareas de metaplanificación (es decir, es el nodo con GridWay instalado). TABLA I Características de los recursos computacionales Máquina Hardware Globus CPU RAM (versión) GridWayI3A Intel Pentium 4 CPU 3.00GHz 2 GB Aulasun1 AMD Opteron 244, 1.80Gz 1 GB Aulasun2 AMD Opteron 244, 1.80Gz 1 GB Aulasun3 AMD Opteron 244, 1.80Gz 1 GB Aulasun4 AMD Opteron 244, 1.80Gz 1 GB Globus1 Intel Pentium 4 CPU 3.00GHz 1 GB B. Carga de trabajo usada Para validar y evaluar el rendimiento de la implementación del metaplanificador Grid con información de red, se han ejecutado diferentes NAS Grid Benchmarks (NGB) [15]. Estos trabajos tienen diferentes dependencias en el flujo de trabajo. Algunos trabajos son intensivos en computación, mientras que otras demandan gran ancho de banda. Por lo tanto, los NGBs nos permiten explorar un gran espectro de condiciones de ejecución. La Figura 4 muestra los flujos de trabajo de las pruebas ejecutadas en nuestro sistema Grid. Las principales características de estos benchmarks se describen brevemente a continuación. (a) SPs3 (b) VPModif (c) Espec (d) HC (e) HT Fig. 4. Flujos de trabajo usados en los tests. - SPs3: Este test está compuesto de varios trabajos SP.jt (uno de los subtrabajos del test ED de los benchmarks NGB) (ver Figura 4 (a)). - VPModif: Este test es similar al test VP de los benckmarks NGB pero se han eliminado algunas dependencias entre trabajos. La Figura 4 (b)) muestra el diagrama de esta prueba. Los nodos circulares, cuadrados y trapezoidales representan trabajos BT, MG y FT, respectivamente. Todos ellos definidos en los benckmarks NGB. - Espec: Destacar de esta prueba (ver Figura 4 (c))que las transferencias realizadas por estos trabajos son diferentes, haciendo la ejecución más asimétrica de lo que puede parecer en el diagrama. Los nodos circulares, trapezoidales, cuadrados y rombos representan, respectivamente, trabajos de tipo BT iteración0, BT iteración3 y BT

5 Castellón, Septiembre iteración3 pero con un incremento de tamaño en los ficheros de entrada y trabajos de tipo BT iteración2. - HC: En este caso, ver Figura 4 (d), no hay tráfico pesado por la red( sólo ficheros de 32 MB). En este caso los nodos circulares, cuadrados y trapozoidales representan respectivamente, trabajos de tipo BT, SP y LU. - Heavy Traffic (HT): Este trabajo está basado en el envío de varios ficheros de gran tamaño, ejecutando un trabajo del tipo BT de los benchmarks NGB. El número de ficheros de entrada que acepta ha sido incrementado (ver Figura 4 (e)). C. Evaluación del rendimiento Los resultados presentados en esta sección son la media de 5 ejecuciones. Destacar también que algunos parámetros del fichero de configuración del planificador fueron cambiados, debido a que algunas políticas activadas por defecto pueden influir en la selección de recursos de una manera no deseada. Cuando se han llevado a cabo los test mostrados, sólo se considera la evaluación de la expresión RANK. C.1 Influencia de la red y la carga de CPU. En estas pruebas se han limitado los recursos computacionales disponibles a los cuatro nodos del Aulasun. La razón de esta elección es chequear el comportamiento de la planificación con información sobre la red usando nodos computacionales con el mismo rendimiento. El nodo GridWayI3A llevará a cabo las tareas de planificación. El objetivo de esta primera evaluación es mostrar la utilidad de nuestra propuesta variando las condiciones de red. En primer lugar, se va a evaluar la influencia de la carga de fondo en la red. Para hacer ésto, se ha considerado una situación ideal en la cual no hay carga en la red. Luego, se han simulado unas condiciones de trabajo más reales generando tráfico de fondo por la red. Este tráfico de fondo es una transferencia de un fichero de un nodo a otro mediante el uso del comando globus-url-copy, y sólo esta transferencia se lleva a cabo en toda la topología. La Figura 5 muestra los resultados de las diferentes pruebas. La etiqueta GW se refiere al rendimiento usando el algoritmo original proporcionado GridWay. GW-iperf se refiere al algoritmo de planificación de GridWay extendido para calcular la información sobre el ancho de banda, aunque dicha información no ha sido usada para las planificaciones. Por último, la etiqueta net-gw hace referencia al algoritmo de planificación extendido considerando la información del ancho de banda para las planificaciones. (a) Sin tráfico de fondo (b) Con tráfico de fondo Fig. 5. Tiempo ejecución En la Figura 5 (a) se muestra el escenario sin tráfico de fondo, y se puede ver que hay mínimas diferencias en términos de tiempo completo de ejecución entre la ejecución de la misma prueba usando y sin usar la información del ancho de banda en las planificaciones (GW-iperf y net-gw respectivamente). En el caso net-gw, se obtienen pequeñas mejoras a pesar de que los recursos computacionales tiene las mismas características y están situados en la misma subred. Esta mejora se debe a que el metaplanificador considera la carga de red generada por las transferencias de ficheros realizadas durante la ejecución de cada prueba. La Figura 5 (b) muestra los resultados cuando hay tráfico de fondo en la red. GW-iperf presenta un notable incremento en el tiempo total de ejecución. Esto es debido a que el nodo que está enviando o recibiendo puede ser elegido para ejecutar el trabajo. Por lo tanto, su enlace de red puede estar demasiado cargado, y las transmisiones sobre dicho enlace pueden tardar más que si se llevaran a cabo sobre otro enlace hacia otro nodo que no se estuviera usando en ese momento. Por el contrario, si se usa la información sobre el ancho de banda (ejecutando net-gw ), se seleccionará un nodo cuyo enlace de red no se esté usando puesto que su ancho de banda es mayor que el resto. Ahora se van a mostrar otro conjunto de pruebas en las que sólo un trabajo es ejecutado cada vez. La Figura 6 muestra el tiempo de ejecución total para los trabajos pudiéndose distinguir los tiempos de transferencia y ejecución. (a) Ejecuciones secuenciales (b) Ejecuciones simultáneas Fig. 6. Tiempo ejecución de Heavy Traffic La Figura 6 (a) muestra los resultados de las pruebas ejecutadas una después de otra. Se puede ver que la presencia de tráfico en la red tiene poca influencia en el tiempo total de ejecución cuando se ejecuta net-gw. Si hubiera un mayor número de transferencias o los enlaces fueran más lentos, estas diferencias entre las ejecuciones con net-gw y GW-iperf serían más destacadas. Esto es debido a que las transferencias tardarían más y se seleccionaría un nodo con un mayor enlace mejorando los tiempos de transferencia significativamente. Además, todos los recursos del Grid son similares, por esto, el tiempo de ejecución es el mismo para todos los experimentos. La Figura 6 (b) muestra los resultados de las pruebas ejecutándose simultáneamente, es decir, unos trabajos son ejecutados con GW-iperf y otros con net-gw. Las transferencias de ficheros de un trabajo son tráfico de fondo sobre la red para el otro. Se puede observar el aumento de tiempo necesario para llevar a cabo las transferencias. Esto se debe a que los tests son enviados desde el mismo nodo (Grid- WayI3A) hacia la misma subred (Aulasun), lo que implica la ralentización de las transferencias.

6 510 XIX Jornadas de Paralelismo Usando el ancho de banda se obtiene una gran mejora en el tiempo necesario para llevar a cabo las transferencias, incluso a pesar de que el trabajo planificado con net-gw acaba antes y deja libre el enlace de red para el trabajo planificado usando GWiperf. En ese momento, el trabajo GW-iperf puede incrementar la velocidad de transferencia. C.2 Estimación de costes del planificador propuesto. Finalmente se comparan los resultados de las ejecuciones de los test VP usando GW, GW-iperf y net-gw, con tráfico de fondo en la red y sin él. El tráfico usado en este experimento es tráfico de un nodo a otro, como se ha explicado anteriormente. La Figura 7 (a) presenta los resultados sin tráfico de fondo, observándose que el cálculo de la información de ancho de banda crea una insignificante sobrecarga (ver columnas GW y GW-iperf ). Cuando se usa esta información para llevar a cabo las tareas de planificación (columna net-gw ) hay una notable mejora. Cuando hay tráfico de fondo (Figura 7 (b)), esas diferencias son remarcables. Se puede observar que cuando se está ejecutando net-gw no hay una diferencia notable entre tener o no tráfico de fondo. Esto es debido a que un recurso con mejor ancho de banda fue seleccionado para ejecutar los trabajos. (a) Sin tráfico de fondo (b) Con tráfico de fondo Fig. 7. Sobrecarga generada por iperf V. Conclusiones y trabajo futuro Un número elevado de proyectos en ciencia e ingeniería no habrían sido viables sin contar con las capacidades para agregar recursos que ofrece la Computación Grid. Uno de los aspectos que requiere todavía atención es el impacton de las características de la red a la hora de tomar decisiones de planificación de trabajos. Los autores han propuesto previamente un marco teórico para la metaplanificación, donde la entidad de metaplanificación tiene en cuenta las condiciones de la red. En este trabajo, se ha presentado y evaluado una implementación operativa de un metaplanificador de Grid consciente de la red. Se han llevado a cabo experimentos empleando los NAS Grid Benchmarks (NGB) como carga de trabajo. Los resultados presentados muestran claramente que cuando se tienen en cuenta las condiciones de la red a la hora de planificar trabajos, los tiempos en completar las tareas se ven reducidos de forma muy significativa. Más aún, la sobrecarga introducida por las herramientas de monitorización de red se amortiza totalmente. Así, los usuarios del Grid obtienen el resultado de sus trabajos con un tiempo de respuesta menor. Esto es muy útil, especialmente en el caso de aplicaciones interactivas, como las integradas en el marco del proyecto Interactive European Grid [21]. Como trabajo futuro, se planea extender la implementación actual con una serie de características adicionales, como considerar las características de la red conjuntamente con características de CPU para llevar a cabo una planificación más sofisticada y eficiente. Referencias [1] Foster, I., Kesselman, C.: The Grid 2: Blueprint for a New Computing Infrastructure. 2 edn. Morgan Kaufmann (2003) [2] CERN: LHC Computing. Página web en interactions.org/lhc/computing/index.html [3] Al-Ali, R., et al.: Network QoS Provision for Distributed Grid Applications. Intl. Journal of Simulations Systems, Science and Technology, Special Issue on Grid Performance and Dependability 5(5) (December 2004) [4] Roy, A.: End-to-End Quality of Service for High-End Applications. PhD thesis, Dept. of Computer Science, University of Chicago (2001) [5] Marchese, F.T., Brajkovska, N.: Fostering asynchronous collaborative visualization. In: Proc. of the 11th Intl. Conference on Information Visualization, Washington DC, USA (2007) [6] Huedo, E., Montero, R.S., Llorente, I.M.: A modular meta-scheduling architecture for interfacing with pre-ws and ws grid resource management services. Future Generation Computing Systems 23(2) (2007) [7] Condor-G Project. Página web en edu/condor/condorg/ [8] Caminero, A., Carrión, C., Caminero, B.: Designing an entity to provide network QoS in a Grid system. En: Proc. of the 1st Iberian Grid Infrastructure Conference (IberGrid), Santiago de Compostela, Spain (2007) [9] Caminero, A., Rana, O., Caminero, B., Carrión, C.: An Autonomic Network-Aware Scheduling Architecture for Grid Computing. En: Proc. of the 5th Intl. Workshop on Middleware for Grid Computing (MGC), Newport Beach, USA (2007) [10] Massie, M.L., Chun, B.N., Culler, D.E.: The Ganglia distributed monitoring system: design, implementation, and experience. Parallel Computing 30(5-6) (2004) [11] Sohail, S., Pham, K.B., Nguyen, R., Jha, S.: Bandwidth Broker Implementation: Circa-Complete and Integrable. Informe Técnico, School of Computer Science and Engineering, The University of New South Wales (2003) [12] NLANR/DAST: Iperf - The TCP/UDP Bandwidth Measurement Tool. Página web en Projects/Iperf/ [13] The Globus Alliance. Página web en globus.org [14] GridWay Team: GridWay 5.2 Documentation: User Guide. Distributed Systems Architecture Group, Universidad Complutense de Madrid. (2007) [15] Frumkin, M., Van der Wijngaart, R.: Nas grid benchmarks: a tool for grid space exploration. En: Proceedings of 10th IEEE International Symposium on High Performance Distributed Computing. (2001) [16] Bhatti, S., Sørensen, S., Clark, P., Crowcroft, J.: Network QoS for Grid Systems. The Intl. Journal of High Performance Computing Applications 17(3) (2003) [17] Adami, D., et al.: Design and implementation of a grid network-aware resource broker. En: Proc. of the Intl. Conference on Parallel and Distributed Computing and Networks, Innsbruck, Austria (2006) [18] Waldrich, O., Wieder, P., Ziegler, W.: A Metascheduling Service for Co-allocating Arbitrary Types of Resources. En: Proc. of the 6th Intl. Conference on Parallel Processing and Applied Mathematics (PPAM), Poznan, Poland (2005) [19] Fuentes, A., Huedo, E., Moreno, R., Martin-Llorente, I.: A grid scheduling algorithm considering dynamic interconnecting network. En: The 3rd Cracow Grid Work- Shop. (2003) [20] Wolski, R., Spring, N.T., Hayes, J.: The network weather service: A distributed resource performance forecasting service for metacomputing. Future Generation Computer Systems 15(5 6) (1999) [21] Interactive European Grid Project. Página web en www. interactive-grid.eu