Experiencias con Localización y Asignación de Recursos para Realizar Cómputo Distribuido: URBE (Ubiquitous Resource BrokEr)

Transcripción

1 Experiencias con Localización y Asignación de Recursos para Realizar Cómputo Distribuido: URBE (Ubiquitous Resource BrokEr) Pedro García T. Departamento de Computación, Universidad Simón Bolívar. Caracas, Venezuela pgarcia@ldc.usb.ve Yudith Cardinale Departamento de Computación, Universidad Simón Bolívar. Caracas, Venezuela yudith@usb.ve Emilio Hernández Departamento de Computación, Universidad Simón Bolívar. Caracas, Venezuela emilio@usb.ve Resumen Se presenta un esquema de localización de recursos en la red, denominado URBE (Ubiquitous Resource BrokEr), que permite niveles de configuración para que la localización se realice siguiendo políticas de asignación (scheduling). En un contexto de distribución de recursos a través de diferentes dominios administrativos, las políticas de asignación locales pueden variar considerablemente, de acuerdo a las políticas de acceso a recursos y autenticación que se definan en cada dominio. Se ha desarrollado una implementación CORBA de URBE, que permite definiciones locales de acceso a recursos, como un sistema jerárquico de objetos que prestan servicios de registro y localización de servidores. Se muestran resultados preliminares del sobretiempo introducido por URBE en la ejecución de procesos en SUMA, un sistema de cómputo distribuido de programas Java. Palabras Clave Metasistemas, Metascheduling, localizacion y admistracion de recursos, Corba INTRODUCCIÓN En un sistema de asignación de recursos para realizar cómputo distribuido, comúnmente denominado metasistema o grid [1,2,3,4], los conceptos de localización y asignación basada en idoneidad están estrechamente vinculados. En este contexto el problema de asignación de recursos, en forma simplificada, consiste en asignar sistemas de computación a las solicitudes de ejecución de procesos. En un primer nivel, es importante asignar recursos de acuerdo con la adecuación de la arquitectura al proceso que se desea ejecutar, el rendimiento de CPU y de la red, y la cantidad de memoria disponible, entre otros posibles factores de decisión. En segundo lugar, las características dinámicas de un metasistema, en el que los recursos computacionales pueden constantemente asignarse y liberarse y las condiciones externas varían continuamente, el problema de asignación de recursos debe ser de naturaleza dinámica. Para ésto se debe acudir a mecanismos de asignación (scheduling) dinámicos, basados en información sobre los procesos y usualmente indirectos, denominados a veces metaschedulers [5]. En el caso de CORBA [6], los servicios de localización definidos por en el estándar (Naming Service, Object Trader Service, Porperty Service, etc.) son muy primitivos como para incorporar mecanismos de asignación sofisticados, aparte de no responder a la necesidad de descentralización o jerarquización que deben tener las decisiones de asignación en contextos reales. Algunos trabajos de investigación se han orientado al desarrollo de metaschedulers [5,7,8,9,10,11,12]. Las topologías de metaschedulers pueden ser clasificadas en arquitecturas centralizadas y descentralizadas[5]. Los esquemas centralizados [7,8,9] a pesar de presentar aceptable desempeño, adolecen de la falta de escalabilidad, característica esencial en ambientes de metacomputación. Nuestro trabajo se enfoca en una arquitectura jerárquicadistribuida, tema que también ha sido abordado [10,11,12], pero no sólo considera las funcionalidades de despacho de tareas, sino que además incorpora funcionalidades de registro y localización de servicios en el metasistema. Este artículo presenta un esquema de localización de recursos en la red, denominado URBE (Ubiquitous Resource BrokEr), que permite niveles de configuración para que la localización se realice siguiendo políticas de asignación (scheduling). Se ha desarrollado una implementación CORBA de URBE, que permite definiciones locales de acceso a recursos, como un sistema jerárquico de objetos que prestan servicios de registro y localización de servicios. Se muestran resultados preliminares del sobretiempo introducido por URBE en la ejecución de procesos en SUMA, un sistema de cómputo distribuido de programas Java. En el capítulo 2 se describen las características generales del esquema propuesto. En el capítulo 3 se describe la capacidad de metascheduling incorporada a la herramienta desarrollada. El capítulo 4 contiene una aplicación específica de URBE, incorporada a un metasistema denominado SUMA. En este mismo capítulo se discuten algunos resultados relacionados con el sobretiempo

