Referaggio calcolo CMS 2014 CSN1 - 18 Settembre 2013 Tommaso Boccali (INFN Pisa) 1.

Presentazione sul tema: "Referaggio calcolo CMS 2014 CSN1 - 18 Settembre 2013 Tommaso Boccali (INFN Pisa) 1."— Transcript della presentazione:

1 Referaggio calcolo CMS 2014 CSN1 - 18 Settembre 2013 Tommaso Boccali (INFN Pisa) 1

2 Outline Stato generale calcolo CMS Stato italiano calcolo CMS Evoluzione modello di calcolo E soprattutto … Richieste 2014 2

3 Stato Computing Presa dati (pp) meglio del previsto: – Secondi in collisione piu’ delle previsioni, e inoltre 1 mese e mezzo aggiuntivo in pp 3 +25% rispetto al planning di inizio 2012

4 Trigger rate salito da ~400 Hz a 1200 Hz Ben oltre le specifiche a 300 Hz (che erano 100 Hz nel Computing TDR) Totale eventi raccolti 2012: 7.8B (di cui 3.2B parked) 4 PU alto ma gestibile; sostanzialmente costante tutto l’anno (a differenza del 2011) Reco time vs lumi

5 AODSIM (il data tier per la fisica):) : 13B+4B di eventi prodotti MonteCarlo 2012-13 5

6 Utilizzo in Analisi CMS-World: Ormai da > 1 anno preponderan te (>90%) attivita’ su formato dati ridoto (AOD) Stabilizzati su 300-400 utenti singoli la settimana 6

7 Utilizzo risorse T1&T2 T1: buco dovuto alla preparazione dei reprocessing; in risalita T2: calo ultimi mesi in attesa del nuovo reprocessing 2011 + dei nuovi samples per post-LS1 7

8 Reprocessing con release 5_3_X (legacy per il run 2010-2013) Reprocessing in pratica finito. E poi … 8 2013

9 9 2011 final rereco

10 Italia! 10 Riorganizzazione disco per dare pledge 2012 Rotture multiple controller disco Interventi elettrici Campus di Bari

11 Italia T1: – Pledge 2012 e’ 18.85 kHS06 CPU, 2.8 PB DISCO, 6.6 PB TAPE Raggiunto fine 2012 – PLEDGE 2013 e’ 22.75 kHS06 CPU, 3.38 PB DISCO, 6.5 PB TAPE Raggiunto ~ Agosto – Anzi CNAF ci ha permesso a Agosto/13 un overpledge di ~500 TB per effettuare la separazione TAPE/Disk (vedere dopo) 11

12 Utilizzo T1_IT_CNAF L’approccio italiano (1 solo T1 per tutti gli esperimenti) permette periodici overpledge anche grossi – Vero soprattutto per esperimenti grossi, che sono molto efficienti a occupare tutte le risorse libere – CMS ha avuto periodi di overpledge e di underpledge, bilanciamento possibile solo grazie alla natura shared del sito # jobs 09-2012/09-2013 ai T1: CNAF migliore dopo FNAL (consolidato dato 2012) 12

13 Utilizzo CNAF per CMS 13 CPU: sostanzialmente in pledge (4 mesi under, 8 mesi over) TAPE: saturazione del pledge raggiunta. Attivita’ NON bloccata grazie alla separazione tape/disk (dopo…)

14 News dal Tier1 Attivita’ di analisi per utenti Italiani attiva fin da meta’ 2012 Separazione dello storage Tier1 in Tape e Disk In grado di aprire all’analisi di tutti gli Utenti di CMS (grazie a tape/disk separation) 14

15 Separazione DISK/TAPE Spazio TAPE con frontend di disco “piccolo” (~350 TB, 10% del pledge) sostanzialmente dedicato solo ai dati da tenere in custodial Tutto il resto del disco (~ 3 PB) come area svincolata dal disco – Permette un utilizzo caotico (in analisi, per esempio) senza dover temere sovraccarichi della parte TAPE – Svincola il T1 in modo netto fra parte di data custodiality e parte di processing (produzione + analisi) 15

