Calcolo a LHC e proposte per Tier2 C. Bozzi, INFN Ferrara per il comitato di referaggio F. Bossi, C.B., R. Carlin, R. Ferrari, D. Lucchesi, D. Martello,

Presentazione sul tema: "Calcolo a LHC e proposte per Tier2 C. Bozzi, INFN Ferrara per il comitato di referaggio F. Bossi, C.B., R. Carlin, R. Ferrari, D. Lucchesi, D. Martello,"— Transcript della presentazione:

1 Calcolo a LHC e proposte per Tier2 C. Bozzi, INFN Ferrara per il comitato di referaggio F. Bossi, C.B., R. Carlin, R. Ferrari, D. Lucchesi, D. Martello, M. Morandin, M. Taiuti CSN1, 28 Gennaio 2008

2 Sommario Il quadro globale La situazione italiana Il piano per i Tier2 e le proposte di assegnazione

3 La griglia sta diventando realtà Infrastruttura più stabile, cresce l’utilizzo

4 Site reliability – CERN e Tier1 “Site Reliability” a function of grid services middleware site operations storage management systems networks........ Targets – CERN + Tier-1s Before July July 07Dec 07 Avg.last 3 months Each site88%91%93%89% 8 best sites 88%93%95%93%

5 Accounting a T1 e T2

6 Distribuzione dei dati dal CERN jan feb mar apr may jun jul aug sep oct Target 2008  Data distribution from CERN to Tier-1 sites  The target rate was achieved in 2006 under test conditions  In 2007 under more realistic experiment testing, reaching target peak rate with ATLAS and CMS active

7 Storage: le note dolenti… SRMv2 ha ritardato –conseguenze su interfacce sottostanti (dCache, CASTOR, dPM) –In produzione nei Tier1 –In propagazione verso i Tier2 –Test ancora limitati CASTOR2: we have a problem…

8 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 8 We have a real problem User complaints –Long stage-in time during challenges –Data on tape unavailable Low batch efficiency –Long queues waiting for tape data staging –CPU jobs waiting for tape data to be read High failure rate of robotics –Drives and robot arms require maintenance –Tapes are often disabled needing repair 8 Tim Bell@LCG MB 8 Jan 2008

9 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 9 Analysis Data collected during Nov/Dec 2007 –Distribution of file sizes on tape –Tape mounts and performance –Production tapes only (no user tapes) Root causes identified –Small file sizes –Repeated mounting 9 Tim Bell@LCG MB 8 Jan 2008

10 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 10 File size and performance 10 Tape drives need to stream at high speeds to achieve reasonable performance. Per-file overheads from tape marks lead to low data rates for small files LHC tape infrastructure sizing was based on 1-2GB files. AliceAtlasCMSLHCb 200 MB150 MB2200 MB200 MB Tim Bell@LCG MB 8 Jan 2008

11 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 11 Repeat Mounting 11 Tapes are being repeatedly mounted/unmounted. Takes around 4 minutes to mount a tape compared to 100 minutes to write a complete tape Increases wear/tear on robots and drives along with risk of tape media issues. Tim Bell@LCG MB 8 Jan 2008

12 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 12 Total performance to tape 12 Total performance is based on the sum of data transferred against the total time spent on drives (including mount unmount time). VOFile SizeMounting Overhead Alice  Atlas  CMS  LHCb  Planning was based on total performance of 50MB/s. Tim Bell@LCG MB 8 Jan 2008

13 CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it 13 Proposal Experiments should –Move to 2GB files for tape transfers –Ensure that pre-staging is standard for all applications Castor Operations will change policies for CCRC –Write policy of at least one tape of data with 8 hours maximum delay –Limit mounting for reads unless at least 10GB or 10 files requested for each read mount or if a request is 8 hours old Monitor February CCRC performance and cover shortfall with –Major drive purchases and dedication for experiments Fixed budget! Implies reduction in CPU/disk capacity 13 Tim Bell@LCG MB 8 Jan 2008

