- (INFN)

GRID
per la fisica delle alte energie
Nicola De Filippis
Dipartimento di Fisica
dell’Università degli Studi e
del Politecnico di Bari e INFN
N. De Filippis, INFN Bari
n° 1
Sommario
 I progetti GRID
 GRID per gli esperimenti HEP ad LHC
 L’esperienza di CMS in GRID:
1. Il Data challenge 2004
2. L’analisi di utente finale
N. De Filippis, INFN Bari
n° 2
Perchè GRID?
Quando si collega una qualunque apparecchiatura alla rete elettrica
non ci si preoccupa della locazione della sorgente di energia e della
distribuzione di questa su aree geografiche.
….allo stesso modo immaginiamo di collegare il computer alla
presa di casa e di avere a disposizione immediatamente tutte le
risorse di calcolo di cui si ha bisogno, senza preoccuparsi di dove
esse siano e come vi ci si accede.
N. De Filippis, INFN Bari
n° 3
Perchè GRID?
La fisica, l’ingegneria, l’analisi medica, le biotecnologie,
l’informatica, etc. procedono attraverso:
o risorse di calcolo, sistemi di informazione e strumenti eterogenei;
o le interazioni delle persone;
o tutte geograficamente e organizzativamente sparse.
Lo scopo principale delle “Grid”:
o di fornire un insieme di risorse di calcolo fisicamente distribuite in un
numero di siti geograficamente separati, su scala mondiale;
o di facilitare le interazioni di queste risorse.
N. De Filippis, INFN Bari
n° 4
Che cosa è GRID?
“ Grid computing [is] distinguished from conventional distributed computing by its
focus on large-scale resource sharing, innovative applications, and, in some
cases, high-performance orientation...we review the "Grid problem", which we
define as flexible, secure, coordinated resource sharing among dynamic
collections of individuals, institutions, and resources - what we refer to as
virtual organizations.“
From "The Anatomy of the Grid: Enabling Scalable Virtual Organizations" by Foster, Kesselman and Tuecke
GRID è un sistema costituito da:
 risorse di calcolo: server di dati, nodi di calcolo, strumenti distribuiti
geograficamente e accessibili attraverso una rete molto efficiente
 software che fornisce interfacce uniformi e standard in modo da
garantire un utilizzo trasparente e capillare delle risorse distribuite
 possibilità di creazione di potenti sistemi di calcolo virtuali (virtual
organization), aggregando risorse distribuite.
N. De Filippis, INFN Bari
n° 5
Applicazioni di GRID
Mediche e biomediche:



Processing delle immagini (digital X-ray image analysis)
Simulazione per le terapie di radiazione
Protein folding
Chimica:



quantistica
organica
modello dei polimeri
Studi sul Clima
Scienza spaziale
Fisica:



BARI
Fisica delle alte energie e degli acceleratori
Fisica teorica, calcoli su reticolo
Fisica del neutrino
Genomica
Scienze dei materiali
N. De Filippis, INFN Bari
n° 6
GRID per la fisica delle alte energie
Gli esperimenti di HEP ad LHC (Large Hadron Collider)
useranno la GRID come soluzione per il calcolo intensivo e la
gestione di enormi quantità di dati.
N. De Filippis, INFN Bari
1.
2.
CMS
ATLAS
3.
4.
LHCB
ALICE
n° 7
I numeri per la HEP
Il passato al LEP: collisore e+e-
Il presente ad LHC:collisore pp
•
Rivelatore: ALEPH
•
Rivelatore: CMS
•
Dati in 10 anni: qualche TB (1012Bytes)
•
Dati in 1 anno: 1 PB (1015Bytes)
•
CPU: qualche centinaio al CERN
•
CPU: 4000 CPU per il DAQ al CERN
•
utenti di analisi: 200
•
utenti di analisi: 1000
•
Collaborazione 500 persone
•
Collaborazione: 1500 persone
N. De Filippis, INFN Bari
n° 8
GRID per l’HEP: funzionalità richieste
 Gestione di decine di PetaByte di dati per anno, storage, risorse di rete
 Gestione del calcolo su grandi quantità di dati: tempi di processing
lunghi, utilizzo di grande memoria, esecuzione di applicazioni intense di
I/O
 Definizione di policy locali e globali per la gestione delle risorse cioè
per stabilire che cosa può essere usato per che cosa, da chi e dove…
 Alte prestazioni per l’accesso ai dati remoti in termini di velocità ed
affidabilità
 Controllo sull’accesso ai dati e sugli utenti
 Elaborazione di software per cataloghi di dati
 Gestione delle repliche dei dati e discovery della copia “migliore” di
questi
 Coordinazione, sincronizzazione e autenticazione del sistema