2 introducido por URBE al metasistema. El capítulo 5 contiene las conclusiones y trabajo futuro. CARACTERÍSTICAS BÁSICAS DE URBE URBE es un sistema jerárquico, conformado por una única pieza de software llamada DRBroker (Domain s Resource Broker). Múltiples instancias de este componente tienen la capacidad de comunicarse entre sí y formar una estructura jerárquica, lo cual provee niveles de tolerancia a fallas, escalabilidad, configurabilidad y eficiencia. La jerarquización corresponde con la presencia de dominios administrativos en Internet. URBE ofrece la capacidad de establecer políticas de uso a los servicios prestados entre diferentes dominios. El concepto de dominio manejado no tiene ningún tipo de restricción, está representado por un nombre que es utilizado por un conjunto de usuarios. Múltiples instancias de DRBrokers tienen la capacidad de operar de manera coordinada para conformar una estructura jerárquica. Para todo DRBroker es posible definir si cuenta con una instancia superior, en caso afirmativo se especifica el URL de localización. Con este simple mecanismo se construye una organización piramidal, donde cada nodo representa un dominio. Para cada DRBroker, un dominio inferior puede estar conformado por sistemas, usuarios independientes u otro DRBroker. Para cada dominio se definen datos como la información administrativa y de contacto, los tipos de servicios compartidos y la restricción de los servicios a horarios específicos. En la Figura 1 se observa un esquema de una estructura de DRBrokers correspondientes a diferentes dominios y util izados por la aplicación SUMA, un metasistema basado en CORBA: Figura 1. Estructura jerárquica de DRBrokers Las estructuras jerárquicas han demostrado ofrecer un alto grado de escalabilidad. Este modelo de organización es capaz de manejar una gran cantidad de recursos. No se definen restricciones en el número de niveles de la pirámide de DRBrokers, ni en el número de nodos por nivel. Cada DRBroker publica su referencia CORBA en formato IOR (Interoperable Object Reference ), en un archivo disponible a través de una dirección en el web. Los clientes obtienen la referencia estableciendo una conexión HTTP para solicitar el contenido del archivo en el URL acordado. IOR es un formato estándar para referenciar objetos CORBA, contiene toda la información necesaria para que el ORB pueda iniciar la comunicación con el objeto. Tolerancia a Fallas La estructura jerárquica en sí misma ofrece un nivel de tolerancia a fallas, determinado por el hecho de que si un DRBroker falla, se pierde el acceso a recursos del dominio que controla, pero el resto del sistema sigue en funcionamiento y sus recursos disponibles. Sin embargo, URBE ha sido reforzado con mecanismos que proveen tolerancia a fallas en tres aspectos adicionales: 1. Los objetos registrados por los diferentes dominios son persistentes en el tiempo. 2. La disponibilidad del DRBroker se realiza a través de uno o varios servidores secundarios por dominio. 3. Verifica que los servidores localizados en las consultas de los usuarios se encuentren disponibles. La disponibilidad del DRBroker es fundamental para garantizar la estabilidad del sistema. La replicación es necesaria para evitar que el DRBroker de cada dominio sea un SPOF (Single Point of Failure). La s respuestas a las posibles consultas que puede atender un DRBroker ya están precalculadas a través de un conjunto de vistas, por lo que se estima que la carga del componente no amerita un tipo de replicación activa. El tipo de replicación implementada para los DRBrokers se conoce como replicación pasiva. Escalabilidad Las estructuras jerárquicas con servidores por dominios han demostrado su escalabilidad con la utilización de DNS (Domain Name System) como parte fundamental de Internet. URBE ofrece una estructura jerárquica con servidores por dominios. Cada servidor o DRBroker puede manejar una gran cantidad de objetos registrados, por la poca información que se almacena; sólo la referencia CORBA de los servidores y los tipos de servicios. También puede atender un número considerable de consultas simultáneas, gracias a su capacidad de concurrencia a través de un pool de threads y a la eficiencia de las operaciones de consulta. Vistas de Usuario Según el nivel de conocimiento del usuario de URBE o los requerimientos del sistema que desee utilizar sus servicios, pueden aprovecharse en un mayor o menor grado sus capacidades. El nivel de integración deseado o permitido

