Diapositiva 1

Il Computing di ATLAS
Gianpaolo Carlino
CSN1
Roma, 2 Giugno 2008
•
Il Computing Challenge
• I Tier2
• Richieste finanziarie 2008
Attività Computing ATLAS
ATLAS ha svolto un’intensa attività di test nel 2008 sia nell’ambito del
CCRC08 (combinato con gli altri esperimenti) che indipendentemente:
FDR e CCRC08-1,5
 Febbraio 2008:
 FDR-1: simulazione dell’intera catena di software & computing
 CCRC08–1: test della distribuzione dei dati T0 T1  T2
 sosprattutto un test delle operazioni al Tier0, di funzionalità del sistema e di
installazione e configurazione di SRM 2.2
 Marzo-Aprile 2008:
 CCRC08-1.5: test di computing preparatori per il CCRC08-2
 ripetizione test di funzionalità e configurazione canali Tier1 Tier1
 Maggio 2008
 CCRC08-2: test intensivo di DDM, T0 T1  T2 e T0 T1  T1
 test di funzionalità e throughput
 metriche molto esigenti
 4 settimane di test con incremento graduale delle complessità dei test
 impossibilità a svolgere test di lunga durata; durante il weekend priorità per
cosmici e commissioning dei rivelatori.
 Giugno 2008
 FDR-2
 test delle procedure di validazione, ricostruzione e analisi distribuita dei dati
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
2
Il Computing Challenge in
ATLAS
• CCRC08 – Fase 1 (feb 08)
• CCRC08 – Fase 1,5 (mar-apr 08)
• CCRC08 – Fase 2 (mag 08)
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
3
FDR-1 e CCRC08-1
Febbraio 2008: FDR-1 (Week 1) e CCRC08-1 (Weeks 2-4)
 FDR-1: simulazione dell’intera catena di computing dall’online all’analisi
distribuita
 dati similati con physics mix a luminosità 1031
 Run 10 hrs @ 200 Hz dagli SFO
 Full Tier0 Operations: calibrazione, data quality, first pass
reconstruction, sottoscrizione e trasferimento ai Tier1.
Dell’intera catena ci si è concentrati soprattutto sulle operazioni al Tier0 che
hanno richiesto più tempo del previsto.
Inoltre limitata disponibilità dei dati mixati
 Setup dei site services di Atlas
 Test degli endpoint SRM 2.2
 definizione degli Space tokes, ACLs
 Configurazione canali FTS
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
4
FDR-1 e CCRC08-1
CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con
le operazioni degli altri esperimenti LHC.
FDR data exports (Week 2)
2 set di dati: day 1&2 (molti errori a causa
di problemi di certificazione interni al
Tier0) e day 3 (100% eff.)
“real” CCRC exercise (Week 3)
 dati prodotti con il load generator al
Tier0 di grandezze nominali da 300 MB a 3
GB (FDR data non sufficienti)
 Rump Up al rate nominale. Share come
da CM e MoU
Target 900 MBps sostenuto 24h
 Risultati relativamente buoni:
 Throughput 700 MBps per 2 giorni
 picchi di 1.1 GBps per alcune ore
 Debugging (utilissimo) delle
configurazioni dei Tier1
Replica dei dati nelle cloud (Week 4)
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
5
FDR-1 e CCRC08-1
CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con
le operazioni degli altri esperimenti LHC.
Weekly
Throughtput
2.1 GBps in uscita
dal CERN
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
6
FDR-1 e CCRC08-1
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
7
FDR-1 e CCRC08-1
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
8
FDR-1 e CCRC08-1
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
9
Attività di Commissioning del
Computing in ATLAS
• CCRC08 – Fase 1 (feb 08)
• CCRC08 – Fase 1,5 (mar-apr 08)
• CCRC08 – Fase 2 (mag 08)
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
10
CCRC08-1.5
 Il CCRC08-1 è stato un utilissimo esercizio per debuggare le operazioni al
Tier0, il sistema di distribuzione dei dati e le configurazioni dei siti (per la
prima volta si è usato in molti siti SRM2.2).
 Sono state rimandate alla fase 1.5 e 2:
 debugging approfondito delle configurazioni dei sistemi ai Tier1 e Tier2
 ripetizione dei test con i sistemi più stabili e richiedendo metriche
quantitative stringenti
 3 attività per il periodo pre CCRC-2:
 Tier0 processing e data distribution (ripetizione dei Functional Test e
dei Throughput Test) per tunare significativamente il sistema
 Trasferimenti incrociati tra i Tier1 per configurare i canali FTS
 Tier1 M5 data reprocessing
 job di test (250 files) per ogni cloud per testare le varie procedure. OK in
9/10 clouds.
 Produzione ai Tier2
Utilizzo in tutti i siti di SRM2.2. Test alla scala reale (necessità di spazio
disco, carente in tutti i siti). Test delle operazioni reali: shifts, comunicazioni
etc.
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
11
CCRC08-1.5
Functional Test di Aprile
1 settimana di trasferminenti al rate nominale, rispettando lo share tra i siti
del MoU (CNAF 5%) e il CM (AOD replicati in tutte le cloud su disco, RAW
data su tape, una copia nell’insieme dei Tier1, ESD su disco 2 copie nell’insieme
dei Tier1)
Per molti siti si è superata una
efficienza del 95% richiesta come
metrica di successo per il test.
Problemi:
• catalogazione doppia degli eventi in
LFC (suspicious datasets). Baco in DDM
per cui non vengono catalogati dataset
effettivamente trasferiti e viene quindi
ripetuto il trasferimento
• problema ai disk server del CERN
perché il load generator generava troppi
file molto piccoli per cui alcuni dati si
sono persi e non sono stati trasferiti
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
12
CCRC08-1.5
 Reprocessing dei dati M5 al CNAF
 Attività primaria per un Tier1 effettuato su un subset dei dati M5
 Un dataset di 250 job per Tier1 (5 TB)


Conditions data su disco, 250 files, 35 input files per job
Output su disco (Storm) e archiviato su nastro
 Esercizio di:
1. stage dei file da tape (mai provato prima in Atlas) e copia su WN
2. lettura file di input (conditions data) residenti su disco (Storm)
3. sottomissione dei job con il sistema dei pilot (prima applicazione in Italia)
 Efficienza 93% (con 60 retries). Durata 27 h. Durata singolo job ~ 60 min.
 Attività da ripetere dopo il CCRC08-2.
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
13
Attività di Commissioning del
Computing in ATLAS
• CCRC08 – Fase 1 (feb 08)
• CCRC08 – Fase 1,5 (mar-apr 08)
• CCRC08 – Fase 2 (mag 08)
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
14
CCRC08 - 2
W
E
E
K
DDM Functional Test (FT)
L
Studio dell’efficienza del sistema di trasferimento dei dati
Trasferimenti Tier0  Tier1s
M
M
G
V
I
W
E
E
K
II
W
E
E
K
III
S
D
L
M
M
G
V
S
D
L
M
M
G
V
E
M
IV
Dataset sottoscritti agli endpoint Tape e Disk secondo gli share MoU
 RAW data su Tape – CNAF 5%
 ESD su Disk nei siti che ospitano i corrispondenti RAW –
