Proceso Certificacin y Manejo de Datos en EGEE Gonzalo Merino PICIFAE

1
Proceso Certificación y Manejo de Datos en EGEE
Gonzalo MerinoPIC/IFAE
XVIII Grupos de Trabajo de RedIRIS Sesión
EGEE-IrisGRID Toledo 25-Oct-2004
www.eu-egee.org
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

3
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
4
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
• 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.
• 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?varrelease

5
Soporte a los RCs en LCG

• El PS Proporciona soporte al RC durante el
  proceso de configuración.
• 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 ltCEgt
  /bin/hostname
• Jobmanager PBS globus-job-run ltCEgt/jobmanager-lcg
  pbs /bin/hostname

6
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 gt
  edg-job-status gt 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 -gtSE local
• SE local -gt SE de certificación
• SE de certificación -gt SE local
• SE de certificación -gt WN local

7
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.

8
Soporte a los RCs en LCG

• 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-deployment_at_cern.ch) e Ian Bird
  (Ian.Bird_at_cern.ch) 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-req
  uest/

9
Soporte a los RCs en LCG
10
Soporte a los RCs en LCG
11
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-testzo
  ne-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.

12
GOC Monitoring gppmon
13
GOC Monitoring GIIS Monitor
14
GOC Monitoring MapCenter
15
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 )

16
Certificación de middleware
Documento SA1 Services and Testbeds
https//edms.cern.ch/document/470778
17
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.

18
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.

19
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/
20
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.

21
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.