14 Punti salienti Maggiore stabilità e utilizzo della griglia –Prevalentemente in produzione –Il modello di analisi va ancora testato su larga scala Accounting migliorato Middleware: funzionalità basilari OK. –Si pensa alla stabilità –Preoccupazione per EGEEIII Tagli pesanti nello sviluppo del middleware e nel supporto alle applicazioni. Nessun taglio al supporto operativo della griglia Lo storage di massa rimane il punto critico Verso la presa dati: CCRC08 (Combined Computing Readiness Challenge) –Tutti insieme appassionatamente! –Febbraio: challenge di integrazione –Maggio: 4 settimane, test del sistema alla scala prevista a LHC –Schedula strettissima

15 …e in Italia?

16 Storage @ CNAF 3 classi di storage –Disk0Tape1 (D0T1)  CASTOR Spazio gestito dal sistema Dati migrati su nastro e cancellati dall’area di staging quando questa si riempie –Un ginepraio di opzioni possibili –Disk1tape0 (D1T0)  GPFS/StoRM Esclusivamente spazio disco, gestito da esperimenti –Disk1tape1 (D1T1)  CASTOR Praticamente inutilizzato al CNAF Spazio gestito dagli esperimenti (ad es. se il disco è pieno la copia fallisce) per dati ad accesso frequente Buffer disco grosso con backup su nastro I problemi del CERN sui nastri si ritrovano al CNAF, aggravati da carenze di risorse hardware (pochi drive) e di manpower

17 We have a problem… La questione nastri va avanti da troppo tempo Manca una dichiarazione chiara e quantitativa del problema e di qual è il modo di risolverlo Non c’è nessuna garanzia che CASTOR funzioni al CNAF quando arriveranno i dati –Prodotto sviluppato dal CERN “in casa”, ancora oggetto di un'intensa attività di sviluppo e non ancora maturo per un uso in produzione (carenza delle interfacce di gestione, documentazione, strumenti di monitoring) –Architettura complessa, basata su vari strumenti non ancora ben integrati in una unico framework applicativo : spesso, per sbloccare il sistema sono richiesti interventi manuali di basso livello –problemi evidenti nelle politiche di migrazione disco  nastro, nell’ottimizzazione delle risorse e nell’efficienza di migrazione da nastro –il tutto aggravato dai modelli di calcolo degli esperimenti laddove prevedono un uso intensivo delle librerie (T1D0) per l'analisi, con grandi investimenti in tape drive, servers e manpower –Prodotto difficilmente adattabile a siti esterni Il CERN sicuramente ce la farà, ma non abbiamo evidenze che il sistema di storage al CNAF riesca a sostenere il carico dei quattro esperimenti funzionanti a regime

18 Piano B E’ indispensabile avere un’alternativa da provare al più presto GPFS+StoRM già in produzione al CNAF per Atlas T0D1 –Buona performance –Gestione leggera in termini di risorse umane GPFS versione 3.2 permette di interfacciare GPFS con sistemi di tape management, quali ad es. HPSS e TSM test su piccola scala in corso al CNAF –collaudo di StoRM –Integrazione GPFS+TSM per classi di storage T1D1 e T1D0 –In collaborazione con LHCb C’è molto lavoro da fare –Coordinamento con gli esperimenti –Strumenti di monitoring –Capire qual è l’impatto sull’interfaccia SRM (StoRM) –CNAF ed esperimenti devono sviluppare un piano dettagliato

19 E nel frattempo? Si cerca di utilizzare al meglio quello che c’è –Si mettono su nastro solo i dati che verranno riutilizzati raramente (2-3 volte l’anno) per attività programmate e sequenziali (per es. reprocessing) –Si collocano su disco i dati da utilizzare più frequentemente Occorre un piano dettagliato dagli esperimenti e dal CNAF –Workflow per trasferimenti e produzioni –Risorse di disco e nastro per le varie classi di storage –Servizi richiesti (di esperimento e middleware) e loro armonizzazione –Cronoprogramma Formata task force CNAF-esperimenti, primo meeting questa mattina