L’architettura distribuita è necessaria e vitale
N. De Filippis, INFN Bari
LCG
n° 9
LHC Computing Grid Project – LCG
LCG
Les Robertson – LCG Project Leader
CERN – European Organisation for Nuclear Research
Geneva, Switzerland
Scopo del progetto:
 Preparare, testare e rendere operativi:
 l’ambiente di calcolo per analizzare i dati raccolti dai rivelatori ad LHC
 l’ambiente di sviluppo di applicazioni, strumenti comuni e framework
GRID è solo uno strumento per raggiungere questo scopo
N. De Filippis, INFN Bari
n° 10
BARI
Total:
78
Sites
~9000 CPUs
6.5
PByte
N. De Filippis, INFN Bari
LCG-2/EGEE-0 Status
24-09-2004
n° 11
Componenti e flusso dei job in LCG
UI
JDL
Replica
Catalogue
(RC)
Information
Service (IS)
Resource
Broker (RB)
Logging &
Bookkeeping
(LB)
Job Submission
Service (JSS)
Working
Node (WN)
Storage
Element
(SE)
Computing
Element (CE)
N. De Filippis, INFN Bari
n° 12
Componenti del sistema LCG (1)
Il sistema LCG è organizzato in:
1.
Virtual Organizations (cms,atlas, ecc.): insiemi di individui e istituzioni che
condividono risorse in maniera flessibile, sicura e coordinata.
2.
Infrastruttura di sicurezza grid per l’autenticazione tramite certificato utente
in forma criptata.
3.
UserInterface (UI): macchina dove l’utente LCG ha un account personale e
dove il certificato utente è installato; la UI fa da gateway ai servizi grid per le
operazioni di base:
a) sottomettere un job per l’esecuzione su un nodo di calcolo;
b) listare tutte le risorse adatte per eseguire il job;
c) Replicare e copiare file;
d) Monitorare lo stato di job, cancellare job;
e) recuperare l’output dei job finiti
4.
Computing element (CE): è la macchina che fa da server delle code di batch
come front-end al resto della grid; al CE è associato un cluster di nodi di
calcolo Worker Nodes (WN).
N. De Filippis, INFN Bari
n° 13
Componenti del sistema LCG (2)
5.
Storage element (SE): macchina che fornisce un accesso uniforme ed i
servizi per grandi spazi di storage: array di dischi, sistemi di storage di
massa.
6.
Resource Broker (RB): il RB è la macchina dove girano i servizi di
workload management che risolvono il matching fra le richieste del job di
un utente e le risorse disponibili, selezionando quelle più opportune per il
job.
7.
Replica Location Service (RLS) and Replica Manager: forniscono i
servizi e gli strumenti client di management dei dati; in ambiente grid, i file
di dati sono replicati in differenti siti e gli utenti o le applicazioni non hanno
bisogno di sapere dove sono localizzati i dati.
8.
Software installation: l’esigenza di un ambiente software omogeneo per
gli esperimenti ad LHC ha portato alla creazione di una procedura di
installazione e di management del software tramite strumenti grid. Un
software manager per ogni esperimento è responsabile dell’installazione di
software specifico di experimento in tutti i siti LCG.
N. De Filippis, INFN Bari
n° 14
La farm CMS/GRID di Bari
Hardware:
Servizi:
1 server di batch (2 CPU 1.2 Ghz)
 25 WN (biproc. da 1.2 a 3.2 GHz)
 6 code (4 per grid 2 in locale)
 5 TB per i dati di Input/Output
 650 Gb per le home degli utenti
 Batch System: Torque
 Scheduler: Maui
 File access: RFIO e NFS
 Database server: MySQL
Sistema operativo:
Scientific Linux
N. De Filippis, INFN Bari
n° 15
Modello di calcolo di CMS in LCG
~PBytes/sec
Online System
~100 MBytes/sec
~20 TIPS
There are 100 “triggers” per second
Each triggered event is ~1 MByte in size
~622 Mbits/sec
or Air Freight (deprecated)
France Regional
Centre
SpecInt95 equivalents
Offline Processor Farm
There is a “bunch crossing” every 25 nsecs.
Tier 1
1 TIPS is approximately 25,000
Tier 0
Germany Regional
Centre
Italy Regional
Centre
~100 MBytes/sec
CERN Computer Centre
FermiLab ~4 TIPS
~622 Mbits/sec
Tier 2
Caltech
~1 TIPS
Tier2 Centre
Tier2 Centre
Tier2 Centre
Tier2 Centre
~1 TIPS ~1 TIPS ~1 TIPS ~1 TIPS
Bari
~622 Mbits/sec
Tier 3
Institute
Institute Institute
~0.25TIPS
Physics data cache
Institute
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
~1 MBytes/sec
Tier 4
Physicist workstations
N. De Filippis, INFN Bari
n° 16
L’esperienza di CMS in GRID
L’attivita del calcolo di CMS nel 2003-2005 è stata di:
a)
simulazione su larga scala di eventi di fisica a CMS con tecniche
Monte Carlo e simulazione dell’apparato sperimentale
c)
messa a punto degli strumenti di calcolo per la gestione dei dati attraverso step
successivi di complessità crescente: Data
d)
Messa a punto e test della intera catena
Challenges
di analisi che comprende:
 Ricostruzione degli eventi al Tier-0
 Data Management al Tier-0 e distribuzione ai Tier-1
 Trasferimento di campioni di dati ai Tier-2 dai Tier-1
 Analisi dei dati in real-time ai Tier-1 e Tier-2
 Analisi di utente finale di CMS per studi di fisica