CNAF 5%
D
L
K
Dati prodotti con il load generator al Tier0 corrispondenti al 40% del
nominal rate per 3 giorni
S
W
E
Nessuna attività nei Tier2
M
G
V
S
D
CNAF, 20 Giugno 2008
 in preparazione al T1-T1 della Week 2
 AOD sottoscritti completamente a tutti i Tier1
Metrica
Replica completa al 90% dei dataset sottoscritti
Replica dei dataset completata in 48h dalla sottoscrizione
G. Carlino: Il Computing di ATLAS
15
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
W
L
E
M
E
K
IV
CNAF
(97% complete)
Test superato da
tutti i Tier1 Atlas e
dal CNAF
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
16
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
M
G
V
S
D
L
M
G
V
Nessuna attività nei Tier2
S
D
L
 Replica degli ESD della Week 1 da ogni Tier1 a tutti gli altri
 ESD su disco (T0D1), non precisamente la configurazione finale del
reprocessing (T1D1)
M
M
G
V
S
D
E
M
IV
Studio dell’efficienza del sistema di distribuzione dei dati simulando
il trasferimento dei dati prodotti nel reprocessing
(Tier1-Tier1 transfer matrix)
M
L
K
Trasferimenti incrociati Tier1s  Tier1s
M
W
E
Tier1-Tier1 test (T1T1)
L
M
G
 Ripetizione in scala maggiore del test effettuato da tutti i Tier1 in
Marzo-Aprile: 10 siti attivi contemporaneamente in ingresso e uscita
Test delle configurazioni dei canali FTS
V
S
D
 Sito sorgente sempre definito (nessun trasferimento caotico)
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
17
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
M
G
V
S
D
L
M
M
G
V
S
D
M
M
G
S
D
E
M
IV
Throughtput:
 90 MB/s import rate per ogni Tier1. Superiore al rate nominale
V
L
K
Volume di dati:
 629 datasets corrispondenti a 18TB di dati da replicare in ogni
Tier1
L
W
E
Timing:
 definizione molto attenta dell’inizio e della fine del test: inizio
alle 10AM del 13 Maggio e fine alle 2 PM del 15 Maggio
 Le sottoscrizioni partono contemporaneamente per tutti i Tier1
 verifica della capacità del sistema di reggere un boost
improvviso di richieste
M
G
Metrica
Per ogni canale (Tier1-Tier1 pair) il 90% dei dataset deve essere
completamente replicato nel tempo definito
V
S
D
CNAF, 20 Giugno 2008
Test molto challanging!!
G. Carlino: Il Computing di ATLAS
18
CCRC08 - 2
E
E
K
I
W
E
E
K
II
W
E
E
K
III
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
L
E
M
K
IV
All days
All days (errors)
D
W
E
DAY1
L
MB/s
W
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
19
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
G
V
S
0%
M
M
20%
G
V
S
D
40%
L
M
M
G
60%
V
S
D
E
M
IV
= Not Relevant
L
L
K
FROM
D
W
E
Frazione di dataset completati
M
80%
M
100%
G
V
S
TO
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
20
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
W
L
E
M
E
K
IV
Attività concorrente con CMS sebbene non visualizzata in GridView!!!
I trasferimenti nei canali Tier1-Tier1 non sono ancora monitorati
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
21
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
M
M
G
V
S
D
M
G
V
S
D
L
M
M
 I test effettuati in aprile erano riusciti: efficienza ~ 100% e alto
throughput. Il fatto che coinvolgevano solo 3 Tier1 a6lla volta e non era
previsto flusso di uscita ha mascherato alcuni problemi nella configurzione.
G
V
S
D
E
M
IV
Al CNAF: bassa efficienza nell’import da molti siti !
Efficienza media 45% e throughput medio 40 MBps
M
L
K
Il test è stato superato dalla gran parte dei canali dei Tier1
 efficienze ~ 99% e picchi di throughput di 500 MBps (bulk of data,
16 TB, trasferito in sole 4 ore) in alcuni siti
L
W
E
Analisi dei Risultati:
L
M
G
V
S
D
Problemi individuati:
 Alto carico sui server GridFTP: traffico in uscita dai server doppio di
quello in ingresso dovuto alla riscrittura dello stesso dato. Ciò limita il
traffico in ingresso
 Problema legato all’interazione tra GridFTP e GPFS (differenza nella
block-size, 64 kB vs 1 MB). Si manifesta quando il numero delle stream/file
sui canali FTS è maggiore del numero di server GPFS.
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
22
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
M
G
V
S
D
L
M
M
G
V
S
D
M
M
G
V
S
D
L
E
M
K
IV
1. Riduzione del numero di stream/file sul sever FTS del CNAF al
numero di server GPFS (4). Ciò però limita il throughput (necessario
aumentare di molto il numero di file concorrenti)
2. Aumentati a 6 i server GridFTP per distribuire meglio il carico
Risoluzione parziale: nessuna riscrittura ma sempre basso throughput
L
W
E
Risoluzione dei problemi:
M
G
 È stato prolungata di due giorni la durata del test recuperando parte
del backlog
 È stato effettuato un nuovo test T1T1 autonomamente nel fine
settimana con buoni risultati.
 Problema di efficienza superato. Da verificare la capacità di
effettuare trasferimenti ad alto throughput (Week 3)
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
23
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
W
L
E
M
E
K
IV
Throughput comunque limitato nei due giorni successivi
alla fine del test anche in assenza di attività
contemporanea negli altri siti.
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
24
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
L
DDM Throughput Test (TT)
M
M
Trasferimenti ad alto rate Tier0  Tier1  Tier2
G
V
S
Simulazione dell’export dei dati dal Tier0 per 24h/day
di data taking a 200 Hz
D
L
M
M
G
V
S
D
L
M
~ 150% del nominal rate di 14h/day
No Oversubscription per aumentare il throughput. Se non si ha alta
efficienza (>90%) non si raggiunge il rate nominale
M
E
G
K
V
S
III
W
E
E
K
D
L
M
M
G
Metrica
Ogni sito deve essere in grado di sostenere il peak rate per
almeno 24 ore e il nominal rate per 3 giorni
V
S
IV
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
25
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
M
M
G
D
L
M
M
G
V
S
D
L
M
M
K
V
S
E
E
K
DISK
Total
BNL
79.63
218.98
298.61
IN2P3
47.78
79.63
127.41
SARA
47.78
79.63
127.41
RAL
31.85
59.72
91.57
FZK
31.85
59.72
91.57
CNAF
15.93
39.81
55.74
ASGC
15.93
39.81
55.74
PIC
15.93
39.81
55.74
NDGF
15.93
39.81
55.74
TRIUMF
15.93
39.81
55.74
Sum
318.5
696.8
1015.3
S
G
W
Rates(MB/s) TAPE
V
E
III
Rate Attesi
L
D
L
M
CNAF share del 5%
corrispondente a
56 MBps
M
G
V
S
IV
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
26
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
L
Data transfer complessivo
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
E
G
K
V
S
III
W
E
E
K
D
L
M
M
G
V
S
IV
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
27
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
L
M
M
G
PEAK
V
S
D
NOMINAL
L
M
M
G
V
S
D
L
M
M
E
G
K
V
ERRORS
S
III
W
E
E
K
D
L
M
M
G
V
S
IV
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
28
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
M
M
G
V
S
M
M
G
V
S
D
L
M
M
G
V
S
E
E
K
D
L
M
M
G
V
S
IV
Al CNAF:
L
K
W
Il test è stato superato:
 si è sostenuto il rate di picco per 24h e il rate nominale per 72h
