GRID
per la fisica delle alte energie
Nicola De Filippis
Dipartimento di Fisica Dipartimento di Fisica dell’Università degli Studi e dell’Università degli Studi e del Politecnico di Bari e INFN del Politecnico di Bari e INFN
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
Sommario
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.
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.
Perchè GRID?
Che cosa è GRID?
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.
“ 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
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:
Fisica delle alte energie e degli acceleratori
Fisica teorica, calcoli su reticolo
Fisica del neutrino
Genomica
Scienze dei materiali
BARI
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.
1. CMS 2. ATLAS
3. LHCB
4. ALICE
I numeri per la HEP
Il passato al LEP: collisore e+e-
• Rivelatore: ALEPH
• Dati in 10 anni: qualche TB (1012Bytes)
• CPU: qualche centinaio al CERN
• utenti di analisi: 200
• Collaborazione 500 persone
Il presente ad LHC:collisore pp
• Rivelatore: CMS
• Dati in 1 anno: 1 PB (1015Bytes)
• CPU: 4000 CPU per il DAQ al CERN
• utenti di analisi: 1000
• Collaborazione: 1500 persone
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 LCG
LHC Computing Grid Project – LCG
Les Robertson – LCG Project Leader
CERN – European Organisation for Nuclear Research Geneva, Switzerland
LCG
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
LCG-2/EGEE-0 Status 24-09-2004
Total:
78 Sites
~9000 CPUs 6.5 PByte Total:
78 Sites
~9000 CPUs 6.5 PByte
BARI
UI JDL
Logging &
Bookkeeping (LB)
Resource Broker (RB)
Job Submission Service (JSS)
Storage Element (SE)
Computing Computing Element (CE) Element (CE)
Information Service (IS) Replica
Catalogue (RC)
Working Working Node (WN) Node (WN)
Componenti e flusso dei job in
LCG
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).
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.
La farm CMS/GRID di Bari
Hardware:
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
Servizi:
Batch System: Torque
Scheduler: Maui
File access: RFIO e NFS
Database server: MySQL
UI
OUTPUT/DATI
Griddisk.cmsfarm1.. GRID
CE
gridba2
WN
UI
Sistema operativo:
Scientific Linux
Tier2 Centre
~1 TIPS Online System
Offline Processor Farm
~20 TIPS
CERN Computer Centre
FermiLab ~4 TIPS France Regional
Centre Italy Regional
Centre Germany Regional
Centre
Institute Institute
Institute Institute
~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)
Tier2 Centre
~1 TIPS Tier2 Centre
~1 TIPS Tier2 Centre
~1 TIPS Caltech
~1 TIPS
~622 Mbits/sec
Tier 0 Tier 0 Tier 1
Tier 1
Tier 2 Tier 2
Tier 4 Tier 4
1 TIPS is approximately 25,000 SpecInt95 equivalents
Modello di calcolo di CMS in LCG
Tier 3 Tier 3
Bari
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 Challenges
d) Messa a punto e test della intera catena 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.
Pre-Challenge Production (PCP) nel 2003/2004
oSimulazione e digitizzazione di 70 milioni di eventi come input per il DC04
750K job, 3500 KSI2000, 700 K file,80 TB di dati
2 milioni di eventi simulati a Bari
oProduzioni fatte su farm locali e via GRID-LCG (40 %)
Data Challenge (DC04)
oRicostruzione di dati per un periodo continuato a 25Hz
oDistribuzione dei dati ai siti Tier-1,Tier-2
oAnalisi dei dati in siti remoti in real-time (Bari) oDimostrazione della fattibilità della catena (Bari)
PCP
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):
DC04 25Hz
Simulation Generation
Digitization
Tier-0
Tier-1
Reco Data
Tier-2 Tier-2
Reconstruction
Analysis
Reco Data
Tier-1
Analysis
Reco Data
Tier-2 Analysis
Il Data Challenge 2004 – DC04
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
Produzione di CMS in LCG: risultati
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)
La real-time analysis per il DC04
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 di attesa dei job sulla GRID ~ 2
min.
Overhead di GRID Tempo per copiare
i file di input e output ~ 110
secondi
il tempo per la sottomissione di job ~ 3 minuti
overhead di sottomissione del job dovuto alla grid è
~ 2 minuti
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
DC04: Analisi della timeline
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
Il ritardo dalla ricostruzione dei dati al Tier-0 alla loro analisi è stato di 20 minuti in media
L’efficienza della grid è risultata più grande del 90 %
La catena implementata ha soddisfatto i goal del DC04 della distribuzione di file su larga scala in alcuni siti e la successiva
analisi.
La real-time analysis: risultati
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
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
La validazione dei dati è eseguita alla fine del trasferimento via ValidationTools (BARI)
CERN Computer Centre
FermiLab
France Regional
Centre Italy Regional
Centre (CNAF) Germany
Regional Centre
~100 MBytes/sec
Bari
Tier 0 Tier 0
Tier 2
Tier 2 Bologna LNL Padova
Tier 1 Tier 1
PubDB
Local catalogues
ValidationTools
I dati sono spostati dal Tier 0 ai Tier 1 e ai Tier 2 sites via PhEDEx
I dati sono pubblicati in un database locale, PubDB
PhEDEx
PhEDEx
Gli strumenti di data management
Il flusso dei job di analisi di CMS
CRAB
Job submission tool
Computing Element
Storage
Resource Broker (RB)
UI
Workload Management
System
L’utente fornisce:
il nome del Dataset (runs,#event,..)
codice di analisi
DataSet Catalogue (PubDB/RefDB)
Worker node
XCMSI
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
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