Il
gruppo di Bari ha fortemente contribuito a tutti gli step.
N. De Filippis, INFN Bari
n° 17
Il Data Challenge 2004 – DC04
E’ stata una sperimentazione su larga scala dei modelli di calcolo e
analisi con 50 milioni di eventi simulati, corrispondenti a circa il 25 %
del numero di eventi acquisiti dall'apparato CMS in un mese (a LL):
 Pre-Challenge Production (PCP) nel 2003/2004
o Simulazione e digitizzazione di 70 milioni di eventi come
PCP
Digitization
input per il DC04
750K job, 3500 KSI2000, 700 K file,80 TB di dati
DC04
 2 milioni di eventi simulati a Bari
o Produzioni fatte su farm locali e via GRID-LCG (40 %)
 Data Challenge (DC04)
o Ricostruzione di dati per un periodo continuato a 25Hz
o Distribuzione dei dati ai siti Tier-1,Tier-2
Tier-1
Tier-2
25Hz
Reconstruction
Tier-0
Reco Data
Reco Data
o Analisi dei dati in siti remoti in real-time (Bari) Analysis
o Dimostrazione della fattibilità della catena (Bari)
N. De Filippis, INFN Bari
Generation
Simulation
Analysis
Tier-1
Reco Data
Analysis
Tier-2
n°Tier-2
18
Produzione di CMS in LCG: risultati
  2.6 Milions of events ( 10K job lunghi), 2TB data
 Efficienza globale tra il 70% ed il 90%
 La rate di failure variabile a causa di alcuni problemi:
 Non disponibilità dell’RLS poche volte, →la rate di failure dei job poteva
crescere sino al 25-30%
 Instabilità dovuta a errata configurazione di un sito, problemi di rete, problemi di
scheduler locale, failure dell’hardware con inefficienza totale di circa 5-10%
 Pochi % dovuti a failure dei servizi
 La rate di successo su LCG-1 era più bassa rispetto a CMS/LCG-0 (efficienza 
60%)
 minore controllo sui siti, minore supporto per siti e servizi (anche per Natale 2003)
 Difficoltà maggiori identificate nella configurazione dei siti
 Buone efficienze e condizioni stabili del sistema wrt con quelle dei challenges
