javier sánchez, santiago gonzález jornadas técnicas de rediris toledo, 25/10/2004 resource center...

Javier Sánchez, Santiago González

Jornadas Técnicas de RedIris Toledo, 25/10/2004

Resource Center de EGEE

k

IFIC Instituto de Física CorpuscularCSIC-Universitat de València

25-Oct-2004 IRISGRID-EGEE 2

Infraestructura: CPUs

134 PCs en 6 racks formato 2U (117 en EGEE)

CPU:o 67 Athlon K7 @ 1.2 GHzo 67 Athlon K7 @ 1.4 GHz

RAM: 1 Gbytes HD: 40 Gbytes

o ~2 Gbytes Linux RH 7.3o Resto para trabajos

NIC: FastEthernet (100 Mbps)


Infraestructura: CPUs

8 Intel servers CPU:

o Pentium 4 @ 3.2 GHz RAM: 1 Gbytes HD: 120 Gbytes NIC: Gigabit + FastEthernet


Almacenamiento: CASTOR

CASTOR: CERN Advanced STORage Manager Es un HSM desarrollado en el CERN cuyo objetivo es

manejar los datos de LHC en un entorno distribuido. Actualmente el CERN almacena en este sistema ~ 2

PBytes de datos experimentales en ~ 35000 cintas Gestiona el espacio en disco y la migración automática de

ficheros entre los servidores de disco y las cintas. El usuario maneja un espacio virtual de ficheros, ej.:

o /castor/ific.uv.es/grid/atlas/datafiles/… El acceso nativo a los ficheros se hace usando un

protocolo llamado RFIO.



1

1

1

2

4

34


Servicios CASTOR

o PC para espacio de nombres y gestión de volúmenes

nsdaemon Cupvdaemon vdqmserv vmgrdaemon mysqld

o PC para la gestión de espacio de disco (stager) Cdbserver stgdaemon rfiod


1

2


Servidores de disco para CASTOR

o 4 servidores ( 4TBytes ) 2 x Intel Xeon @ 2.8 GHz 2 x Ethernet Gigabit 2 x 3ware 8506-8 Serial ATA

Raid Controller 12 x HD 160 Gbytes o 200

Gbytes

• En 6 RAID1 (mirror) por parejas


3


Librería de cintas 140 TBytes o STK L700eo 700 slotso 4 x drives HP LTO2

(200GB/nativo, 400GB comp.)o Interface Fibre Channel para

los drives, SCSI para el control de la robótica



Servidores de cinta para CASTOR

o 2 servidores para la lectura/escritura de las cintas

2 x Intel Xeon @ 2.8 GHz 2 x Ethernet Gigabit 1 x qla2300 fibre channel

HBA Cada servidor está asociado a

2 lectores del robot Interconectados a traves de

un switch de FC


4


Servidores de cinta para CASTOR

o PC para el control de la robótica

Recibe las peticiones de montaje, desmontaje e inventario de los dos servidores de cinta


4


Red

o 22/23 PCs con FastEthernet de cada rack se conectan en conmutadores con enlace de subida de gigabit.

o Los servidores de disco y los de cinta se conectan a un switch gigabit ethernet.

o Ambos se conectan al backbone de la “nave experimental” del IFIC a GigabitEthernet que a su vez que conecta con el conmutador del campus de Burjassot-Paterna de la Unversidad de Valencia 10Gigabit.

Red


Servicios básicos o LCFGng: Sistema de instalación y configuracióno CE: Computing Element

Gestor de batch (PBS) Gatekeeper de Globus EDG Workload Manager

o UI: User Interface Herramientas de envío de trabajos de EDG

o SE: Storage Element Versión modificada de gridftp para proporcionar acceso a

castor.o WN: Worker Nodeo MON: RGMA monitoring system

EGEE


Servicios suplementarios

o RB: Resource brokero BDII: Berkley Database Information Indexo MyProxy: Proxy delegation serviceo VO server: Servidor de VO para la federación SWE

Servicios dedicados para ATLASo RBo BDIIo UI

EGEE


EGEE

Servicio Número de servidores

EGEE general 9

