130 likes | 224 Views
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
E N D
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 • 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
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
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
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
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
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
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
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
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
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
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
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