Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Estructura de SLAcado en los Términos de servicio (ej. 2 (máquinas),x86 64 (arquitectura de la CPU), etc.). Finalmente,el bloque Restricciones de creación contiene las limitacionesde la negociación.En Enero de 2011, una revisión de la especificaciónWS-Agreement fue publicada [21], extendiendo elproceso de negociación. El protocolo de negociacióndefinido en la especificación básica contempla únicamenteun proceso de negociación simple, donde elusuario pide una plantilla de negociación al proveedorde servicios, la rellena con la QoS que esperarecibir y la envía al proveedor de servicios; el cualacepta o rechaza el SLA. Pero con la reciente revisión(ver Figura 4), la renegociación es posible gracias aun bucle entre el usuario y el proveedor de serviciosprevia aceptación de una oferta. Esto permite alcanzarun acuerdo mejor para ambos participantes.La definición de los Términos en cada SLA noestá definido en la especificación WS-Agreement, porello, su definición se deja a cargo del proveedor deservicios. Él es el encargado de especificar los términospara sus propias necesidades (p. ej. hardware,restricciones temporales o restricciones relacionadascon el trabajo). Estos términos pueden ser muy numerososy diferentes entre sí, pero hay varios de ellosque suelen aparecer: relacionados con el hardwarenecesario (como el número de máquinas o la cantidadde RAM entre otros), y más importantes, relacionadoscon restricciones temporales. Estas restriccionessuelen aparecer como start–time y duración (odeadline). Pero es posible definir nuevos términospara mejorar el conocimiento sobre los trabajos yexplotarlos en el proceso de meta-planificación.Para este propósito, cada SLA emitido a esteframework debe seguir la especificación WS-Agreement (ver Figura 3). Por ello, los Términosde servicio especificados en cada SLA sonlos parámetros de ejecución para el proceso demeta-planificación. Estos términos son fundamentalmente:trabajo, (app, in file), start-time (t s) ydeadline (d)). El bloque Nombre sólo especifica unidentificador de fácil reconocimiento para los humanos,mientras que el bloque Contexto contiene dosparámetros fundamentales: template-id, identificadorde la plantilla de negociación para identificación internay proveedor de servicio para la identificacióndel proveedor de servicio. Esta estructura está abiertaa una futura extensión de los parámetros definidos.Finalmente, no se prevee la utilización de las Restriccionesde creación.Este framework implementa la especificación WS-Agreement y es posible interactuar con él a través deun portal web (ver Figura 5). Este portal ofrece loscampos a rellenar de una plantilla de negociación.Pulsando el botón “Submit”, la información de loscampos se transfiere a un SLA y es enviado al gestorde SLAs. El resultado de la petición se muestra alusuario a través del mismo portal, y si la emisión deltrabajo ha sido satisfactoria, devuelve el EPR (End-Point Reference) del acuerdo. La monitorización delos SLAs y la extensión del proceso de negociaciónrepresenta el próximo hito de nuestro trabajo.Hay varias ventajas que se desprenden del uso deSLAs en nuestro sistema, y especialmente de la implantaciónde la especificación WS-Agreement. Principalmente,representa una formalización del procesode emisión de trabajos. Además, son el mecanismopara una representación formal de las restriccionestemporales que el usuario requiere y que nuestro Gridtiene que respetar.Finalmente, los SLAs son mensajes XML (especificadoen WS-Agreement), por ello pueden ser fácilmentemanejados en entornos web. Además, tecnologíascomo Gridsphere [31] pueden ser utilizadaspara el desarrollo de nuevos entornos web. Para, deesta manera, ocultar la complejidad del sistema alusuario, el cual tiene la posibilidad de interactuarcon el Grid a través de un portal web.V. Conclusiones y Trabajo FuturoVarias investigaciones intentan proveer QoS enGrids mediante reservas por adelantado, aunque lareserva de recursos no siempre es posible en estos entornos.Por esto, este artículo propone un frameworkcon capacidad para negociar SLAs y planificar poradelantado para mejorar la QoS de los servicios ofrecidos.Sin embargo, este tipo de planificación requiereestimar si una aplicación puede ser ejecutada antesdel deadline especificado por el usuario. Por ello, esnecesario afrontar varios retos, como la predicción deltiempo necesario para la ejecución de los trabajos enlos recursos.Por este motivo, el sistema se ocupa del comportamientodinámico de los recursos asociados al Grid,su uso, y las características de los trabajos. Además,este sistema tiene en cuenta la precisión en las últimaspredicciones para calcular su confianza en cadarecurso.Además, implementa un gestor de SLAs para permitirla interacción con el usuario y ofrecer la capacidadde negociar SLAs entre usuario y proveedor deservicios. Este módulo se encarga de la comunicaciónentre el sistema, interactuando con el SA–Layer, y losusuarios; y hace posible proveer QoS a los usuarios deforma contractual (a través de los SLAs). Asimismo,cada SLA puede especificar más información relativaal trabajo que puede ser utilizada en el proceso demeta-planificación.Una interesante dirección a seguir en futuras investigacioneses el desarrollo de técnicas para mejorarlas estimaciones de los tiempos de transferencia.JP2011-487