D
E
III
Analisi dei Risultati:
L
D
Il test è stato parzialmente superato
 Trasferimenti sempre lenti
 Non si è riusciti a superare il rate nominale, in caso di backlog
determinato da periodi di inefficienze alla sorgente o alla
destinazione non si riusciva ad “accelerare” i trasferimenti (come
succede agli altri siti) per recuperarlo
Problemi individuati:
 interazione tra GridFTP e GPFS a limitare il throughput
 Errata configurazione dello storage aggiuntivo (20 TB) da parte
degli installatori (un solo canale collegato) causa della lentezza di
trasferimenti.
Individuato solo alla fine della settimana
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
29
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
DDM Full Exercise
L
M
M
Simulazione dell’intero set di trasferimenti Tier0  Tier1,
Tier 1  Tier1, Tier1  Tier2
G
V
S
D
L
M
M
G
V
S
 Si considera il rate 14h/day di data taking
 Si considera il reprocessing a full rate (200 Hz)
 Primi due giorni: test di funzionalità
 Ultimi due giorni: test di throughput
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
I siti vengono “appesantiti” da un’alta sottomissione di job di
produzione MC nei Tier1 e Tier2.
• si aggiungono i trasferimenti MC tra Tier2 e Tier1
Metrica
Tier0  Tier1: 90% dei dataset completi in 6 ore dalla fine del test
Tier1  Tier1 (functional): 90% dei dataset completi in 6 ore
Tier1  Tier1 (throughput): mantenimento del rate di tasferimenti
del reprocessing Tier1 gemello previsto dal MoU per tutta la durata
del test (CNAF: 10 MBps di ESD e 20 MBps di AOD)
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
30
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
M
M
Load Generator at 100%,
NO RAW
Load Generator at 100%
T0
G
V
S
D
L
M
M
G
V
S
T1
D
T1
15% ESD, 15% AOD
L
M
M
10% ESD, 10% AOD
G
V
S
D
L
M
M
G
V
S
T2
T2
T2
T2
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
31
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
Tier0  Tier1
L
M
M
G
V
S
Test di backlog recovery
Primi dati generati in 12 ore
e sottoscritti in bulk
D
L
M
M
G
V
S
12h di backlog
recuperati in 90 minuti
in tutti i siti!
D
L
M
M
Risolti problemi di
throughput per
trasferimenti dal Tier0:
~ 200 MBps per 2h
G
V
S
D
L
M
Appena inizia il T1T1 il
Cnaf rallenta
~5 MBps da ogni sito
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
32
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
T0 T1s data distribution
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
Suspect Datasets
Datasets completi
(OK) ma con doppia
registrazione
M
G
V
S
D
L
M
M
Incomplete Datasets
Effetto del power-cut
al CERN Venerdi
mattina
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
33
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
M
M
Expected Rate
G
V
Tier0 Tier1
transfers
S
D
Problemi al load
generator il 27
L
M
M
G
Power-cut il 30
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
34
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
Tier1 - Tier1 transfer matrix
M
M
G
V
S
YELLOW boxes
Effetto del power-cut
DARK GREEN boxes
Double Registration problem
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
CNAF, 20 Giugno 2008
Grande miglioramento rispetto a Week2
G. Carlino: Il Computing di ATLAS
35
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
Produzione MC, in sovrapposizione alle altre attività
M
# running jobs
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
# jobs/day
M
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
36
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
Analisi dei Risultati:
M
M
G
V
S
D
L
M
M
Ogni sito ha superato il test:
 nonostante problemi di power cut al Cern e al load generator il
primo giorno
 nonostante il problema delle doppie sottoscrizioni
G
Al CNAF:
V
S
D
L
M
M
G
V
Il test (sia T0T1 che T1T1) è stato superato in extremis risolvendo il
problema della lentezza dei trasferimenti che causava il basso
throughput e la bassa efficienza (time-out dei job)
S
D
L
M
M
G
V
S
D
Risoluzione del problema:
 Upgrade dei server GridFTP a SLC4
 aumento a 256 kB della block size e quindi miglioramento del
problema delle riscritture
 aumento del numero di stream/file a 5
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
37
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G
V
S
 Aumento del throughput (fattore ~2) dopo le 13 del 29-5 per
l’upgrade a SLC4 dei server GridFTP
 Throughput medio 125 MBps e recupero molto veloce del
backlog
 Test superato in extremis
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
38
CCRC08 - 2
W
E
E
K
L
M
Attività nell’intero mese, incluendo sia CCRC che commissioning
M
G
V
S
I
W
E
E
K
II
W
E
D
L
M
M
G
V
S
D
L
M
M
E
G
K
V
CASTOR@CERN
stress tested
S
III
D
W
L
E
E
K
IV
ssd
M
M
G
V
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
39
CCRC08 - 2
W
E
E
K
L
M
G
V
S
I
W
E
E
K
II
W
E
D
L
M
M
G
V
D
L
M
M
G
K
V
S
III
D
W
L
E
K
IV
 Il sistema di distribuzione dei dati era uno degli item critici di Atlas e
destava preoccupazione negli utenti (scarsa fiducia sulla possibilità di
reperire i dati con velocità ed efficienza)
 Il commissioning di questo sistema ha focalizzato l’attenzione durante
le due fasi del CCRC
 Grande collaboriazione tra il gruppo ADC e le clouds
S
E
E
Considerazioni finali sul CCRC
M
M
M
G
V
 Il giudizio finale è positivo. È stato effettuto un debugging
approfondito delle configurazioni di tutte le parti del sistema testando,
ben oltre gli use cases previsti per il data taking 2008, tutti i tipi di
trasferimenti previsti dal Computing Model
 Efficienze e throughput molto alti !
Attività principali dei prossimi mesi:
 Test del reprocessing ai Tier1 e uso del tape
 Definizione precisa e test accurati della classe di storage T1D1 in
tutti i sti
S
D
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
40
CCRC08 - 2
W
E
E
K
M
M
G
V
S
I
W
E
E
K
II
W
E
D
L
M
M
G
V
S
D
L
M
M
E
G
K
V
S
III
D
W
L
E
E
K
IV
Il CCRC al CNAF
L
M
M
G
V
S
D
1. Configurazione: Il commissioning ha messo in evidenza che alcuni
aspetti del sistema di storage non erano perfettamente compresi e i
testi effettuati in precedenza non erano stati sufficientemente
accurati da evidenziarli
2. Operations e support: la stretta collaborazione tra esperimento e
Tier1 ha permesso di migliorare le strategie di supporto alle attività.
Necessità di automatizzare le procedure di controllo.
3. Il sistema è ancora poco robusto e richiede un’attenzione continua
Problemi ancora aperti:
 Interazione tra GridFTP e GPFS, bisogna approfondire le conoscenze
su GridFTP.
 T1D1. Test effettuati in LHCb permettono di essere confidenti
sull’uso di Storm per questa classe di storage. È necessario
effettuare test dedicati in collaborazione tra Atlas e il CNAF per
verificare che il sistema sia in grado di soddisfare le richieste
dell’esperimento
 Vero problema per i prossimi mesi: IL DISCO!!! Il ritardo
