Proceso Certificación y Manejo de Datos en EGEE Gonzalo Merino PIC/IFAE XVIII Grupos de Trabajo de RedIRIS Sesión: EGEE-IrisGRID Toledo 25-Oct

IrisGRID-EGEE Toledo, 25/10/ Sumario Proceso de certificación de Centros de Recursos (RCs) del middleware Banco de Pruebas de Certificación Servicio de Pre-producción Manejo de datos Servicios de manejo de datos en EGEE-0 Robust Transfer Challenge

IrisGRID-EGEE Toledo, 25/10/ Proceso de Certificación Según el documento SWE Execution Plan ( ) estos son los centros del SWE-ROC que participan en las actividades relacionadas con certificación: Certificación de Centros de Recursos (RCs) Banco de pruebas de Certificación de middleware Servicio de Pre-producción: CESGA, CSIC, INTA, LIP y PIC. } PIC

IrisGRID-EGEE Toledo, 25/10/ Soporte a los RCs en LCG Organizado de forma jerárquica. Primary Sites (PS): Centros que dan soporte en temas de operaciones a otros centros – El PIC ha actuado de PS en el despliegue y operación de LCG. Procedimento: 1. El PS pide al nuevo RC que rellene el formulario de registro inicial. Datos genéricos: Nombre del centro, dominio... Contactos: Genérico del centro (correo y teléfono) Temas de seguridad –Nombre, correo personal y teléfono del responsable de seguridad del centro. –Teléfono y correo (listbox) para emergencias en caso de incidente de seguridad. 2. Si es necesario, el PS envía al RC punteros a la documentación relevante para instalar y configurar la versión actual de LCG. La cantidad de documentos relevantes es importante. Desde el despliegue de LCG- 2 se mantiene un documento base que contiene referencias a todos los documentos necesarios, para instalar y configurar una versión determinada de LCG:

IrisGRID-EGEE Toledo, 25/10/ Soporte a los RCs en LCG 3. El PS Proporciona soporte al RC durante el proceso de configuración. 4. Al final de este proceso, el PS ejecuta una serie de tests de certificación: Sistema de Información Comprobación de que el GIIS está publicando toda la información sobre el RC de forma correcta, completa y que ésta es coherente. –colas PBS: VOs aceptadas, número de WNs, potencia (kSI2k)... –SEs: VOs aceptadas, path de acceso, protocolos soportados... Storage Element (SE) Prueba del gridftp server a través de un usuario de la VO DTEAM –edg-grdiftp-ls, edg-gridftp-mkdir, globus_url_copy, edg-gridftp-rm... Computing Element (CE) y Worker Nodes (WNs) Prueba directa contra el gatekeeper –Jobmanager fork: globus-job-run /bin/hostname –Jobmanager PBS: globus-job-run /jobmanager-lcgpbs /bin/hostname

IrisGRID-EGEE Toledo, 25/10/ Certificación de RCs (cont.) Pruebas de acceso al RC a través del RB/BDII de certificación. CE y WNs Envío de trabajos a través del RB: –Se incluye el nuevo RC en el BDII de certificación –Prueba de envío de trabajos a través del RB de certificación: »edg-job-list-match, edg-job-submit > edg-job-status > edg-job-get-output Configuración en los WNs: variables de entorno, espacio para instalación de sw,... Funcionalidad combinada: pruebas del Replica Manager (RM) El nuevo RC tiene que configurar sus WNs para que el BDII por defecto sea el de certificación. Ciclos de réplicas usando las 2 herrmientas disponibles: edg-rm y lcg- utils (basado en GFAL): –fichero local WN ->SE local –SE local -> SE de certificación –SE de certificación -> SE local –SE de certificación -> WN local

IrisGRID-EGEE Toledo, 25/10/ Certificación de RCs (cont.) Pruebas de R-GMA Comprobación de que los servicios en el servidor R-GMA del RC (MON-BOX) son accesibles (http, puerto 8080) desde el WN (ArchiverServlet, ConsumerServlet, …) Comprobación de que se pueden publicar datos a través de R-GMA desde el WN.

