1 / 22

Computación Distribuida de Altas Prestaciones Patxi Echarte 23/I/2006

A Distributed Resource Management Architecture that Supports Advance Reservations and Co-Allocation. Computación Distribuida de Altas Prestaciones Patxi Echarte 23/I/2006 http://creativecommons.org/licenses/by/2.5/es/. Índice. Introducción

leanne
Download Presentation

Computación Distribuida de Altas Prestaciones Patxi Echarte 23/I/2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Distributed Resource Management Architecture that Supports Advance Reservations and Co-Allocation Computación Distribuida de Altas Prestaciones Patxi Echarte 23/I/2006 http://creativecommons.org/licenses/by/2.5/es/

  2. Índice • Introducción • Globus Architecture for Reservation and Allocation (GARA) • GARA Application Programming Interface (API) • Implementación GARA • Resultados

  3. Introducción¿Qué es un Grid? • Un GRID es un modelo de computación que permite obtener grandes capacidades de proceso a partir de la unión de diversos recursos repartidos geográficamente y conectados en red, formando un ordenador virtual, orientado a resolver problemas computacionales de grandes dimensiones. • Un Grid intenta resolver el problema de coordinar la compartición de recursos y la resolución de problemas en organizaciones virtuales dinámicas y multi-institucionales.

  4. Introducción¿Qué es un Grid?

  5. Introducción¿Qué es un Grid? • Son necesarios mecanismos que nos permitan descubrir recursos disponibles así como realizar las reservas cuando sean requeridos. • Las reservas pueden ser inmediatas, como asignaciones directas, o avanzadas, para casos con más requisitos de QoS.

  6. IntroducciónGlobus Alliance & Toolkit • Globus Alliance es una comunidad de organizaciones con el objetivo común de construir herramientas que permitan la creación de sistemas Grid. • Team: University of Chicago, EPCC, University of Edimbourgh, National Center for Supercomputing Applications (NCSA), Northern Illinois University, Royal Institute of Technology, Sweden, University of Southern California Information Sciences Institute • Consortium: HP, IBM, Intel, Sun, Nortel, Univa, Cisco Systems

  7. IntroducciónGlobus Alliance & Toolkit • Globus Toolkit es un conjunto de herramientas desarrolladas bajo licencia open source por la Globus Alliance, para permitir la creación de sistemas Grid. • La versión 1.0 salió en 1998 y actualmente está disponible la 4.0 • Open Source bajo licencia Apache Version 2.0 • Es considerado el “estándar de facto” en la computación grid • Algunas aplicaciones que lo utilizan: European Data Grid, Grid Physics Network, Particle Physics Data Grid, the Network for Earthquake Engineering and Simulation (NEES), FusionGrid, the Earth System Grid (ESG), the NSF Middleware Initiative, the National Virtual Observatory… • Empresas desarrollando sobre él: Avaki, DataSynapse, Entropia, Fujitsu, Hewlett-Packard, IBM, NEC, Oracle, Platform, Sun and United Devices

  8. Índice • Introducción • Globus Architecture for Reservation and Allocation (GARA) • GARA Application Programming Interface (API) • Implementación GARA • Resultados

  9. GARAGestión de recursos en Globus • Servicios de información:mecanismos de consulta, descubrimiento automático y LDAP (tipos de recursos, arquitectura, estructura y estado actual). • Varios tipos de agentes de co-asignación • Gestores de recursos locales (Globus Resource Allocation Manager) • No permite reservar recursos de forma anticipada ni disponer de tipos heterogéneos de recursos.

  10. GARAGestión de recursos en GARA • GARA extiende Globus en dos formas: • Objetos de recursos genéricos: network flows, memory blocks, disk blocks, processes… • Reservas • Se divide la asignación en dos fases: • Reserva • Asignación • Se permiten reservas inmediatas y avanzadas • Globus Reservation Allocation Manager

  11. GARAAgentes de Co-reserva/asignación • Agentes de Co-reserva: son uno de los ejes principales de GARA y existe una gran libertad a la hora de construir estos agentes, GARA especifica únicamente su funcionalidad. • Ejemplo: análisis de datos y visualización de resultados • Implica la reserva de superordenadores, almacenes de datos y elementos de red, mediante los GRAM correspondientes. • Se le indica al agente qué datos hay que analizar y a continuación se solicita a otro agente que determine los requisitos computacionales y de red, para el análisis de los datos y su transmisión.

  12. GARAAgentes de Co-reserva/asignación • El agente debe descubrir recursos de computación y de red que satisfagan los requisitos de QoS • Globus: búsqueda exhaustiva y heurísticas. • GARA: heurísticas de búsqueda eficientes basadas en reservas de recursos. • Ejemplo: • Localización para cada conjunto de datos de un superordenador capaz de proporcionar el QoS deseado y con privilegios de acceso a los datos. • Reserva del superordenador y del enlace de red entre él y el usuario. • Reserva del enlace de red entre el superordenador y los datos.

  13. Índice • Introducción • Globus Architecture for Reservation and Allocation (GARA) • GARA Application Programming Interface (API) • Implementación GARA • Resultados

  14. GARA APIApplication Programming Interface

  15. Índice • Introducción • Globus Architecture for Reservation and Allocation (GARA) • GARA Application Programming Interface (API) • Implementación GARA • Resultados

  16. Implementación de GARA • Estructura en capas de GARA • GARA External Interface (GEI): autenticación y procesado de solicitudes, propagación de llamadas a procesos remotos y publicación de información de recursos. • Local Resource Allocation Manager (LRAM): servicios básicos de acceso a objetos y reservas, interactuando con los componentes locales de gestión de recursos y servicios. • Si el gestor de recursos locales soporta “reserva avanzada” LRAM le redirije directamente las solicitudes de recursos. • En otro caso: • Si el LRAM es el único gestor en contacto con el recurso puede utilizarse una tabla de slots • En caso contrario únicamente pueden utilizarse reservas avanzadas probabilísticas

  17. Implementación de GARATimeslot table & manager • Se dispone de una librería para gestionar una tabla de timeslots asociada a un recurso: creación de tablas, creación y cancelación de reservas, consultas de estado de una reserva, y callbacks de monitorización

  18. Implementación de GARALRAM’s implementados • Se han implementado 3 tipos de LRAM • SMP LRAM: ejecución paralela en un multiprocesador con memoria compartida, en el que hay un límite de procesos que pueden ser creados. • DSRT LRAM: gestiona fracciones de tiempo de una CPU, utilizando DSRT (Dynamic Soft Real Time) para gestionar la planificación de tareas. • IntServ LRAM: gestión de flujos de red y reservas de ancho de banda, con RVSP (Reservation Protocol) para asociar reservas y flujos.

  19. Índice • Introducción • Globus Architecture for Reservation and Allocation (GARA) • GARA Application Programming Interface (API) • Implementación GARA • Resultados

  20. Resultados • Interés en contestar a 3 preguntas: • Cuáles son los costes de los mecanismos de reserva y creación de objetos. • Cómo son estos costes en comparación con los mecanismos nativos. • Qué nos dicen estos datos acerca de la utilidad de los mecanismos de reserva.

  21. Resultados • Operaciones locales • Operaciones remotas • El uso de GARA implica unos 11 msec adicionales para la comunicación en red y unos 100 msec para la autenticación. • Los GRAM soportan entre 8 y 10 operaciones de reserva por segundo.

  22. Resultados • En entornos donde la seguridad es importante el coste de crear y luego cancelar un objeto es ligeramente superior al de crear y cancelar una reserva. • De forma general mecanismos de búsqueda que creen y cancelen reservas serán al menos tan eficientes como esquemas basados en asignación inmediata. • Las asignaciones inmediatas requieren una reserva previa pero podría crearse una llamada “crear reserva y objeto” • Conviene reducir operaciones remotas y autenticaciones redundantes cuando se soliciten recursos de un mismo “dominio”

More Related