dell’acquisizione dei pledge 2008 mette l’esperimento in seria
difficoltà. Necessità di aumentare le attività ai Tier2
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
41
i Tier2
• partecipazione ai test CCRC e FDR-2
• le infrastrutture
• utilizzo delle risorse
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
42
Attività di Computing nei Tier2
Partecipazione dei Tier2 italiani al CCRC e al FDR
 Il Computing Model di ATLAS prevede che i Tier2 “interagiscano”
essenzialmente con il Tier1 della propria cloud dei quali sono satelliti.
• pro: modello molto agile e poco caotico
• contro: il Tier1 è un single point of failure
 CCRC-1&2 - test di distribuzione dei dati –
 i Tier2 hanno partecipato al test replicando i dati trasmessi al
CNAF dal Tier0
 studio dell’efficienza dei trasferimenti
 studio del timing dei trasferimenti
 FDR-2 – test dell’intera catena di computing e in particolare, per i
Tier2, del sistema di analisi distribuita
 studio dell’efficienza delle repliche dei dati necessari per l’analisi:
AOD e DPD
 studio della possibilità di accesso ai dati da parte degli utenti e
dell’utilizzo dei tool di analisi distribuita
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
43
Attività Computing ATLAS
CCRC-1,5 – Aprile 2008
Functional Tests:
Distribuzione dei dati secondo MoU:
25% per ogni Tier2
Efficienza dei Tier2 italiani: 100%.
Il test mostra che si possono ottenere ottimi
livelli di funzionalità per esercizi specifici di
breve durata. E’ necessario una grande
attenzione sullo stato dei siti.
Il target è raggiungere per lunghi tempi gli
stessi risultati e senza interventi umani.
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
44
CCRC08 - 2
W
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
L
M
Tier0  Tier1  Tier2
Oversubscription a Na e Rm: 100% AOD
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
G

Files
LNF
86
169
100%
2.64
MI
88
180
100%
2.88
NA
395
794
100%
12,02
RM
395
794
100%
12,02
S
D
L
M
M
G
V
S
D
CSN1, Roma, 2 Luglio 2008
Thr.

Dataset
V
G. Carlino: Il Computing di ATLAS
Eff
MB/s
45
CCRC08 - 2
E
E
K
I
W
E
E
K
II
W
E
E
K
III
W
E
E
K
IV
M
Throughput: Time structure nei trasferimenti.
I Dataset vengono sottoscritti dopo che la replica completa al Tier1, ogni 4h.
M
MB/s
W
L
G
V
S
D
L
M
M
G
V
S
D
L
I Tier2 acquisiscono i dati molto velocemente: max 1.5h dalla richiesta di
sottoscrizione e max 0.5h per completare un dataset
M
M
G
V
S
D
L
M
M
G
V
S
D
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
46
CCRC08 - 2
E
E
K
I
W
E
E
K
II
W
E
M
M
G
V
S
D
L
M
M
G
V
S
D
L
M
M
E
G
K
V
S
III
W
E
E
K
Affidabilità del Tier2: Recupero immediato del backlog
• Esempio: interruzione dei trasferimenti a NA per la scadenza del
certificato del DPM.
• Recupero dei dati in 30 min con un throughput di 100 MBps
D
Errori
W
L
L
M
M
G
V
S
IV
D
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
47
FDR - 2
Lo scopo è testare l’intero computing system come se si trattasse di dati reali per
trovare in tempo i problemi che si potrebbero verificare durante il data taking
Esercizio completo dell’intera catena, dall’on-line/trigger all’analisi distribuita,
per integrare i test svolti fino ad ora in modo indipendente:
 Simulazione di 1 fill di presa dati
 4 Run di 1 hr a 1032 e 250 Hz, 350 nb-1, con configurazioni diverse, ripetuti più volte
 Dati MC pesati con le corrette sezioni d’urto
 Immissione dei dati nel TDAQ e running a partire dagli SFO
 5 physics stream: mu, e/gamma, multijets, Bphys, minbias + Express stream e
calibrazioni
 Completo utilizzo del Tier-0
 merging, scrittura su tape, ricostruzione, calibrazione, validazione etc
 i dati vengono ricostruiti e validati sulla ES per verificare la qualità dei dati. Meeting
di sign-off alle 4 pm per autorizzare la replica dei dati
 Bulk reconstruction sulle physics stream
 vari problemi di merging e ricostruzione,
 Esecuzione del Computing Model in maniera completa
 distribuzione dei dati e analisi distribuita
 Simulazione MC completa in parallelo
 running ai Tier-2, trasferimento dati e ricostruzione ai Tier-1
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
48
FDR - 2
Distribuzione dei dati:
 Dati correttamente
ricostruiti pronti solo il
15-6 e trasferiti ai Tier1
e Tier2
 Richiesti 100% AOD e
DPD a NA e RM, 25% a
MI e LNF
 Efficienza 100%
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
49
FDR - 2
Analisi nei Tier2:
 Utilizzo esclusivo dei Tier2 italiani
 Test di accesso ai dati e running dei job di analisi con Ganga
 contributo fondamentale degli utenti italiani per debuggare Ganga e renderlo
utilizzabile su dpm (primo srm ad essere funzionante con le nuove release)
 possibilità di definire i siti o la cloud sui cui runnare
 soddisfazione degli utenti per la facilità e la velocità di utilizzo dopo il primo periodo
di training e configurazione.
 max 2h tra l’invio dei job, il recupero dell’output e l’analisi locale, nonostante la forte
competizione con la produzione MC
 efficienza dei job > 95%
 Strategie di analisi:
 produzione in grid di DPD di gruppo o utente dagli AOD e DPD primari prodotti
centralmente con i DPDMaker del gruppo di analisi
 analisi dei DPD localmente nei Tier2 di riferimento (ARANA)
 Gruppi di analisi coinvolti
 Susy, Top, Higgs, MS, Minimum Bias, Trigger
 Analisi preliminari
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
50
FDR - 2
Analisi del trigger nella muon stream:
Trigger
decision
@ EF
minbias
m10
jets
m20
m6 + Bphy
t25i
+
m40
m10
2m(10)(4)(6)
L1
L2
LVL1 selection
barrel + endcaps
EF
totalE
+
EtMiss
offline muon
(Muid)
MU6
MU10
MU11
MU20
MU40
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
muon pT (MeV)
51
FDR - 2
Tutte le analisi studiano preliminarmente la ricostruzione di Z e W
Di-m
invariant mass
Di-electron
invariant mass
Di-electron
invariant mass
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
52
FDR - 2
Analisi Susy nella stream e/gamma
ETMISS
PT 1ST jet
muon pT (MeV)
GeV/c
Lepton-neutrino
transverse mass
Milano, 30 Aprile 2008
GeV
G. Carlino: Il Computing di ATLAS
53
FDR - 2
Molteplicità di particelle cariche nella stream Minimum Bias
Etmiss Etsum
nella stream
e/gamma:
Milano, 30 Aprile 2008
G. Carlino: Il Computing di ATLAS
54
Stream di calibrazione dei m
100 Mm/day
40 Mm/day
Calibration center
CERN
 Stream dal LVL2 (10 kHz). Distribuzione in Italia a Roma, sito ufficiale per la
calibrazione degli MDT, e a Napoli per l’analisi, off-line, degli RPC


Canali FTS dedicati con il Tier0 per diminuire la latenza (non appesantisce la banda passante)
100 M ev/giorno, Event Size = 1 kB, Max bandwidth = 10 MBps


