Cloud Computing in WLCG Alessandro De Salvo A. De Salvo – 11 July 2014

Resource Provisioning 2

Dynamic provisioning  La creazione dinamica di VM permette al cluster di scalare automaticamente  Rendendolo di fatto simile a una infrastruttura Grid  Problemi da risolvere:  Distribuzione delle immagini (per VO? per sito? “golden image”?) e la contestualizzazione  Funzionamento in regime saturato  … SaaS PaaS IaaS VMs on demand 3

Esempio: Cloud Computing in ATLAS  Scopo  Integrare le risorse di Cloud con quelle Grid già esistenti  Aspetti principali del data processing e workload management  Code di PanDA nelle Cloud  Management centralizzato  Benefici per ATLAS e per i siti, trasparente agli utenti  Tier3 analysis clusters: instant cloud sites  Gestiti dagli istituti, bassa/media complessità  Personal analysis queue  Gestite dagli utenti, bassa complessità e trasparenza quasi totale  Storage  Caching a breve periodo per accelerare il processamento degli use case di cui sopra  Dati temporanei  Object storage e archivio nella Cloud  Integrazione con il DDM 4

Cloud Computing e PanDA  Situazione attuale  Essenzialmente utilizzato per produzione di MC su Cloud  Funzionante  Testato con vari tipi di cloud (Amazon, HelixNebula, Magellan, OpenStack, …)  Integrato con Panda  Utilizzo di CVMFS per la distribuzione del software e macchine virtuali CERNVM su KVM o Xen Jose Caballero, John Hover, Xin Zhao 5

Integrazione con il framework ATLAS Nei test su AI la VM e’ creata staticamente 6

Integrazione con il framework M.Sgaravatto VM creata dinamicamente 7

Integrazione con il framework 8  Piani a lunga scadenza  Sottomissione adattiva verso provider, ad esempio:  Sottomissione di VM inizialmente verso provider liberi e/o provider locali, fin quando non vengono riempiti  Sottomissione di VM verso provider tipo EC2 (spot)  In caso di grossa richiesta, sottomissione verso provider più costosi, ad esempio EC2 on-demand  Processo inverso durante il ramp down o pause nel workload. Nei test a BNL la VM e’ creata Dinamicamente (evoluzione della APF)

Integrazione con il framework Integrazione con Dirac 9

Integrazione con il framework 10

Integrazione con il framework ALICE - Ståle Nestås, Joachim Carlsen 11

Ambiente  Per tutti gli esperimenti alcune componenti diventano essenziali per avere immagini simili su siti diversi:  Accesso remoto ai dati, ad esempio via xrootd  Eliminata la necessita’ di complicate configurazioni dipendenti dal sito e di localita’ dei dati  Il modo per ottimizzare l’accesso locale esiste (tramite la contestualizzazione) ma e’ potenzialmente complicato  Accesso al software di esperimento tramite CVMFS  Anche in user space via Parrot o simili 12

Ambiente  Necessario comunicare al cliente le caratteristiche della macchina allocata (cores, memoria, …)  Necessario gestire la durata dell’allocazione  Che deve essere piu’ lunga per compensare le inefficienze di start e stop delle VM  WLCG Job/Machine features working group  Uso di files visibili dal pilot job o dalla VM (ad es. sul drive virtuale della VM o dal magic-IP) per passare informazioni 

Jobs in the Vacuum (LHCb)  Eliminata la fase della richiesta di risorse  Si assume il pledge dell’esperimento come richeista permanente (target share)  Meccanismi per recuperare le risorse non usate da una VO e ridistribuirle ad altri  14

 Attività CERN  Basata su OpenStack (Essex, Folsom, Grizzly, …)  Puppet e Foreman per la gestione  Previsti 15K HV / 300K VM nel 2015  Nel 2015 si prevede di fornire le risorse via OpenStack e non più via LSF  Tier-0 distribuito  CERN, Wigner  Migrazione verso gestione con tools Cloud   Agile Infrastructure 15

Wigner Data Centre 16 The sites are connected by 2 independent 100 Gbps circuits.  Primo utilizzo delle risorse di Wigner ad inizio luglio 2014  Tenant dedicato  Utilizzo delle risorse di Wigner in modo analogo a quelle di Meyrin  Ancora nessun risultato quantitativo sulle prestazioni