EGEE dedicado 3

EGEE WN 117

Castor 9

Serv. Disco 4

Serv. Cinta 2

Control 3


LHC (CERN)

Mont Blanc, 4810 m

Ginebra


LHC (CERN)


El reto de la computación en LHC (CERN)


El reto de la computación en LHC (CERN)

Tres de los cuatro experimentos generarán del orden del PB, de datos brutos cada año durante un periodo de 10 años.

La frecuencia de lectura de los detectores ATLAS y CMS se espera que sea de 100 Hz y el tamaño de datos brutos para cada suceso es de 1 MB.

Investigadores repartidos por todo el mundo.

El reto tecnológico es suministrar un acceso rápido a muestras del tamaño del TB y un acceso rápido a los recursos de cálculo distribuidos por el mundo, para posibilitar el trabajo de análisis.


Colaboración ATLAS

34 países 150 institutos y universidades 1850 físicos


Calendario de los ATLAS Data Challenge

DC1 (2002-2003)o Primer test del software del detector (Instalación Manual)

Simulación de los datos Reconstrucción

o Sistema de producción no automatizado Herramientas (bookkeeping; monitoring; …) Uso del Grid (30%)

DC2 (Verano 2004)o Nuevo software del detector (Instalación remota)o Sistema de producción automatizadoo Uso del GRID 100% (LCG, GRID3 y NorduGrid)o Test del Modelo de Computing

DC3 (Primavera 2006)o Test finales antes de la toma real de datos


ATLAS-DC2 DC2 se componen de tres partes:

o parte I: Producción de los datos simulados (Julio-Septiembre 2004)

corriendo en el “Grid” A lo largo de todo el mundo

o parte II: Ejercicio del Tier-0 (Noviembre 2004) Hacer en 10 días lo que se debería hacer en 1 día de toma real de

datos Input son los “Raw Data” output (ESD+AOD) los cuales se distribuirán a los Tier-1s en tiempo

real para el análisis

o parte III: test del análisis distribuido utilizando el Grid (Nov.-Dic. 2004)

Acceder a los datos desde cualquier lugar del mundo de una forma caótica u organizada.

Algunos datos de esta faseo ~30 Canales de Física ( 10 Millones de sucesos)o ~50 Institutos/Universidades a lo largo de todo el mundoo ~35 TB


Sistema de Producción de ATLAS

Totalmente automatizado, componentes:o Supervisor: Windmill (US)

Obtener los trabajos a partir de la base de datos de producción Enviar los trabajos a uno de los “executors” Realizar el registro final en caso que todo funcione bien

o Executors (uno por Grid o “legacy batch”) : Traduce las definiciones de neutras a un lenguaje específico (en

nuestro caso JDL) • Capone (Grid3) (US) • Dulcinea (NorduGrid) (Escandinavia)• Lexor (LCG) (Italia)• “Legacy systems” (Alemania-FZK; Francia-Lyon)

o Data Management System (DMS): Don Quijote (CERN) Permite el registro y la movilidad transparente de datos entre los

diferentes grid utilizados por ATLAS.o Bookkeeping: AMI (Atlas Metada Interface) (LPSC-Grenoble)o Base de datos de producción (Oracle)

Definición y estado de los trabajos


LCG NG Grid3 LSF

LCGexe

LCGexe

NGexe

G3exe

LSFexe

super super super super super

prodDBdms

RLS RLS RLS

jabber jabber soap soap jabber

Don Quijote

Windmill

Lexor

AMI

CaponeDulcinea

Sistema de Producción de ATLAS

IFIC-Valencia


ATLAS DC2 Fase I Empezó a principios de Julio y todavía corriendo Se utilizan los tres “sabores” de Grid:

o LCG (http://lcg.web.cern.ch/LCG/) The job of the LHC Computing Grid Project – LCG – is to prepare the computing

infrastructure for the simulation, processing and analysis of LHC data for all four of the LHC collaborations. This includes both the common infrastructure of libraries, tools and frameworks required to support the physics application software, and the development and deployment of the computing services needed to store and process the data, providing batch and interactive facilities for the worldwide community of physicists involved in LHC.

o NorduGrid (http://www.nordugrid.org/) The aim of the NorduGrid collaboration is to deliver a robust, scalable,

portable and fully featured solution for a global computational and data Grid system. NorduGrid develops and deploys a set of tools and services – the so-called ARC middleware, which is a free software.

o Grid3(http://www.ivdgl.org/grid2003/) The Grid3 collaboration has deployed an international Data Grid with dozens

of sites and thousands of processors. The facility is operated jointly by the U.S. Grid projects iVDGL, GriPhyN and PPDG, and the U.S. participants in the LHC experiments ATLAS and CMS.

IFICValencia

http://www.nordugrid.org/middleware/


LCG middleware LCG-1 fue (hasta Feb 2004):

o VDT (Globus 2.2.4) (proyecto americano)o EDG WP1 (Resource Broker) (European DataGrid)o EDG WP2 (Herramientas de Replica Management)o GLUE 1.1 (Information schema) + unas pocas extensiones esenciales de

LCGo LCG modificaciones:

Modificación de los Job managers para evitar problemas en el sistema de ficheros compartidos

MDS – BDII Mejoras al Globus gatekeeper necesarias para LCG Corrección de bugs de EDG y Globus/VDT

LCG-2 es una actualización y mejora de LCG1 (desde Junio 2004):

o Nuevo VDT 1.1.14 (Globus 2.4.3)o Mantenimiento del Workload Managemento Mantenimiento y mejora del Data Managemento Mejoras en la monitorización de los centros con GridICE

Middleare es libre y se puede coger de su repositorio de CVSo http://lcgdeploy.cvs.cern.ch/cgi-bin/lcgdeploy.cgi/

LCG-2 correrá hasta la primavera de 2005 Después el middleware a utilizar vendrá del EGEE


Integración LCG-EGEE LCG-2

focus on production, large-scale data handling

The service for the 2004 data challenges

Provides experience on operating and managing a global grid service

Development programme driven by data challenge experience

o Data handlingo Strengthening the

infrastructureo Operation, VO management

Evolves to LCG-3 as components progressively replaced with new middleware

-- target is to minimise the discontinuities of migration to the new generation

Aim for migration plan by end of year

LCG-2 (=EGEE-0)

prototyping

prototyping

product

20042004

20052005

LCG-3 EGEE-1

product

gLitefocus on analysis

Developed by EGEE project in collaboration with VDT (US)

LHC applications and users closely involved in prototyping & development (ARDA project)

Short development cycles

Co-existence with LCG-2 Profit as far as possible

from LCG-2 infrastructure, experience

Ease deployment – avoid separate hardware

As far as possible - completed components integrated in LCG-2

improved testing, easier displacement of LCG-2

Les

Robert

son C

ER

N-I

T G

DB

meeti

ng Ju

lio 0

4Le

s R

obert

son C

ER

N-I

T G

DB

meeti

ng Ju

lio 0

426


Sitios en Grid3

• 28 centros, multi-VO• comparten recursos• ~2000 CPUs• dynamic – roll in/out


NorduGrid & Co. Recursos:

7 paises:

CPUs para ATLAS: ~3280 “Storage Elements” para ATLAS: 10

o Capacidad: ~14 TB, compartido


ROMA1

• 22 Paises• 58 Institutos: (45 Europeos, 2 US, 5 Canadá, 5 Asia, 1 HP)

• en el futuro: Nueva Zelanda, China, otros HP (Brasil, Singapur)

• 3800 cpu

Centros en LCG-2

Federación Suroeste


ATLAS DC2 Fase I Principales problemas encontrados:

o Para todos los Grids Debugging el sistema de Producción En LCG y GRID se corren varios “supervisores” (En el IFIC corremos uno) para

mejorar la estabilidad del sistema. Esto hace más difícil controlar el sistema producción.

Respuesta lenta de la Base de Datos de producción.o LCG

Mala configuración de algunos centros; Sistema de Información (información errónea o no publicada); Servicio de envío de trabajos (JSS) y el Resource Broker.

Data management (copia & registro); Stage in/out o NorduGrid

Replica Location Service (Globus) modificado a mano varias veces por dia Mala configuración de algunos centros Acceso a la base de datos de producción

o Grid3 Data Management - RLS Replica Location Service Problemas con las distribución del software Load on gatekeepers Problemas con los certificados (abortando algunos trabajos)

o Colaboración con los desarrolladores del middleware en los distintos “sabores” Grids para resolver los problemas.


ATLAS DC2 Fase I Problemas relacionados con la configuración de los Problemas relacionados con la configuración de los

sitiossitioso ResponsableResponsable de la mayoría de los problemas ocurridos

durante los DC2 o Lista no completano completa de los problemas:

La variable VO <VO> SW DIR apunta a un área de los WN la cual no existe. En el área dedicada para instalar el software del experimento, los responsables de

instalar lo (ESM) no tienen permiso. Mala información publicada en el Sistema de Información (Glue Object Classes not

linked) Los límites temporales de las colas publicados en minutos en vez de segundos y no

normalizados Firewall Ficheros con las CA no instalados propiamente Problemas con NFS (home directories ó el área para los ESM) Perfiles equivocados para los usuarios Los discos de los Elementos de Almacenamiento (SE ) no “migrados” adecuadamente Problemas técnicos con la configuración de algunos componentes del middleware

o No existe en estos momentos un método eficiente para detectar estos fallos

o En el caso de Lexor, este executor incluye métodos para detectar problemas de configuración en los nodos de producción (WN)


ATLAS DC2 (CPU)

LCG41%

Grid330%

NorduGrid29%

LCG

NorduGrid

Grid3

Total

~ 1470 kSI2k.months~ 100000 jobs~ 7.94 million events (fully simulated)~ 30 TB


Distribución de trabajos en LCG

1% 2% 0%1% 2%

14%

3%

1%

3%

9%

8%

3%2%5%1%

4%

1%

1%

3%

0%

1%

1%

4%1%

0%

12%

0%

1%

1%

2%

10%

1% 4%

at.uibk

ca.triumf

ca.ualberta

ca.umontreal

ca.utoronto

ch.cern

cz.golias

cz.skurut

de.fzk

es.ifae

es.ific

es.uam

fr.in2p3

it.infn.cnaf

it.infn.lnl

it.infn.mi

it.infn.na

it.infn.na

it.infn.roma

it.infn.to

it.infn.lnf

jp.icepp

nl.nikhef

pl.zeus

ru.msu

tw.sinica

uk.bham

uk.ic

uk.lancs

uk.man

uk.rl

uk.shef

uk.ucl

PIC-Barcelona

IFIC-Valencia

Uni. Aut. Madrid


IFIC en los DC2 Desde Agosto participamos en la Validación del sistema de

producción Se instaló el “executor” Lexor para el cual se han dedicado 3

máquinas:o User Interface, donde se instala Lexoro Resource Brokero BDII

Lexor es el mecanismo por el cual se envían trabajos de ATLAS a los centros con el middleware de LCG instalado. El IFIC está contribuyendo en correr, validar y mejorar Lexor.

Utilizamos SQuirrel (SQL Client) para poder ver la estructura de la base de datos de producción de ATLASo Programa gráfico en Javao Permite utilizar los comandos de SQL

Para poder enviar los trabajos


IFIC en los DC2 Trabajos enviados por Lexor en Valencia (7/10/2004) a

todos los sitios de ATLAS en LCG

1135 Fallados

8325 Acabados correctamente

167 Pendientes

227 Corriendo

96 Enviados


Conclusiones EL IFIC esta operando una infraestructura de

producción dentro de EGEEo 117 WNso 4 TBytes de capacidad de disco en EGEE o 140 TBytes de capacidad de almacenamiento en cinta

Participa en los retos de datos (DC2) de ATLAS o Proporcionando recursos dentro de EGEEo Corriendo una instancia del ejecutor de ATLAS

Proporciona los servicios de VO para la región Suroeste de EGEE (ver presentación de Alvaro Fernández)

javier sánchez, santiago gonzález jornadas técnicas de rediris toledo, 25/10/2004 resource center...

Documents