Esperienza di Elastic Computing al Tier 1 Vincenzo Ciaschini & Donato de Girolamo CCR 16-20/5/2016

Indice Contenuti: ◦ Idea e Architettura ◦ Il prototipo ◦ La produzione

PARTE 1 Idea e Prototipo

Descrizione Problema: Fare offloading del carico al CNAF durante i picchi di utilizzo ◦ È possibile prendere risorse esterne al CNAF e utilizzarle come se fossero interne?  Cioè utilizzabili con tutte le interfacce e gli strumenti di gestione a disposizione del Tier1? Liberare risorse pregiate locali SI.

L’idea Prendiamo una macchina remota. ◦ Pezzo di ferro, VM o container. Creiamo un tunnel VPN host-to-host con un VPN server interno al CNAF. Configuriamole come se fossero interne. Creiamo dei tunnel GRE tra il VPN server e altre risorse interne del CNAF per permettere mutua visibilità tra risorse remote e locali (Es: LSF server, CE) Siamo pronti ad usarle

Architettura VM VPN Server Batch server CE INTERNET GRE Conf Server VPN Configurazione

In Dettaglio La macchina fa il boot VM contatta un configuration server per chiedere come configurarsi Conf server spedisce configurazione e indirizzi del VPN server + configurazione generale Inoltre il configuration server spedisce comandi che vengono eseguiti sulla macchina remota. A questo punto il configuration server è fuori dai giochi. VM Contatta il VPN server e entra nella rete e ha visibilità SOLO DEI NODI NECESSARI Il Batch System prende carico del nuovo nodo VM completa la configurazione (route verso altri nodi (ce), etc…) VM funzionante e parte della farm

Requisiti sulla macchina remota Outbound connectivity. ◦ In particolare NON e’ necessario un indirizzo pubblico. Poter eseguire comandi come root. ◦ Necessario per poter creare la VPN. ◦ E per configurare la macchina. 2 rpm per gestire la connessione al configuration server all’avvio della macchina. ◦ Banale se VM o container vengono forniti da noi. È tutto.

Vantaggi Semplicità ◦ Requisiti minime sulle macchine remote. Traffico di rete minimo: ◦ Sulla VPN passa solo il traffico NECESSARIO al funzionamento del batch system. Isolamento: La macchina remota vede SOLO le risorse rese esplicitamente visibili dal Sito. Dinamicità: Servono più risorse? È sufficiente far partire più macchine remote. (virtual machine o docker container) Indipendente dal particolare Batch System.

Ringraziamenti Desideriamo ringraziare l’Università di Pisa e in particolare la persona di Maurizio Davini per il supporto e la messa a disposizione di macchine per lo sviluppo del sistema.

PARTE 2 Il Prototipo In collaborazione con il Tier 1 e il Tier 3 di Bologna

Prototipo con T3-BO e CMS Collaborazione con T1 e T3-BO per utilizzare questo meccanismo con i job di CMS ◦ OpenStack del CNAF come sorgente di machine remote. ◦ Risultati presentati al workshop CCR di Maggio 2015 a Frascati come work-in-progress e come risultato finale a ISGC 2016 da Giuseppe Codispoti Seguono brevi slide da quelle presentazioni (lievemente editate ed usate con permesso)

Una Collaborazione Speciale C. Aiftimiei 3,4, D. Bonacorsi 1,2, P. Calligola 1, V. Ciaschini 3, G. Codispoti 1,2, A. Costantini 3, S. Dal Pra 3, D. DeGirolamo 3, R. Di Maria 1,2, C. Grandi 1, D. Michelotto 3, M. Panella 3, G. Peco 1, L. Rinaldi 1,2, V. Sapunenko 3, M. Sgaravatto 5, S. Taneja 3, G. Zizzi 3 1 INFN Bologna, Bologna, Italy 2 Physics and Astronomy, University of Bologna, Bologna, Italy 3 CNAF, Bologna, Italy 4 IFIN-HH, Magurele, Romania 5 INFN, Padova, Italy 26/05/2015G. CODISPOTI - CCR

Cloud Bursting del Tier 3 Bologna Estensione del Tier-3 di Bologna avvenuta con successo ◦Testata sulla struttura OpenStack del CNAF (Havana e Juno) ◦Sperimentato l’accesso locale (GPFS) attraverso export via NFS ◦Non ideale: Collo di bottigle per le VM e per tutto GPFS ◦Ritornati all’accesso remoto (xrootd, srm) Nuovi nodi visti come «normali» nodi del T3 dalla sottomissione via Grid Completamente trasparente per gli strumenti di CMS: ◦Usato nel sistema di produzione Sottomessi > 3000 job ◦Con il workflow standard di CMS per la creazione di oggetti di Analisi ◦Jobs suddivisi tra nodi fisici e VM ◦Circa il 5% ha raggiunto i nodi virtuali ◦Non si sono visti fallimenti 16/03/2016G. CODISPOTI – ISGC16 – MARCH 2016, ACADEMIA SINICA, TAIPEI, TAIWAN 9

PARTE 3 Aruba

Aruba ● Uno dei principali resource provider Italiani ● Web, host, mail, cloud... ● Main datacenter in Arezzo ISGC

Lo Use Case Aruba: ◦ Aruba fornisce potenza computazionale quando questa non è richiesta dai suoi clienti. ◦ Quando questa potenza è richiesta, la frequenza del processore nelle vm è abbassata fino a pochi Mhz (Le VM NON vengono distrutte) CNAF ◦ Inserire queste risorse tra quelle interne ◦ Per il momento usate solo da CMS ◦ Essere un progetto pilota

Setup Il setup utilizzato ricalca in grossa misura quello sperimentato col T3. Differenze principali: ◦ Su Aruba è stata messa una cache AFM per concedere l’accesso in sola lettura a /usr/share/lsf, necessario per LSF ◦ L’imagine della macchina virtuale utilizzata è basata su un normale node del T1 Presentato a ISGC 2016 ◦ Slide di Stefano Dal Pra riutilizzate con permesso (e lievemente editate)

Collaborazione Ciaschini V., Dal Pra S., Boccali T., Chierici A., De Girolamo D., Sapunenko V.

Dynfarm workflow ISGC

Results 160GHz total amount of CPU (Intel 2697-v3). – Assuming 2GHz/core → 10 x 8-cores VMs (possible overbooking) ISGC

Results Currently the remote VM run the very same jobs delivered to CNAF by GlideinWMS Job efficiency on elastic resources can be very good for certain type of jobs (MC) Special configuration at GlideIN can specialize delivery for these resources. ISGC 2016 QueueSiteNjobsAvg_effMax_effAvc_wctAvg_cpt CMS_mcAR CMS_mcT

Conclusioni Il sistema funziona Ci sono chiari (previsti) cali di efficienza quando il job è I/O intensive. È abbastanza flessibile da adattarsi a diversi ambienti/setup È abbastanza stabile da poter essere usato in produzione senza problemi.

Ringraziamenti Vogliamo ringraziare Aruba per la disponibilità di risorse.