20 Piano 2008 dei Tier2 aumento notevole delle risorse e quindi dei finanziamenti nel 2008 –scelte architetturali cui si rimane legati anche per gli anni successivi –budget dominato (~2/3) dal costo dello storage CSN1 09/2007: 1.5M€ per i Tier2 di Atlas+CMS+LHCb –458k€ s.j., il resto in tasca indivisa s.j. legato all’esito di un workshop identifichi l’architettura di storage che risponde meglio alle esigenze degli esperimenti, compatibilmente con i costi (hardware e di gestione). Oltre agli aspetti tecnici occorre avere un quadro chiaro di –modelli di calcolo degli esperimenti –infrastrutture esistenti e loro evoluzione –interazioni con il Tier1 e il middleware di Grid –grado di preparazione della collaborazione italiana –attività di test e commissioning Il workshop si è tenuto il 17 e 18 gennaio al CNAF, con incontri preparatori in novembre e dicembre –Agenda e talk: http://agenda.cnaf.infn.it/conferenceDisplay.py?confId=60http://agenda.cnaf.infn.it/conferenceDisplay.py?confId=60 –Partecipazione al workshop: circa 50 persone –Presentazioni di ottimo livello, parecchia discussione –dimostrazioni di analisi dati dal vivo da parte degli esperimenti

21 Infrastrutture di storage per Tier2 Grazie a: A. Brunengo & Gruppo storage della CCR

22 Interfaccia SRM –dCache, DPM, StoRM Protocolli di accesso –dCache: (gsi)dCap, xrootd, (gsi)FTP –DPM: rfio (lan), xrootd (lan), gridFTP –StoRM: file, gridFTP (xrootd, rfio) File system –local FS (EXT3, XFS, ZFS) –file system parallelo (GPFS) Configurazione di accesso –“DAS”, “SAN” (switched, non switched): tutto integrato o server separati? Ridondanza –sul disk server, sul controller, sul file (repliche), sul disco (raid sw/hw, raid level) Hard disk –SATA, SAS, FC Una elevata quantita’ di combinazioni possibili –non esiste una soluzione giusta –alcune scelte per una componente implicano scelte per altre componenti Zona “grigia”: striping, gestione dei volumi, load balancing possono essere implementati da componenti diversi Componenti del sistema

23 Parametri & requisiti Prestazioni, scalabilità –funzione dei requisiti –crescita progressiva dell’installato Affidabilità e solidità in occasione di failure Flessibilità –modifica di configurazioni (aggiustamenti in corso) –impatto sulle riconfigurazioni hw/sw Complessità di management Costi Dimensione dello storage –oggi: ~ decine di TB –2008: ~ raddoppio –a regime (2012): ~500 TB Throughput aggregato (a regime) –read: ~1000 MB/s (WN), ~10 MB/s (T1) –write: ~ 60 MB/s (T1), ~ 10 MB/s (WN) Slot di calcolo: ~ 500 (50% per analisi) Throughput per slot: 1-10 MB/s –Determina il numero di disk server e di controllori per TB Altri requisiti –protocolli di accesso locale e remoto: dipende dalle esigenze di esperimento –protocolli SRM: l’interfaccia e’ definita (V2.2 nel 2008)

24 Disco & ridondanza Volumi e tipologia di accesso suggeriscono l’uso di dischi SATA –MTBF ~ 0.6 Mh, size 1TB, 7.2 Krpm, ~350-400 €/TB –Dischi SAS e FC sono più affidabili e veloci, ma molto più costosi Ridondanza sul disco assolutamente necessaria, da realizzarsi tramite RAID –hardware: tipicamente RAID5, molto meglio RAID6 richiede un controller idoneo, di buon livello –software: ridondanza a livello di logical volume o di file system (ad esempio la soluzione SUN Thumper con ZFS) Ridondanza sull’hardware del server consigliabile –impatto non eccessivo sui costi ~ 2.2-2.4 k€ server non ridondato ~ 2.8-3.2 k€ server ridondato + 0.5/0.8 per HBA

25 Configurazioni possibili “NAS” o “DAS”: il disco e’ direttamente connesso al singolo server (tipicamente integrato nel case) semplicità di installazione e costi contenuti  una failure del server implica inaccessibilita’ ai volumi fino al ripristino ridondanza, flessibilità, stabilità  Costi e setup “SAN”: rete FC tra disk server e controller. La separazione server-disco permette di gestire: –failover sul disk server, su controller e su path verso i volumi –bilanciamento del carico –backup o migrazione di volumi senza impattare sull’I/O