Spazio disco: 3 TB nel 2008 e 10 TB nel 2009
CPU: ~150 kSI2k
 Calibrazione entro 24h dalla presa dati
 Accesso e scrittura su DB Oracle. Replica del DB al Cern
 Risorse necessarie:
Milano, 30 Aprile 2008
G. Carlino: Il Computing di ATLAS
55
Stream di calibrazione dei m
FDR:
 43 M eventi analizzati al giorno (equivalenti a 6h di presa dati al giorno)
 Durata del test: 3 giorni
Distribuzione dei dati:


Trasferimento rapidissimo
 Pochi minuti dalla registrazione in
DDM
Lunghi tempi di attesa per le registrazioni
dei file nei cataloghi
 Problemi con i cataloghi centrali, ora
risolti, dovuti ad errori di accesso ai
cataloghi di NorduGrid
 Ritardo nelle registrazioni fino a 5h
 Soluzioni in fase di implementazione
Processamento dei dati:




Milano, 30 Aprile 2008
Splitting dei dati e produzione di ntuple
max 2h dopo il completamento dei dataset
Calibrazione dalle ntuple max 3h
Filling del DB locale e replica al Cern
I dati arrivati nei siti sono stati comunque
processati entro il termine di 24h a
partire dalla presa dati nonostante il
problema di registrazione
G. Carlino: Il Computing di ATLAS
56
Stream di calibrazione dei m
Database di calibrazione:
 Database locale Oracle nei siti di calibrazione
 Accesso delle applicazioni di calibrazione: OK

T0, RT, validazione
 Replica in linea dei dati al CERN: OK
 Monitoring del database (Roma) con Spotlight
 Ottimizzazione delle query parallele
 Numero di connessioni
 Dati inseriti durante FDR-2
 148 calibrazioni con tag FDR2
Milano, 30 Aprile 2008
G. Carlino: Il Computing di ATLAS
57
i Tier2
• partecipazione ai test CCRC e FDR-2
• muon calibration
• le infrastrutture
• utilizzo delle risorse
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
58
Il Tier-2 di Milano
La



Sala Macchine e gli spazi per il Tier-2
8 Rack per ATLAS, 5 parzialmente occupati
4 rack (2 per ogni sala) connessi con fibra a 10 Gbps
Spazio e risorse per altri rack eventualmente necessari
LOCALE
NON
DISPONIBILE
ZONA DI
PERTINENZA
TIER 2
CNAF, 20 Giugno 2008
LOCALE
UPS E
QUADRO
PARALLELO
CENTRALE
TERMICA
ZONA DI
PERTINENZA
TIER 2
LOCALE
IN FASE
DI ALL.
ZONA DI
PERTINENZA
TIER 2
G. Carlino: Il Computing di ATLAS
59
Il Tier-2 di Milano
Impianto elettrico:
 Gruppo di continutà da 200 KVA corrispondenti a 160 KW, autonomia 15’.
 Ordinato un gruppo elettrogeno da 400 KVA in esclusivo uso della sala macchine,
in grado di sopperire alle esigenze della parte elettrica e del sistema di
raffreddamento. Autonomia 11 ore.
Impianto termico:
 Il sistema di condizionamento realizzato per l’intera sala è costituito da due
chiller da 90 kW termici ognuno
 Modifiche al sistema di distribuzione dell’aria sono già previste per ottimizzarlo
Impianto Antincendio:
 Il sistema attualmente installato non copre tutte le zone previste, nel prossimo
anno è prevista la sua revisione e la sostituzione dell’estinguente attualmente non
più a norma
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
60
Il Tier-2 di Napoli
La strategia è di
suddividere il Tier2 nelle
due sale con connessioni
dirette a 10 Gbps
Sala ATLAS INFN
 Superficie 44 m2
4 Rack installati attualmente:
 Connessione tra i rack a 10 Gbps con
switch in cascata
Espansione fino a 10 Rack
 Impianti dimensionati per tale capacità
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
61
Il Tier-2 di Napoli
Sala PON SCoPE
 Superficie 120 m2
 Capacità 120 Rack. 10 Tier-2 a disposizione del Tier-2
 Il Tier-2 di ATLAS verrà ospitato in questa struttura usufruendo di
tutte le facilities di monitoraggio e intervento previste dal progetto
 In fase di installazione una connessione di rete costituita da 6 coppie
di fibre monomodali a 10 Gbps tra la sala SCoPE e il Tier2
 Stato di avanzamento dei
lavori (Giugno 2008)
 Disponibilità autunno 2008
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
62
Il Tier-2 di Napoli
Impianto Elettrico:
 Max potenza disponbile: 250 kW
 2 Gruppi di continuità da 60 kVA in parallelo. Autonomia a pieno carico 7’.
In corso installazione sistema di videosorveglianza
 Monitoraggio remoto dei parametri elettrici dell’armadio di zona
 Ad ogni rack arriva una linea elettrica trifase da 22KW
 Gruppo elettrogeno in comune con la sala SCoPE, verrà installato
entro la metà del 2008
Impianto termico:
 Chiller con capacità di raffreddamento di 90 kW, due compressori
indipendenti
 Rack autoraffreddanti RIMatrix della Rittal con potenza dichiarata
di 12kW espandibile a 20 KW modificando la temperatura e i flussi
dell’acqua
 Raffreddamento ambientale della sala garantito da due unità da 6 KW
Impianto Antincendio:
 Protezione dei rack
•
Centralina che attraverso una coppia di rivelatori per rack (in AND) attiva la scarica
all’interno dei rack stessi
 Protezione della sala
•
CNAF, 20 Giugno 2008
Analogo funzionamento ma i sensori sono distribuiti nella sala dove avviene la scarica
G. Carlino: Il Computing di ATLAS
63
Il Tier-2 di Roma1
Nuova sala disponibile da fine Novembre 2007
 Dimensione sala 60 m2 espandibile fino a oltre 120 m2
 4 rack disponibili per Atlas, connessi a 10 Gbps
 Capacità della sala: 14 rack con gli attuali impianti, fino a 21 modificando la rete
idraulica (progettata per questa eventualità)
Impianto termico:
 Rack autocondizionati ad acqua della Knuerr
 Max potenza per rack: 17kW
 2 chiller da 80 KW ognuno con doppia pompa indipendente
Impianto Elettrico:
 Max potenza disponibile: 360 KVA
 UPS da 120 KVA, un secondo simile in consegna a marzo 2008 con autonomia di 10’ a
pieno carico
Impianto Antincendio:
 Impianto a gas inerte che agisce sull'intera sala macchine e all’interno dei rack.
 Sensori posti sia nella sala che all’interno dei rack
 La centralina di controllo è situata all'interno della sala macchine e verrà collegata
con un sistema di allarmistica alla vigilanza dello stabile
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
64
Il proto Tier-2 di Frascati
 La sala che ospita attualmente il proto-Tier2 è situata al pian terreno di un edificio
a due piani che ospita il servizio di calcolo dei LNF, una libreria a nastro
dell’esperimento Kloe, il sistema informativo dell’INFN ed il POP GARR dell’area di
Frascati
 Superficie 97 m2.
 Il Tier-2 occupa attualmente due rack e può essere espanso con altri tre rack
 Può ospitare tranquillamente tutte le risorse previste per il 2008
