Proposta per una cache distribuita a livello italiano ALESSANDRO DE SALVO (RM1) TOMMASO BOCCALI (PI)

Presentazione sul tema: "Proposta per una cache distribuita a livello italiano ALESSANDRO DE SALVO (RM1) TOMMASO BOCCALI (PI)"— Transcript della presentazione:

1 Proposta per una cache distribuita a livello italiano ALESSANDRO DE SALVO (RM1) TOMMASO BOCCALI (PI)

2 Outline Il problema Possibili linee di attacco Possibili implementazioni tecniche Stima di costi

3 Il problema A differenza del Run I, nel RunII le risorse a disposizione degli esperimenti LHC NON sono sufficienti per una gestione comoda dello spazio disco Esempio: RunI vs RunII 1.Trigger rate 2-3x (includendo parking su nastro) 2.Event complexity (PU) 2x 3.Pulizia degli eventi peggiorata (25 ns vs 50 ns) – maggiore tempo di ricostruzione In generale una stima per il RunII usando lo stesso modello del RunI dava nel 2015 un fattore ~10x di aumento di risorse necessario Nello stesso periodo (2012 vs 2015) la legge di Moore dava a malapena un fattore 2x di miglioramento tecnologico Quindi, 10x risorse nel 2015 costano 5x piu’ di quanto speso nel 2012

4 Soluzioni (?) Nessun miracolo (e’ stato) possibile, solo ottimizzazioni Di codice (piu’ veloce) Almeno 2x, ma non ha impatto sullo storage Di dimensioni dell’evento (formati piu’ piccoli, ma comunque soddisfacenti – non ottimali - per l’analisi) Troppo presto per dire se funionera su larga scala o meno Di modus operandi Produrre meno MC a parita’ dei Dati Avere meno copie distribuite dei samples Soprattutto quest’ultimo aiuta Stima CMS/ATLAS: RunI = 3 copie per “dato” di analisi RunII giu’ fino a poco piu’ di una copia in media Con quali effetti?