16 Un minimo di dettaglio La separazione e’ stata decisa in CMS qualche mese fa A tutt’oggi CNAF risulta il PRIMO Tier1 ad aver completato la transizione (RAL ha cominciato molto prima ma ancora non ha finito) Operazione effettuata interamente ad Agosto (dal 5 al 19) – … per chi dice che e’ impossibile lavorare ad Agosto in Italia … – Un grosso grazie al personale T1 e al supporto CMS! – 1.1 PB di dati richiamati da TAPE e spostati su parte DISK in ~ 10 giorni – Transizione di tutta la farm effettuata il 20 agosto 16

17 T2 italiani BA, LNL, PI, RM1 – Totale risorse pledge 2012: Disco = 3.5PB CPU = 45.5kHS06 – 2013: identico Accordate solo dismissioni 17

18 Picture simile a quella dell’anno scorso: US inarrivabili, (cf slides G1, Sett 2012) Italia nel gruppo che segue FNAL # jobs, 01/2012 – 09/2013 18 Come # di jobs successful Italia 1 o posto (di un epsilon…)

19 E all’interno dell’Italia (T2 only) 19 Nota usuale sui rossi: I “rosa” sono certamente problemi di workflow (utenti o team di produzione) I rossi intensi sono problemi dal lato GRID (possono essere sia di sito sia di infrastruttura) I rossi scuri sono probabilmente problemi di sito, ma anche di workflow Per esempio se viene mandato un job che richiede una versione del sw che non c’e’ Una *mia* stima dei problemi veri di sito da’ numeri inferiori al 5%; il resto sono errori operazionali # jobs, 01/2012 – 09/2013

20 Disco I T2 italiani ~ 900 TB l’uno (come il 2012) Lo spazio e’ TOTALMENTE ALLOCATO secondo I dettami di CMS – Spazio reale occupato 70-95%, ma grossa variabilita’ annuale – Non vi e’ spazio aggiuntivo usabile liberamente 20 Esempio di Pisa: fino a 10 gg fa pieno al 98%; refill di emergenza attuato Numeri 2012, 2013 +5%

21 Gruppi di fisica Sono ufficialmente supportati 8 gruppi di fisica: – Bari: Higgs, SUSY – LNL: ElectroWeak, Muons – Pisa: Tracking, Tau & Particle Flow – Rome: Higgs, Egamma & ECAL – Nulla di nuovo da anni…. 21

22 Italia in totale (01/2012 - 09/2013) (occhio, # di jobs, non secondi CPU – e gli workflows che girano a T1 e T2 sono diversi) 22 (nota: T3_IT_Padova a meta’ 2012 e’ stato completamente integrato in T2_IT_LNL; ora sono una cosa sola)

23 Highlights 2013 L’Italia con gli US e’ l’unico stato ad aver fatto deployment completo di Xrootd a T1+T2 (e anche qualche T3) Abbiamo un redirettore nazionale + ospitiamo quello Europeo (Bari) – Erano 2 milestones 2013 -> 100% DONE 23

24 24 Traffico Xrootd di CMS a livello mondiale …

25 25 Italia assolutamente centrale a livello Europeo … ed Europeo

26 Anche CNAF in Xrootd! Al CNAF sono state accese 4 porte Xrootd Necessaria l’implementazione di patches a Xrootd per proteggere sistema TAPE del CNAF – Xrootd non pubblica nel redirettore files solo su TAPE – In caso di accesso diretto a files su tape, il recall avviene via GEMSS in modo “pulito” – Soluzione sviluppata in Italia Patches ora accettate da Xrootd e in release ufficiale CNAF + FNAL unici T1 completamente abilitati con accesso Xrootd per lungo tempo 26

27 Milestones 2013 “termine installazione/configurazione di Xrootd sui T2 per l'accesso remoto degli utenti italiani ai dati” – 1 giugno 2013 – 100% DONE Tutta l’italia e’ nel redirettore di Europeo CMS (anche T1 e qualche T3) “messa in opera del redirettore della cloud di calcolo italiana” – 15 dicembre 2013 – 100% DONE Redirettore della cloud italiana xrootd-it.ba.infn.it operativo (“definizione delle procedure di utilizzo del T1 per analisi e disponibilita' dello spazio disco necessario” – Done Luglio: – ) 27