Altri
experim
Sistema
Informativ
o
CALCOLO
Tier 2
Nastri
utenti
CNAF, 20 Giugno 2008
Kloe
Garr
G. Carlino: Il Computing di ATLAS
65
Il proto Tier-2 di Frascati
Impianto elettrico:
 Potenza attualmente necessaria: 15 kW (Atlas) + 40 kW (altre risorse)
 UPS da 160 KVA, autonomia 15’
 Gruppo elettrogeno da 120 kW in azione dopo un minuto
Impianto termico:
 L’impianto di raffredamento esistente e’ a circolazione d’acqua ricavato
deviando una parte del condizionamento di Dafne
Impianto Antincendio:
 Impianto a gas inerte (FM200) dimensionato tenendo conto della
destinazione d’uso e dimensione dei vari ambienti
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
66
i Tier2
• partecipazione ai test CCRC e FDR-2
• le infrastrutture
• utilizzo delle risorse
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
67
Reliability e Availability dei Tier2
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
68
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
07/06/2008
24/05/2008
10/05/2008
26/04/2008
12/04/2008
29/03/2008
15/03/2008
01/03/2008
16/02/2008
02/02/2008
2008
19/01/2008
Utilizzo Risorse
05/01/2008
22/12/2007
08/12/2007
24/11/2007
10/11/2007
27/10/2007
13/10/2007
29/09/2007
15/09/2007
01/09/2007
Usage (%)
Tier-2 Milano
Tier2 Milano Wall Time
Altre VO
Atlas
100
90
80
70
60
50
40
30
20
10
0
69
Tier-2 Milano
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
70
Tier-2 Napoli
Tier2 Napoli - Wall Time
Altre VO
Utilizzo Risorse
ATLAS
160
2008
140
120
Usage (d)
100
80
60 core (fino al 21-3)
60
72 core (fino 3-6)
40
160 core
20
0
1/1
0/ 0
7
1/9
/0 7
1/1
1/ 0
7
1/1
2/ 0
7
1/1
/0 8
1/2
/0 8
1/3
/0 8
1/4
/0 8
1/5
/0 8
1/6
/0 8
Tier2 Napoli - Wall Time
Altre VO
ATLAS
100
90
80
Usage (%)
70
60
50
40
30
20
10
0
1/9
/0 7
CNAF, 20 Giugno 2008
1/1
0/ 0
7
1/1
1/ 0
7
1/1
2/ 0
7
1/1
/0 8
1/2
/0 8
1/3
/0 8
1/4
/0 8
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
1/5
/0 8
1/6
/0 8
71
Tier-2 Napoli
CPU - WALL Time Ratio
ATLAS
Utilizzo Risorse
100
90
80
2008
70
(%)
60
50
40
Miglioramento del
30
20
rapporto CPU/Wall Time
10
08
01
/0
6/
20
08
01
/0
5/
20
08
01
/0
4/
20
08
01
/0
3/
20
08
01
/0
2/
20
08
01
/0
1/
20
07
01
/1
2/
20
07
01
/1
1/
20
07
01
/1
0/
20
01
/0
9/
20
07
0
Tier2 Napoli - CPU Time
Altre VO
ATLAS
100
90
80
Usage
70
60
50
40
30
20
10
0
1/9
/0 7
CNAF, 20 Giugno 2008
1/1
0/ 0
7
1/1
1/ 0
7
1/1
2/ 0
7
1/1
/0 8
1/2
/0 8
1/3
/0 8
1/4
/0 8
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
1/5
/0 8
1/6
/0 8
72
Tier-2 Napoli
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
73
Tier-2 Roma I
Utilizzo Risorse
2008
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
74
Tier-2 Roma I
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
75
Proto Tier-2 Frascati
Wall time
Utilizzo Risorse
Usage (%)
2008
CPU Time
120.00
100.00
80.00
Usage (%)
60.00
CNAF, 20 Giugno 2008
40.00
Atlas
20.00
Altre VO
0.00
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
76
Proto Tier-2 Frascati
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS IV – Test e Commissioning
77
I Tier2 Italiani
Considerazioni sui Tier2 italiani
 Affidabilità e robustezza
 Efficienza del 100% e velocità nel trasferimento dei dati dal CNAF 
garanzia di reperibilità dei dati per l’analisi
 I momenti di bassa attività sono legati soprattutto al rallentamento delle
attività dell’esperimento o a problemi nei servizi della cloud
 l’utilizzo da parte degli utenti italiani per l’analisi distribuita è in
significativa crescita
 Qualche difficoltà si è avuta nel passato negli upgrade del middleware. Per il
CCRC:
 SRM: passaggio alla v2.2 senza difficoltà
 SLC4: nessun problema nell’upgrade dei WN e dei server DPM
SRM:
 DPM estremamente affidabile e facile da gestire
 STORM, dubbi sul futuro del supporto e la capacità di scalare di DPM
(verificata in atlas almeno fino a 100 TB) consigliano di testarlo anche nei Tier2
 Test di STORM al Tier2 di Milano (vedi talk di F. Prelz)
 Tutorial al CNAF il 2 e 3 luglio con gli sviluppatori di STORM e gli esperti
di GPFS
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
78
Attività di Computing in Italia
• Nuovo sistema di produzione
• Benchmarking CPU
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
79
Produzione in Italia
Modifica del sistema di produzione nella cloud Italiana
Sottomissione con i Pilot Job
Utilizzo di PANDA, il tool usato per la produzione in OSG
 ultima cloud a “resistere” alla migrazione

Pilot job:
 sottomessione alla Grid di piccoli job (pilot job), praticamente equivalenti a
quelli da runnare
 invio attraverso un server centrale (Panda server) dei job reali ai pilot
 Sistema utilizzato solo per la produzione e non per l’analisi

Vantaggi:
 controllo maggiore sull’ordine di esecuzione dei job
 job con priorità maggiore vengono processati prima anche se arrivati dopo
 maggiore efficienza: non vengono inviati job verso nodi mal configurati. Solo il
pilot job muore
1.
2.
Installazione di un Panda Server al Cern
Attivazione di una pilot factory al CNAF che rimpiazza lo scheduler dei pilot con un
sistema più modulare interfacciato ai tool di LCG come WMS per la sottomissione
dei job (sviluppata soprattutto in Italia) e la Dashboard
Sistema operativo da aprile per la produzione MC e il reprocessing al CNAF
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
80
Produzione in Italia
Produzione in LCG
4,20%
4,20%
CNAF
LYON
RAL
FZK
TRIUMF
PIC
ASGC
SARA
NDGF
Dettaglio Produzione nelle tre griglie
grid
Success
failure
efficiency
LCG
3062205
1182560
72.1%
OSG
1559546
358364
81.3%
None
164476
254263
39.3%
Nordugrid
427524
45134
90.5%
total
5213751
1840321
73.9%
Quota produzione LCG ~ 65%
Produzione in Italia
17,97%
12,22%
48,91%
La produzione in Italia nel semestre è stata rallentata dal passaggio
10,76%
4,64%
CSN1, Roma, 2 Luglio 2008
BARI
CNAF
FRASCATI
LEGNARO
MILANO
NAPOLI
ROMA
G. Carlino: Il Computing di ATLAS
5,44%
81
Produzione in Italia
number of jobs
walltime
CSN1, Roma, 2 Luglio 2008
grid
success
failure
efficiency
LCG
3062205
1182560
72.1%
OSG
1559546
358364
81.3%
None
164476
254263
39.3%
Nordugrid
427524
45134
90.5%
total
5213751
1840321
73.9%
G. Carlino: Il Computing di ATLAS
82
Sistema di benchmark
La suite di benchmark di ATLAS
 Definizione di un sistema di benchmark per ATLAS, basato