5 Effetti attesi In uno scenario di Data Grid (== i jobs vanno dove sono I dati) l’avere un’unica copia di un “dato” forza ad avere un solo “sito” dove poter girare Problemi di congestione Problemi se sito va giu’ (e contiene l'unica copia) Problemi di affidabilita’ (solo ~50% dei siti e’ davvero affidabile su tempi lunghi) E soluzioni Distribuzione del “dato” deve essere ottimale Per esempio, un “dato” che ci si apetti popolare, deve andare in siti affidabili Inoltre Se valore medio delle repliche e’ vicino a 1, si puo’ guadagnare flessibilita’ nel non avere del tutto repliche per I dati non popolari Necessita’ di sistemi esperti / ML per stimare a priori la popolarita’ di un “dato” Ma tutto questo puo’ non bastare Il miglior sistema esperto non e’ infallibile Gli utenti sono spesso non prevedibili

6 Soluzioni possibili 1.Aumentare lo spazio disco aumentando il numero di repliche NO 2.Mandare i jobs _anche_ dove non ci sono i dati Sia volutamente: user driven (nessun matching fra dati e cpu) Sia come extrema ratio (se i jobs aspettano di girare da 10 ore dove ci sono I dati, tanto vale provare a fare accesso remoto) Sia come failsafe ( I dati al sito locale ci dovrebbero essere, ma si e’ rotto qualcosa) 3.Tutto questo si applica anche all’analisi interattiva … vedi dopo 1.Se si sceglie accesso remoto di qualche tipo, ci sono comunque possibilita’ aperte 1.lazyDownload: un remote read fa si che tutto il file richiesto venga spostato localmente prima di procedere con l’attivita’ Sul WN (quindi perso alla fine del job) Su una cache locale (con una certa vita media) 2.Streaming: fopen si traduce in accesso remoto via rete con vari protocolli possibili Root WebDAV OneData…

7 CMS e ATLAS (ma anche ALICE, almeno) Situazione attuale Se un file non e’ disponibile localmente Cercarlo su uno storage streaming vicino (sostanzialmente Xrootd, ma potenzialmente anche WebDAV) Se non c’e’ vicino, cercarlo + lontano Se c’e’, accedervi via streaming root:// o https:// Iterare fino a che non arrivi al vertice della gerarchia, se non c’e’ neppure li’ -> File Open Error 1.Un file (non locale al sito) viene richiesto al redirettore italiano degli SE standard 2.Se disponibile, viene servito dall’SE di un altro sito italiano 3.Altrimenti, la richiesta viene passato al redirettore europeo e poi a quello globale (se quello europeo non ha il file) 4.Il file viene servito dal sito che lo ha, con preferenza per I siti europei

8 Costo "operazionale" della soluzione Ci sono vari tipi di costo operazionale 1.Possibile saturazione delle linee di rete se il file non arriva da “vicino” Link con l’India e’ facile da saturare Link con US non cosi’ facile, ma viste le risore dall’altro lato dell’oceano non impossibile Italia: tipicamente I nostri T2 hanno Banda su LAN > 10x 2.Possibile diminuzione drastica dell’efficienza CPU del job 1.Dipende da banda passante, tipo di job, meno dalla latenza se le cose sono fatte bene (Random read TTreeCache) Rete: oggi il traffico Xrootd in CMS ~20% del traffico globale. In crescita Vantaggi competitivo (inaccettabile?) delle nazioni meglio “connesse”

9 Random read: perche’ aiuta? Ci immaginiamo solitamente che l’organizzazione delle informazioni nei files Root sia ROW-wise (cioe’ temporale): Invece, leggendo le analisi solamente sempre gli stessi oggetti (p.e. solo i Muoni), si puo’ fare di meglio in modalita’ COLUMN- wise... Evento N Muoni Jets Evento N+1 Muoni Jets Evento N+2 Muoni Jets Fine file... Inizio file Sequential read … Lo leggo Non lo leggo Lo leggo Non lo leggo Lo leggo Non lo leggo …... Muoni Evento N Evento N+1 Jets Fine file... Inizio file Evento N+2 Evento N Evento N+1 Evento N+2 … Lo leggo … Non lo leggo Non Lo leggo Non lo leggo …

10 In realta’ Per fare da serie temporale (ROW-wise) a aggregazione per oggetti, quando scrivo file dovro’ tenere in memoria le info fino a che ci stanno per “ribaltarle” Non per ore! Altro vantaggio: avere in memoria oggetti naturalmente simili aiuta la compressione Quindi i random read serviranno comunque, almeno alla fine di ogni blocco... Fine file... Inizio file Muoni Evento N Evento N+1 Evento N+2 Jets Evento N Evento N+1 Evento N+2... Muoni Evento N+1000 Evento N+1001 Evento N+1002 Jets Evento N+1000 Evento N+1001 Evento N+1002 … Lo leggo … Non lo leggo Non Lo leggo Non lo leggo … Lo leggo … Non lo leggo Non Lo leggo Non lo leggo …

11 TTreecache: cosa e' e perche' funziona? Dato di fatto: se faccio analisi si 1 miliardo di eventi, e nei primi mille leggo le informazioni sui muoni, e’ probabile che nei restanti 1e9-1e3 … legga le informazioni dei muoni! In questo modo posso fare si’ che i pacchetti di rete che mi arrivino Siano grossi anche se chiedo pochi bytes “probabilmente” contengano anche le informazioni che starei per chiedere Fase di training Fase di prefetch... Muoni Evento N Evento N+1 Jets Fine file... Inizio file Evento N+2 Evento N Evento N+1 Evento N+2 Mi serve questo Chiedo anche questi supponendo che tanto poi mi serviranno

12 ANALISI piu’ veloce!!! Lo stesso meccanismo ha forse addirittura piu' senso per le fasi finali dell'analisi, dove il pattern e' tipicamente: Leggi delle Ntuple non necessariamente piccole: PROOF/MapReduce su 100 nodi e 50 TB Non necessariamente tutto quello che c’e’ dentro Alcuni contenuti sono per esempio solamente per degli studi speciali Cambia qualcosa Itera a piacere Le ntuple sono generalmente NON preplaced, spostamento a mano da parte dell'utente Una cache fa’ si’ che spostamenti veri geografici avvengano solo la prima volta Se c’e’ abbastanza cache e non va in trash

13 Caching locale??? Le cache esistono da tanto: Meccanismi on-demand per spostamento file su richiesta Gestione automatica del purge dei dati meno utilizzati quando si riempiono Esempio tipico per noi le caches squid per Frontier/CVMFS Pero’: Tipicamente le usiamo semplicemente per limitare accesso a servizi remoti (p.e. il software di esperimento) Sono piccole: Tutto il SW e tutte le condizioni “recenti” poche centinaia di GB Hanno access patterns chiari: Un file viene letto o non letto Un file viene letto in momenti particolari (p.e. inizio del job) Servono piu’ a proteggere I servizi remoti da DDOS che a ottimizzare le prestazioni

14 Si puo’ fare di meglio?? 1.Una cache deve essere adeguata come size 1.Cache flush continui peggio che accesso diretto streaming 2.Una cache puo’ essere anche non locale, ma diminuisce l’efficacia con la banda/latenza 3.In modalita’ di analisi tipica, un utente non legge la totalita’ del file, ma suo sottoinsieme (per esempio i Muoni ma non i Jet, etc, etc) 1.Una cache alla lazyDownload puo’ essere PEGGIO di accesso remoto streaming, e porta a flush piu’ frequenti 1.Una cache a livello NREN, in cui I link sono sotto a bassa latenza, e a banda ~ garantita aumenta lo spazio a disposizione con bassa penalty di distanza 2.Una cache block/branch/basket level (non files completi) diminuisce la penalty 3.Una cache che comunque interviene solo in caso di non disponibilita’ di dato presente non localmente, ma su scala NREN, diminuisce gli hit 4.Cache non accessibile da fuori Italia per non “sporcarla” con richieste per noi non interessanti

15 In questo modo, la cache sarebbe a “protezione” dell’esistenste storage italiano Questa modalita’ garantisce Utilizzo ottimale della cache Riempimento ottimale della cache (prima EU poi US) C’e da capire quanto debba essere grande per non essre soggetta a flush incontrollati Facciamo una stima 1.Un file (non locale al sito) viene richiesto al redirettore italiano degli SE standard 2.Se disponibile, viene servito dall’SE di un altro sito italiano 3.Altrimenti, la richiesta viene passata alla cache, che serve il file se ce lo ha; 4.Altrimenti lo chiede alla gerarchia EU/Global di CMS 5.E lo cacha (la parte rilevante) in una delle cache distribuite, preferendo quella + vicina alla richiesta 6.Il file viene servito dalla cache al job

16 Quanto deve esser grande una cache per avere senso? Caso di CMS, MiniAOD + AOD, dati + MC di un anno tipico (ATLAS simile) 5 Bevents Dati, 7 Bevents MC = 12 Bevents Size media dell’evento AOD = 300 kB; 50 kB MiniAOD TOT AOD = 4 PB; TOT MINIAOD = 600 TB Poi ci sono I dati derivati dell’utente, a cui si vuole accedere velocemente. Su scala nazionale facilmente 1 PB quelli totali; forse la meta’ quelli di interesse CMS usa una mixture di questi, per cui pochi AOD effettivamente acceduti (in proiezione), per cui diciamo 1 PB Storage nazionale “standard” ordine 7 PB, ma contiene Piu’ anni Piu’ versioni RAW data, RAW MC, … Visto che lo storage nazionale e’ 1/10 del totale, e ci sono ~ 2 copie dei dati -> hit rate solo del 20% Una cache di 1 PB/esperimento dovrebbe poter intercettare la gran parte delle richieste di “dati” che non siano gia’ sullo storage

17 Perche’ distribuita e non (per esempio) tutta al CNAF? CPU Italiane sono distribuite al momento CMS: 48 kHS06 al T1 84 kHS06 ai 4 T2 ATLAS: 47 kHS06 al T1 51 kHS06 ai 4 T2 Storage CMS: 3.9 PB at T1 (ma molto di questo per utilizzi “production like”) 4.5 PB ai T2 ATLAS: 4.2 PB at T1 (ma molto di questo per utilizzi “production like”) 5.0 PB ai T2 Rete: T1: 40 Gbit/s T2: ~100 Gbit/s Le risorse italiane NON sono prevalentemente al CNAF, perche’ metterci la cache? Inoltre, se questo “aggiunge” XX Gb/s di accesso di rete, meglio distribuirlo Quanto e’ XX? Jobs di CMS ~ 1-2 MB/s/job Jobs analisi in italia ~ 10000 -> 200 Gbit/s Parte di questo assorbita da storage locale Diciamo vogliamo fino a 100 Gbit/s dalla cache

18 NREN = LAN ? Chiaramente ancora non ci siamo: tutti i nostri T2 sono a 10 Gb/s verso GARR (pochi a 20) Esempio di Pisa: Traffico LAN misurato oltre 12 GB/s verso lo storage – ma soprattutto per attivita’ di produzione Fattore 6 di WAN 100 Gbit/s sarebbe oggi indistinguibile (latenza a parte …) dalla LAN CNAF: 80Gbit/s (?) Solo CMS ha fatto 18 GB/s verso lo storage (quindi fattore 4 …) Lato US: Tutti i T2 a 100 Gbit/s da almeno un paio di anni Upgrade a 200 Gbit/s “imminente” In queste condizioni WAN = LAN non e’ lontano

19 Costi (2 esperimenti LHC) Storage “classico”: 200 kEur/PB: 400 kEur Diviso su almeno 5 siti (totali) = 400 TB/sito Da ogni cache di sito vogliamo a regime ottenere ~50 Gbit/s (si puo’ partire tranquillamente con 10, anche perche’ la rete sotto oggi non c’e’) Non del tutto banale con queste cifre … da studiare Contatti con E4 e DELL per capire 5 server @ 10 Gbit/s per sito In attesa di avere i 40 e/o i 100 su LAN 5x5x5keur = 125 kEur Sviluppo Dipende dalla soluzione (Xrootd o meno). Nel caso di Xroot di pezzi ci sono tutti, e’ soprattutto attivita’ di integrazione/test nota: Xrootd devel confermano che Una cosa del genera ancora non e; stata provata (Feb 2016) E’ interessante dal lato loro quindi darebbero supporto) 0.5 FTE in totale per un anno? Diciamo 30 kEur Tutto cio’ acquisisce senso vero solo in presenza di un’upgrade della rete GARR a ~ 100 Gbit/s Costo non inserito qui 600-1000 kEur??