28 https://twiki.cern.ch/twiki/bin/viewauth/CMS/T1ItalyForUsers 28

29 Esempio di funzionamento di Xrootd 15/04: Storage di Legnaro down per upgrade di dCache. Attivita’ di sito NON ferma perche’ I jobs potevano accedere ai dati via Xrootd. 29 Altri tests fatti Reprocessing @ CNAF leggendo dati RAW in Xrootd-Fallback da FNAL Reprocessing @ T2_IT leggendo MC RAW in Xrootd-Fallback da CNAF (sempre piu’ vicini ad un modello full mesh …)

30 Analisi al T1 L’analisi al T1 per tutti gli utenti italiani e’ stata attivata (mediante un gruppo VOMS specifico) Una settimana al CNAF (estate, credo) Prossimo step attuabile grazie a tape/disk separation: attivarla per tutti gli utenti CMS 30

31 Networking Durante gli ultimi 12 mesi – T2+T1 (extra LHCOPN) sono passati a LHCONE, che permette ottimizzazione dei flussi di analisi e di trasferimento dati a matrice completa – I T2 sono passati a GARR-X 10 Gbit/s per BA, RM1, LNL (2012) 20-  Gbit/s per PI (inizio 2013) – Questo rende + efficace l’utilizzo italiano di Xrootd in modo trasparente 31

32 Attivita’ di sviluppo SW/CMP CRAB (tool di analisi) – Common Solutions con ATLAS/CERN-IT – Responsabilita’ di componenti fondamentali H.Riahi, D.Cingottini (PG) TaskManager Async Stage Out … – Alpha e Beta Testing, test di scala Pisa, Torino, Bologna, Padova Computing Evolution – C. Grandi coordinatore L2, si sta formando un gruppo anche interessato agli studi Cloud partiti in CCR M.Sgaravatto (PD): HLT Cloud, General CMS-Cloud Interface, Gestione delle immagini virtuali BA: could storage, Testbed per Cloud IaaS basata su OpenStack per il progetto PON-PRISMA PG … 32

33 HLT Cloud Idea: sfruttare farm HLT (~13kCores/~200kHS06) quando la DAQ e’ spenta / ad uso ridotto – Shutdown lunghi (LS1) - ~ 2 anni – Shutdown invernali- ~ 3 mesi – Periodi di machine development ~ 2-5 giorni – Interfill – 1-2 ore Usato approccio CLOUD (Openstack/KVM con Openvswitch) – Accesso allo storage via Xrootd – Possibilita’ di allocare / deallocare macchine in pochi minuti (non serve reboot dell’host) – Possibilita’ di allocare solo una frazione della farm (per esempio periodi a bassa luminosita’) Esperienza specifica, ma molte soluzioni riutilizzabili per generico uso di risorse opportunistiche, visto che – Nessuna dipendenza da sistema operativo – Nessuna dipendenza da topologia di rete (c’e’ un overlay virtualizzato) – Unico servizio che serve davvero un CLOUD service che istanzi le macchine, e una immagine preconfigurata per parlare con glideinWMS 33 M.Sgaravatto (PD): x acquisire questa expertise in Italia

34 HLT cloud 2013 – in produzione! 34 _AI: Agile Infrastructure CERN (non risporse CMS) 170j jobs _HLT: la farm HLT a P5 480k Jobs processati Success rate comparabile con T1/T2 Picchi fino a 6k jobs running