26 “SAN” senza switch Si connettono gli oggetti di una “SAN” senza utilizzare lo switch.  Meno flessibilità Stesse features Con controller dotati di due canali, si possono costruire mini-SAN con (doppio) controller e due/quattro server. Si mantiene il failover sul disk server connettendo ogni controller a due server; Si mantiene il failover sul controller collegando ogni coppia di controller a due server. backup o migrazione di volumi tra mini-SAN distinte passano attraverso i server connessi, quindi competono con l’I/O dei server stessi. Controller 1 Controller 2 Gbps 4 Gbps FC 4 Gbps FC Gbps 2 x 1 Gbps Ethernet 2 x 1 Gbps Ethernet

27 Una precisazione In realtà utilizziamo termini quali “SAN”, “NAS”, “DAS” in modo impreciso –SAN: infrastruttura di rete attraverso la quale le applicazioni hanno accesso allo storage (disk+tape) via block I/O. –DAS: il termine si usa abitualmente nei casi in cui le applicazioni accedono localmente ai dati; si tratta normalmente di applicazioni di servizio, come server Web o server Mail che poi vengono interfacciate ai client attraverso protocolli specifici (ma senza accesso a file); –NAS: è l'accesso classico a file system attraverso rete Ethernet; NAS è di fatto la modalità che descrive meglio quello che noi facciamo, anche se i protocolli sono diversi dallo standard NFS (Unix); ma si tratta sempre di accessi basati su file, dove i file system sono creati e gestiti nei server, non dai client. Quindi non parliamo di architetture SAN piuttosto che NAS/DAS nei T2, perché il pattern di utilizzo allo storage e' tipicamente NAS. Parliamo invece di configurazione dei server e della sua ridondanza –“DAS/NAS”: soluzioni integrate tradizionali (dischi + CPU integrati in un unico box, tipicamente usate in architetture DAS/NAS), ridondanza attraverso replicazione –“SAN (senza switch)”: soluzioni Sata-to-FC con server ridondati e storage separato, senza replicazione

28 File system e interfacce SRM Tipicamente si utilizzano file system locali (ext3, xfs) File system paralleli (GPFS) bene accoppiati a SAN –Bilanciamento del carico, gestione dinamica dei volumi, quote –Occorre fare attenzione allo striping dei dati Interfacce SRM – dCache: utilizzata da CMS, da tempo in produzione scalabilità (FNAL, DESY), distribuzione del carico sui server  Curva di apprendimento ripida, management complesso – DPM: utilizzata da Atlas, da tempo in produzione Semplicità di utilizzo  scalabilità (?)  bilanciamento del carico, compatibilità con CMS – StoRM: utilizzata da Atlas al T1, prodotto giovane e italiano Interfaccia naturale a GPFS, ne sfrutta al meglio le caratteristiche Facilità di gestione (se si conosce GPFS)  Non ancora testato abbastanza, supporto deve essere garantito

29 Architetture possibili DASSAN dCache Thumper + ZFS (ma costa)  DAS low level + FS locale GPFS, ma costi alti anche di gestione FS locale, ma costi alti DPM  DAS low level + FS locale GPFS, ma costi alti FS locali ma costi alti StoRM  DAS low level + FS locale GPFS È necessario eseguire test significativi, sia per tipologia di accesso che per carico, al T1 o a un T2 sovradimensionato rispetto allo stato attuale

30 Costi (e qualità) “DAS” Low level: 0.9 K€/TBN (acquisti di piccole dimensioni) –alta possibilita’ di failure –eventuale replica dei dati, con incremento dello spazio disco High level –Thumper: 1.3 k€/TBN (offerta di lancio) –Non ci sono dati per altre soluzioni di marca “SAN” controller+disco –dipende fortemente dal brand e dalla dimensione –per acquisti dell’ordine dei 40 TB: 1.1 - 1.2 k€/TBN (low level), ma arriva a 1.6 - 1.7 k€/TBN per soluzioni di qualita’ (EMC2, StorageTeK) i migliori brand offrono assistenza e garanzie che altri non possono dare –acquisti di materiale di alta qualita’ dell’ordine di centinaia di TB: prezzi fino a 1.2 - 1.3 k€/TBN (vedi T1) costo disk server –da 3.0 a 4.0 k€ in funzione della ridondanza hardware –Impatto per TB dipende da quanto storage viene servito (20TB) costo dello switch –low level: ~ 400-500 €/porta