Wigner Data Centre 17

Testing su CERN AI (file open error) 18

Testing su CERN AI 19

Testing su CERN AI e non solo 20

Ancora testing ATLAS 21

Google Compute Engine  Jobs compute-intensive  Infrastruttura statica  Alta efficienza  Remote access  Test di ATLAS su Google Compute Engine  4K cores per due mesi 22

Utilizzo delle farm Online durante LS1  Le farm HLT di ATLAS e CMS sono usata come un “sito” Grid opportunistico durante LS1  > 30k core, corrispondenti ad un grande T2 (se non un T1)  Infrastruttura overlay di tipo Cloud basata su OpenStack  CERN IT (Agile), CMS (HLT Farm) e BNL già utilizzano OpenStack 23

Farms online  Installato OpenStack - risorse rese disponibili quando possibile  Disaccoppiamento con l’ambiente online  Risorse ingenti (paragonabili a quelle dei Tier-1)  Disponibili fuori dalla presa dati ATLAS CMS 24

Farms online - ATLAS 25

Farms online - ATLAS 26

Farms online - CMS 27

T3 analysis clusters  Nuove tecnologie all’orizzonte per i cluster di analisi nei T3  Cloud Computing e T3 virtuali  Federazioni di storage e caching per ridurre la pressione sul data management  Xrootd e HTTP  Accesso dati su WAN  Il codice utente deve essere migliorato per ridurre le latenze  Disaccoppiamento dello Storage e della CPU  Testbed  Cloud pubbliche (EC2, Google)  Cloud di ricerca (Future Grid, HelixNebula)  Cloud private (basate su OpenStack, OpenNebula) 28

EGI-InSPIRE RI T3 PanDA clusters PanDA analysis clusters on GCE+FutureGrid+AWS (Doug, Henrik, Val) Usage of puppet Node configurations (CVMFS, xrootd, condor, PanDA, etc.) Cluster orchestration Investigating whether puppet can also be used for scaling the size of the cluster Open questions: What is the scale of the virtual clusters? From personal analysis cluster to multi-institution analysis cluster Masterful vs. master-less setups – what is the easiest for the researcher? Proxies for Panda Pilots (personal or robotic) How is the data handling and caching done? Initial activity used Federation storage as source What is the latency incurred by this dynamic system? What is the performance penalty of virtualization? 5/30/2016 Cloud Computing Summary

EGI-InSPIRE RI T3 PROOF clusters T3 type PROOF/Xrootd cluster on Google Compute Engine (Sergey) D3PD based physics analysis 64 nodes with ~500 cores 180TB of ephemeral storage Studying data transfer using DQ2, xrdcp and direct read Plan to study scalability of PROOF workload distribution system at very large number of nodes Interest from UT-Austin ATLAS group in personal cluster solution (Peter Onyisi) Recent activity Looking at very interactive use case (more PROOF than PanDA) TACC Alamo FutureGrid hosted resources 5/30/2016 Cloud Computing Summary

EGI-InSPIRE RI Helix Nebula: The Science Cloud European Cloud Computing Initiative: CERN, EMBL, ESA + European IT industry Evaluate cloud computing for science and build a sustainable European cloud computing infrastructure Identify and adopt policies for trust, security and privacy CERN/ATLAS is one of three flagship users to test a few commercial cloud providers (CloudSigma, T-Systems, ATOS...) Agreed to run MC Production jobs ~3 weeks per provider First step completed: First step completed: Ran ATLAS simulation jobs (i.e. small I/O requirements) on CloudSigma 31Fernando H. Barreiro Megino (CERN IT-ES) 31

EGI-InSPIRE RI Experiment tests on CERN AI PanDA production jobs in 12 hours 5/30/2016 Cloud Computing Summary

