Estensioni elastiche CNAF – un po’ di idee e status report

Presentazione sul tema: "Estensioni elastiche CNAF – un po’ di idee e status report"— Transcript della presentazione:

1 Estensioni elastiche CNAF – un po’ di idee e status report

2 Possibilita’ attuali Aruba CloudItalia Unicredit Microsoft (INDIGO)
Tecnicamente ok, in produzione a lungo Ora stop tecnico (sembrano non risponderci piu’ alle mail/telefonate  Gaetano) CloudItalia Volendo deployment uguale ad Aruba, ma si puo’ osare di piu’ Unicredit Naufragata per mancanza di iteresse (anche da parte nostra – poche risorse) Tecnicamente fattibile utilizzando setup INDIGO-like Microsoft Grant di 20k$ arrivato (INDIGO) Un po’ di dettagli …

3 Possibilita’ tecniche (WM)
Estensione elastica LSF Completamente trasparente a tutto (tutte le VO) LSF non ha modalita’ WAN: serve VPN o simile Bari: fatta dal GARR a livello rete Aruba: kernel level (dynfarm, in-house) – NAT irrilevante Accounting garantito centralmente da APEL+LSF+Cream Estensione elastica HTCondor HTCondor ha una modalita’ WAN (via CCB – anche su risorse NAT) LSF in tempi medio lunghi dovra’ essere comunque dismesso ($$$), HTCondor appare la soluzione piu’ ovvio al momento anche per le risorse locali HTCondor come batch system puo’ essere affiancato a Cream (ATLAS?) o a HTCondorCE o ad ARC Mi pare di capire che se si fa il salto si vuole farlo tutto  Soluzione all HTCondor Accounting dipende dall’accoppiata CE-HTCondor usata Tutte pero’ sono funzionanti in qualche parte del mondo HTCondor Startd diretto Funziona solo per le VO che usano un global pool di esperimento E’ completamente staccato dal CNAF, per quanto riguarda WM Ha problemi di autenticazione non irrilevanti Accounting da inventare – al momento fa solo quello di Esperimento

4 Possibilita’ tecniche (accesso ai dati) - #1
Accesso completo GPFS esportato WAN (con o senza AFM) Necessita di DMZ fra I siti (o almeno, meglio che ci sia…) Necessita di storage di caching (se AFM) molto performante E’ dove e’ fallito a Bari (e per scrivere??) Accesso streaming diretto Per noi vuol dire sostanzialmente Xrootd e potenzialmente WebDAV Entrambi potrebbero essere montati Posix, ma con non pochi problemi Non tutte le VO pronte ad utilizzare il sistema (e per scrivere???)

5 Possibilita’ tecniche (accesso ai dati) - #2
Caching! La cosa si fa complessa … Si vuole cachare solo il disco CNAF verso il sito remoto, e altrimenti utilizzare i meccanismi di fallback standard? (quindi come se la macchina fosse dentro il CNAF....) E’ ok per tutte le VO E’ ok per fallback Xrootd di LHC se la rete WN-LHCONE e’ decente e non a pagamento AFM dovrebbe essere ok, ma anche Xrootd proxy verso server CNAF, o comunque qualunque cosa che sappia “riempirsi” utilizzando protocolli che CNAF esporta Si vuole cachare tutto l’incoming traffic? + difficilmente ok per tutte le VO Ha bisogno di conoscenza su dove andare a prendere il file in caso di cache-miss Quindi probabilmente deve allacciarsi ad una federazione

6 Soluzioni tecniche identificate
GPFS/AFM Gia usata con Bari; in pratica caching asincrono intelligente (per block) dei files del CNAF (usabile in scrittura?) Protocollo = Posix Xrootd Caching sia dello storage CNAF, sia di “tutto” se via federazione Facile da implementare, ma aiuta solo se protocollo di accesso lato utente e’ Xrootd Varnish Caching di HTTPS (e quindi di WebDAV); testato in una certa misura al CERN Caching trasparente: client richiede il file alla destinazione finale (via federazione?) DPM Ultima versione capace di cachare https/Xrootd/…. O caching dello storage CNAF solamente, o di “tutto” via federazione Ufficialmente supportato come test da DPM developers Idee da testare con CloudItalia

7 Per LHC il mondo e’ piu’ semplice…
… Se c’e’ abbondante rete (Geant/Garr/Whatever ma tanta) … Se si accede a tutto via Xrootd/WebDAV ... Se la scrittura avviene in altro modo (SRM verso l’endpoint Storm CNAF o simili) In realta’ non serve molto, basta fidarsi del fallback Xrootd, magari in modo intelligente Primo fallback = CNAF Secondo fallback = Federazione

8 Oppure un caching trasparente
Quello di cui si era parlato all’ELBA: QUI Caching nel POP della NREN (Xrootd per esempio), quindi la cache dal punto di vista dell’utente diventa un pezzo dell’infrastruttura di rete Molto Netflix-like Caching intelligente: block level, con TTreeCache dal lato utente Latenza in pratica azzerata, banda non un problema Questo sarebbe probabilmente il test piu’ interessante da fare, ma servirebbe collaborazione con GARR …

9 INDIGO – cosa stiamo facendo
CMS diventato un use case ufficiale di INDIGO in WP2: “Seamless instantiation of on-demand, opportunisticLHC/CMS computing centers” Idea e’ la terza: HTCondor connesso direttamente al Global Pool di esperimento TX on demand: TOSCA template definisce il sito (N WNs, M Squids, ….) Macchine istanziate via Marathon e Mesos Creazione di siti dal nome qualunque, via template (T3_Tommaso_This_week) Utilizzo di tools standard di CMS (CRAB) per mandare jobs (possibile utilizzo di OneData come storage per le ntuple risultanti) Quasi funzionante Manca lato TOSCA Manca lato OneData

10 Use case tipici alla INDIGO
Estensione elastica di un sito Risorse opportunistiche temporanee I sysadmin creano in INDIGO un sito virtuale, con lo stesso nome di quello reale. I WN del sito remoto virtuale si sommano dal punto di vista del global pool a quelli locali, senza nessuna distinzione Un gruppo di ricerca ottiene N cores per M giorni grazie ad un grant Con un sito on demand, dal nome specifico, puo’ utilizzare I tools di CMS per mandarce dei jobs senza concorrenza con gli altri standard