1 / 13

Integración de VOs y middleware para EGEE

Integración de VOs y middleware para EGEE. Álvaro Fernández Casaní Instituto de Física Corpuscular (CSIC/UV) Valencia. Proyecto EGEE. Orientado hacia un grid de producción a nivel europeo

Download Presentation

Integración de VOs y middleware para EGEE

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. Integración de VOs y middleware para EGEE Álvaro Fernández Casaní Instituto de Física Corpuscular (CSIC/UV) Valencia

  2. Proyecto EGEE • Orientado hacia un grid de producción a nivel europeo • Soporte actual a aplicaciones de física, pero nuevas áreas como biomedicina y otras están siendo incluidas. • En la región Sudoeste (España y Portugal) distribución de servicios de un ROC, entre ellos: • Aportar recursos (Resource Centres) • Servicios centrales (RB, II, BDII, RLS, VO) • Soporte a usuarios, monitorización y accounting de recursos, inclusión de nuevos RC’s. • Adición de Organizaciones Virtuales • No hay financiación explicita para desarrollo de middleware, sólo reingeniería del mismo. • Adaptación de mw desarrollado en otros proyectos (datagrid, lcg, alien). Grupos Trabajo Middleware IrisGrid

  3. 1 - Organizaciones Virtuales en EGEE • Organización virtual agrupa diferentes usuarios con intereses comunes en cuanto a computación. • Parte imprescindible para la autorización de usuarios en los recursos que desean usar. • Un RC da autorización a un número de VOs • En la práctica puede requerir SLAs. • Actualmente se sigue un modelo pull de autorización. Los recursos preguntan a un servidor central por los usuarios. • Soporte en nuestra federación (España y Portugal): • Creación de nuevas Vos para grupos que surgan en el contexto de EGEE Grupos Trabajo Middleware IrisGrid

  4. Creación y Gestión de VOS • Creación de una VO: • Requerimientos de EGEE • VO manager • Creacion de la VO • Registrar interface • Usuarios registrados • Proceso de registro • 1-Usuario se Registra en web interface • 2- VO manager recibe notificacion • 3- éste añade al usuario y se lo comunica Reg Users Auth Registrar Server REGISTRAR WEB SERVER EGEE VO Server VO1 EMAIL firmado HTTPS EMAIL firmado USUARIO VO MANAGER Grupos Trabajo Middleware IrisGrid

  5. Arquitectura de autorización basada en LDAP VO1 VO Server CE LCMAPS UI (edg-gatekeeper) VO2 GSI LCAS Proxy X509 MK-gridmapfile VO Server N LDAP/S VO3 Grid-mapfile LDAP/S REGISTRAR WEB SERVER Auth Registrar Server Reg Users Grupos Trabajo Middleware IrisGrid

  6. Futuros Servicios de Vos en EGEE • La aproximación actual tiene varios problemas: • Un usuario sólo puede pertenecer a una VO • No se puede definir qué puede hacer cada usuario autorizado en los recursos. • La BD local (gridmapfile) no escala para un entorno de prod. Con muchos usuarios. • Actualizaciones via comandos ldap o scripts con interfaces poco amigables. • VOMS soluciona estos problemas • Extensiones a los proxys X.509 para identificar a que VO pertenece el usuario. • Modelo de autorización por “agente”. • Permite definir grupos y roles. • Implica cambios en: • El proxy contiene informacion agregada (compatible) de las VOs a las que pertenece • Grid-mapfile desaparece para dar cabida a grupos/roles • Sistema de Informacion debe soportar los nuevos esquemas • No hay servidores LDAP, sino VOMS que son contactados por el usuario para comprobar la autorización y la VO/grupo/rol al que se pertenece en un momento dado. • Cambios en LCAS local. Grupos Trabajo Middleware IrisGrid

  7. Conclusiones sobre VOs • EGEE da soporte a nuevos RCs y sus nuevas Vos. • Servicios basados en globus con extensiones, actualmente LDAP y próximamente con VOMS • Arquitectura de autorización deben seguir los esquemas planteados para estar en concordancia con EGEE. Grupos Trabajo Middleware IrisGrid

  8. 2 – Midleware para EGEE • Actualmente se está utilizando middleware desarrollado en proyectos anteriores, entre ellos edg, lcg, alien. • Orientado principalmente hacia aplicaciones HEP, secuenciales (batch) con mucho requerimiento de CPU. • En EGEE más áreas de aplicación con requerimientos diferentes: aplicaciones paralelas mpi, interactivas, etcetera. • En Eu-Crossgrid hemos desarrollado soporte para estas aplicaciones utilizando mw compatible de edg-datagrid (RB), con lo que es posible utilizarlo actualmente con pocas modificacione en el testbed de producción. Grupos Trabajo Middleware IrisGrid

  9. Ejemplo: Arquitectura de gestion de recursos Resource Broker / SA Llamadas al API del MDS Para localizar recursos MDS: Grid Index Info Server UI PORTAL/RAS Llamadas al API del MDS Para localizar recursos SCHEDULING MDS: Grid Resource Info Server Llamadas al API Gram para pedir reserva del recurso Y creacion de procesos Preguntar el estado Actual del recurso Creacion de callbacks Para notificar cambios De estado GSI Local Resource Manager Creación de procesos Petición Job Manager Crear Control y Monitorización Gatekeeper (CE) Process Parse WN WN Process Storage Element (SE) RSL Library Process WN WN Grupos Trabajo Middleware IrisGrid

  10. Principales componentes del RB/SA Resource Broker / SA • Ejecución típica de pasos de scheduling para 1 trabajo por el Scheduling Agent: 1 - Recepción del trabajo Resource Searcher: • 2 - Búsqueda de recursos • 3 – Planificación y Prioridades • 4 – Reserva Temporal Aplication Launcher: • 5 - Envío del trabajo • 6 - Monitorización • 7 - Finalización RS MDS/RGMA AL Resource Management Condor-G Gatekeeper (CE) Grupos Trabajo Middleware IrisGrid

  11. Soporte para aplicaciones mpi • Soporte para aplicaciones mpi (intracluster) y mpich-g2 (intercluster) • Desarrollo de sistema de selección de múltiples recursos (set-matching), para asignar un trabajo a un grupo de recursos (mpich-g2). • Lanzador de aplicaciones: • Aplicaciones mpich-p4 son lanzadas directamente a través de condor-g. • Lanzador específico de mpich-g2, divide en subtrabajos que pueden ser lanzados individualmente • Basado en Resource Broker de edg, utiliza Condor-G para lanzamiento de trabajos. Grupos Trabajo Middleware IrisGrid

  12. Aplicaciones interactivas y DAGS, con prioridades • Basado en condor Bypass, establece un canal de comunicación entre el UI y el WN • Wrapper sobre las aplicaciones que realizan los pasos necesarios • Soporte para aplicaciones interactivas secuenciales, y paralelas mpich-p4 y mpich-g2. • Soporte para aplicaciones descomponibles y modelables por DAGS. • Prioridades soportadas con condor Glide-in Grupos Trabajo Middleware IrisGrid

  13. Conclusiones sobre el Middleware • Resource Broker con nuevo soporte a aplicaciones batch e paralelas, interactivas, y DAGs • Utilizado en producción en Eu-Crossgrid. • Debido a la compatibilidad con las soluciones de LCG y EGEE podemos pensar incluir nuestros desarrollos en producción a nivel europeo. • En EGEE Se están portando las soluciones existentes a basadas en Web Services. Grupos Trabajo Middleware IrisGrid

More Related