35 Partecipazione a progetti MIUR PRIN08 (BA, MIB, PI, TS) –“Progetto e sviluppo di un ambiente hardware e software ottimizzato per l'analisi dei dati dell'esperimento CMS” –Concluso 09/2012 PRIN10/11 (… tutti …) –“Sviluppo di tecnologie per l’ottimizzazione dell’accesso ai dati di LHC, trasferibili ad altri domini scientifici, mediante l'approccio del grid e del cloud computing“ –02/2013 – 01/2016 Premiale PIDES (di CMS: CNAF, BA, PI) – approvato settembre 2013 –“Long-Term Data Preservation and Scientific and Cultural Heritage” PON ReCaS (BA in CMS) PON Pegasus (BA in CMS) 35

36 Sinergie locali Storicamente, i centri “proto T2”(2004+) sono stati iniziatori di attivita’ GRID su larga scala nelle Sezioni a partire dal 2002. La situazione attuale (per difetto, solo I progetti maggiori) – BA: Grosso centro per la fisica teorica PON RECAS Progetto PIDES per la data preservation – LNL Sinergie con esperimenti di GIII integrazione totale con PD via fibre dedicate – PI Partnership industriali (Ferrari, Ducati, Consorzio +39) Centro di Calcolo Nazionale di GIV Progetto PIDES per la data preservation Progettazione centro di calcolo teorico SISSA + proposte di collaborazione per condivisione risorse – RM1 Progetto regionale della Sapienza su cloud Nessuno di questi progetti sarebbe nato senza CMS come catalizzatore Nessuno di questi progetti sopravviverebbe a lungo senza il T2, che nella quasi totalita’ dei casi – Ha predisposto le infrastrutture – Fornisce expertise 36

37 Evolution of Computing Model per post LS1 1.Perche’ e’ necessario “cambiare” qualcosa – Nuovo environment da LHC – Nuove situazioni al contorno (funding etc) 2.Soluzioni: – Cambiamenti al computing model puro – Cambiamenti al nostro software 37

38 Parametri …. 38 Nuovo environment di LHC x il 2015 (25 ns – 50 ns)

39 2015 Target del trigger: mantenere stessa physics capability sui canali dell’Higgs Questo da solo richiede un rate di trigger fra 800Hz e 1.2 kHz – 1 kHz nei conti seguenti (2.5 x wrt standard 300 Hz) Inoltre ci sono 2 fattori che complicano ulteriormente la situazione, a partita’ di numero di eventi raccolti – Lumi istantanea + alta = reco time x2.5 – Out of Time PU (non lo considero nel seguito, siamo ragionevolmente convinti di poterci proteggere) 39

40 40 Per cui … In un mondo ideale, fattore 6x di risorse necessario 2015-2013; chiaramente impossibile Soluzioni messe in campo 1.Miglioramento dell’efficienza di uso delle risorse: CPU Mitigare effetto di trigger rate + alto: usare i T1 anche per una frazione della prompt reconstruction – Meno reprocessing completi possibili (solo 1 alla fine dell’anno) Usare farm HLT per Prompt Reco – Gia’ attivo, via HLT Cloud Uso opportunistico di risorse non CMS (e non HEP) – Una parte della produzione MC 2012 girata su UCSD SuperComputing Centre Ridurre il numero di eventi simulati 2.Miglioramento dell’efficienza di uso delle risorse: Disco Remote data access per evitare di dover distribuire piu’ copie dei dati/MC Data placement intelligente e dinamico Abbandono totale del formato RECO per AOD 3.Miglioramento dell’efficienza del nostro SW Computing/Offline

41 Rimane un fattore 2 di risorse da acquisire (su T0 e T1 *) Dal 2013 al 2015 … Statement di CMS: ottenibile con flat budget 2014+2015, o tutto su 2015 (dipende da scelte dell’ente finanziatore) *: I T2 sono molto meno critici, visto che li’ – Una parte dell’attivita’ scala con I dati (AOD dell’anno in corso) – Una parte scala meno (produzione MC, basta farne meno  ) – Una parte scala con il numero di utenti 41

