Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di...

Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003

Evoluzione dei modelli di calcolo distribuito

nell’esperimento CMS

Claudio Grandi(INFN Bologna)

12 giugno 2003Workshop Commissione Calcolo 2Claudio Grandi INFN Bologna

Outline• Il Computing Model di CMS nel 1999

– MONARC!

• Combiamenti nel Computing Model di CMS – L’utilizzo di meddleware grid– Il progetto LCG del CERN

• Data Challenges di CMS


CMS Computing Model ~1999• Software applicativo:

– Migrazione a linguaggi Object Oriented (C++)– OODBMS per il data management Objectivity/DB

• Data model e analysis model– MONARC (vedi oltre)

• Architettura– MONARC (vedi oltre)


Monarc Data Model

RawData

Slow controlCalibration data

Trigger TagSimulation

Data

Reconstruction

ESD/Rec.Obj.Data

TagData

Selection

Anal.Obj.Data

AOD (2 steps)Data

1 PB/Year +0.001 PB/Year? +~0.5 PB/Year?

Input of

Analysis

Local DBand/or

Histograms

Input of

Input of

1.1 PB/Year +100 GB/Year or0.1 PB/Year +100 GB/year

CMS

ATLAS

Off-Line Farm(and “other” resources

for Simulation)

RCs (including CERN)

0.2 TB/Year x 2using TAG

CMS

20 TB/Year x 2using TAG

2 TB/Year x 2using TAG

ATLAS pass1

ATLAS pass2

RC (including CERN)and/or Desktops

Huge amount of Data!But negligible for Users(if DB is out of Global Objy DB)

By P.Capiluppi Jul 1999


Monarc analysis processDAQ

--------------Raw

Slow C--------------Calibration

Reconstruction----------------------

ESD/Rec. Obj+TAG DB

Selection---------------

AOD/Anal. Obj

Selection---------------

AOD/Anal. Obj

Analysis-------------

Selected AOD/Anal. Obj& TAG DB

Analysis-------------

Selected AOD/Anal. Obj& TAG DB

TriggerInfo

x n WG

x n Users in the WG

