Workshop della Commissione Calcolo e Reti 28 Maggio 2013 Federazione di risorse Cloud con CLEVER 1

Interoperabilità tra clouds L’ interoperabilità è la capacità di comunicare, eseguire programmi, o trasferire dati tra diverse unità funzionali in un modo che l'utente richiedente abbia poca o nessuna conoscenza delle caratteristiche di tali unità (Information Technology Vocabulary, Fundamental Terms). La possibilità di migrare o utilizzare risorse federate comporta però la necessità di affrontare standard di comunicazione eterogenei (look-in proprietari). 2

Obiettivi Creazione di ambienti virtuali on-demand per applicazioni scientifiche e servizi Utilizzo di risorse di calcolo e rete già disponibili Rendere CLEVER interoperabile con altri middleware cloud implementando la federazione. Dare la possibilità a soggetti federati di migrare geograficamente servizi in downtime 3

CLEVER Cloud-Enabled Virtual EnviRonment Sistema ad Agenti Plugin based sviluppato in java Particolare sistema di comunicazione basato su XMPP Non richiede installazione Non richiede permessi di root Supporta i maggiori hypervisor Adesso supporta l’integrazione di middleware cloud esterni attraverso OCCI e RESTful. 4

Architettura di CLEVER 5

Comunicazione in CLEVER 6

CHAIN-REDS CHAIN-REDS (Co-ordination & Harmonisation of Advanced e-Infrastructures for Research and Education Data Sharing) è la prosecuzione del progetto CHAIN Uno degli argomenti del progetto è testare la possibilità di federare risorse su scala geografica a supporto delle VRC È stato definito lo sviluppo di un testbed basato su CLEVER per testare alcuni semplici use-case Il progetto cerca di basarsi quanto più possibile su standards Nel caso del cloud computing lo standard preso come riferimento è OCCI 7

Partecipanti alla cloud distribuita CIEMAT 2 siti Spagna Iisans Bratislava (EGI) Iulich supercomputing center (EGI) GRNET Okeanos INFN Openstack e OpenNebula Catania Cti espol Ecuador lmf-SRFG Austria 8

Open Cloud Computing Interface 9 Un contributo alla standardizzazione per l’interazione tra i vari sistemi di cloud sta avvenendo attraverso lo standard OCCI (Open Cloud Computing Interface) OCCI fornisce una API per l'interazione e l'utilizzo delle funzionalità del middleware sottostante. Attraverso OCCI è stato sviluppato il modulo di interoperabilità Cloud Manager Grazie alla modularità di CLEVER è possibile implementare lo stesso modulo anche con altri sistemi di comunicazione

Scenari per la federazione 10 OpenStack Spagna Amazon USA OpenNebula Italia OpenStack Austria Sistema di federazione

Requirements Richiesta interfaccia OCCI verso i partner Gestione dell’autenticazione, che non è prevista dallo standard Attualmente storage replicato Integrazione con noVNC Testbed con siti esteri 11 xxx xxx

Testbed con MyCloud 12 APIAPI MyCloud occi openstack.ceta-ciemat.es Nodi Clever nativi

Cloud manager La nostra proposta consiste nel modificare l'Host Manager in modo che il nuovo elemento gestirà un sistema remoto in modo simile a un nodo di calcolo. Questo approccio permette di integrare all’interno della struttura di CLEVER una intera cloud remota rendendola pienamente trusted. L’utente vedrà le risorse locali e remote in maniera omogenea. 13

Cloud manager Una volta recuperati i parametri indispensabili all'avvio della macchina virtuale, il CM invoca l’esecuzione della VM attraverso lo standard OCCI e viene restituito lo stato dell'operazione e l'identificativo della macchina virtuale che verrà salvato nel database SEDNA di CLEVER. Se tale operazione va a buon fine la macchina virtuale sarà avviata e sarà possibile entrare sulla VM partita attraverso SSH o VNC 14

Cloud Manager 15

Federazione in azione 16

MyCloud Nella sezione Cloud Nodes, sulla sinistra, sono mostrati i nodi attualmente presenti nella Cloud. Ogni nodo è un host dove il middleware CLEVER è in esecuzione, connesso alla stanza condivisa all’interno del server XMPP. Tra i nodes attivi è possibile vedere i nodi specifici per le cloud remote OpenStack e OpenNebula essi sono nodi speciali in quanto realizzano la federazione tra i middleware remoti gestendo anche la sicurezza per l’infrastruttura poichè i parametri per la connessione non vengono esposti. 17

Drag & drop 18 Deploy delle vm attraverso drag & drop

19 VM Market PlaceMyCloud Basic VM1 Basic VM2 VRC1 VM1 VRC1 VM2 VRC2 VM1 VRC2 VM2 Node of cloud m/w 1 on site X Node of cloud m/w 2 on site Y Node of cloud m/w 3 on site Z Workflow di MyCloud

Accesso VNC e ssh 20

Conclusioni La federazione con sistemi cloud remoti permette virtualmente di incrementare le risorse di calcolo del proprio datacenter on-demand semplicemente facendo partire i servizi che fanno da bridge verso le risorse esterne. E’ stata mostrata l’integrazione di MyCloud con gli Science Gateways. E’ stata mostrata la gestione delle risorse locali e remote in maniera omogenea e trasparente. 21

Sviluppi futuri Testing della soluzione proposta su un ampio numero di macchine valutandone la QoS, la gestione dei fautl ed ottimizzandone le prestazioni per ambienti di ricerca che fanno uso massivo di dati di I/O e risorse di calcolo come l’INFN Utilizzo di altri standard di comunicazione per sistemi cloud tra cui sicuramente Amanzon EC2 22

Grazie per l’attenzione 23