IrisGRID-EGEE Toledo, 25/10/ Soporte a los RCs en LCG 5. Cuando el resultado de estos tests es positivo, contacta al LCG deployment team (OMC) en el CERN para que se incluya el nuevo RC en la lista de nodos LCG (EGEE). Mensaje al grupo de LCG Deployment del CERN (support-lcg- e Ian Bird adjuntando: Formulario con los contactos de seguridad, etc. Contacto LDAP del GIIS del nuevo RC. Mensaje al GOC pidiendo acceso (indicar el subject del certificado del administrador) a la Base de Datos de recursos (GOC DB) en la que los administradores de cada RC deben: mantener un listado actualizado de máquinas en las que corren los servicios grid. anotar los períodos de mantenimiento programados (scheduled downtime) para que el sistema de monitorización los tenga en cuenta. Mantener actualizada la información de contactos del centro (teléfonos, correos, etc).

IrisGRID-EGEE Toledo, 25/10/ Soporte a los RCs en LCG

IrisGRID-EGEE Toledo, 25/10/ Soporte a los RCs en LCG

IrisGRID-EGEE Toledo, 25/10/ Monitorización de RCs Finalizado este proceso, el nuevo RC pasará a ser monitorizado/testeado con regularidad por el GOC: LCG Deployment Testing: Repetición diaria de las pruebas de certificación (envío de trabajos, réplicas de ficheros, etc): Gppmon: Pruebas de envío de trabajos a través de diversos RBs. GIIS Monitor: Comprobación de la información publicada a través del GIIS: Pruebas de consistencia (entradas vacías, ausencia de ObjectClasses o DNs, …) Monitorización del uso de CPU y almacenamiento publicados (totalCPU, freeCPU, runJob, waitJob, seAvail, seUsed, …) Mapcenter: Monitorización periódica de diversos servicios: CE: gatekeeper, mds, … SE: gridftpd, mds, … RB: gridftpd, ns, … Monitorización de la caducidad de los certificados de CEs y SEs.

IrisGRID-EGEE Toledo, 25/10/ GOC Monitoring: gppmon

IrisGRID-EGEE Toledo, 25/10/ GOC Monitoring: GIIS Monitor

IrisGRID-EGEE Toledo, 25/10/ GOC Monitoring: MapCenter

IrisGRID-EGEE Toledo, 25/10/ Certificación de middleware De forma paralela al servicio de producción, EGEE/SA1 operará otros servicios/testbeds que se usarán en a lo largo del middleware release cycle: Servicio de Pre-producción: Correrá la siguiente versión del mw a la desplegada en el servicio de producción. Debe ser un servicio estable. Su finalidad principal es que las aplicaciones puedan validar en él las siguientes versiones de los servicios Grid. En general, no necesita dar acceso grandes cantidades de recursos (CPU y almacenamiento) y el soporte es más limitado (8x5). Todos los centros del SWE-ROC tendrán nodos en esta infraestructura. Banco de pruebas de Certificación: La finalidad de esta infraestructura es validar la funcionalidad del middleware antes de desplegarlo en el servicio de pre-producción. Actualmente sólo cuenta con recursos en el CERN, pero el plan es abrir la puerta a incluir recursos a través de los ROCs, ya que en algunos casos puede haber requisitos específicos de RCs en ciertas federaciones que puedan afectar a la certificación del middleware (pej, certificación en ciertas plataformas …)

IrisGRID-EGEE Toledo, 25/10/ Certificación de middleware Documento SA1 Services and Testbeds

IrisGRID-EGEE Toledo, 25/10/ Certificación de mw: situación Servicio de Pre-producción: De momento, 8 centros se han ofrecido voluntarios para iniciar el servicio: FZK, CNAF, Padova, Bari, NIKHEF, SNIC, Protvino-IHEP y RAL. Varios de los otros ROCs ya han mostrado interés en unirse. El software inicial será: LCG-2 (v2.2.0) sobre RedHat 7.3 Los WNs correrán sobre SLC3 (la versión SLC3 de todos los módulos LCG2 se esperaba para mediados de octubre). La migración a gLite se hará componente por componente, a medida que éstos vayan estando disponibles y vayan pasando la certificación de SA1. Banco de pruebas de Certificación: Todavía muy centralizado en el CERN. En el PIC tenemos planeado desplegar una primera instancia para esta infraestructura dentro del SWE-ROC después de desplegar el nodo del servicio de pre-producción.

IrisGRID-EGEE Toledo, 25/10/ Manejo de Datos en LCG-2/EGEE-0 En la infraestructura que actualmente hay en producción (LCG2/EGEE0, versión LCG-2_2_0) el servicio destinado a la transferencia de fichero es fundamentalmente: EDG Replica Manager: Movimiento de datos síncrono. –El no permitir movimientos de datos asíncronos puede ocasionar problemas, como por ejemplo cuando desde muchos WNs se quaccede simultáneamente a un fichero remoto y este acaba transfiriéndose muchas veces, malgastándose espacio de almacenamiento y ancho de banda de red. Interacciona con los catálogos (Local Replica Catalog y Replica Metadata Catalog). Puede hablar con diversos SEs: SRM, SE-Classic (servidor gridftp + GRIS) y EDG WP5 SE.

IrisGRID-EGEE Toledo, 25/10/ Manejo de Datos en EGEE-1 (gLite) En gLite, el subsistema de Manejo de Datos constará de diversos servicios, cada uno de ellos dedicado a una tarea bien definida. La finalidad es, además de tener un sistema modular, conseguir un servicio de transferencia de datos fiable, que implemente colas, prioridades, etc y con buen rendimiento. Data Scheduler: Servicio central para cada VO. Responsable de planificar y monitorizar las transferencias y operaciones de catálogos entre multiples centros. Transfer Fetcher: Hace de conexión entre el DS global y el FPS local. Contacta el DS para comprobar si existen transferencias pendientes hacia el SE local. En caso de que las haya, las lee y las envía al FPS. File Placement Service: Coordina la transferencia e interactua con los catálogos. Cada RC corre un FPS. File Transfer Service: El servicio de más bajo nivel. Controla las transferencias entrantes a un cierto RC. Comparable a la cola batch de una granja de cómputo. Cada RC corre un solo FTS.

IrisGRID-EGEE Toledo, 25/10/ Manejo de Datos: RTC LCG ha planeado llevar a cabo una serie de Service Challenges para comprobar que el middleware Grid (inicialmente LCG-2) es capaz de llevar a cabo las tareas que se requerirán en el LHC. En relación con el manejo de datos, se llevará a cabo el Robust Data Transfer Service Challenge: Desplegar y probar prototipos de los servicios de transferencias de datos que se necesitarán en el LHC. Probar la distribución fiable de ficheros a velocidades de hasta 500MB/sec desde el Tier-0 a los Tier-1. Inicialmente disco a disco, pero más adelante cinta a cinta e incluyendo accesos a los catálogos de réplicas. Inicialmente, transferencias a un solo Tier-1, pero más adelante incluyendo transferencias simultáneas a más de un Tier-1. El PIC ha empezado a establecer contactos con el CERN para participar en estas pruebas. El calendario propuesto es empezar en Nov-Dic 2004 y acabar a mediados del 2005.

IrisGRID-EGEE Toledo, 25/10/ Sumario En EGEE parte de las tareas asignadas a los ROCs incluyen la certificación de los RCs de la propia federación, previa a su inclusión en el servicio de producción, y la participación en el proceso de certificación y validación del middleware producido por JRA1. El PIC, como parte del SWE-ROC, participa en el proceso de certificación de RCs, en la infraestructura EGEE de certificación de middleware así como en el servicio de pre- producción. Los servicios de transferencia de ficheros que proporcione EGEE tienen que cubrir las necesidades del LHC. Desde el CERN se ha organizado un Service Challenge dedicado a seguir el desarrollo de estos servicios. El PIC planea participar en él.