precedenti
o che dimostravano la maturità del middleware e dei servizi, purchè un continuo e rapido
supporto fosse garantito dai fornitori del middleware e dagli amministratori di sito
N. De Filippis, INFN Bari
n° 19
La real-time analysis per il DC04
Goal della real-time analysis per il DC04:
dimostrare che i dati potevano essere analizzati non appena erano
trasferiti ai Tier-1 e misurare il ritardo temporale tra la ricostruzione al
Tier-0 e l’analisi ai Tier-1/Tier-2
stabilire la replica automatica di dati ai Tier-2 per l’analisi
valutare la robustezza del middleware LCG2 per l’analisi dei dati, i
successi, le failure ed i colli di bottiglia
Strategia:
Sviluppare dei codici per permettere la preparazione di job di analisi
e la sottomissione sincrona con l’arrivo dei dati (BARI)
Usare il Resource Broker e le risorse CMS in LCG-2 (Tier-1/2 in
Italia e Spagna)
N. De Filippis, INFN Bari
n° 20
DC04: Statistica temporale dei job
Analisi tTH eseguita su un campione mu03_W1mu
Tempo di
esecuzione totale
~ 7 minuti
Tempo di
esecuzione di
ORCA ~ 5 minuti
Tempo per copiare
i file di input e
output ~ 110
secondi
N. De Filippis, INFN Bari
Tempo di attesa dei
job sulla GRID ~ 2
min.
Overhead di
GRID
n° 21
DC04: Analisi della timeline
Il ritardo temporale tra la disponibilità al
Tier-0 di un file e l’analisi a PIC è stato
20 minuti in media. Il tempo minimo è
stato circa 5 minuti.
I contributi più importanti:
tempo di trasferimento del file dal Tier-0
al Tier-1 ~ 13 minuti in media.
tempo di replica dallo SE CASTOR al SE
disco ~ meno di 1 minuto.
tempo per la preparazione del job~ circa
1.5 minuti
il tempo per la sottomissione di job ~ 3 minuti
overhead di sottomissione del job dovuto alla grid è
~ 2 minuti
N. De Filippis, INFN Bari
n° 22
La real-time analysis: risultati
La real-time analysis è stata eseguita con successo ai Tier-1/2:
due settimane di running quasi continuo in Italia!
il numero totale di job sottomessi ~ 17500
la massima rate di eventi analizzati ~ 40 Hz
L’efficienza della grid è risultata più grande del 90 %
Il ritardo dalla ricostruzione dei dati al Tier-0 alla loro
analisi è stato di 20 minuti in media
La catena implementata ha soddisfatto i goal del DC04 della
distribuzione di file su larga scala in alcuni siti e la successiva
analisi.
N. De Filippis, INFN Bari
n° 23
L’analisi di utente finale
Esempi:
Ricerca del bosone di Higgs ad LHC
Ricerca di particelle supersimmetriche ad LHC
L’analisi consiste:
nell’eseguire dei codici di selezione su campioni di eventi
simulati o dati reali distribuiti in vari siti con job sottomessi
da una user interface (laptop) e che girano in remoto.
Nel recuperare i file di output ed eventualmente processarli
per estrarre le variabili fisiche di interesse
L’architettura attuale si basa sulle seguenti assunzioni:
I dati risiedono in siti remoti e al CERN
Cataloghi locali dei dati sono disponibili nei siti
Il software di CMS è disponibile sui siti remoti
Il gruppo di Bari sta contribuendo allo sviluppo degli
strumenti
di analisi di utente finale in GRID n° 24
N. De Filippis,
INFN Bari
Attività del gruppo di Bari
Il gruppo di Bari per l’analisi di utente finale sta
contribuendo a:
 sviluppo di strumenti di catalogazione dati
 sviluppo di strumenti di validazione dati
 sviluppo di strumenti di monitoraggio di job per
applicazioni generiche su grid in tempo reale
 sviluppo di stumenti di output management
N. De Filippis, INFN Bari
n° 25
Gli strumenti di data management
~100 MBytes/sec
 I dati sono spostati dal Tier 0 ai
CERN Computer Centre
Tier 1 e ai Tier 2 sites via PhEDEx
Tier 0
PhEDEx
France Regional
Centre
Germany
Regional Centre
Italy Regional
Centre (CNAF)
FermiLab
Tier 1
PhEDEx
ValidationTools
Tier 2
Bari Bologna LNL Padova
PubDB
Local
catalogues
 La validazione dei dati è eseguita alla fine del
trasferimento via ValidationTools (BARI)
 I dati sono pubblicati in un database locale, PubDB
N. De Filippis, INFN Bari
n° 26
Il flusso dei job di analisi di CMS
 L’utente fornisce:
 il nome del Dataset (runs,#event,..)
 codice di analisi
DataSet
Catalogue
(PubDB/RefDB)
UI
CRAB
Job submission tool
 CRAB ricerca ove risiedono i
dati interrogando i database
RefDB/ PubDB
 CRAB prepara, splitta e sottomette i
job al Resource Broker
 Il RB manda i job ai siti ove
risiedono i dati purchè il software di
CMS è installato
 CRAB recupera automaticamente
i file di output dei job
N. De Filippis, INFN Bari
Workload
Management
System
Resource Broker (RB)
XCMSI
Computing
Element
Storage
Element
Worker
node
n° 27
Conclusioni
 Le applicazioni di HEP sono funzionanti in ambiente distribuito; il
gruppo di Bari sta contribuendo alla attività di sviluppo e dei test
dei componenti di GRID e di quelli condivisi da CMS
 Tutti gli esperimenti LHC stanno usando le implementazioni di
molti progetti grid per i Data Challenge
o L’esempio di CMS:
 Produzione massiva di eventi simulati (LCG)
 L’intera catena di analisi è stata sperimentata con successo in LCG
 L’analisi distribuita di utente finale di CMS è funzionante ed è
usata dagli utenti reali:
50 utenti, 10 milioni di eventi analizzati, 10000 job sottomessi
 Scalabilità e prestazioni sono gli elementi chiave del sistema
N. De Filippis, INFN Bari
n° 28