Cloud computing in ATLAS US  Soluzione Open Source  OpenStack  Puppet  Boxgrinder  BNL_CLOUD: Standard production PanDA site  La coda può essere estesa in modo trasparente verso Amazon o qualiasi altra Cloud accademica  Esecuzione sostenuta di circa 200 job slot  Auto esclusione di HC abilitata  Performance paragonabili e talvolta anche superiori del sito principale di BNL  Esecuzione ibrida OpenStack/EC2 per un breve periodo  Picchi fino a ~5000 job slots BNL_CLOUD faster than BNL_CVMFS_1 (wallclock 1740s vs. 1960s) Hammercloud (ATLASG4_trf_7.2...) Setup time (no AFS)? No shared filesystem? Similar spread for other tests (e.g., PFT Evgen ) Anticipate using Iljia’s HC framework to conduct more tests 33

NeCTAR: National eResearch Collaboration Tools and Resources  Progetto sponsorizzato dal governo australiano (47M$)  Costruzione di una nuova infrastruttura destinata alla ricerca in Australia  Si aggiunta alla capacità dei Tier2 australiani di ATLAS  Costruzione di una federazione di T3 per High Throughput Data Analysis  Infrastruttura IaaS con circa core su 8 siti basata su OpenStack 34

Il framework del T2 Nectar Code di produzione e analisi di PanDA Australia-NECTAR e ANALY_NECTAR 160 core utilizzati da job di produzione di ATLAS Code di produzione e analisi di PanDA Australia-NECTAR e ANALY_NECTAR 160 core utilizzati da job di produzione di ATLAS 35

Il T3 federato Nectar 36

Cloud Pubbliche: EC2  Risorse On-Demand  Si paga il prezzo standard.  Le risorse non sono mai terminate, ma non è garantito il loro start  Spot  Si dichiara il prezzo massimo  Si paga il prezzo variabile (spot price)  Quando il prezzo dello spot eccede il massimo fissato l’istanza è terminata senza preavviso  Si è visto che anche con richieste medie in dimensione (~5000 nodi) a volte non è possibile ottenere il numero di istanze che si desidererebbe  Problemi  La memoria è assegnata in unità di 1.7GB, meno dello standard WLCG di 2GB  Condor ora supporta la sottomissione di job su istanze di tipo spot-price  Attraverso richieste di singole istance di tipo spot 37

38 Amazon EC2 Pricing Options

Considerazioni su EC2  Servizio e addebito  I nodi spot vengono terminati senza avvertimento  Le ore parziali di computing non vengono addebitate  Possibili scenari  Running di job inferiori alle 2 ore (o addirittura 1 ora)  Flag dedicata nei sistemi di produzione che faccia considerare i “lost hearbeats” causati dallo spegnimento improvviso delle macchine come aspettati piuttosto che job falliti  Processamento e stage-out per-evento (es.: event server di ATLAS) 39

EGI Federated Cloud  A community of providers  Defines a set of required function  Common Interface (OCCI)  Including x509 support  Pre-uploaded images (CernVM via AppDB)  Integrated Accounting (APEL and the Portal)  Support network for sites  Infrastructure operations L. Field 40

Attività future  Finalizzazione dell’integrazione coi sistemi attuali basati su Grid (che non scompare)  Federazioni di Cloud – test di nuove infrastrutture  Utilizzo di risorse sature (shares and all that…)  Accounting, monitoring  Comunicazione provider -> client  Service discovery e servizi “location aware”  Integrazione con risorse opportunistiche e volunteer computing 41

Accesso ai dati: Storage Federation  Le tecnologie di cloud per il momento non sono ancora mature a livello di performance per fornire un livello di servizio adeguato per il calcolo di WLCG  La situazione tuttavia sta evolvendo in modo molto rapido  Una valida soluzione per ovviare al problema è quella di utilizzare le fedarazioni di storage, o “Storage Federations”  Poco codice necessario da sviluppare da parte degli esperimenti  Prodotti maturi, esistnti da molto tempo sul mercato  Tecnologie comuni tra gli esperimenti LHC  Ad esempio ATLAS, CMS ed ALICE usando già da molto tempo XrootD  Efficienti a livello di file discovery  Utilizzo semplice con framework di analisi quali Root e compatibili con tutti I formati di largo utilizzo  Team di sviluppo molto collaborativi e spesso anche direttamente coinvolti nelle attività degli esperimenti 42