42 Altre condizioni al contorno in cambiamento veloce Il paradigma CLOUD sta diventando standard industriale (molto piu’ di quanto GRID sia mai riuscito a fare) – Come implementazione, non un unico standard ma una certa interoperabilita’ per costruzione (per es. EC2 + OpenStack) Il supporto economico FPVI-FPVII (EMI, EGI) sta per finire – Se vogliamo un middleware solo nostro (HEP), dobbiamo pagarcelo – Seguire standard industriali dove si puo’, usare soluzioni comuni a N esperimenti quando non si puo’ (Common Solutions, CERN/IT) In generale, i fondi per il supporto dei siti (da INFN, per esempio), non sono certo in aumento 42

43 Altro …. Il mondo dell’IT ci sta cambiando intorno (lo fa da tempo in realta’, ma noi potevamo in un certo modo “fregarcene”) – Le reti geografiche sono cresciute molto + delle aspettative fine 199x (MONARC) Modello gerarchico di MONARC non piu’ una necessita’ La rete puo’ essere usata per ottimizzare accesso a storage (e comprarne quindi meno) – Le architetture di CPU stanno cambiando Mono -> multi core (da qualche anno) Cores x86 -> GPU (da qualche anno, ma non per noi) Cores x86 -> ARM (+ recente) In GRID, passaggio ormai a sottomissione via pilot – Meno supporto centrale, piu’ CLOUD friendly 43 Utilizzo + efficiente Maggiore potenza di calcolo Minore costo di gestione

44 In una slide … Ridurre differenze T0/T1/T2: girare dove ci sono risorse Disaccoppiare Disco e CPU nel brokering Nuove architetture (ARM, Phi) Transizione verso tools di analisi/produzione comuni almeno con ATLAS MW GRID sostanzialmente congelato da usare nei nostri siti, ma: Essere pronti a sfruttare opportunita’ impreviste (slot in centri supercalcolo, risorse opportunistiche) via CLOUD – Tanto lavoro da fare: intra e inter cloud scheduling; ottimizzazione dell'accesso allo storage.. E additittura volunteer computing per produzione MC (completamente da fare) 44 Xrootd: BA, PI, BO + T2 CRAB3: PG, PD, PI, TO BO, PD, BA PI, CNAF

45 Responsabilita’ 45 L1 L2 L3

46 46

47 47

48 48

49 1) Solo ottimizzazione 2) Sviluppi in direzioni prevedibili3) Don’t ask … 49 Attivita’ di miglioramento SW di CMS

50 Fase 1: subito dopo LS1 Niente che non sia gia’ in buono stato ha speranza di essere usabile Per CMS sostanzialmente: Multicore Scheduling (vero) – Vero: Multicore “dei poveri” gia’ usabile oggi (forking) – Piani dicono multithreading vero in test finale late 2013, e subito dopo in produzione 50

51 Vantaggi Multicore #1 51 Avere controllo completo su una macchina intera invece che su uno “slot” porta numerosi vantaggi, alcuni attuali altri “possibili” Miglior utilizzo delle caches dei processori Scheduling di jobs a alta CPU e a alto I/O sulle stessa macchine (ora le controlliamo “globalmente”) Meno memoria utilizzata (perche’ calibrazioni etc sono presenti una volta sola) -> disegnare algoritmi piu’ efficienti, ma che utilizzino piu’ memoria Trend opposto a quello seguito gli scorsi due anni, dove si e’ fatto di tutto per diminuire la memoria, a volte a scapito delle performance

52 Vantaggi Multicore #2 Utilizzo di risorse opportunistiche con meno RAM, ad oggi a noi negate Il fatto che lo scheduling non e’ piu’ per core, ma per “macchina” diminuisce di un fattore ~ 10 il carico dell’infrastruttura di computing # di jobs da gestire # di slots da gestire # di files temporanei da gestire In fase finale di test Autunno 2013 (perche’ ESISTE gia’) 52

