Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoAlberta Nicolina Pasini Modificato 8 anni fa
1
Cloud Computing in WLCG Alessandro De Salvo 11-7-2014 A. De Salvo – 11 July 2014
2
Resource Provisioning 2
3
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
4
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
5
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
6
Integrazione con il framework ATLAS Nei test su AI la VM e’ creata staticamente 6
7
Integrazione con il framework M.Sgaravatto VM creata dinamicamente 7
8
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)
9
Integrazione con il framework Integrazione con Dirac 9
10
Integrazione con il framework 10
11
Integrazione con il framework ALICE - Ståle Nestås, Joachim Carlsen 11
12
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
13
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 https://twiki.cern.ch/twiki/bin/view/LCG/MachineJobFeatures https://twiki.cern.ch/twiki/bin/view/LCG/MachineJobFeatures 13
14
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
15
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
16
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
17
Wigner Data Centre 17
18
Testing su CERN AI (file open error) 18
19
Testing su CERN AI 19
20
Testing su CERN AI e non solo 20
21
Ancora testing ATLAS 21
22
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
23
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
24
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
25
Farms online - ATLAS 25
26
Farms online - ATLAS 26
27
Farms online - CMS 27
28
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
29
www.egi.eu EGI-InSPIRE RI-261323 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 11.12.201229
30
www.egi.eu EGI-InSPIRE RI-261323 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 11.12.201230
31
www.egi.eu EGI-InSPIRE RI-261323 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
32
www.egi.eu EGI-InSPIRE RI-261323 Experiment tests on CERN AI PanDA production jobs in 12 hours 5/30/2016 Cloud Computing Summary 11.12.201232
33
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 16.6.5) Anticipate using Iljia’s HC framework to conduct more tests 33
34
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 25000 core su 8 siti basata su OpenStack 34
35
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
36
Il T3 federato Nectar 36
37
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
38 Amazon EC2 Pricing Options
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
Mirror servers Web servers listening on port 80, 8000 Proxy servers Local load-balanced Squid forward proxy (Squid) CVMFS backends 46
47
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
48
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
49
VAC 49
50
VAC 50
51
Cloud Scheduler 51 F. Berghaus
52
Cloud Scheduler 52 F. Berghaus
53
Cloud Scheduler 53 F. Berghaus
54
GlideIN WMS 54 S. Padhi
55
Frontier 55 D. Dykstra
56
Frontier 56 D. Dykstra
57
Frontier deployment model 57 D. Dykstra
58
Shoal 58 https://wiki.heprc.uvic.ca/twiki/bin/view/Main/ShoalAgentSquidInstallation F. Berghaus
59
HTTP Federations 59 F. Furano
60
HTTP Federations 60 F. Furano
61
HTTP Federations 61 F. Furano
62
HTTP Federations 62 F. Furano
63
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
64
ATLAS @ Home 64
65
Utilizzo dei tool di Cloud in WLCG ALIC E ATLASCMSLHCb HLT CernVM Ganglia VAC BOINC 65
66
ATLAS @ Home 66
67
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
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.