31 Raccomandazioni dei referee Dischi SATA e controller RAID (5, meglio 6) Bisogna fare attenzione a non acquisire oggetti integrati “DAS” di basso costo che possono rivelarsi problematici, specialmente per le applicazioni di storage più critiche Una configurazione di tipo “SAN” è preferibile per flessibilità e soluzioni di failover –Una “SAN” senza switch (SATA-to-FC) offre un ragionevole compromesso tra affidabilità, ridondanza e costi –Si accoppia bene a tutte le interfacce SRM considerate (dCache, DPM, StoRM) File system paralleli sfruttano al meglio le caratteristiche delle “SAN” Accorpare ordini per soluzioni omogenee (magari scegliendo soluzioni omogenee ove possibile) per spuntare prezzi migliori soluzioni integrate di buon livello hanno un costo non molto diverso dalle soluzioni SATA-to-FC con migliore rapporto prezzo- prestazioni, entrambe possono essere prese in considerazione a seconda del tipo di applicazione e noi ci siamo basati su entrambe per valutare il costo del TB netto. 1.4k€/TBN per il 2008

32 E la rete? Gaetano Maron, Workshop Tier2, CNAF, 17-18 gennaio 2008 Potenza di calcolo: 2.3 MSI2k ~700 cores (3.3 kSI2k/core) ~ 100 boxes Storage: 600 TB Capacità di I/O: Analisi + MC (2 - 8 MB/s/kSI2k): (6.6 – 16.4)GB/s 10 GB/s 100 Gbps Copia Data Set + MC: (1 – 10 ) Gbps Disk Array 1 100 100 CPU BOX 100 Gbps Max 10 Gbps Al Tier 1 CMS Tier 2 600 TB disks A regime:

33 Possibile layout Gaetano Maron, Workshop Tier2, CNAF, 17-18 gennaio 2008 Server Disk Array Server SANSAN Disk Array 1 Gbps links 10 boxes 80 cores o Blade center Switch Concentratore 2x10 Gbps link > 200 Gbps Ethernet backbone ~ 50 TB 4 + 4 Gbps FC links N*Gbps trunck 10 Gbps X-Pop / Centro Stella Lab.

34 Conclusioni rete Si va verso un'infrastruttura a 10Gbps, motivata anche dai dati riportati dagli esperimenti, effettuando una transizione che tenga conto: –della probabile riduzione sostanziale dei costi dovuta all'introduzione dei collegamenti a 10 Gbps in rame –della integrazione con la rete GARR-X (collegamenti dedicati a 10 Gbps per i T2). Costituito un gruppo ad hoc che iniziera' a lavorare nelle prossime settimane –Gaetano Maron (CMS) –Domenico Di Bari (Alice) –Alessandro De Salvo (Atlas) –esperti Netgroup CCR (R. Gomezel, et al.) Per acquisti di apparati di rete va riportato il parere dei responsabili dei servizi calcolo e reti delle sezioni/laboratori. Andrebbe fatto in generale anche per gli acquisiti della macchine, in modo da garantire che l'infrastruttura Tier2 si integri senza problemi in quella di Sezione.

35 Tier2 e modelli di calcolo Per capire quali sono le risorse richieste ai Tier2, abbiamo chiesto agli esperimenti di riempire un file excel, con indicazioni su –Risorse attualmente disponibili –attività di calcolo previste nelle federazioni T2 in termini quantitativi con profilo temporale di crescita in relazione ai ruoli che i vari siti T2 possono svolgere tenuto conto del loro eventuale diverso grado di sviluppo. Le prossime diapositive riassumono le risposte

36 Parametri dei modelli ATLASCMS

