La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

N° 1 N. De Filippis, INFN Bari GRID per la fisica delle alte energie Nicola De Filippis Dipartimento di Fisica dellUniversità degli Studi e del Politecnico.

Presentazioni simili


Presentazione sul tema: "N° 1 N. De Filippis, INFN Bari GRID per la fisica delle alte energie Nicola De Filippis Dipartimento di Fisica dellUniversità degli Studi e del Politecnico."— Transcript della presentazione:

1 n° 1 N. De Filippis, INFN Bari GRID per la fisica delle alte energie Nicola De Filippis Dipartimento di Fisica dellUniversità degli Studi e del Politecnico di Bari e INFN

2 n° 2 N. De Filippis, INFN Bari I progetti GRID GRID per gli esperimenti HEP ad LHC Lesperienza di CMS in GRID: 1. Il Data challenge Lanalisi di utente finale Sommario

3 n° 3 N. De Filippis, INFN Bari 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.

4 n° 4 N. De Filippis, INFN Bari La fisica, lingegneria, lanalisi medica, le biotecnologie, linformatica, etc. procedono attraverso: orisorse di calcolo, sistemi di informazione e strumenti eterogenei; ole interazioni delle persone; otutte geograficamente e organizzativamente sparse. Lo scopo principale delle Grid : odi fornire un insieme di risorse di calcolo fisicamente distribuite in un numero di siti geograficamente separati, su scala mondiale; odi facilitare le interazioni di queste risorse. Perchè GRID?

5 n° 5 N. De Filippis, INFN Bari 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

6 n° 6 N. De Filippis, INFN Bari 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

7 n° 7 N. De Filippis, INFN 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

8 n° 8 N. De Filippis, INFN Bari I numeri per la HEP Il passato al LEP: collisore e + e - Rivelatore: ALEPH Dati in 10 anni: qualche TB (10 12 Bytes) 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 (10 15 Bytes) CPU: 4000 CPU per il DAQ al CERN utenti di analisi: 1000 Collaborazione: 1500 persone

9 n° 9 N. De Filippis, INFN Bari GRID per lHEP: 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 laccesso ai dati remoti in termini di velocità ed affidabilità Controllo sullaccesso 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 Larchitettura distribuita è necessaria e vitale LCG

10 n° 10 N. De Filippis, INFN Bari 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: lambiente di calcolo per analizzare i dati raccolti dai rivelatori ad LHC lambiente di sviluppo di applicazioni, strumenti comuni e framework GRID è solo uno strumento per raggiungere questo scopo

11 n° 11 N. De Filippis, INFN Bari LCG-2/EGEE-0 Status Total: 78 Sites ~9000 CPUs 6.5 PByte Total: 78 Sites ~9000 CPUs 6.5 PByte BARI

12 n° 12 N. De Filippis, INFN Bari UI JDL Logging & Bookkeeping (LB) Resource Broker (RB) Job Submission Service (JSS) Storage Element (SE) Computing Element (CE) Information Service (IS) Replica Catalogue (RC) Working Node (WN) Componenti e flusso dei job in LCG

13 n° 13 N. De Filippis, INFN Bari 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 lautenticazione tramite certificato utente in forma criptata. 3.UserInterface (UI): macchina dove lutente 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 lesecuzione 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 loutput 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).

14 n° 14 N. De Filippis, INFN Bari 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: lesigenza 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 dellinstallazione di software specifico di experimento in tutti i siti LCG.

15 n° 15 N. De Filippis, INFN Bari 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 Sistema operativo: Scientific Linux

16 n° 16 N. De Filippis, INFN Bari 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 Institute Institute ~0.25TIPS Physicist workstations ~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 Caltech ~1 TIPS ~622 Mbits/sec Tier 0 Tier 1 Tier 2 Tier 4 1 TIPS is approximately 25,000 SpecInt95 equivalents Modello di calcolo di CMS in LCG Tier 3 Bari

17 n° 17 N. De Filippis, INFN Bari Lesperienza di CMS in GRID Lattivita del calcolo di CMS nel è stata di: a) simulazione su larga scala di eventi di fisica a CMS con tecniche Monte Carlo e simulazione dellapparato 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.

18 n° 18 N. De Filippis, INFN Bari Pre-Challenge Production (PCP) nel 2003/2004 o Simulazione 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 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 o Analisi dei dati in siti remoti in real-time ( Bari ) o Dimostrazione 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 Reconstruction Analysis Reco Data Tier-1 Analysis Reco Data Tier-2 Analysis Il Data Challenge 2004 – DC04

19 n° 19 N. De Filippis, INFN Bari 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à dellRLS 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 dellhardware 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

20 n° 20 N. De Filippis, INFN Bari 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 lanalisi ai Tier-1/Tier-2 stabilire la replica automatica di dati ai Tier-2 per lanalisi valutare la robustezza del middleware LCG2 per lanalisi 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 larrivo 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

21 n° 21 N. De Filippis, INFN Bari 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

22 n° 22 N. De Filippis, INFN Bari 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 lanalisi 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

23 n° 23 N. De Filippis, INFN Bari 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 ~ 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 Lefficienza 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

24 n° 24 N. De Filippis, INFN Bari Lanalisi di utente finale Esempi: Ricerca del bosone di Higgs ad LHC Ricerca di particelle supersimmetriche ad LHC Lanalisi consiste: nelleseguire 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 Larchitettura 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

25 n° 25 N. De Filippis, INFN Bari Attività del gruppo di Bari Il gruppo di Bari per lanalisi 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

26 n° 26 N. De Filippis, INFN Bari 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 2 BolognaLNLPadova 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 Gli strumenti di data management

27 n° 27 N. De Filippis, INFN Bari Il flusso dei job di analisi di CMS CRAB Job submission tool Computing Element Storage Element Resource Broker (RB) UI Workload Management System Lutente 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

28 n° 28 N. De Filippis, INFN Bari 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 Lesempio di CMS: Produzione massiva di eventi simulati (LCG) Lintera catena di analisi è stata sperimentata con successo in LCG Lanalisi distribuita di utente finale di CMS è funzionante ed è usata dagli utenti reali: 50 utenti, 10 milioni di eventi analizzati, job sottomessi Scalabilità e prestazioni sono gli elementi chiave del sistema Conclusioni


Scaricare ppt "N° 1 N. De Filippis, INFN Bari GRID per la fisica delle alte energie Nicola De Filippis Dipartimento di Fisica dellUniversità degli Studi e del Politecnico."

Presentazioni simili


Annunci Google