proceso certificación y manejo de datos en egee gonzalo merino pic/ifae

Proceso Certificación y Manejo de Datos

en EGEE

Gonzalo MerinoPIC/IFAE

XVIII Grupos de Trabajo de RedIRISSesión: EGEE-IrisGRID

Toledo 25-Oct-2004

www.eu-egee.org

IrisGRID-EGEE Toledo, 25/10/2004 - 2

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


Proceso de Certificación

• Según el documento ‘SWE Execution Plan’ (https://edms.cern.ch/document/477596/) 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


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:

http://grid-deployment.web.cern.ch/grid-deployment/cgi-bin/index.cgi?var=release



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 <CE> /bin/hostname– Jobmanager PBS: globus-job-run <CE>/jobmanager-lcgpbs /bin/hostname


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


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.



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-

[email protected]) e Ian Bird ([email protected]) 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).

http://goc.grid-support.ac.uk/gridsite/db-auth-request/


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):http://lcg-testzone-reports.web.cern.ch/lcg-testzone-reports/cgi-bin/lastreport.cgi

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.


GOC Monitoring: gppmon


GOC Monitoring: GIIS Monitor


GOC Monitoring: MapCenter


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 …)


Certificación de middleware

Documento ‘SA1 Services and Testbeds’ https://edms.cern.ch/document/470778


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.


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.


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.

https://edms.cern.ch/document/476451/


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.


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.

proceso certificación y manejo de datos en egee gonzalo merino pic/ifae

Documents