sull’esecuzione delle applicazioni del software di esperimento
 Misura realistica della CPU utilizzata, attraverso l’utilizzo di task reali
 Possibilità di utilizzare questo benchmark per la determinazione dei
processori più adatti da acquistare
 Basato su una infrastruttura già esistente, potenziata per raccogliere le
informazioni di benchmark e presentarle in modo interattivo agli utenti
 Kit Validation

sviluppato per validare le installazioni del software (installazioni Grid e utente)

Invia i risultati dei test (informazioni sulle macchine: CPU type, CPU speed,
Memory size …) a un Web service
 Global Kit Validation portal
 I risultati dei test sono ottenuti effettuando un parsing dinamico dei
logfile
 I tempi di processamento sono ottenuti dai servizi del framework di ATLAS
 I test vengono effettuati tramite uno script che installa le release del
software di ATLAS ed è in grado di inviare più test concorrenti (utile
per test su macchine multi-CPU e multi-core)
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
83
Sistema di benchmark
Risultati dei test e summary table
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
84
Sistema di benchmark
 Applicazioni eseguite: Generazione, Simulazione, Digitizzazione e Ricostruzione.
 Si determina il power factor di vari processori confrontando i tempi di esecuzione
rispetto ad una macchina di riferimento
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
85
Sistema di benchmark
Test della memoria
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
86
Sistema di benchmark
Scaling tests (Intel 2 x dual-core)


CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
Tutti i task, eccetto per la
simulazione , peggiorano quando
si incrementa il numero di task
concorrenti nella stessa
macchina
Peggior valore a full load

-10.9% in ricostruzione
87
Sistema di benchmark
Scaling tests (AMD 2 x dual-core)


CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
Tutti i task, eccetto per la
simulazione , peggiorano quando
si incrementa il numero di task
concorrenti nella stessa
macchina
Peggior valore a full load

-3.5% in ricostruzione
88
Risorse nei Tier2 e
Richieste 2008
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
89
Risorse necessarie - dati
 LHC data taking
 50.000 sec @ 200 Hz  106 eventi/giorno
con 14h di data taking
 3·106 sec (6·108 eventi), corrispondenti a 2
mesi di data taking
 Cosmics data taking
 presa dati complementare a LHC
(~ 10 settimane)
 fino ad ora dati trasferiti al Tier1
su disco e on demand ai Tier2 ma
analisi su Castor soprattutto.
 Messa a punto recente di Ganga per
runnare sui RAW data su pressione
italiana  Analisi solo sui Tier2 (No
Tier1!!)
LHC - Storage @ Tier2
1.
2.
3.
4.
2 versioni complete di AOD
5 versioni di DPD (primari e
secondari)
Frazione di RAW (metà della quota
CNAF del 5%)
Frazione di ESD (metà della quota
CNAF del 10%)
Totale = ~350 TBn
Cosmics - Storage @ Tier2
1.
2.
RAW e ESD (replica per l’analisi
dei dati inviati al CNAF)
No AOD e DPD
3. e 4. per studi di performance dei rivelatori
RAW = 1.6 MB - AOD = 0.2 MB
ESD = 1 MB
- DPD = 0.02 MB
CNAF, 20 Giugno 2008
Totale = ~80 TBn
Stima effettutata in base ai dati raccolti nelle
week M6 e M7 supponendo circa il 10% in italia
G. Carlino: Il Computing di ATLAS
90
Risorse necessarie - Analisi
Uso delle risorse per gli utenti italiani
Bisogna trovare un modo per garantire l’uso delle risorse dei Tier-2 italiani alla
comunità italiana impedendo che le attività centrali di ATLAS o gli utenti non italiani le
usino in maniera predominante
1. Creazione di un gruppo atlas/it a livello di VO
Gennaio 08
2. Job Priority Mechanism:
• definizione di quote dedicate per le varie attività (p.es. produzione 50% e analisi 50%)
e i vari gruppi (atlas e atlas/it)
3. Fair-Share Mechanism per ottimizzare l’uso delle risorse
• bilanciamento temporale dell’uso delle risorse per impedire che rimangano inutilizzate
quando non viene utilizzata completamente la quota dedicata ad una precisa attività o a
un gruppo
Stato attule:
CPU: Il gruppo atlas/it è stato creato ma non è ancora operativo perché si è attesa
un unpgrade del WMS per la pubblicazione del sistema di priorità dei job
nell’information system. È ora possibile inserire il gruppo italiano nel sistema
fornendogli i privilegi nell’uso delle risorse dei Tier2
Disco: Lo spazio a disposizione per gli utenti nei Tier2 è del 27% secondo il CM.
Frazione di questo sarà dedicato agli utenti italiani e il resto come zona scratch per gli
altri utenti di atlas (discussione in corso in Atlas)
CNAF, 20 Giugno 2008
G. Carlino: Il Computing di ATLAS
91
Risorse necessarie - Analisi
 Analisi nei Tier2
 analisi caotica da parte degli utenti
 produzione di DnDP
 analisi di gruppo: prevista al Tier1. Utilizzo delle risorse dei Tier2
anche per analisi di gruppo
 presenza importante di italiani nei gruppi di fisica
 replica completa di AOD e DPD nei Tier2
Stato attuale:
 fino al 2007 uso marginale dei Tier2 per l’analisi
distribuita (ampia attività locale)
 grande collaborazione della comunità italiana con gli
sviluppatori per aumentare la semplicità di utilizzo,
l’efficienza, l’individuazione dei siti sui cui runnare in
GANGA
 risoluzione di problemi tecnici:
 accesso allo storage con srm Storm e DPM
 accesso ai RAW data e alla stream di calibrazione
 FDR-2: partecipazione di molti gruppi italiani
13 gruppi (Higgs, SUSY, MS, Top, Tau, Etmiss, Trigger)
 analisi nei Tier2 e uso di GANGA
 Alta efficienza (>95%), velocità di esecuzione e recupero
degli output
CNAF, 20 Giugno 2008
Utenti @ Tier2
1.
2.
3.
 utenti: 100
Disco: 1 TBn
CPU: 10 kSI2k
Totale = 100 TBn
e 1000 kSI2k
1. L’attività durante l’FDR ci autorizza
a considerare realistica questa stima
2. Stima di Atlas: 1.5 TBn
3. ~4 core
G. Carlino: Il Computing di ATLAS
92
Risorse necessarie - MC
June-Sept 08
10 TeV
Sept-Dec 08
10 TeV
Dec-Mar 09
14 TeV
total
Geant4
20M
25M
25M
70M
ATLFAST
70M
70M
70M
210M
total
90M
95M
95M
280M
Simulation time
kSI2k·s
Minimum Bias
300
QCD
700
W/Z, WH, Top
600
SuSy
1100
Higgs
700
B-physics
600
CNAF, Giugno 2008
 Il piano di produzione MC si basa
sulla disponibilità delle risorse. Non
tutte le nazioni hanno soddisfatto i
pledges ai Tier1 e Tier2
 La nostra strategia è di spostare la