37 Attività: CCRC08 Suddivisione delle risorse: 30% sui ciascuno dei 3 approvati, 10% sul proto Tier2 3 versioni AOD ATLAS CMS

38 Attività: presa dati Suddivisione delle risorse: 30% sui ciascuno dei 3 approvati, 10% sul proto Tier2 Stime un po’ generose Stesse dimensioni di un evento da collisione? ATLAS CMS

39 Profilo temporale ATLAS CMS

40 Osservazioni C’è ancora del lavoro da fare per quanto riguarda le dimensioni degli eventi Il numero di versioni richieste di AOD può essere ridotto Le stime delle risorse per analista contengono un fattore di incertezza abbastanza grosso Il profilo temporale nella seconda metà dell’anno è reso incerto dalla schedula della macchina

41 Proposte di assegnazione: Atlas Piano settembre 2007 aggiornato con gli acquisti effettivamente realizzati nel frattempo Sono incluse anche le risorse acquistate con altri fondi (sezione, laboratorio, PON, eccetera). Esiste un “meccanismo virtuoso” Totale: 285k€ 225k€ s.j. 60k€ nuove assegnazioni (30k€ switch, 30k€ storage MI) ATLAS

42 Proposte di assegnazione: CMS Totale 256k€ 233k€ da s.j. 23k€ nuove assegnazioni per sostituzione di server dedicati all’esperimento e ormai obsoleti Piano settembre 2007 aggiornato con gli acquisti effettivamente realizzati nel frattempo Sono incluse anche le risorse acquistate con altri fondi (sezione, laboratorio, PON, eccetera). Esiste un “meccanismo virtuoso”. Pisa e Bari dispongono rispettivamente di circa il 70% e il 50% della CPU indicata CMS

43 Riepilogo proposte ATLAS sblocco sj 225k€ 75k€ a Roma1 e Napoli (15k€ CPU, 60k€ storage) 50k€ a Milano (solo storage) 25k€ a LNF (5k€ CPU, 20k€ storage) ATLAS Assegnazioni aggiuntive 57k€ 30k€ a Milano per storage. Questo, assieme a 2 rack di CPU dismessi dal CNAF per motivi di bilancio energetico, porta Milano allo stesso livello degli altri Tier2 30k€ a Napoli per l’acquisto di switch concentratori per tutti i Tier2. Gli oggetti da comprare vanno determinati con la collaborazione dei servizi di calcolo di ogni sezione e la CCR, per verificarne la compatibilità con l’infrastruttura di rete già esistente CMS sblocco sj 224k€ Roma1 61k€ (24k€ CPU, 37k€ storage) LNL 53k€ (storage) Pisa 76k€ (storage) Bari 34k€ (storage) CMS sblocco sj 9k€ e assegnazione aggiuntiva 23k€ per sostituire server obsoleti Roma1 14k€ LNL 18k€ ATLAS CMS

44 Procedure di acquisto Si utilizza il mercato elettronico –Presentazione dettagliata al workshop –Procedure ben definite –Acquisti separati per esperimento e categoria merceologica (storage, CPU, switch) Sono stati identificati gli acquisti da poter effettuare in comune –ATLAS: storage (MI, NA, Roma1) e switch (NA) –CMS: server (Roma1, LNL), storage (Roma1, LNL)

45 Dove siamo? Dove andiamo? ATLASI 2008 II 2008 III 2008 IV 2008 Piano esperimento CPU (kSI2k) Storage (TBN) 650 70 1550 200 2120 560 2370 930 Proposte 01/08 e piano tentativo CPU Storage 810 200 1150 350 2200 750 Piano T2 09/07 CPU Storage 1140 630 CMSI 2008 II 2008 III 2008 IV 2008 Piano esperimento CPU Storage 1000 100 1100 200 1700 460 1750 680 Proposte 01/08 e piano tentativo CPU Storage 2100 180 2250 330 2250 650 Piano T2 09/07 CPU Storage 1500 511 Le proposte di oggi copriranno le esigenze fino a metà estate (almeno). I piani per la seconda metà dell’anno sono ancora abbastanza incerti. Il piano tentativo, corrispondente a una spesa di circa 1M€, assume che le CPU siano prese dal CNAF.