Configured regional redirectors in ATLAS all.role manager all.manager leftregion:1234 all.manager meta xyzzy:1234 xrootd.redirect xyzzy:1234 ? / all.role manager all.manager rightregion:1234 all.manager meta xyzzy:1234 xrootd.redirect xyzzy:1234 ? / Global Redirector Regional Redirector Local RedirectorProxy ServerProxy ManagerLocal Redirector ServerProxy ServerServer all.role meta manager all.manager meta xyzzy:1234 all.role manager all.manager lefthand:1234 all.manager meta leftregion:1234 xrootd.redirect leftregion:1234 ? / all.role manager all.manager righthand:1234 all.manager meta rightregion:1234 xrootd.redirect rightregion:1234 ? / all.role server all.manager leftregion:1234 ofs.osslib psslib.so pss.origin mycluster:1094 all.role proxy manager all.manager meta leftregion:1234 xrootd.redirect xyzzy:1234 ? / Site DSite ASite BSite C Andrew Hanushevsky (SLAC) XrootD redirectors 43

Xrootd and CMS Software  Layered data access configured in CMSSW  Regional redirectors already active  UNL (Nebraska) for US sites  Bari for EU sites  CERN will soon publish EOS/CAF via Xrootd I need ‘store/foo’ I try local access (via ‘direct’ protocol) … if not found I try accessing a first level redirector (national, for example)… if not found …..… I scale up to the global redirector 44

Distribuzione dinamica del software tramite CVMFS (CernVMFileSystem) Virtual software installation tramite un File System HTTP Distribuzione di file binary in sola lettura I file e I meta dati sono scaricati e inseriti in una cache locale Self-contained (ad esempio /cvmfs/.cern.ch), non interferisce con il file system locale Possibilità di rilocazione In uso da tutti gli esperimenti di WLCG e oltre CVMFS 45

 Mirror servers  Web servers listening on port 80, 8000  Proxy servers  Local load-balanced Squid forward proxy (Squid) CVMFS backends 46

CERNVM  The OS files over CVMFS  Replicates a reference file system using HTTP  Stratum 0  50MB OS vs 460MB for ATLAS  Why?  Because CVMFS is the solution  Removes the overhead of distributed version management  Single place for version control  CernVM is therefore a common requirement  Availability becomes an infrastructure issue  Recipe is the responsibility of the VO  Each needs to define an internal function/role  The goal is to start a CernVM-based instance  And contextualize  A small delta L. Field 47

 VAC  Site-controlled bare metal provisioning  V-Cycle  VAC for OpenStack tenants  Cloud Scheduler  Condor-based VM control  glideinWMS  Glidein factory for clouds  AliEC2  Lifecycle management using EC2  BOINC  Extra capacity for certain classes of job  … Cloud Tools L. Field 48

VAC 49

VAC 50

Cloud Scheduler 51 F. Berghaus

Cloud Scheduler 52 F. Berghaus

Cloud Scheduler 53 F. Berghaus

GlideIN WMS 54 S. Padhi

Frontier 55 D. Dykstra

Frontier 56 D. Dykstra

Frontier deployment model 57 D. Dykstra

Shoal 58 F. Berghaus

HTTP Federations 59 F. Furano

HTTP Federations 60 F. Furano

HTTP Federations 61 F. Furano

HTTP Federations 62 F. Furano

Boinc  The Berkeley Open Infrastructure for Network Compting (BOINC) allows scientists to harness computing power from thousands of volunteer PCs for their scientific computing projects  The clients connect to a central BOINC server via the web and download jobs from there  When the computations on the volunteer PC are finished, the resulting output files are uploaded to the BOINC server and the results reported  The user gets BOINC Credit for his work 63

Home 64

Utilizzo dei tool di Cloud in WLCG ALIC E ATLASCMSLHCb HLT  CernVM  Ganglia  VAC  BOINC  65

Home 66

Conclusioni 67  Il calcolo di WLCG si sta spostando sempre di più sul Cloud Computing  Per tutto il Run2 di LHC non si cambieranno i modelli in modo sostanziale e pertanto il sistema principale continuerà ad essere quello Grid  Le tecnologie Cloud, sia di calcolo che di storage, rappresentano il futuro vicino per la fisica delle Alte Energie