produzione il più possibile ai Tier2 per
dedicare le risorse del CNAF
soprattutto al reprocessing
G. Carlino: Il Computing di ATLAS
93
Risorse necessarie - MC
Strategia di simulazione:
1. G4 Hits prodotti nei Tier2 e uploaded nei Tier1
2. Hits su T1D1
3. Digi, Pile-up e Reco al Tier1
4. 20% di RDO su disco
5. AOD esportati agli altri Tier1 e ai Tier2 della
cloud
6. AOD prodotti nelle altre cloud importati al
Tier1 e esportati ai Tier2 della cloud
7. DPD primari prodotti dagli AOD al Tier1 e
esportati ai Tier2 della cloud
HITS = 4 MB - ESD = 1 MB
RDO = 2 MB - AOD = 0.2 MB
Simulazione @ Tier2
1.
2.
3.
2 versioni di AOD
5 versioni di DPD
Tier2 buffer per il MC
per 2 settimane
Storage = ~ 150 TBn
CPU = ~ 500 kSI2k
Ricostruzione:
 Merging dei file di input (circa 10 RDO per job) al Tier1
 avviene soprattutto ai Tier1 perché richiede molti file di input da replicare ai Tier2
 I task vengono assegnati alla cloud, i job al Tier1 o ai Tier2 in base ad un criterio di
ranking che tiene conto del numero di slot disponibili, delle code e di un fattore di
peso, definito dalla cloud, che penalizza i Tier2 (maggiore è il peso peggiore è il rank
dei Tier2)
 Il tuning del peso permette di variare il rapporto reco/simu al Tier1 e ai Tier2
 In caso di necessità e di risorse disponibili possiamo aumentare il rapporto ai Tier2
CNAF, Giugno 2008
G. Carlino: Il Computing di ATLAS
94
Risorse necessarie - riepilogo
Attività
CSN1, Roma, 2 Luglio 2008
CPU
Disco
(kSI2k)
(TBn)
LHC data taking
350
Cosmics data taking
80
Simulazione
500
150
Utenti
1000
100
Totale
1500
680
G. Carlino: Il Computing di ATLAS
95
Risorse disponibili nei Tier2
CPU (kSI2k)
Disco (TBr)
Sep 07
Gen 08
Giu 08
Sep 07
Gen 08
Giu 08
LNF
41
101
169
16
48
63
Milano
128
214
343
34
84
140
Napoli
112
210
330
40
40
152
Roma
156
383
383
30
66
133
Tot
437
908
1225
120
238
488
100 (TBn)
198 (TBn)
407 (TBn)
 Sep 07 indica le risorse disponibili nella prima parte del 2007, Gen 08 indica le
risorse acquisite nella seconda parte del 2007 con lo sblocco del sub judice 2007,
Mag 08 indica le risorse acquisite o in fase di acquisizione con lo sblocco del primo
sub judice 2008
 1 CInt06_Rate = 0,2 kSI2k - 1 kSI2k = 5 CInt06_Rate
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
96
Richieste 2008
Costi
CPU: 0.16 K€/kSI2k
Disco: 1.1 K€/TBn
(kSI2k)
Nuove necessità 2008
1500
Risorse a Giugno 2008
1225
hp1
Richieste
300
50
hp2
Richieste
300
50


CPU
Disco
K€
Totale
TBn
K€
K€
470
520
570
300
330
380
680
200 (occupato)
210 (disponibile)
 Gli ultimi acquisti di storage sono in fase di installazione, vanno quindi considerati
totalmente disponibili per le nuove attività e sottratti alle richieste
 hp1 : richiesta della totalità dello storage necessario = 470 TBn


Si eccede il budget potenzialmente disponibile per Atlas (metà della tasca indivisa)
L’esperimento richiede che una parte delle risorse disponibili per il computing venga
destinata per l’acquisto di spare PS degli MDT
 hp2: richiesta di una frazione dello storage necessario = 300 TBn



Liberazione di gran parte dello spazio disco attualmente disponibile cancellando
gradualmente i dati attuali e conservando solo cosmici e dati FDR utili per l’analisi
La quota di 300 TBn corrisponde precisamente all’acquisto nei Tier2 di Mi, Na e RM1 di un
sistema di storage di 110 TBr e 4 disk server, simile a quello appena acquistato
Margine per la richiesta di 100 k€ per gli spare PS degli MDT
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
97
Richieste 2008
Ulteriori richieste:
 Switch di rete per il quarto rack a Napoli
 Si prevede l’acquisto di un quarto switch 3Com dello stesso tipo acquistato in
tutti i Tier2 per garantire la connessione a 10 Gbps tra i WN e lo Storage: 3.5 k€
 Consumo
 Richiesta di 3 k€ per ogni Tier2
CPU
Disco
Switch
Consumo
Totale
K€
K€
K€
kSI2k
K€
TBn
K€
LNF
30
5
30
30
3
38
Milano
90
15
90
100
3
118
Napoli
90
15
90
100
3
121.5
Roma
90
15
90
100
3
118
Tot
300
50
300
330
12
395.5
CSN1, Roma, 2 Luglio 2008
3.5
3.5
G. Carlino: Il Computing di ATLAS
98
Richieste 2008
Proposta dei Referee:





Nessuna assegnazione a Frascati
Stime necessita’ per LHC ridotte a 250 TBn invece di 350TBn, corrispondente a 2·106 s
Altre necessita’ come da richieste
Variazione stima dei costi: CPU 0.15 k€/kSI2k, Disco 1 k€/TBn
Consumi: utilizzo del sj assegnato a settembre (5 k€). Rm e LNF devono ancora chiedere
lo sblocco
CPU
Atlas
Disco
Referee
Atlas
Switch
Referee
Consumo
Tot
A
R
A
R
R
K€
K€
K€
K€
K€
kSI2k
K€
kSI2k
K€
TBn
K€
TBn
K€
LNF
30
5
0
0
30
30
0
0
3
0
0
Milano
90
15
100
15
90
100
90
90
3
0
105
Napoli
90
15
100
15
90
100
90
90
3
0
108.5
Roma
90
15
100
15
90
100
90
90
3
0
105
Tot
300
50
300
45
300
330
270
270
12
0
318.5
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
3.5
3.5
3,5
3,5
99
Acquisti - Mercato Elettronico
Esperienze con il MEPA
Atlas ha effettuato nel 2008 acquisti in comune tra 3 Tier2 con il Mercato Elettronico
 Storage: gara con fatturazione separata
 Switch: gara con fatturazione unica a Na e consegna nelle varie sedi

Problemi con il grey market. Sarebbe utile chiarire le procedure nell’INFN
Esperienza:
 Difficoltà iniziale a comprendere le nuove regole del MEPA anche a causa di
conoscenze ancora non diffuse nell’ente
 Difficoltà a definire contemporaneamente la precisa quantità di materiale da
acquistare e il relativo prezzo massimo
 Richiede un’indagine di mercato molto accurata
 Rischio che le gare vadano deserte
 Ritardi dovuti all’arbitrarietà con cui la Consip annulla gare in corso
 Gara switch annullata per inserire nuovo categoria di metaprodotto




Facilità a definire metaprodotti anche complicati
Velocizzazione delle procedure
Aumento dei fornitori iscritti
Grande aiuto e disponibiltà da parte dell’amministrazione di Napoli
CSN1, Roma, 2 Luglio 2008
G. Carlino: Il Computing di ATLAS
100