3 con el sistema, es también un factor importante para determinar el tipo de uso. La implementación predeterminada del DRBroker presta servicios de registro y localización de servidores por nombres, similar al servidor de nombres de CORBA, con algunas capacidades adicionales. Con la misma simplicidad del servicio de nombres que provee el estándar de CORBA, un método para registro y uno para búsqueda, se accede a los servicios de URBE. Existen características adicionales que representan importantes ventajas comparativas: Tolerancia a fallas; persistencia de la información registrada y alta disponibilidad del DRBroker. Múltiples servidores por nombre o servicio. En la Figura 2 se presenta un diagrama con el modelo de ejecución de un cliente y una aplicación que utilizan URBE como servicio de nombres. Las políticas de uso de URBE también pueden ser aprovechadas por sistemas que buscan publicar servicios en la red. La definición de una serie de limitaciones en el DRBroker facilita el control de la utilización de los servicios, permitiendo restringir el acceso según horario y/o procedencia. Control de recursos y scheduler El DRBroker mantiene una base de datos de servidores registrados que son monitoreados constantemente. Adicionalmente utiliza una política de planificación configurable, para prestar los servicios de localización de servidores. Un sistema podría aprovechar estas capacidades y utilizarlo como scheduler, donde los recursos se registran directamente al DRBroker y los clientes le solicitan un recurso con las características deseadas. La capacidad de clasificar servidores por tipos, aumenta la adaptabilidad a distintos requerimientos y la escalabilidad en caso de grandes cantidades de recursos. En la Figura 3 se ilustra este esquema. La utilización como servicio de nombres y como control de recursos, pueden ser combinados opcionalmente con la gestión de servicios entre dominios. Figura 2. URBE según vista de Servicio de Nombres CAPACIDAD DE METASCHEDULING URBE brinda la posibilidad de desarrollar e incorporar políticas de scheduling, que se adapten a cualquier sistema o tarea. Esta funcionalidad, sumada a una base de datos de servicios disponibles a través de diferentes dominios, permite que un DRBroker pueda ser utilizado como un meta-scheduler. Un DRBroker puede comportarse como un metascheduler centralizado o jerárquico, según el algoritmo de planificación incorporado [5]. Gestión de servicios entre dominios Sistemas o metasistemas que se ejecutan en diferentes dominios y que desean establecer colaboración entre sus diferentes instancias, pueden beneficiarse de la aplicación de las políticas de uso de URBE. Los tipos de servidores pueden ser compartidos individualmente a cada uno de los dominios, esto permite un alto grado de flexibilidad al establecer los niveles de integración. En estos casos, URBE representa el punto común donde cada instancia puede localizar las otras. La tolerancia a fallas del sistema garantiza la estabilidad necesaria para ser adoptado como un elemento de vital importancia. En la Figura 1 se observan los diferentes módulos de SUMA adoptando este esquema de utilización. Figura 3. URBE según vista de control de recursos y scheduler Las políticas de planificación incorporadas a URBE, pueden explotar la jerarquía de DRBrokers impleme ntando búsquedas recursivas o iterativas a través de los dominios. De manera similar al DNS (Domain Name System), URBE puede buscar un recurso a través de los diferentes dominios, interrogando iterativamente a diferentes DRBrokers, o puede retornar a su cliente la referencia de un DRBroker superior en caso de no conseguir un recurso en su espacio de dominios que cumpla con los requerimientos. Configurabilidad URBE se ofrece como una herramienta para ser utilizada por cualquier sistema distribuido. Esta propuesta requiere un alto nivel de configurabilidad, que le permita adaptarse a diferentes requerimientos y plataformas. La única restricción

