ATLAS: cloud computing & dynamic allocation Alessandro De Salvo A. De Salvo – 31 maggio 2013

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

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

Utilizzo della farm HLT durante LS1  La farm HLT di ATLAS verrà usata come un “sito” Grid opportunistico durante LS1  ~14k 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 4

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)

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 6Fernando H. Barreiro Megino (CERN IT-ES)

EGI-InSPIRE RI Experiment tests on CERN AI Experiment tests started end of October Successful setup after ~2 weeks, including training of technical student (Katarzyna Kucharczyk) PanDA production jobs in 12 hours 5/30/2016 Cloud Computing Summary

Cloud computing in 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

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

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

Il T3 federato Nectar

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 ATLAS di 2GB  Condor ora supporta la sottomissione di job su istanze di tipo spot-price  Attraverso richieste di singole istance di tipo spot

13 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 in ATLAS  Running di job inferiori alle 2 ore (o addirittura 1 ora) tramite il Production System  Flag dedicata nelle code Cloud in PanDA che faccia considerare i “lost hearbeats” causati dallo spegnimento improvviso delle macchine come aspettati piuttosto che job falliti  Processamento e stage-out per-evento, tramite un event server

Condor Scaling Test (1)  Test di scaling su Amazon  Grant di 50k$ in US  Test di scaling di migliaia di nodi tramite WAN  Determinazione empirica dei costi  Primo test effettuato  Singolo host di Condor (schedd, collector, …)  Singolo processo per ogni daemon  Autenticazione con password  Condor Connection Broker (CCB)  Risultati del primo test di scalabilità  Max ~3000 nodi  Il load del collector ha causato timeout del demone di schedd  Troppe connessioni di rete, maggiori del limite massimo degli open file  Duty cycle del collector ~0.99

Condor Scaling Test (2)  Secondo test effettuato  Schedd, collector, negotiator, CCB separati  20 processi di collector  Startd configurati per scegliere in modo random un collector  Abilitazione del reporting dei collector, in modo tale che tutti I sub-collector riportino ad un collector top-level  Aumento del numero di file aperti a 1M nell’OS  Abilitazione delle porte condivise dei demoni su tutti I nodi  Multiplexing delle connessioni TCP  Decine di connessioni piuttosto che migliaia  Abilitazione dell’autenticazione delle sessioni, in modo che ogni connessione dopo la prima salti il controllo di autenticazione della password  Risultati del secondo test di scalabilità  Operazioni fluide fino a ~5000 startd, anche con grandi burst  Nessun degrado delle operazioni dello schedd  Duty cycle del collector ~0.35  Buon margine di miglioramento  Con 7 startd si potrebbe teoricamente arrivare fino a slot con poco load aggiuntivo

Condor Scaling Test (3)  Risultati complessivi  ~5000 nodi operativi per molte settimane  Esecuzione di job di produzione (simulazione)  Stage in/out a BNL  Circa 13k$ spesi, di cui 750$ per trasferimento dati  Basso tasso di fallimenti dovuto alla chiusura delle VM  Il prezzo praticato in questa occasione da Amazon per gli spot è molto basso, minore di 0.01$/h per istanze di tipo m1.small  La soluzione sembra “competitiva” anche se non ci sono ancora delle statistiche solide di costo/efficienza

Allocazione delle risorse 18  Stato corrente  Management statico delle VM  APF è operativo con istanze EC2 (spot) e Openstack da ~3 mesi  Attraverso il plugin "KeepNRunning”  2 code di AutoPyFactory (APF)  La prima coda (standard) osserva una coda di Panda, sottomette pilot ad un pool locale di Condor  La seconda coda controlla il pool locale di Condor, sottomettendo WN virtuali verso una Cloud IaaS quando i job sono idle  Gli startd di Condor nei WN effettuano il join verso il pool locale di Condor  Le VM sono identiche, non hanno bisogno di IP pubblici e sono totalmente scorrelate  I Panda Site (e.g. BNL_CLOUD, CERN_CLOUD, …) sono associati agli storage e agli LFC di altri siti  Il software viene utilizzato tramite CVMFS  Shutdown attraverso la disabilitazione della coda e/o operazioni manuali (condor_rm) dei job nelle VM

Allocazione dinamica delle risorse 19  Piani a breve termine  Dynamic draining/ramp-down  Richiede una correlazione di quale VM corrisponde a quale Condor execute host  APF invia un comando 'condor_off --peaceful' per effettuare il drain  APF si accorge quando un intero nodo è idele e lo termina  Codice esistente, già utilizzato  Necessaria integrazione con il sistema generale  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.

Conclusioni  ATLAS sta valutando o già utilizzando sia soluzioni Cloud private che Cloud commerciali a basso costo o gratuite  Utilizzo di VM allocate staticamente in una cloud è stato ampiamente dimostrato in produzione (includendo anche la farm HLT)  ATLAS si concentrerà ad ottimizzare la gestione dinamica delle risorse di calcolo attraverso delle interfacce di provisioning di VM (ad esempio OpenStack)  Il piano consiste nell’integrare la AutoPilot Factory 2 con OpenStack/EC2  Si lavorerà sull’ottimizzazione del workflow per l’utilizzo di risorse opportunistiche  Nuovo “event server”, ossia il dispatcher di eventi per la parallelizzazione dei task, molto utile in questo ambito  Attività Cloud in parallelo con la valutazione di utilizzo di risorse di tipo HPC, ma alcuni problemi  Whole-node scheduling  Assenza di disco nei nodi  Nessuna connessione outbound 20

Backup slides 21

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