1st time at CERN(then at RC? ==> Parameters?

Different WGat different site?==> Parameters?

RC or Desktop?==> Parameters?

4 times per Year?(per Exp.)

Onceper Month?(per WG)

4 timesper Day?(per User)

Raw Data : On Tape, at CERN and at RCESD/Rec.Obj : On Tape at CERN, on Disk at RC (Including CERN RC) for the samples needed by analysis at a given RC AOD/Anal. Obj : On DiskSelected AOD/Anal. Obj : On DiskTAG DB : On Disk

By P.Capiluppi, Jul 1999


Modello di computing: Monarc

– Il Modello di Computing e’ basato su due pilastri:• Le risorse hardware (incluso il Network), software e “programming”

non possono essere basate solo e principalmente al CERN.

• La dispersione dei partecipanti agli Esperimenti richiede una organizzazione di “collaboration at a distance”, implicando (anche politicamente) un Distributed ComputingDistributed Computing di portata e complessita’ senza precedenti (anche per gli “Informatici”).

• [Terzo pilastro!: occorre fare uso il piu’ possibile della realta’ della commoditycommodity (budget and availability)]

By P.Capiluppi, Jul 1999


Monarc: computing model

Tier2 Centre ~1 TIPS

Online System

Offline Processor Farm

~20 TIPS

CERN Computer Centre

FermiLab ~4 TIPSFrance Regional Centre

Italy Regional Centre

Germany Regional Centre

InstituteInstituteInstituteInstitute ~0.25TIPS

Physicist workstations

~100 MBytes/sec

~100 MBytes/sec

~622 Mbits/sec

~1 MBytes/sec

There is a “bunch crossing” every 25 nsecs.

There are 100 “triggers” per second

Each triggered event is ~1 MByte in size

Physicists work on analysis “channels”.

Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server

Physics data cache

~PBytes/sec

~622 Mbits/sec or Air Freight (deprecated)




Caltech ~1 TIPS

~622 Mbits/sec

Tier 0Tier 0

Tier 1Tier 1

Tier 2Tier 2

Tier 4Tier 4

1 TIPS is approximately 25,000

SpecInt95 equivalents

By H.Newman


Monarc: architettura– Definizione in termini di servizi

– Servizi di dati:• produzione MC• reprocessing eventi• produzione ESD/AOD/tags• accesso a ESD/AOD/tags• bookkeeping

– Servizi Tecnici:• Database maintenance• tools for data services• storage management• CPU-DB-I/O usage monitoring/policing• Documentation

By L.Barone, oct 1999


Definizione di Tier-1 e Tier-2– Un centro regionale tier-1 fornisce tutti i servizi tecnici, tutti i servizi dati

per l’analisi ed è in grado di fornire almeno un’altra classe di servizi dati

– Un RC tier-1 è dimensionato in rapporto al CERN– Dimensioni iniziali tra il 10 e il 20 % del CERN (singolo esperimento)– 100,000 SI95, 150-300 boxes, 100 TB di disco, 0.2-0.3 PB su nastro– Evoluzione nel tempo

– Tutti gli ESD/AOD/Tags– Tutte le calibrazioni– Bookkeeping aggiornato – Parte dei Raw Data ???– Accesso trasparente per gli utenti– Datasets mossi preferibilmente via rete



Definizione di Tier-1 e Tier-2

– Un centro tier-2 è simile a un tier-1 ma su scala minore, fino al 25% di un tier-1

– Dedicato solo all’analisi (tutti gli AOD/tags, frazione degli ESD)

– Scambia dati con un tier-1 piuttosto che con il CERN, per ottimizzare il traffico di rete



Definizione del Computing ModelJ F M A M J J A S O N D J F M A M J J A S O

Ph

ysic

sM

od

elC

om

pu

tin

gM

od

el

DC04

C-TDReditorial 1s t

Draft

C-TDRFinal

DC

04p

re-p

rod

uct

ion

san

d o

per

atio

n

OSCAR valid'n data

1st version new LCG softwarePOOL persistency + SEAL base

Detector and physicsobject creation / storage

Preparation of DC04calibration/analysis SW

So

ftw

are

dev

elo

pm

ent

CMKIN samples for DC04

OSCAR / GEANT4 validation

TDR docum entionsys tem in place

Pos t-m ortemof DC04

Computing Modelincluding DC04

experience

Computing Model (v2)

coarse-granularitysystem modelling

Phys. Model (v3)calibration and

analysis workflows

Editorialwork

Demonstrate grid of T0,T1,T2 centres & software copes with 25Hz rate (2.10**33)

Comp. Model (v3)usage patterns,

policy, dynamics,measurements…

Chapter sum m ariesscope, issues , etc.

Sectionsum m aries

Data moving ( ~1 TB/day)Digitisation

Geant4 simulation (50M evts)50kSI95, steadily more LCG-1

Physics Model(v1)rough scope, key

parameters

Phys. Model (v2)incl. DC04 tasksand Data Model

Computing Model (v1)

top-level numbers& modelling tools

20032003 20042004


CMS Computing Model ~2003• Software applicativo:

– Migrazione a OO quasi completato• Geant-4 è la componente “difficile”

– Uso di OO-streaming library su flat files o RDBMS• Soluzione quasi comune agli esperimenti LHC

• Data model e analysis model– Non sono fondamentalmente cambiati. Sono in fase

di definizione i dettagli (ad es. dimensione dei dati)

• Architettura– MONARC, ma con il middleware di grid– Si ricercano soluzioni comuni (LCG)


Uso di grid• Dove i tools di grid aiutano nell’implementazione del modello di

calcolo:– Meccanismi di autenticazione e autorizzazione comuni– Interfaccia comune a diversis Local Resource Manager Systems– Interfaccia comune a diversi Mass Storage Systems– Unico entry-point verso le risorse– Unico entry-point verso i dati

• Per l’utente finale, cioè il fisico:– semplificato l’accesso ai dati e alle risorse di calcolo

• Per il production manager:– accesso diretto ad un maggior quantitativo di risorse (cioè è necessario

un numero minore di production managers!)

• Per il system manager:– maggiore libertà nella scelta delle politiche locali di accesso– maggiore libertà nella scelta di LRSM e MSS (in prospettiva!)


Uso di gridAttenzione a non cadere in facili semplificazioni:

– L’utente finale (il fisico) può beneficiare di un maggior livello di incapsulazione (dettagli, quali la locazione delle risorse e dei dati possono essere nascosti)

Però:– Per garantire uno sfruttamento efficiente delle risorse, la

dislocazione di risorse e di dati deve essere oculata. Utenti selezionati (production managers) devono poter agire direttamente sulle risorse!

– Il nostro non è un vero modello provider-client: le founding agencies (INFN!) pagano sia le risorse e la loro gestione, sia i fisici che fanno analisi! Spesso le persone che gestiscono e utilizzano le risorse sono le stesse.

– Un modello gerarchico di servizi rimane la chiave per il successo del sistema


Produzioni grid con MOP (VDT)• MOP is a system for packaging

production processing jobs into DAGMAN format

• Mop_submitter wraps Impala jobs in DAG format at the “MOP master” site

• DAGMAN runs DAG jobs through remote sites’ Globus JobManagers through Condor-G

• Results are returned using GridFTP. Though the results are also returned to the MOP master site in the current IGT running, this does not have to be the case.

Master Site

Remote Site 1

IMPALA mop_submitterDAGManCondor-G

GridFTP

BatchQueue

GridFTP

Remote Site N

BatchQueue

GridFTP

UW Madison is the MOP masterfor the USCMS Grid Testbed

FNAL is the MOP master for the IGTand the Production Grid


SECE

CMS software

Produzioni grid con EUDataGrid

BOSSDB

WorkloadManagement

System

JDL

RefDB

parameters

data registration

Job output filteringRuntime monitoring

input

dat a

lo

cat i

on

Push data or info

Pull info

UIIMPALA/BOSS

Replica Manager

CE

CMS software

CE

CMS software

CE

WN

SECE

CMS software

SE

SE

SE


LHC Computing Grid Project 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.

LCG Manpower (April 2003)

49

54.9

20.5

9.55.8

ApplicationsFabricGrid DeploymentGrid TechnologyManagement


The appliccation area

Application Area manpower provenance

Experiments26%

LCG41%

CERN33%

Application Area Projects

POOL

SPI

SEAL

PI

Math Libraries

Grid interfacing

Architecture

Management

Simulation

ROOT

Gli esperimenti contribuiscono a LCG con un considerevole numero di persone (circa 4 FTE da CMS…)

Total of 49 FTE’s


CMS Data Challenges

CMS

1

10

100

1000

10000

100000

2002 2003 2004 2005 2006 2007 2008 2009

kS

I95.M

on

ths

CERN

OFFSITEAverage slope=x2.5/year

DC04Physics TDR

DC05LCG TDR

DC06Readiness

LHC2E33

LHC1E34

DAQTDR

1999: 1TB – 1 month – 1 person2000-2001: 27 TB – 12 months – 30 persons 2002: 20 TB – 2 months – 30 persons2003: 175 TB – 6 months – <30 persons

By V.Lefebure Sep 2002


DC04 e pre-production (PCP03)• Simulazione del processo di ricostruzione e analisi del

primo anno di running di LHC ad una scala pari al 25% delle dimensioni reali (5% delle dimensioni finali).– Un mese: febbraio 2004– Processamento dati a 25 Hz (50 MB/s) al CERN– Distribuzione dei dati ai Tier-1 e Tier-2 e analisi con grid– 50 milioni di eventi in input

• Pre-produzione da luglio a dicembre 2003– simulazione e digitizzazione dei 50 milioni di eventi– circa 1M SpecInt2000, 175 TB di dati– 75 TB di dati da trasferire al CERN in 2 mesi (~125 Mbit/s)– In Italia circa il 20% della pre-produzione

• ~200 KSpecInt2000 per 6 mesi, 34 TB di dati prodotti e archiviati• ~25 Mbit/s bandwidth CNAF CERN (nov-dic 03) • ~20 Mbit/s bandwidth Tier-2’s CNAF (lug-dic 03)


Tools per PCP03

MCRunJob

Site Manager startsan assignment

RefDBPhys.Group asks for

an official dataset

User starts aprivate production

Production Managerdefines assignments

DAG

job job

job

job

JDL

shellscripts

DAGMan(MOP)

LocalBatch Manager

EDGScheduler

Computer farm

LCG-1testbe

d

User’s Site Resources

ChimeraVDL

Virtual DataCatalogue

Planner


Conclusioni• Utilizzo di tecnologia OO confermato. Sviluppo di

soluzioni home-made per la gestione dei dati• Data model e analysis model confermati.• Organizzazione gerarchica delle risorse a-la-

MONARC. I tools di grid semplificano alcuni aspetti della gestione ma non modificano l’architettura.

• La migrazione di manpower esperto in computing dagli esperimenti ai progetti grid e a LCG obbliga gli esperimenti alla ricerca di soluzioni comuni (e quindi a compromessi!)

• Data Challenges di dimensioni e complessità crescenti tentano di utilizzare tools di grid

Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di...

Documents

Transcript of Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di...