4 de URBE es que presta servicios a sistemas con comunicación basada en CORBA. Aún así el grupo de posibles usuarios es bastante amplio y variado. Algunos elementos configurables en el DRBroker son la implementación de CORBA, el algoritmo de scheduling utilizado y las políticas de uso. Con el objetivo de facilitar la incorporación de URBE a diversos sistemas por parte de los desarrolladores, se provee un API (Application Programming Interface) de Java. Estas clases implementan funcionalidades para ubicar un servidor DRBroker o invocar sus servicios de forma directa. Interfaz del DRBroker URBE presta servicios para el registro de servicios y la posterior localización de los servicios registrados. Estos servicios pueden presentar un comportamiento variable según las necesidades del usuario, que va de un servicio de nombres simple a una base de datos de recursos con scheduler o metascheduler incorporado. Permite a cada dominio definir tipos de servidores y asociar un número variable de servidores a cada tipo. Los servidores están representados por objetos CORBA y los tipos de servidores por un nombre o texto. El DRBroker ofrece tres tipos de servicios; registro, notificación de eliminación y localización de servidores. Cada tipo presenta diferentes alternativas o métodos. A continuación se des criben en detalle los servicios del DRBroker. Registro y actualización de servicios Sistemas o usuarios provenientes de un dominio conocido por el DRBroker, pueden registrar o actualizar servidores de cualquier tipo de servicios. Existen tres métodos disponibles para efectuar este proceso: void registerdomain (in string domainname, in Services Permite a un dominio registrar un grupo de servidores de diferentes tipos. void updatedomain (in string domainname, in Services Actualiza toda la información de tipos y servidores disponibles. void addservice (in string domainname, in Services Agrega un tipo o grupo de tipos con sus respectivos servidores. Notificación de eliminación de servicios disponibles Un servidor o grupo de servidores previamente publicados puede ser retirado de la base de datos de objetos compartidos cuando sea deseado. Este proceso puede ser realizado a través de dos métodos diferentes: void unregisterdomain (in string domainname) Elimina todos los servidores compartidos por un dominio. void removeservice (in string domainname, in Services Elimina los servidores de un tipo o grupo de tipos dado, compartidos por un dominio. Localización de servicios por nombre y dominio Los servicios más utilizados por los usuarios son los de localización de servidores, que le permiten obtener todos los servidores disponibles para un tipo específico. Estos servicios permiten ajustar la búsqueda a un dominio part icular o a un rango de dominios en la jerarquía de los DRBrokers. Cuatro métodos ofrecen este servicio con algunas variantes: Servers getservers (in string invokingdomain, in string servicename) Retorna todos los servidores del tipo solicitado, que están disponibles según el dominio de procedencia del usuario que invoca el servicio. Servers getserversbydomain (in string invokingdomain, in string servicename, in string domainname) Retorna los servidores del tipo solicitado, que están registrados por un dominio en específico. Servers getserversbylevel (in string invokingdomain, in string servicename, in long level) Retorna los servidores del tipo solicitado, que están disponibles según el dominio de procedencia del usuario, en un rango definido en la jerarquía de DRBrokers de URBE. Ej.: si el número dado es 1, sólo se retornan los servidores disponibles en el DRBroker que recibe la petición. Si es 2, se incluyen también los servidores disponibles en el DRBroker superior al que recibe la petición. Servers getmyservers (in string invokingdomain, in string servicename) Retorna todos los servidores del tipo solicitado, que han sido registrados por el propio dominio de procedencia del usuario que invoca el servicio. Este método facilita la utilización del DRBroker como servicio de nombres. CASO DE ESTUDIO: APLICACIÓN DE URBE A SUMA SUMA (Scientific Ubiquitous Metacomputing Architecture) [9] es un proyecto de metacomputación para ejecución de código Java con soporte para cómputo científico, con facilidades de profiling[10]. Extiende el modelo de la máquina virtual de Java para obtener un sistema de componentes. De una manera muy general SUMA presenta tres niveles de componentes; los clientes, el núcleo del sistema (Core ) y los agentes de ejecución (Exec ution Agents). Los clientes son aplicaciones de diversos tipos y funcionalidades que se comunican con el Core, entregando la información necesaria para solicitar la ejecución de una aplicación Java. El Core se encarga de recibir las peticiones y encontrar un servidor de aplic aciones adecuado para la ejecución de cada petición, monitoreando su estado y garantizando la ejecución. Los

5 Agentes de Ejecución (Execution Agents) residen en los recursos de alto rendimiento y gran capacidad de ejecución y finalmente ejecutarán las aplicaciones. Limitaciones Actualmente el Core de SUMA es único y centralizado. Si dos grupos de trabajo separados geográficamente aportan a SUMA clientes y agentes de ejecución, el sobretiempo producto de la comunicación entre ambos grupos será muy alto. Los grupos participantes deberán trabajar bajo la misma configuración de los componentes del Core, sin posibilidad de experimentar de manera local. Se desea que las diferentes instancias de SUMA puedan operar de manera autónoma, pero tengan la capacidad de compartir recursos bajo criterios definidos por los administradores de cada red. Solución propuesta utilizando URBE La incorporación de URBE a SUMA demuestra la capacidad del sistema para resolver problemas de integración de módulos en sistemas distribuidos reales. Para resolver el problema existente en la versión centralizada de SUMA, se estableció un modelo de comunicación para los componentes de las diferentes instancias, utilizando una estru ctura jerárquica de URBE. Esta estrategia que se describe a continuación, les permite compartir recursos y establecer políticas de uso. Al disponer SUMA de un Scheduler, que ha sido concebido como un componente capaz de realizar de manera autónoma las tareas de planificación de las peticiones recib idas, se adoptó un esquema donde URBE es utilizado como servicio de nombres para localizar otras instancias de Scheduler. Con esta implementación, los Schedulers de las diferentes instancias de SUMA pasan a conformar un Scheduler distribuido. El modelo planteado resuelve el problema de comunicación entre las diferentes instancias de SUMA, agregando beneficios en autonomía de los sitios y escalabilidad en el número de recursos manejados. Sin embargo, el escenario ideal, a implementar a futuro es sustituir completamente al Scheduler de SUMA por URBE. La posibilidad de realizar ambas implementaciones demuestra la flexibilidad de URBE como herramienta de localización y asignación de recursos. La Figura 4 ilustra la integración de URBE a SUMA adoptada en este estudio. Mediciones Uno de los principales objetivos de un metasistema para ejecución remota, es mejorar el desempeño de las aplic aciones aprovechando la mayor capacidad de cómputo presente en los recursos que se ponen a disposición de los usuarios. Para cumplir este objetivo, es importante minimizar el sobretiempo introducido desde que se recibe la petición hasta que se inicia la ejecución en un recurso remoto. El objetivo de esta medición es obtener información sobre el costo, en tiempo de ejecución y comunicación, de localizar un recurso remoto a través de URBE en otra instancia de SUMA. Figura 4: Integración de URBE a SUMA Plataforma para Mediciones Los experimentos y mediciones se llevaron a cabo en las salas de computadoras LDC (Laboratorio De Computación) y CAR (Cómputo de Alto Rendimiento), ubicadas en el edificio MYS (Matemática y Sistemas) de la Universidad Simón Bolívar. Ambas salas están ubicadas en pisos diferentes y se conectan a través de un backbone de 100 Mb que es compartido por todas las dependencias y oficinas del edificio. La sala LDC está compuesta por 32 máquinas con sistema operativo Red Hat Linux 7.1, conectadas a través de una red Ethernet 10/100 MB. Las 32 máquinas tienen procesadores Pentium III (Coppermine) de 800 Mhz y 256 MB de memoria. La sala CAR cuenta con 7 máquinas con sistema operativo Red Hat Linux 6.2, conectadas a través de una red Ethernet 10 MB. Cinco máquinas tienen procesadores Intel PIII (Katmai) de 600 Mhz, las otras 2 tienen procesadores Pentium III (Coppermine) de 800 Mhz, todas con 256 MB de memoria. Se utilizó la versión de JSDK de Sun como máquina virtual de Java y la versión de Orbacus como implementación de CORBA. Experimento Se ejecutaron dos instancias independientes del Core de SUMA, una en la sala CAR y otra en la sala LDC. La instancia LDC contaba con un Execution Agent secuencial con servicio de profiling. En el dominio CAR no funcionaba ningún Execution Agent, en una de sus máquinas se ejecutó la aplicación cliente. El DRBroker encargado de comunicar los dos dominios funcionó en una máquina de la sala LDC. En la Figura 5 se observa la distribución de los componentes dispuesta para la medición. Las máquinas utilizadas se reservaron de forma exclusiva para el experimento. Todos los componentes de SUMA, el

6 servidor de nombres de CORBA de cada dominio y el DRBroker se ejecutaron en máquinas distintas. Figura 5: Distribución de componentes para medición de tiempos de ejec ución de recursos remotos De forma similar a la medición de ejecución en recursos locales, se utilizó el servicio Execute para ejecución en línea de aplicaciones secuenciales, activando la opción de profiling. La aplicación ejecutada es una clase que no realiza ninguna instrucción. Resultados Con el esquema de comunicación entre instancias de SUMA planteada en este caso de estudio, sólo se necesitan dos pasos adicionales en el modelo de ejecución para localizar un recurso disponible en un dominio remoto. Estos pasos se presentan como 1 y 2 en la Figura 5. En 1 el Scheduler solicita al DRBroker las instancias de otros Schedulers de SUMA. Luego en 2, solicita directamente un Execution Agent disponible al Scheduler provisto por el DRBroker. En la Figura 5 se presenta de forma global, el tiempo que toman las llamadas 1 y 2 y el tiempo de ejecución del DRBroker y el Scheduler remoto. 18 milisegundos para todas estas operaciones representan un incremento de 0,25% respecto al tiempo necesario para iniciar la ejecución en un recurso local. El resultado obtenido en esta medición puede no ser constante en un ambiente de ejecución real, donde factores como clientes concurrentes, distancia entre instancias y variaciones en los algoritmos de planificación pueden influir en el desempeño. A pesar de las posibles variaciones, el bajo tiempo de ejecución obtenido demuestra claramente que el modelo planteado puede ser utilizado de forma eficiente para compartir recursos entre diferentes instancias de SUMA. CONCLUSIONES Se presentó un esquema de localización de recursos en la red, denominado URBE (Ubiquitous Resource BrokEr), que permite niveles de configuración para que la localización se realice siguiendo políticas de asignación (scheduling). Se ha desarrollado una implementación CORBA de URBE, que permite definiciones locales de acceso a recursos, como un sistema jerárquico de objetos que prestan servicios de registro y localización de servicios. Los resultados preliminares muestran que aparte de ser un sistema relativamente fácil de configurar, el sobretiempo introducido por URBE en la ejecución de procesos en SUMA, un sistema de cómputo distribuido de programas Java, es reducido. Se visualiza como altamente probable que la ganancia por haber obtenido una adecuada asignación de recursos a los procesos del metasistema compensarán con creces el ligero sobretiempo introducido en el sistema, en particular porque se trata de un sobretiempo inicial, no vinculado al rendimiento posterior de la ejecución de una aplicación. No obstante, en el desarrollo de la primera versión de URBE no se consideró la seguridad como uno de los objetivos principales. Adicionalmente la experiencia adquirida motiva a la incorporación de nuevos elementos, que contribuirán a mejorar los servicios que el sistema ofrece actualmente. REFERENCES [1] I. Foster and C. Kesselman. The Grid: Blueprint for a new Computing Infrastructure. Morgan Kaufmann, [2] M.Livny M. Litzkow and M. Mutka. Condor a hunter of idle workstation. In In Proc 8th Intl. Conf. on Distributed Computing Systems, pages [3] J. Dongarra and the Netsolve team. The Netsolve Project [4] I. Foster and C. Kesselman. Globus: A metacomputing infrastructure toolkit. The International Journal of Supercomputer Applications and High Performance Computing, 11(2): Summer [5] OMG. The Common Object Request Broker: Architecture and Specification 2.0. July [6] V. Hamscher, U. Schwiegelshohn, A. Streit, R. Yahyapour. Evaluation of Job-Scheduling Strategies for Grid Computing. Lecture Notes in Computer Science, vol 1971, pp , año [7] Vadhiyar, S. y Dongarra, J. A Metascheduler for the Grid. Proceedings of th 11th IEEE Symposium on High-Performance Distributed Computing, pp , año 2002

7 [8] Gehring, J. Y Preiss, T. Scheduling a Metacomputer with Un-cooperative Subschedulers. Lecture Notes in Computer Science, vol 1659, pp , año [9] Jackson, D. Silver Metascheduler Project. visitado el 17/6/2003. [10] Ranganathan, K. y Foster, I. Decoupling comp utation and Data Scheduling in Distributed Data-intensive applications. Proceedings of 11th IEEE International Symposium for High Performance Distributed Computing (HPDC-11), pp , Edimburgo, año [11] V. Subramani, R. Kettimuthu, S. Srinivasan, P. Sadayappan. Distributed Job Scheduling on Computational Grids Using Multiple Simultaneous Requests. 11 th IEEE International Symposium on High Performance Distributed Computing HPDC Edinburgh, Scotland, 2002 [12] Bucur, A. y Epema, D. The Maximal Utilization of Processor Co-Allocation in Multicluster Systems. Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS'03), Nice, France, año [13] E. Hernández, Y. Cardinale, C. Figueira and A. Teruel. SUMA: A scientific metacomputer. In Proceedings of the International Conference ParCo99. Imperial College Press, January [14] Figueira, C.; Hernández, E.. "Profiling Facility on a Metasystem". Lecture Notes in Computer Science, 2001, Vol 2110, pp