Tommaso Boccali (INFN-Pisa / CERN) IDDLS (Italian Distributed Data Lake for Science) Preventivi Pisani 2020 Tommaso Boccali (INFN-Pisa / CERN)

Cosa fa? Vuole implementare su scala italiana, utilizzando tecnologie di rete all’avanguardia, un prototipo di un Data Lake (non solo per) LHC Data Lake: nasce dall’idea di consolidare lo storage necessario a LHC (sia per data preservation che per operazioni) in modo sicuro, e indipendente dalla locazione effettiva delle CPU (“mettiamo i dati al sicuro”); inoltre, mediante distinte visioni logiche (“un solo lake”) e fisiche (“N siti partecipano”) diminuire il numero di copie distribuite dei dati Una rete di nuova generazione e’ necessaria affinche’ i dati possano arrivare alle CPU, in modalita’ molto simile a quello che succede oggi con Neflix: Cache mediated se necessario Con previsioni di uso

The data lake model > 1 Tb/s HPC center CPU center Lake Node 1 Lake Node 3 Keep the real value from the experiments safe (RAW) data and a solid baseline of CPU in owned and stable sites Allow for multiple CPU resources to join, even temporarily Eventually choosing the cheapest at any moment Solid networking: use caches / streaming to access data Reduce requirements for Computing resources Commercial Clouds Other sciences’ resources SKA, CTA, Dune, Genomics, ... HPC systems CPU center > 1 Tb/s Lake Node 4 Lake Node 2 CPU center CPU center HPC center ProtoDune 2-3 GB/s (like CMS); Real Dune 80x SKA up to 2 PB/day A single genome ~ 100 GB. a 1M survey = 100 PB CTA projects to 10 PB/y

Come? La rete e’ la componente essenziale: GARR fa parte dell’esperimento! Utilizzare le infrastrutture GARR (che mette a disposizione ~200kEur per il progetto) per creare un’aggiuntiva rete veloce dedicata fra alcuni nodi italiani (T1, T2) La tecnologia utilizzata e’ DCI, che abbiamo gia’ sperimentato per il link CNAF-CINECA: una connessione point-to-point su singola fibra fino a 1.2 Tbit/s (100 Gbit/s per partire) Perche’ PI e LNL sono «arancioni»? Pisa: problema e’ bypassare il Serra, al momento non banale Si comincia con gli altri siti

Perche’ e’ interessante? Ad almeno 100 Gbit/s la LAN e la WAN diventano praticamente indistinguibili come banda La latenza non e’ un problema con sistemi predittivi tipo TTreeCache: «vedo che negli ultimi 100 eventi hai letto da disco i Muoni da disco, mi porto avanto e faccio prefetch» In generale per il GARR, connettere l’italia usando N link point-to-point potrebbe essere piu’ economico dell’infrastruttura attuale con nodi di concentrazione

Caching! Esempio concreto per CMS Spostarsi (per una frazione dello storage) da disco managed via sistemi di data movement attivi a caches passive Invece di avere caches desincronizzate per sito, con probabile spreco di cache via riempimenti multipli, mettere in piedi una insfrastruttura nazionale di caching intelligente, sfruttando una gerarchia di storages Il disco locale e’ piu’ veloce di tutto Una cache distribuita nazionale e’ comunque piu’ veloce di un accesso remoto (rete nazionale > rete internazionale) Al limite, accesso remoto con riempimento della cache

Stato Nella pratica, non e’ successo quasi nulla. Motivo: non siamo ancora riusciti a trovare un accordo con GARR su cosa comprare che rispetti il budget e usi una tecnologia più innovativa rispetto a 100Gbit/s standard, i.e. DCI. Appena questo succede, si parte con le sperimentazioni Per lo stesso motivo, non e’ stato speso praticamente nulla Pisa: 500 Eur Missioni, 0 spese (Kick off meeting da remoto / su altri fondi) Personale in sezione Io 20%: interesse sul lato caching solution, anche in vista del progetto ESCAPE e delle implementazioni EOSC; per patti con presidente CSN1, tali 20% _non_ sono tolti da CMS Enrico 10%: lato networking, tentativo (nonostante Serra) di avere 100 Gbit/s asap In tal caso la connettivita’ geografica andrebbe a spese GARR + l’apparato locale sul progetto, in tasca CNAF Richieste 2020: In linea con 2019, pochi soldi missione O(1000 Eur); apparati su tasca CNAF

Totali richieste 2018 («non spesi»)  Sostanzialmente replicate per 2019