53 Fase 2 (~2018) Qui si puo’ fare R&D vera sull’architettura Tre aspetti in gioco 1.Massively multicore, ma sempre x86: XEON Phi 2.Massively multicore, architettura nuova: GPU+CUDA/OpenCL 3.Riduzione dei consumi sia diretti sia di condizionamento: ARMv8_64 53

54 1. XEON Phi Interessante per usi “tipo coprocessore”: un core Intel standard esegue ricostruzione, e passa la parte meglio parallelizzabile (tracking) al Phi Non necessita di nuovo codice: architettura di host e guest e’ la stessa E’ una buona palestra per massively multicore Chi lo fa ? Al momento ITALIA in pole position, con Francesco Giacomini + Matteo Manzali hanno cominciato una collaborazione con CMS per studiare il boost di particolari algoritmi (inizio probabile e’ il seedinf nei Pixel), usando il Phi del CNAF Pisa ha altri 2 Phi, collaborazione in partenza con informatici per capire se e’ possibile collaborazione Recentemente il gruppo HLT/CERN ha manifestato interesse... Non credo siano ancora partite attivita’ vere e proprie 54

55 2. GPU Questa e’ una soluzione molto performante in un piccolo subset di algoritmi (quelli sostanzialmente vettoriali) E’ anche la piu’ complicata dal punto di vista degli skill necessari; non permette un facile riuso di codice (deve essere riprogettato) – CUDA, OpenCL, etc In CMS si e’ pensato a utilizzi solo a livello di trigger, ma non mi pare si stia davvero muovendo nulla 55

56 3. ARM (v8, 64 bit) Interessante per 2 motivi: 1.Consumo! 1.Un core i7 consuma 10-20 W (e in media altri ~4 per raffreddarlo) 2.Un core ARM e’ 1-1.5 W 2.E’ un mercato con molta concorrenza (prezzi bassi, aumento di performance maggiore anno su anno) – La ricompilazione di CMSSW su ARM e’ conclusa CMS Puo’ girare su ARM Vedere per esempio mie slides alla CCR di Maggio – Per ora e’ solo un test preliminare (ARMv8 non esiste ancora) ma non e’ detto che in 6-7 anni il mercato e/o I costi infrastrutturali non ci spingano in questa direzione 56 Per il momento attivita’ CERN/OpenLAB. Sistema di sviluppo equivalente a Pisa; interesse da parte degli informatici per benchmarking / misura di performance

57 57

58 Richieste 2014 Processo a 4 steps 1.1 Aprile: richieste CMS 2.Fine Aprile: report C-RSG 3.1 Settembre: aggiornamento richieste CMS 4.28 Ottobre: report finale C-RSG 58 Siamo qui! Senza dire troppo sulla storia: #2: accettate in sostanza le richieste 2014 #3: forte diminuzione richieste 2015 sul T1 (dovute principalmente a riduzione stima secondi di presa dati 2015 + compromessi sulla frazione di eventi da simulare) Le risorse richieste a maggio (meeting ref a Pisa), a giugno (CSN1) e adesso sono identiche!

59 Richieste 2014-2015 59 “paga il CERN” “paga la Giunta” “paga la CSN1” Inoltre: delta 2014-2013 e’ MINORE, visto che il refereraggio calcolo aveva assegnato piccolo overpledge l’anno scorso (come risulta da REBUS) CMS-IT e’ al 13% di CMS

60 REBUS T1 T2 60

61 Tier1 2014 Al netto delle dismissioni (vedi Donatella) Unico aumento sono 650 TB di TAPE CPU e Disco gia’ a posto a 40 Eur/TB (stima) sono circa 25kEur 61

62 TIER2 “mancano” 5.2 kHS06 62 (Nota preliminare …. Aspettare discussione su ReCaS prima di trarre troppe conclusioni)