20 Chi paga? Realizzazione Sostanzialmente irrilevante a questo livello di proposta tecnica MA: ci sono delle linee di finanziamento al di fuori di quelle standard INFN (Giunta e CSNX) potenzialmente accessibili Sinergie con GARR? IPCEI? Progetti Comuni ITA/US? Xrootd unica possibilita? No, ma la piu’ facile per ora vista l’esperienza dei gestori dei siti WebDAV? Alternativa semplice, anche semplicemente per il fatto che Xrootd ha ancheun demone HTTPD internamente DynaFED (CERN): soluzione esistente per realizzare la gerarchia. Cache potrebbe al limite essere gestita via varnish standard (anche block level?) INDIGO/OneData? Interessante ma sostanzialmente inesplorato per ora a parte chiaccherate al caffe’

21 Conclusioni Un approccio di caching regionale presenta molti vantaggi rispetto ad una cache locale ◦Maggiore spazio complessivo a disposizione ◦Possibilita’ di smart placement dei dati (vicini all’utente) ◦In presenza di una rete GARR adeguata, latenza non e’ un problema Costo contenuto, interesse multiplo ◦Rendere la vita piu’ facile ai nostri analisti ◦Interesse tecnologica, in vista della sostanziale rottura della gerarchia Monarc Una cache di questo tipo puo’ servire da prototipo per T2 o T3 diskless ◦Con solo parte di cache locale ”vicino”, o addirittura che si appoggino solo a quella distribuita Una struttura di questo tipo e’ importante per sfruttare opportunita’ di calcolo opportunistico ◦Dove tipicamente vengono offerte CPU, ma non storage ◦Ma facilmente utilizzabile anche in caso di storage “opportunistico”, visto che il contenuto di auto-tuna allo spazio disponibile