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

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

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

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%

Accounting a T1 e T2

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

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…

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

CERN - IT Department CH-1211 Genève 23 Switzerland 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 MB 8 Jan 2008

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

…e in Italia?

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

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

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

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

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: –Partecipazione al workshop: circa 50 persone –Presentazioni di ottimo livello, parecchia discussione –dimostrazioni di analisi dati dal vivo da parte degli esperimenti

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

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

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)

Disco & ridondanza Volumi e tipologia di accesso suggeriscono l’uso di dischi SATA –MTBF ~ 0.6 Mh, size 1TB, 7.2 Krpm, ~ €/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 ~ k€ server non ridondato ~ k€ server ridondato + 0.5/0.8 per HBA

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

“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

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

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

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

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: k€/TBN (low level), ma arriva a 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 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: ~ €/porta

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

E la rete? Gaetano Maron, Workshop Tier2, CNAF, 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 CPU BOX 100 Gbps Max 10 Gbps Al Tier 1 CMS Tier TB disks A regime:

Possibile layout Gaetano Maron, Workshop Tier2, CNAF, 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 Gbps FC links N*Gbps trunck 10 Gbps X-Pop / Centro Stella Lab.

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.

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

Parametri dei modelli ATLASCMS

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

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

Profilo temporale ATLAS CMS

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

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

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

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

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)

Dove siamo? Dove andiamo? ATLASI 2008 II 2008 III 2008 IV 2008 Piano esperimento CPU (kSI2k) Storage (TBN) Proposte 01/08 e piano tentativo CPU Storage Piano T2 09/07 CPU Storage CMSI 2008 II 2008 III 2008 IV 2008 Piano esperimento CPU Storage Proposte 01/08 e piano tentativo CPU Storage Piano T2 09/07 CPU Storage 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.