Globus Architecture for Reservation and Allocation (GARA)

GARA API

El API de GARA se basa en 6 operaciones principales, CreateReservation, CreateObject, CancelReservation, CancelObject, ModifyReservation y RegisterCallback. Con ellas podemos crear reservas, modificarlas y cancelarlas, crear objetos y cancelarlos, y registrar callbacks, con el fin de que una reserva u objeto pueda informar de sus acciones a nuestras aplicaciones.

En la siguiente imagen puede verse un ejemplo de agente de co-reserva que localiza un ordenador «b» que esté conectado vía red «net» con un ordenador base «a», realizando una búsqueda exhaustiva de recursos.

Implementación de GARA

GARA está construido en varias capas. La capa más externa se denomina GARA External Interface (GEI) y se encarga de cuestiones como la autenticación y el registro y propagación de llamadas de callbacks entre otras. Por debajo de GEI hay otra capa correspondiente al gestor de asignaciones de recursos locales (LRAM), que provee los servicios de reserva y asignación, interactuando con los recursos de cada sistema específico así como con los servicios de reserva y asignación existentes si los hubiera.

La estructura de cada LRAM por lo tanto depende de la naturaleza del gestor de recursos local encargado de un determinado recurso. Pueden darse 3 casos distintos:

1. Si el gestor local ofrece mecanismos de reserva el LRAM puede pasarle directamente la solicitud de reservas avanzadas.
2. En otro caso hay dos alternativas:
   1. Si el LRAM es el único gestor en contacto con el recurso puede utilizarse un timeslot para implementar reservas avanzadas sobre el recurso.
   2. En caso contrario únicamente podrán realizarse reservas avanzadas de forma probabilística, utilizando un timeslot y estimando los recursos que habrá disponibles en cada momento.

GARA dispone de una librería que permite gestionar una tabla de timeslots, permitiendo la creación de tablas, creación y cancelación de reservas, consultas de estado y definición de callbacks. Se han implementado 3 LRAM diferentes que utilizan este gestor de timeslots, siendo únicamente diferente el tipo de recurso que gestionan.

• SMP LRAM: ejecución paralela en un multiprocesador con memoria compartida en el que hay un límite de procesos existentes simultáneos. Las llamadas a CreateReservation crean entradas en la tabla de timeslots y las llamadas a CreateObject implican la creación de procesos, mediante llamadas a fork en Unix. Este LRAM será de tipo 2(a) o 2(b) dependiendo de si todas las creaciones de procesos pasan por él o no.
• DSRT LRAM: gestiona fracciones de tiempo de utilización de una CPU, utilizando DSRT (Dynamic Soft Real Time) como planificador de tareas. Se utiliza el gestor de timeslots para la creación de reservas. La creación de objetos implica la creación de un proceso y su planificación vía DSRT. Este LRAM puede ser de tipo 2(a) o 2(b).
• IntServ LRAM: este LRAM gestiona enlaces de red y la asignación de anchos de banda sobre ellos. Se utiliza también un gestor de timeslots para controlar los recursos disponibles, contabilizando el ancho de banda disponible. La creación de objetos se hace mediante la creación de sockets y la realización de llamadas RSVP (Reservation Protocol). Al igual que en los casos anteriores puede ser de tipo 2(a) o 2(b).

Resultados

Se han construido 3 implementaciones de gestores de recursos y se ha demostrado su viabilidad para la creación de reservas y asignaciones de recursos de diferentes tipos. Se plantean 3 preguntas como consecuencia:

• Cuáles son los costes de los mecanismos de reserva y asignación
• Cómo son estos costes en comparación con los nativos de Globus
• Que nos dicen estos datos acerca de la utilidad de los mecanismos de reserva

Inicialmente se han realizado múltiples experimientos de forma local con el objetivo de medir los tiempos empleados en la creación de reservas, objetos y cancelación de objetos bajo cada tipo de LRAM. En la siguiente tabla pueden verse los resultados obtenidos en media, indicados en milisegundos.

Cómo puede apreciarse el coste de las reservas es significativamente menor que el de la creación de objetos. En operaciones realizadas de forma remota usando GARA hay que añadir unos 11 msec adicionales para la comunicación en red y otros 100 msec para la autenticación, lo cual hace que el tiempo dedicado a la autenticación sea el de principal peso. Esta situación lleva a pensar en optimizaciones que permitan reducir el número de autenticaciones necesarias, por ejemplo creando una nueva operación createReservationAndObject para la creación inmediata de asignaciones, evitando tener que hacer primero la reserva y luego la asignación, o evitando realizar autenticaciones redundantes cuando se solicitan múltiples operaciones dentro de un mismo dominio.

De forma general por lo tanto, los mecanismos de búsqueda de recursos basados en la creación y cancelación de reservas, serán normalmente más eficientes que los basados en el trabajo directo con asignaciones. Teniendo en cuenta las posibles optimizaciones indicadas está diferencia podría incrementarse significativamente.

Referencias

• Artículo original
• Power Point de la presentación