Il Computing di ATLAS IV – Test e Commissioning Gianpaolo Carlino Referaggio Computing LHC CNAF, 17/18 Gennaio 2008 Attività di computing in ATLAS nel 2007 Utilizzo delle risorse nei Tier-2 italiani Utilizzo delle risorse nei Tier-2 italiani Soluzioni di Storage nei Tier-2 italiani Soluzioni di Storage nei Tier-2 italiani Finanziamenti 2008 Finanziamenti 2008

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Attività di Commissioning del Computing nel 2007 in ATLAS Stato del computing estate 2007 Test autunno-inverno 2007 Conseguenze dei test

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Computing Operations fine 2007 Breve riassunto dei progressi negli ultimi mesi:  Fino a Luglio 2007 – situazione “complicata”  Estate 2007 – miglioramenti grazie a nuove versioni di DQ2 e del sistema di storage al CERN e al CNAF (Castor) e soprattutto all’attenzione continua sia in Atlas Italia che al CNAF  Autunno 2007 – test del sistema con risultati più che incoraggianti, passaggio a un nuovo sistema di storage al CNAF (STORM) Dei vari sistemi di cui si compone il computing di ATLAS, il sistema di distribuzione dei dati è quello che ha richiesto nell’ultimo periodo maggiori attività di sviluppo e test Necessità di garantire alta efficienza e velocità nella replica dei dati come previsto dal Computing Model

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Il sistema di Distributed Management (DDM) di ATLAS, Don Quijote (DQ2), implementa tutte le funzionalità previste dal Computing Model relative alla: Distribuzione di dati raw e ricostruiti, reali e simulati, tra i vari Tier  Distribuzione di dati raw e ricostruiti, reali e simulati, tra i vari Tier Il sistema, ha un’organizzazione basata sui datasets Il sistema, ha un’organizzazione basata sui datasets: Cataloghi di dataset centrali, suddivisi in vari DB per facilitare l’accesso  Cataloghi di dataset centrali, suddivisi in vari DB per facilitare l’accesso Dataset Repository, Dataset Content Catalog, Dataset Location Catalog, Dataset Subscription Catalog Cataloghi di file distribuiti (locali)  Cataloghi di file distribuiti (locali) mapping nome logico  nome fisico: LFC (LCG File Catalog) al Tier1 Trasferimento dei file attraverso il Sistema di Sottoscrizione:  T0  T1 e T1  T1 (trasferimenti tra clouds)  T1  T2 e T2  T1 (trasferimenti nella cloud) Sistema di Distribuzione dei Dati (DDM)

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio ASGCBNLCERNCNAFFZKLYONNGPICRALSARATRIUMF ASGC BNL CERN CNAF FZK LYON NG PIC RAL NIKHEF TRIUMF <25% no AODs consolidation within the cloud or/and replication was stopped to from 95+%90-95%80-90%25-60%60-80% % X Sistema di Distribuzione dei Dati (DDM) Distribuzione tra i Tier1 di AOD e NtupleDistribuzione tra i Tier1 di AOD e Ntuple Data Replication Period Feb – Jun 2007, DQ2 0.2 Data Replication Period Feb – Jun 2007, DQ2 0.2 Data Volume: datasets, 570+ Kfiles, 23+ TB Data Volume: datasets, 570+ Kfiles, 23+ TB Target: efficienza 100% Target: efficienza 100% Luglio 07 – incontro Referee ATLAS

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Sistema di Distribuzione dei Dati (DDM) Picchi di trasferimento al CNAF 8 agosto Eff. ~ 90% Throughput 17 MB/s 23 agosto Eff. ~ 95% Throughput 25 MB/s Throughput (MB/s) Data Transferred (GB) Agosto 07 – incontro Referee calcolo

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Sistema di Distribuzione dei Dati (DDM) Throughput (MB/s) Data Transferred (GB) trasferimento al CNAF - Agosto Eff. ~ 58% Miglioramento rispetto al passato ma molto ancora da migliorare. L’inefficienza è causa anche delle sorgenti Agosto 07 – incontro Referee calcolo

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Computing Operations – fine 2007 Test del sistema di distribuzione dei dati: 1.Functional Test: Simulazione del data flow previsto dal CM a basso rate  Obiettivo: replicare completamente i dataset alle cloud Definizione di un insieme di dataset di ~ 30 files di dimensioni variabiliDefinizione di un insieme di dataset di ~ 30 files di dimensioni variabili Trasferimenti T0  T1 e di seguito T1  T2 della cloud secondo lo share previsto dal Computing ModelTrasferimenti T0  T1 e di seguito T1  T2 della cloud secondo lo share previsto dal Computing Model CNAF ~10% del totale CNAF ~10% del totale ogni Tier2 italiano 25% dei dati del CNAF ogni Tier2 italiano 25% dei dati del CNAF Trasferimenti T1  T1 dei dati riprocessatiTrasferimenti T1  T1 dei dati riprocessati  Studio dell’efficienza dei trasferimenti in termini di numero di dataset replicati correttamente e velocità di arrivo dei file, numero di retry 2.T0 Throughput exercise: Test di throughput  Obiettivo: mantenere con stabilità i throughput di trasfermento tra il Cern e le clouds previsti dal Computing Model: T0   T1 = 1 GB/s T0   T1 = 1 GB/s T0  CNAF = 100 MB/s (2/3 su disco e 1/3 su nastro) T0  CNAF = 100 MB/s (2/3 su disco e 1/3 su nastro) 3.Run di cosmici M5  Trasferimento dei dati (RAW e ESD) al CNAF e nei Tier2 secondo le percentuali previste dal Computing Model

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio ASGCBNLCNAFFZKLYONNGDFPICRALSARATRIUMF ASGC BNL CNAF FZK LYON NDGF PIC RAL SARA TRIUMF ASGCBNLCNAFFZKLYONNDGFPICRALSARATRIUMF CERN Trasferimenti CERN  Tier-1s 100%, 90+%, 50%, less than 50%, of data transferred within 24h Functionl Test – Oct 2007 Trasferimenti Tier-1  Tier-1

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Functionl Test – Oct 2007 Total subscriptions Completed Transfers

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Total subscriptions Completed Transfers Functionl Test – Oct 2007 T2 italiani – efficienza 100%

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio M5 Cosmic Run – Oct/Nov 2007  2 settimane di Run  Detector integration la prima settimana e reale Data Taking nella seconda  Data sample totale (analizzabile): ~ 90 TB  RAW Data su Tape e ESD su Disco  No AOD o DPD  analisi effettuata sui RAW Data  Raw Data e ESD distribuiti in Dataset a tutti i Tier-1 secondo lo share previsto dal CM  Copia intera ad alcuni Tier-1 che ne hanno fatto richiesta (BNL, Lyon, Triumf)  Utilizzo degli end-point srm di produzione  Storm al CNAF  Test di integrazione. Da considerare come un Function Test  trasferimenti a basso throughput e non molto stabili  Solo RAW data per l’analisi  Tuttavia un buon test sull’efficienza del sistema di trasfermiento

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Site problem Backlog due to late data replication drom CERN Transfers not finished after 80h Completed transfers In completed transfers T0 – dataset subscription time T1 – last file transfer time M5 Cosmic Run – Oct/Nov 2007

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio M5 Cosmic Run – Oct/Nov 2007

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio T0 Export Exercise – Oct 2007 Obiettivi:  Throughput al 100% MoU  Come se la macchina operasse 24h/day ~ 1 GB/sec  MoU prevede 720 MB/sec  Operazioni completamente automatizzate senza intervento  Corretto share tra dati da inviare su tape (tipo RAW) e su disco (tipo AOD e ESD) In Italia:  Thoughput da sostenere con continuità 100 MB/s  Test del nuovo srm end-point per il disco (T0D1): STORM  Sviluppato interamente dall’INFN

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio T0 Export Exercise – Oct 2007 Obiettivo raggiunto ! Rate di ~ 1.2 GB/sec per un periodo prolungato con un set incompleto di Tier-1. Notevoli margini di sicurezza! MB/s MB/s GB

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio T0 Export Exercise – Oct 2007  Il Tier-0 e i Tier-1 multi esperimento hanno dimostrato di poter supportare l’attività contemporanea di due esperimenti: ATLAS e CMS  Test di attività contemporanea tra i 4 esperimenti LHC nel 2008: CCRC08

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio T0 Export Exercise – Oct 2007 Al CNAF:  Utilizzo del nuovo srm come disco T0D1: STORM  Castor come tape endpoint T1D0  Nel periodo ottobre si è superato, con continuità, il throughput previsto di 100 MB/s del ~ 50%  Capacità di gestire backlog  Efficienze medie superiori al 90%  Si è deciso di utilizzare STORM come srm definitivo a partire dal run di cosmici M5  Buoni risultati di Castor Tape ma efficienza ancora da migliorare 18 – 19 ottobre 19 – 20 ottobre MB/s MB/s

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio  I test della seconda parte del 2007 mostrano un deciso miglioramento delle performance del sistema di distribuzione e autorizzano ad essere fiduciosi sulla reperibilità dei dati per l’analisi nel Tier-1 e nei Tier-2 nel  Ovviamente bisogna dimostrare che questi risultati possono essere ottenuti con continuità e in presenza di molte attività concorrenti  Il risultato del T0 throughput test e del M5 cosmic run ha mostrato una buona affidabilità del nuovo srm STORM. Si è quindi deciso di metterlo definitivamente in produzione.  primo caso di srm 2 in produzione in Atlas  3 server gridftp, 10 server GPFS (130 TB), 2 server FE StoRM, 1 BE StoRM Computing Operations – fine 2007

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Migrazione da CASTOR (disk) a STORM  78 TB trasferiti per un totale di circa 1.5 M files  esclusi file corrotti o da archiviare su tape  Effettuata dal 16 al 23 Novembre  5 giorni (3,5 giorni effettivi), 1 giorno per controlli e preparazione del nuovo storage per l’entrata in produzione, 1 giorno per l’aggiornamento del catalogo  Trasferimenti effettuati utilizzando 12 diskservers con carico distribuito.  Throughput 300 MBps. Efficienza 100%. Esperienza con STORM Problemi riscontrati dall'entrata in produzione di StoRM di interesse comune perché STORM è il primo srm versione 2 in produzione e ha fatto esperienza di tutti i problemi connessi all’interazione con gli altri sistemi  Dal 23 Novembre STORM in produzione  fallimenti durante il trasferimento di files da altri siti verso StoRM dovuti ad incompatibilita' tra client e server: 1. FTS non crea la struttura di directories che avveniva a livello srm per srm1. Risolto Problemi nei trasferimenti con siti che hanno dCache come srm. File di default “volatili” per cui scomparivano dopo una breve lifetime (40h). Fix per dCache sarò disponibile a fine gennaio. Per il momento allungata la lifetime (4000h) dei file. Persi 10 kfiles. 3. Problemi con Ganga nell’accesso ai file in corso di risoluzione

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test dei canali FTS Test dei canali di trasfermiento FTS: CNAF  Tier-2 e Tier-2  CNAF Obiettivo: verifica della configurazione dei canali in modo da garantire il throughput di trasferimento previsto dal CM  Trasferimenti Tier-2  CNAF: File MC (RDO e HITS) prodotti nei Tier-2 e trasferiti nei Tier-1 per la ricostruzione e l’archivio  file da ~ 2 GB (jumbo files)  throughput previsto 10 / 20 MBps (normale, picco)  Trasferimenti CNAF  Tier-2: File AOD,TAG e DPD per l’analisi  file da ~ 1 GB  throughput previsto 15 / 30 MBps (normale, picco)  Parametri:  Numero di file paralleli per job FTS (10) e stream per file (5)  Timeouts  Retry (in realtà gestiti da DQ2) Test in corso, risultati preliminari Trasferimento Tier-2  CNAF (storm) Trasferimento Tier-2  CNAF (storm) throughput aggregato > 60 MBps throughput aggregato > 60 MBps normali condizioni di operazione del sito normali condizioni di operazione del sito Valore che soddisfa le nostre esigenze Valore che soddisfa le nostre esigenze Problemi con alcuni canali che danno risultati peggiori, da comprendere in collaborazione con il Tier-1 Problemi con alcuni canali che danno risultati peggiori, da comprendere in collaborazione con il Tier-1 sec Tempo di trasferimento dei file

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Uso delle risorse nei Tier-2 italiani

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Produzione in Italia Produzione in LCG Produzione in Italia gridsuccessfailureefficiency LCG % OSG % None % Nordugrid % total % Dettaglio Produzione nelle tre griglie Quota produzione LCG ~ 65%

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio gridsuccessfailureefficiency LCG % OSG % None % Nordugrid % total % number of jobs walltime

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 Milano Utilizzo Risorse 2007

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 Milano

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio core (34 fino a aprile) Tier-2 Napoli Utilizzo Risorse 2007

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 Napoli Utilizzo Risorse 2007 Miglioramento del rapporto CPU/Wall Time

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 Napoli

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 Roma I

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Efficienza dimunuita nel periodo luglio 07 a causa dei problemi legati ai numerosi upgrade del middleware GRID contenenti bachi Proto Tier-2 Frascati Utilizzo Risorse feb07 - gen08

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Proto Tier-2 Frascati

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio I Sistemi di Storage dei Tier-2 Italiani

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio  Throughput  Analisi: Throughput ~ 10 MB/s in lettura, trascurabile in scrittura Determinato considerando un tipico programma di analisi non particolarmente CPU consuming (elevato accesso ai dati). Accesso diretto ai dati senza passare per la LAN (dati su disco locale del WN) Determinato considerando un tipico programma di analisi non particolarmente CPU consuming (elevato accesso ai dati). Accesso diretto ai dati senza passare per la LAN (dati su disco locale del WN)  Simulazione: Throughput trascurabile (  10 KB/s)  Trasferimenti: Sottoscrizioni di dataset tra i Tier dell’ordine di ~10 MB/s e quindi compatibile con sistemi in grado di fornire 1 GB/s in lettura  Slot di analisi fine 2008: ~ 100 (50% dei core disponibili)  Volume di disco fine 2008 Tier-2 tipico: 100 TB  Dimensionamento WN – disk server:  Server con doppia connessione GE verso la LAN: ~ 2 · 100 MBps 20 core per disk server 20 core per disk server 5 disk server in totale 5 disk server in totale 1 server ogni ~ 20 TB 1 server ogni ~ 20 TB  Numero di accessi contemporanei ai dati non eccessivo soprattutto nell’ipotesi di distribuzione uniforme dei dati nel sistema di storage (garantita da DPM) Dimensionamento dello storage

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Infrastruttura hardware:  Sistemi più vecchi: DAS Dischi direttamente collegati al server Dischi direttamente collegati al server  Acquisti più recenti: SAN Separazione dischi-server Separazione dischi-server Collegamento diretto FC senza switch Collegamento diretto FC senza switch  Dischi SATA II 2.Interfaccia SRM: DPM  Protocolli di accesso: RFIO e gridFTP 3.Connessione di rete WN - Storage  Link 1 Gbps Attuale sistema di Storage in ATLAS RACK CPU RACK STORAGE 1 Gbps

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Collegamento FC a 4 Gbps per canale tra il controller e i server di front-end Controller 1 Controller 2 Gbps 4 Gbps FC 4 Gbps FC Gbps 2 x 1 Gbps Ethernet 2 x 1 Gbps Ethernet Doppiocollegamento Doppio collegamento a 1 Gbps Ethernet per server di front-end Switch Gigabit Ethernet Box dischi SATA, connessi via FC al controller Controller bicanale FC (eventualmente in configurazione ridondata configurazione ridondata ) Server di storage (front-end), dotati di scheda FC bicanale Attuale sistema di Storage in ATLAS Unità di storage. Adottata in tutti i Tier-2

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test dello storage in ATLAS Diversi tipi di test effettuati  Bonnie++  Test della capacità massima di throughput dei dischi, a livello di controller  Effettuato direttamente sui disk server  Netperf  Performance della connessione di rete tra i sistemi  Effettuate tra i WN e i disk server  Rfperf  Applicazione sviluppata ad hoc per il test delle performance dei trasferimenti di RFIO Scrittura da WN (memoria) a SE (disco) di file da 1 GB Scrittura da WN (memoria) a SE (disco) di file da 1 GB Rilettura da SE (disco) a WN (memoria) con simulazione di lettura di un file di analisi Rilettura da SE (disco) a WN (memoria) con simulazione di lettura di un file di analisi  Lettura parziale del file, con salto casuale del 30% degli eventi (assumendo 1 MB/evento) I test sono stati eseguiti in ciascun Tier2 della Federazione, ottenendo risultati simili

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test dello storage in ATLAS: Netperf  Vengono lanciati accessi concorrenti dai WN ad un SE con numero crescente di WN  Saturazione immediata della banda passante (1 Gbps)  I WN si dividono equamente la banda passante disponibile  Test rilevanti solo ai fini della configurazione di rete Mbps

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test dello storage in ATLAS: rfperf Numero di WN Gbps  Prova concreta del pattern di accesso ai dati dell’analisi, utilizza le lib di rfio  Rfperf legge e scrive n file da 1 GB dalla memoria di ciascun nodo verso un SE  Provato per diversi numeri di stream (2,4 e 8 file) dai WN  Stesse prestazioni in lettura e scrittura  Saturazione immediata e costante della rete: attualmente il collo di bottiglia è nella connessione a 1 Gbps agli SE Gbps

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test dello storage in ATLAS : BONNIE++  Test su singolo array, con uno o più processi concorrenti  Max ~110 MB/s in scrittura e ~130 MB/s in lettura  Lento peggiormanto delle performance in caso di accesso concorrente  Ad esempio un sistema di 3 array sarà in generale in grado di fornire ~240/300 MB/s  Sistema limitato dalla banda passante dei controller e dall’overhead della “testa”  Generalmente i costruttori dichiarano un throughput dell’intero sistema  1 GB/s nominale e  500 MB/s reale  Attenzione nel calibrare la quantità di storage nel singolo sistema

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Test di scalabilità in ATLAS  Test su DPM effettuati al Tier-2 di Atlas a Glasgow  Come nei nostri test, massimo rate per job di analisi 10 MB/s  Avendo a disposizione fino a 9 server di disco e 100 TB, si vuole verificare il throughput totale all’aumento del numero di client (job di analisi) Accesso allo storage effettuato con diverse modalità di RFIO (normale, buffered, streaming) Accesso allo storage effettuato con diverse modalità di RFIO (normale, buffered, streaming) Sia per lettura completa che parziale del file Sia per lettura completa che parziale del file  Switch di rete da 80 GB/s

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Sistema di Storage - Hardware L’infrastruttura hardware che riteniamo più adatta alle nostre esigenze è la SAN in una configurazione minimale senza switch  Soluzione già adottata da alcuni Tier-2 dal 2006 e attualmente da tutti SAN: connessione controller – disk server attraverso uno switch Fibre Channel Vantaggi SAN (A. Brunengo, 18/12, Padova):  failover sul disk server: diversi server possono vedere lo stesso volume e possono essere configurati per sopperire alla failure del singolo server  bilanciamento del carico: possono essere aggiunti volumi serviti dallo stesso disk server, o si possono spostare parte dei volumi di un controller su un altro (nuovo) disk server per scaricare i server attivi, il tutto senza muovere dati (modificando configurazioni della SAN o dei controller)  si può sostituire un disk server rotto con uno nuovo senza spostare dati (minore tempo di ripristino di funzionalita’)

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio SAN senza switch  Contenimento dei costi  Mantiene le principali caratteristiche della SAN con switch, grazie ai 2 canali FC di uscita dai contoller, seppur limitando la flessibilità A. Brunengo – 18/12 - Padova Ridondanza  Il CM di ATLAS prevede repliche dei dati nella cloud e tra le cloud. Non c’è quindi la necessità di estrema ridondanza dell’hardware  E’ sufficiente la connessione di ogni controller a due server, in caso di guasto del server principale lo storage ad esso associato potrà essere esportato dal secondo server attraverso una riconfigurazione del sistema  Il numero di server viene determinato solo dalle necessità di throughput Sistema di Storage - Hardware

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Attuale soluzione: DPM e file system locale  Esperienza di ATLAS: Semplicità di installazione (qualche problema iniziale dovuto alla migrazione dal classic SE) Semplicità di manutenzione e di operazione (aggiunta file system, creazione pool) Supporto tempestivo e buona documentazione Larga esperienza nei siti italiani Scalabilità verificata per il volume di storage tipico dei Tier-2 italiani nel 2008  Possibili problemi: Meno flessibile nel bilanciamento del carico Scalabilità da verificare per volumi maggiori Sistema di Storage – SRM

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Possibile migrazione verso STORM/GPFS  GPFS  file system che aggrega diversi dischi potenzialmente connessi a diversi server in un unico file system Aumento del throughput tramite lo striping dei file che parallelizza l’accesso su più server il file system e’ espandibile/riducibile dinamicamente tramite aggiunta o rimozione di dischi (con migrazione automatica dei pezzi di file) ogni file system e’ montabile direttamente da tutti i WN del cluster, ed accessibile tramite chiamate standard posix. Rischio di rendere inaccessibile l’intero file system nel caso di perdita di un volume a causa dello striping Necessita corretta configurazione dei volumi e replica dei metadata Sviluppato dall’IBM, licenze sempre di tipo educational?  STORM  Implementazione SRM che sfrutta al meglio le caratteristiche di GPFS Bilanciamento del carico Gestione dinamica dei volumi Accesso ai dati in modalità file Sviluppato dall’INFN e utilizzato al Tier-1, garanzia di supporto Necessità che l’INFN continui a “credere” nel progetto Scarsa diffusione nel resto del mondo Sistema di Storage – SRM

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Rete: I Tier-2 di ATLAS devono potenziare la rete locale e passare ad una connessione a 10 Gbps tra i rack di WN e di storage 2.Hardware: la soluzione SAN soddisfa le richieste di throughput, di affidabilità e ridondanza.  Soluzione senza switch, non necessario per i nostri volumi di storage nel prossimo futuro. Ciò permette di non aumentare i costi e evita il problema della configurazione non banale del sistema  E’ possibile optare per sistemi di medio livello che garantiscono costi nel range previsto dall’INFN ma contemporaneamente la qualità di hardware e l’assistenza necessaria per un sistema cruciale come lo storage Le marche più importanti hanno prezzi mediamente molto alti  Accordo tra i siti per la scelta di questa soluzione 3.SRM: le performance di DPM ci soddisfano per cui non vi è urgenza per migrare a STORM/GPFS  Necessità di vedere il comportamento al Tier-1  Nell’ipotesi di un Tier-2 con volumi di storage sufficientemente alti possiamo organizzare test di scalabilità di DPM e test STORM nel primo semestre del 2008  Assenza di conoscenze specifiche nei Tier-2. In caso di migrazione a STORM/GPFS sarà fondamentale che l’INFN organizzi training nei Tier-2 e che vi sia una collaborazione molto stretta con il Tier-1 e il gruppo di storage del CCR Strategie di Storage di ATLAS

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Richieste Finanziarie

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Acquisti fine 2007 Tier-2 Na:  CPU: Cestello Blade da almeno 10 slot. 5 lame con processori dual quad core da almeno 70 CInt06_Rate e 16 GB di RAM. Validità dell’offerta di 6 mesi in modo da completare il cestello con i prossimi finanziamenti. Spesa indicativa 20 k€.  Disco: completamento sistema IBM DS4700 (SATA2FC) costituito di 2 server dual quad core e 4 box di dischi da 500 GB (32 TB). Acquisto di 3 box di espansione con dischi da 750 TB (36 TB) e due server dual quad core. Spesa indicativa 55k€ Tier-2 Mi:  CPU: WN dual quad core con 16 GB di RAM per un totale di circa 250 CInt06_Rate. Spesa indicativa 18.5 K€  Disco: sistema SATA2FC da circa 25 TB. Spesa indicativa 30 k€. Tier-2 Roma1  CPU: 7 WN twin dual quad core (16 core per WN) Xeon 2.33 GHz Harpetown E5410 per un totale di 1200 CInt06_Rate. Spesa 37 k€. Ottimo acquisto grazie ad una contemporanea gara per grandi volumi di CPU al Cern. Metà della potenza di calcolo sarà destinata alle attività di calibrazione dei muoni.  Disco: sistema SATA2FC da 36 TB in Raid5 e 1 server dual quad core. Spesa 42 k€. Tier-2 LNF  CPU: Blade IBM HS21 con 2 lame con processori dual quad core 2.66 GHz. Spesa 8 k€  Disco: sistema SATA2FC Storagetek 6140 con 32 dischi da 1 TB. Spesa 35k€

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Risorse disponibili inizio 2008 CPUDisco I (kSI2k) II Tot inizi 2008 (kSI2k) I II – 2007 Totale inizio 2008 Milano CI06 ~ 50 kSI2k ~ TBr 27 TBn ~ 25 TBr ~ 20 TBn ~ 59 TBr ~ 47 TBn Napoli100 ~ 400 CI06 ~ 80 kSI2k ~ TBr 32 TBn ~ 36 TBr ~ 29 TBn ~ 76 TBr ~ 61 TBn Roma CI06 ~ 240 kSI2k ~ 240 (~ 130 cal) 30 TBr 24 TBn 36 TBr 29 TBn 66 TBr 53 TBn LNF CI06 ~ 40 kSI2k ~ TBr 12 TBn 32 TBr 26 TBn 48 TBr 38 TBn Tot401~ TBn104 TBn~ 200 TBn I – 2007 indica la totalità delle risorse disponibili nella prima parte del 2007, II – 2007 indica le risorse acquisite nella seconda parte del 2007 (soprattutto con lo sblocco del sub judice)I – 2007 indica la totalità delle risorse disponibili nella prima parte del 2007, II – 2007 indica le risorse acquisite nella seconda parte del 2007 (soprattutto con lo sblocco del sub judice) Sono state considerate le dismissioni di macchine obsolete o ad uso utenti locali (soprattutto storage)Sono state considerate le dismissioni di macchine obsolete o ad uso utenti locali (soprattutto storage) 1 CInt06_Rate = 0,2 kSI2k - 1 kSI2k = 5 CInt06_Rate1 CInt06_Rate = 0,2 kSI2k - 1 kSI2k = 5 CInt06_Rate

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Finanziamenti M€ in totale per ATLAS e CMS 1.5 M€ in totale per ATLAS e CMS ~ 1/3 s.j. da sbloccare = 225 k€ ~ 1/3 s.j. da sbloccare = 225 k€ 1/4 CPU = 45 k€ 1/4 CPU = 45 k€ 3/4 Disco = 180€, ~ 130 TBn 3/4 Disco = 180€, ~ 130 TBn Ipotesi I - Tier-2 (approvati) equivalenti Suddivisione tra i siti: Suddivisione tra i siti: 30% per Milano, Napoli e Roma1, ~40 TBn per sito 30% per Milano, Napoli e Roma1, ~40 TBn per sito 10% per Frascati 10% per Frascati I Tier-2 approvati avrebbero a disposizione circa 100 TBn ognuno I Tier-2 approvati avrebbero a disposizione circa 100 TBn ognuno Necessità di storage in base alle attività e allo sviluppo temporale indicato nella tabella: Necessità di storage in base alle attività e allo sviluppo temporale indicato nella tabella: II semestre: ~ 120 TBn, III semestre: ~280 TBn per sito II semestre: ~ 120 TBn, III semestre: ~280 TBn per sito senza considerare la sommabilità dello storage e che i dischi in uso sono quasi pieni. Lo sblocco del s.j. copre solo parzialmente le esigenze del II semestre. senza considerare la sommabilità dello storage e che i dischi in uso sono quasi pieni. Lo sblocco del s.j. copre solo parzialmente le esigenze del II semestre. Le necessità per il terzo semestre devono essere disponibili per l’estate e quindi gli acquisti concordati con sufficiente anticipo Le necessità per il terzo semestre devono essere disponibili per l’estate e quindi gli acquisti concordati con sufficiente anticipo Possibili variazioni delle percentuali CPU/disco o delle suddivisioni tra i siti per livellare le differenze. Per esempio acquisto soprattutto di storage a Roma1 Per esempio acquisto soprattutto di storage a Roma1 F. Forti – CSN1 09/07

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 pilota nel 2008 Ipotesi II - Tier-2 pilota E’ emersa la necessità (richiesta esplicita dei referee) che un Tier-2 sia dotato di maggiori risorse per testare la funzionalità delle soluzioni adottate al crescere del carico di lavoro. E’ da verificare soprattutto il sistema di storage SRM: DPM vs STORM/GPFS SRM: DPM vs STORM/GPFS Non possiamo testare le possibili scelte alternative di hardware Non possiamo testare le possibili scelte alternative di hardware Richiesta che vengano fatti dei test di scalabilità. Dopo le acquisizioni della prima tranche del 2008 ogni Tier-2 approvato avrebbe un volume di storage di ~100 TB. Dopo le acquisizioni della prima tranche del 2008 ogni Tier-2 approvato avrebbe un volume di storage di ~100 TB. In Atlas siti che adottano lo stesso sistema di storage dei Tier-2 italiani (Glasgow) hanno dimostrato la scalabilità e la buona funzionalità del sistema. In Atlas siti che adottano lo stesso sistema di storage dei Tier-2 italiani (Glasgow) hanno dimostrato la scalabilità e la buona funzionalità del sistema. E’ necessario quindi effettuare test su volumi maggiori. E’ necessario quindi effettuare test su volumi maggiori.

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Tier-2 pilota nel 2008 Possibile soluzione: Non riteniamo praticabile l’ipotesi di finanziare esclusivamente un Tier-2 Non riteniamo praticabile l’ipotesi di finanziare esclusivamente un Tier-2 Fornire ad un Tier-2 parte delle (notevoli) risorse di calcolo dismesse dal CNAF per i noti problemi di potenza frigorifera della sala calcolo ma non obsolete Fornire ad un Tier-2 parte delle (notevoli) risorse di calcolo dismesse dal CNAF per i noti problemi di potenza frigorifera della sala calcolo ma non obsolete Sbloccare una parte dei finanziamenti previsti per la seconda metà del 2008 per garantire una crescita significativa del volume di storage Sbloccare una parte dei finanziamenti previsti per la seconda metà del 2008 per garantire una crescita significativa del volume di storage Solo per il Tier-2 pilota e che non modifichi l’integrale Solo per il Tier-2 pilota e che non modifichi l’integrale La quantità di risorse di calcolo (e quindi rack) da installare dipenderà dal volume totale di storage a disposizione in modo da conservare il corretto bilanciamento CPU/dischi La quantità di risorse di calcolo (e quindi rack) da installare dipenderà dal volume totale di storage a disposizione in modo da conservare il corretto bilanciamento CPU/dischi Tale Tier-2 effettuerà nel primo semestre del 2008 i test significativi per definire l’architettura del sistema di storage e di rete da adottare Tale Tier-2 effettuerà nel primo semestre del 2008 i test significativi per definire l’architettura del sistema di storage e di rete da adottare Sito proposto: Milano Maggiore flessibilità infrastrutturale per ospitare un notevole aumento di risorse Maggiore flessibilità infrastrutturale per ospitare un notevole aumento di risorse Interesse del Servizio Calcolo Interesse del Servizio Calcolo

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 17/18 Gennaio Richiesta Sblocco Finanziamenti 2008  Nessuna variazione, rispetto a settembre, per Napoli, Roma1, Frascati: Na e Rm1 = 75 k€ Na e Rm1 = 75 k€ LNF = 25 k€ LNF = 25 k€  Richiesta per Milano di anticipo della parte prevista per la seconda parte del 2008 solo per lo storage: 50 K€ (s.j.08 assegnato a settembre) k€ (2/3 Atlas 2008) · 30% (quota Tier-2 Mi) · 3/4 (quota storage) = 50 k€ + ~90 k€ = ~140 k€ 50 K€ (s.j.08 assegnato a settembre) k€ (2/3 Atlas 2008) · 30% (quota Tier-2 Mi) · 3/4 (quota storage) = 50 k€ + ~ 90 k€ = ~140 k€ acquisto solo di storage corrispondente a circa 100 TBn che garantisce al sito un totale di 150 TBn per aprile acquisto solo di storage corrispondente a circa 100 TBn che garantisce al sito un totale di 150 TBn per aprile  Necessità di comprare switch a 10 Gbps prezzo modello medio (non Cisco) ~ 3.5 k€ prezzo modello medio (non Cisco) ~ 3.5 k€ uno switch per rack uno switch per rack 1 per Na (2 acquistati fine 2007) 1 per Na (2 acquistati fine 2007) 2 per Roma (uno già in possesso) 2 per Roma (uno già in possesso) 4 per Mi (4 rack da equipaggiare) 4 per Mi (4 rack da equipaggiare) 2 per LNF 2 per LNF Acquisti comuni tra i siti per materiale omogeneo proponiamo gare comuni tra i siti per ottimizzazione costi e tempi purché gli importi non superino i limiti oltre i quali è necessario fare gare europee (~220 k€ senza iva) proponiamo gare comuni tra i siti per ottimizzazione costi e tempi purché gli importi non superino i limiti oltre i quali è necessario fare gare europee (~220 k€ senza iva) Tier-2 pilota nel 2008