63 Dismissioni T2 (T1 segue altra strada) TOTALE e’ – 23.6 kHS06 – 440 TBN 63 Dismissioni pure = 437kEur (se 12 Eur/HS06 + 350 Eur/TBN)

64 Richieste 2014 – Summary pre-RECAS T1 – Dismissioni come decise dal centro – 650 TB di Tape T2 – Aumento di 5.2 kHS06 – Dismissioni pari a 23.6 kHS06 e 440 TBN – (+ server / networking come share solito) 64 (se 12 Eur/HS06 + 350 Eur/TBN + 40 Eur/TB)

65 Per sito 65 A meno di 1000 Euro qua e la’, lo stesso che nei preventivi

66 66

67 2015 67 APRILE 2013 SETTEMBRE 2013 Sostanziale diminuzione Tier1 Tier2 invariati A spanne, 300kEuro IN MENO su T1_CNAF per il 2015 rispetto ai numeri della CSN1 di Giugno

68 Le richieste T1 2015 sono adesso davvero ridotte all’osso! 68 La richiesta di 300kH06 non e’ la MEDIA di utilizzo previsto nel 2015, ma IL MINIMO Il modello “regge” solo perche’ nei mesi di shutdown (quando ci sono I reprocessing completi) la farm HLT viene usata come pezzo del T1

69 Dismissioni 2015 - T2 Prima stima al momento Per la parte Disco, in caso di sistemi di alta qualita’, stiamo cercando di capire quanto/se sia possibile prolungare supporto dopo la fine della garanzia iniziale Ci stiamo lavorando … 69

70 Summary delle richieste (+ usual share di networking e server) 70

71 Arriva ReCaS! Volutamente non ho nominato ReCaS per ora ReCaS puo’ aiutare con: 1.Tutto il Delta 2014-2013 nazionale 2.Tutte le dismissioni Bari 2014 3.Parte delle dismissioni Bari 2015 4.(Piccola)Parte del Delta 2015-2014 71 Dipende da come va la gara Appurato con ReCaS Tabella finale richieste:

72 Penultimo: 2 punti 1.Nessuna richiesta Tier3 inserita nei preventivi – Alla CSN1 di 09/12 si era parlato di distribuire (una piccola parte delle) risorse dismesse dal T1 ai T3. Siamo fortemente interessati, non e’ ancora successo perche’ le nuove risorse al T1 sono arrivate da poco. Vorremmo procedere con il sostegno della CSN1 2.Le richieste 2014-2015 di CMS sono volutamente flat per il 2014, con il delta nel 2015. – CMS ha detto chiaramente che e’ facolta’ delle FA ridistribuire il carico sui 2 anni. – L’INFN ha deciso di non farlo, e di lasciare tutto il carico sul 2015, e in tale modo sono state modulate le richieste. 72

73 Ultimo: Milestones 2014 Attivare l'analisi utente al CNAF per tutti gli utenti di CMS – 01/06/2014 Deployment di una infrastruttura per il test di sottomissione jobs via cloud tramite tools standard CMS – 31/12/2014 (negoziabili con I referees…) 73

74 Conclusioni Il computing di CMS in Italia funziona bene – Una “non notizia”, e’ cosi’ da anni – Non solo T1/T2/T3, ma stiamo allargando le attivita’ sullo sviluppo “critico per noi” (con il poco mapower che riusciamo ad attirare) CMS ha recepito i richiami (urla di dolore?) per il 2015, abbassando le richieste – A prezzo di metterci un una condizione assolutamente scomoda, soprattutto se LHC andra’ bene ReCaS e’ un’ottima opportunita’ per risparmiare nel 2014 (appurato) e 2015 (in misura non ancora accertata) – Ma ReCaS dura due anni, e’ importante che i siti non ReCaS siano mantenuti in attivita’ – 2 anni sulla vita aspettata dei T2 e’ poca roba 74