Setup di una cloud privata a Torino Un prototipo in produzione S.Bagnasco, D.Berzano, R.Brunetti, S.Lusso 1
Motivazione! Negli ultimi anni la quantita di risorse hardware eterogenee di fascia consumer e cresciuta in numero e complessita! Il personale da dedicare alla gestione delle risorse non e invece cresciuto in modo proporzionale! Sarebbe importante riuscire a consolidare tali risorse e recuperare una visione di Data Center come fornitore di servizi di calcolo e di storage! In questo modo le farm private, i siti Grid ecc.. possono essere considerati come servizi gestiti da un infrastruttura IaaS di piu basso livello 2
Strumenti utilizzati! Cloud management Toolkit (OpenNebula)! Prodotto open source con una comunita ampia di utilizzatori! Architettura modulare! Molte delle funzionalita richieste gia presenti! Facile da personalizzare (per lo piu shell e ruby script)! Backend storage (GlusterFS)! Facile da utilizzare in una configurazione base! Robusto! Espandibile! Networking delle VM (OpenWRT)! Distribuzione linux per sistemi embedded dotata di servizi per la gestione della connettivita 3
Organizzazione delle risorse! A seconda del tipo di utilizzo delle risorse abbiamo identificato due tipologie di cluster! Services! VM che implementano servizi critici per i quali e necessaria connettivita in/out bound, IP pubblici, live-migration ecc..! Workers! VM che implementano servizi di calcolo non critici con solo IP privato ma con sostanziali richieste di IO su disco.! A queste due classi abbiamo associato diversi tipi di backend storage (Datastores nella terminologia O.N.) in modo da ottimizzare le prestazioni e soddisfare le richieste. 4
Backend Storage (Datastores)! Rappresentano la spina dorsale dell infrastruttura cloud e ne forniscono le due componenti fondamentali:! Repository delle immagini! Shared FS (Simple Gluster Volume) (Images Datastore)! Storage per le running virtual machines! Shared cluster FS (Replicated Gluster Volume) per le VM di tipo Services (System Datastore)! Local storage per le VM di tipo Workers ; cache locale delle VM con tecnica dello snapshotting qcow (Cached Datastore). Uno script ad-hoc si occupa di mantenere sincronizzate le copie via rsync (scpwave) Storage Server SAN FC Storage Server Images Datastore Gluster Rep.Volume System Datastore Cached Datastore Services Cluster Workers Cluster 5
Networking! Network Isolation (Level 2)! Ogni utilizzatore possiede una propria Virtual Network, isolata dalle altre a livello di hypervisor tramite ebtables. Tale funzionalita e gia una di quelle possibili in OpenNebula.! Virtual Routers (Level 3)! Abbiamo costruito un immagine di VM ligth-weight (1 CPU/150 MB Ram) a partire da una distribuzione linux open source per sistemi embedded (OpenWRT) con funzionalita di:! DHCP Server, DNS Server, NAT! Firewalling/Port Forwarding! Instanziando un v-router e possibile definire, per ciascun utilizzatore, una rete classe C dedicata (privata) la cui connettivita e gestita (e limitata) dal corrispondente v-router (che rimane sotto esclusivo controllo dell amministratore) WAN V-router V-NET 1 V-NET 2 6
Aggiunte e Modifiche! Le funzionalita richieste ad implementare gli use case che abbiamo avuto fin ora sono tutte disponibili in OpenNebula! Anche come scelta strategica abbiamo preferito rimanere mainstream aggiungendo (e non modificando) alcuni tools di tipo per lo piu amministrativo, ma sempre utilizzando le API di O.N.! Modifica del comando che restituisce la lista delle VM in modo che fornisca alcune info in piu! Script di sincronizzazione torrent-like delle copie-cache delle immagini nel Cached Datastore usato dai Workers! Contestualizzazioni ad-hoc per i WN in modo che si aggiungano boot-time al LRMS! Script per il draining/shutdown controllato dei WN e dei nodi PROOF! 7
Situazione attuale! Totale nodi fisici: Utilizzo:! 31 host (hypervisors) : 27 in Workers + 4 in Services! 2 storage server ( 20TB SAN frontend)! 1 cloud controller (master) 650 Cores PROOF DEVEL BES WN! Sito Grid T2! Tutti i servizi Grid (CE,SE,BDII ecc..) + xx job slot (i WN si contestualizzano al boot)! Analysis Facility di Alice (PROOF)! Coesiste con il T2 Grid, i nodi vengono instanziati on-demand e si contestualizzano al boot.! Macchine di sviluppo! 3 nodi di sviluppo del sistema di accounting DGAS con inbound connectivity e v-router dedicato! M5L-CAD! INFN & dixit spin-off al quale sono stati assegnati alcuni nodi di calcolo per implementare una farm di analisi delle immagini tomografiche (sperimentazione finita)! Utenti Spot (Sperimentazione Gruppo BES III)! 2 nodi di calcolo con v-router dedicato. Risorse disponibili limitate da quote fissate in termini di numero di VM, numero di CPU, quantita di RAM ecc.. 8
Possibili sviluppi futuri! Esplorare le funzionalita di Object Storage di GlusterFS e capire come integrarle in OpenNebula o metterle a disposizione degli utenti.! Capire se e come sia possibile passare ad una forma di cloud distribuita (OpenNebula Zones )! Cercare di integrare il sistema di Authn/Authz di OpenNebula in un contesto di VO o di autenticazione federata. 9