Integración de VOs y middleware para EGEE Álvaro Fernández Casaní Instituto de Física Corpuscular (CSIC/UV) Valencia

Grupos Trabajo Middleware IrisGrid 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). Toledo, 26 Noviembre 2004 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 Autorización: necesaria para acceder a recursos pero también a datos confidenciales Resource providers enforce local authorization Condicion 1 para un usuario es pertenecer a una VO En realidad deberia poderse pertenecer a muchas Vos con muchos roles, y su membecia a una Vo ser independiente unas de otras Toledo, 26 Noviembre 2004 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 Toledo, 26 Noviembre 2004 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 Globus: gridmapfile, autorizacion manejable para pocos usuarios en entorno de pruebas/demos, pero imposible para producion con muchos sites y usuarios. Necesaria automatización para testbed de produccion Grid-mapfile LDAP/S REGISTRAR WEB SERVER Auth Registrar Server Reg Users Toledo, 26 Noviembre 2004 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, Roles y Capacidades Grupos: permiten dividir una VO y especializarla en grupos (Administrador, usuarios, etc). Se pueden representar como un DAG. Todos los miembros de una VO deben pertenecer a un grupo. Se puede pertenecer a mas de un grupo opcionalmente. Roles: un usuario puede tener varios roles que es capaz de elegir en funcion de sus necesidades, no es como los grupos que se especifican todos obligatoriamente. Capacidades: con cadenas que representan las capacidades para un usuario. Toledo, 26 Noviembre 2004 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. Toledo, 26 Noviembre 2004 Grupos Trabajo Middleware IrisGrid

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. Toledo, 26 Noviembre 2004 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 Toledo, 26 Noviembre 2004 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) Toledo, 26 Noviembre 2004 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. Toledo, 26 Noviembre 2004 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 Toledo, 26 Noviembre 2004 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. Toledo, 26 Noviembre 2004 Grupos Trabajo Middleware IrisGrid