Scalabilità ed Elasticità in Infrastrutture di Cloud Computing

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi Scalabilità ed Elasticità in Infrastrutture di Cloud Computing Anno Accademico 2013/2014 Candidato: Riccardo De Vivo matr. N

2 [Dedica]

3 Indice Indice... III Introduzione... 4 Capitolo 1: Cloud Computing Definizione Elasticità e Scalabilità nel Cloud Computing Modelli di servizio Modelli di distribuzione Virtualizzazione delle risorse Hypervisor Capitolo 2: Piattaforme di Cloud Computing OpenStack Struttura Elasticità VMware vsphere e vcloud Struttura Elasticità Capitolo 3: Cloud Providers Amazon Web Services Panoramica Elasticità Microsoft Azure Panoramica Elasticità Conclusioni Bibliografia... 32

4 Introduzione L avvento di Internet, la sua crescente diffusione e l evoluzione delle tecnologie di rete hanno permesso l estensione del concetto di servizio all ambito dell informatica e delle relative risorse. La maggior parte dei servizi e le fonti energetiche che utilizziamo al giorno d oggi come l acqua, il gas e l elettricità, ormai indispensabili nella vita quotidiana, sono accessibili in maniera semplice e diretta, senza suscitare in noi la preoccupazione di come quella risorsa sia stata effettivamente prodotta o da dove essa provenga. L idea di virtualizzare le risorse di un sistema informatico, come la sua capacità di calcolo, di memorizzazione o il software stesso, rendendole accessibili all esterno sotto forma di servizio offerto a terzi attraverso la rete Internet (IT-as-a-Service), ha suscitato da sempre grande interesse, consentendo lo sviluppo progressivo del Cloud Computing. La maggior parte delle aziende realizza da tempo processi di outsourcing, affidando una parte delle proprie attività a terzi, imprese specializzate nella fornitura di quel particolare servizio. Nell era digitale l outsourcing è stato esteso alle competenze informatiche, riducendo costi di gestione, manutenzione e garantendo una minimizzazione dei rischi, quali perdite di dati (data loss) e interruzioni causate da guasti hardware (hardware failure). Nella prima parte dell elaborato sarà effettuata una breve panoramica del paradigma del Cloud Computing, evidenziandone uno dei maggiori benefici, l elasticità dei servizi offerti. La seconda e terza parte saranno dedicate ad alcune piattaforme cloud e alle soluzioni flessibili proposte dai principali fornitori di servizi (cloud providers). 4

5 Capitolo 1: Cloud Computing 1.1 Definizione Il concetto di Cloud Computing abbraccia diversi aspetti, risulta pertanto complesso offrire una definizione completa, che riesca a sintetizzarli tutti. Il National Institute of Standards and Tecnology (NIST), agenzia del governo Americano, che si occupa della definizione di standard e della gestione delle tecnologie nell ambito dell industria e del commercio, ha redatto un documento ufficiale, in cui identifica il Cloud Computing come un modello per garantire l accesso tramite rete, su richiesta (on-demand) e da ogni luogo, a un esteso bacino di risorse informatiche (e.g., reti, server, memoria, applicazioni e servizi), che possono essere rapidamente fornite in base ai bisogni del consumatore. Tali risorse devono essere facilmente accessibili e gestibili, al punto da comportare la minima interazione con il fornitore del servizio. Il NIST delinea inoltre le componenti fondamentali dell architettura cloud, ovvero le caratteristiche essenziali, tre modelli di servizio e quattro modelli di distribuzione [1]. 1.2 Elasticità e Scalabilità nel Cloud Computing Uno dei maggiori benefici derivanti dall utilizzo di servizi di Cloud Computing è l estrema flessibilità che viene garantita al cliente, l elasticità e la scalabilità sono i principi cardine di questo paradigma ovvero le caratteristiche che hanno maggiormente contribuito alla sua ampia diffusione. Anche se talvolta i due termini vengono utilizzati in maniera interscambiabile, bisogna 5

6 comunque operare una distinzione tra le due proprietà [3]: Scalabilità: si configura come la capacità di un sistema di gestire carichi di lavoro crescenti, aggiungendo risorse in maniera incrementale. In base alla modalità di accrescimento di questa capacità suppletiva, è possibile distinguere due tipi di scalabilità: o Scalabilità orizzontale (scale out): consiste nell aggiunta di nuovi nodi di calcolo o istanze VMs (Virtual Machines 1 ) per consentire, con l aiuto di un load balancer 2, di smistare il carico di lavoro fra più nodi, facendo in modo che lavorino in parallelo come un unica unità. Il concetto di scalabilità orizzontale è ampiamente diffuso in ambito informatico e nella sua accezione generale può indicare sia l aggiunta di macchine fisiche che quella di istanze virtuali. Nel caso specifico del cloud, un cloud provider può incrementare la potenza di calcolo complessiva che può offrire ai clienti aggiungendo altri cloud server al suo Data Center 3 ma nella sua accezione tipica indica l aggiunta di altre istanze VMs a un infrastruttura cloud preesistente, al fine di aumentare le performance del sistema. o Scalabilità verticale (scale up): consiste nel potenziamento di nodi di calcolo o istanze di VMs preesistenti, mediante l aggiunta di altre risorse hardware, ad esempio aggiunta di CPU o core per aumentarne la potenza di calcolo, di RAM o di capacità di memorizzazione. Inoltre esiste sempre un limite alla scalabilità verticale, infatti, seppure si riuscisse ad acquistare una macchina 1 Virtual Machines: una macchina virtuale è un entità software, che attraverso un processo di virtualizzazione, emula il comportamento di una macchina fisica, grazie all assegnazione di risorse hardware. 2 Load Balancer: un bilanciatore è un componente software o in alcuni casi hardware, che permette di distribuire il carico di lavoro tra varie macchine virtuali o fisiche. 3 Data Center: un Centro di Elaborazione Dati Cloud è una server farm Cloud, ovvero un insieme di server collocati in un unico ambiente, al fine di facilitarne la gestione, la manutenzione e la sicurezza e progettato per offrire servizi Cloud. 6

7 Figura 1 Scalabilità verticale e orizzontale con dei componenti hardware di ultima generazione, oltre quello non è possibile spingersi mentre invece è sempre possibile aggiungere un altro nodo di calcolo alla nostra architettura. Elasticità: si configura come la capacità di un sistema di adattare e ridimensionare velocemente le risorse, spesso in maniera automatica, per far fronte a carichi dinamici, sia crescenti sia decrescenti. Questa proprietà prevede, oltre alla scalabilità e quindi l acceso ad altre risorse quando il sistema è sovraccarico, anche il rilascio delle stesse quando non sono più necessarie (scale down e scale in). Tale caratteristica è essenziale in ambiente cloud, dove il cliente vuole pagare solo ciò che effettivamente usa (pay-as-you-use), questo permette sia un risparmio in termini di costi, sia l ottimizzazione delle risorse messe in gioco dal provider. L elasticità è quindi una modalità di scalare un sistema sia verso il basso sia verso l alto ed è un espressione utilizzata particolarmente nel Cloud Computing mentre il concetto di scalabilità può avere diverse connotazioni e quindi ha una portata più ampia. È importante rilevare che l aumento o la diminuzione delle risorse di un sistema, deve comportare come conseguenza, rispettivamente, l aumento e la diminuzione proporzionale delle sue performance. 7

8 1.3 Modelli di servizio I servizi di Cloud Computing sono suddivisi in tre classi, a seconda del livello di astrazione delle funzionalità fornite [1]: IaaS (Infrastructure as a Service): questo modello di servizio è localizzato al livello più basso di astrazione dei servizi cloud, le funzionalità offerte vanno dal potenziamento di VMs preesistenti, aggiungendo ad esempio potenza di calcolo, memoria, servizi di rete e altre risorse informatiche, alla creazione di intere macchine virtuali personalizzate secondo i parametri scelti dall utente o alla disattivazione delle stesse quando non sono più necessarie. Il cliente, a questo livello, non ha il controllo sull intera infrastruttura cloud sottostante, né conosce dove o come siano fisicamente collocate le risorse che sta utilizzando, ma può decidere quali sistemi operativi e applicazioni adoperare sulle sue istanze VMs o Cloud Server. Spesso il consumatore può valutare l impiego di meccanismi per la gestione del carico come un bilanciatore, scegliere che firewall utilizzare a livello SO (Sistema Operativo) e configurarlo o anche se servirsi delle funzioni di scalabilità automatica (autoscaling) offerte dal provider. PaaS (Platform as a Service): questo modello di servizio si colloca sopra quello infrastruttura, i fornitori mettono a disposizione una piattaforma cloud, ossia un ambiente in cui gli sviluppatori possono creare, distribuire e testare applicazioni utilizzando linguaggi di programmazione, librerie e strumenti supportati dal provider. Il cliente in questo caso non avrà il controllo sul livello sottostante ovvero sui cloud server che costituiscono la piattaforma, sui sistemi operativi utilizzati, sulla gestione della memoria o sulle reti ma soltanto sulle applicazioni e gli strumenti che sono forniti per svilupparle. SaaS (Software as a Service): il livello di astrazione è ancora più alto rispetto a quello PaaS, i servizi offerti al cliente consistono nell utilizzo delle applicazioni sviluppate dal provider ed eseguite sulla sua infrastruttura cloud. In questo caso il 8

9 consumatore naturalmente non può sviluppare delle proprie applicazioni o modificare quelle esistenti ma solo servirsene, oltre a configurarle modificandone in maniera limitata alcune impostazioni. Questi software sono solitamente Figura 2 La pila del cloud computing accessibili da diversi dispositivi attraverso portali web, semplificandone notevolmente l uso per il cliente e lo sviluppo e il testing per i provider. 1.4 Modelli di distribuzione I modelli di distribuzione indicano effettuano una classificazione dei servizi di cloud, in base alla loro distribuzione, ossia, dove deve essere organizzato. Il NIST distingue a questo proposito quattro possibili alternative [1]: Private Cloud: l infrastruttura cloud è appannaggio di una sola organizzazione, può essere gestita o essere di proprietà dell azienda stessa o di un fornitore esterno ma chi usufruisce dei servizi è unicamente l organizzazione e le sue diverse unità. Community Cloud: in questo caso, l infrastruttura di cloud computing viene fornita a un gruppo ristretto di aziende o comunità di consumatori che condividono 9

10 caratteristiche comuni, come obiettivi, requisiti di sicurezza o politiche aziendali. Solitamente la gestione della struttura o la proprietà della stessa è prerogativa di un organizzazione appartenente alla comunità o di un insieme di queste. Public Cloud: è il caso più diffuso, un fornitore di servizi cloud eroga le sue risorse informatiche attraverso la rete Internet, rendendole accessibili al pubblico e usufruibili a pagamento. Hybrid Cloud: solitamente si parla di modello di distribuzione ibrido quando un infrastruttura cloud privata al fine di potenziare le sue risorse, acquista servizi messi a disposizione da un infrastruttura pubblica. 1.5 Virtualizzazione delle risorse Uno dei principi cardine su cui si fonda il Cloud Computing, è quello riguardante la virtualizzazione delle risorse hardware, questo meccanismo consente di eseguire diversi sistemi operativi (guest OS) corredati dal relativo insieme di applicazioni su una stessa macchina fisica (host) Hypervisor Il componente software o hardware che agisce da interfaccia tra la macchina fisica sottostante o server fisico e le istanze di macchina virtuale installate su di esso è chiamato VMM (Virtual Machine Monitor), meglio conosciuto col nome di hypervisor. Come già individuato nell articolo "Formal Requirements for Virtualizable Third Generation Architectures" (Gerald J. Popek e Robert P. Goldber, Communications of the ACM, Volume 17 Numero 7, 1974), possiamo operare una classificazione tra questi componenti che contribuiscono alla gestione di una infrastruttura cloud [4]: Hypervisor nativo (type-1 o bare-metal): un VMM di questo tipo è un sistema eseguito direttamente sull hardware del server fisico, permettendone il controllo diretto e l installazione dei sistemi operativi ospiti al livello superiore. 10

11 Hypervisor hosted (type-2): in questo caso il VMM è in esecuzione sul sistema operativo ospitante (host OS), collocato sopra lo strato hardware e prevede funzionalità di supporto alla virtualizzazione e controllo delle VMs, ma si affida al livello inferiore per la gestione della memoria, l allocazione delle risorse, lo scheduling e per altre operazioni. Figura 3 Struttura di un server virtualizzato I sistemi che utilizzano un hypervisor possono adottare diverse tecniche di virtualizzazione [2]: Virtualizzazione completa (full virtualization): la virtualizzazione dell hardware da parte dell hypervisor è completa, il sistema operativo ospite non si accorge di essere in un ambiente virtuale, per cui opera sulle risorse che gli vengono assegnate come se fossero quelle di un ipotetica macchina fisica sottostante e non risorse emulate. Virtualizzazione assistita dall hardware (hardware assisted virtualization): la virtualizzazione è supportata da soluzioni hardware apposite, ad esempio un processore la cui architettura consente l impiego di istruzioni speciali che favoriscono questa funzionalità e consentono al sistema ospite di inoltrare 11

12 chiamate direttamente al livello fisico. Questo approccio consente di incrementare notevolmente le prestazioni globali del sistema. Paravirtualizzazione (paravirtualization): l hypervisor non esegue una virtualizzazione completa dell hardware ma espone piuttosto un interfaccia modificata alle macchine virtuali, composta da API 4 (Application Programming Interface) appositamente progettate e accessibile in maniera diretta dalle stesse. In sintesi la paravirtualizzazione non mira a creare un emulazione dell hardware di un server fisico ma a regolare l utilizzo delle sue risorse da parte delle VMs. Tuttavia questo metodo può comportare una modifica del kernel 5 del sistema operativo ospite. Esistono inoltre soluzioni per la virtualizzazione non basate sull uso dell hypervisor ma su un sistema operativo ospitante condiviso, che permette di replicare le proprie funzionalità direttamente sui sistemi operativi ospiti senza che essi debbano compiere chiamate che coinvolgono più livelli. In questo caso il sistema operativo ospite è vincolato ad essere dello stesso tipo di quello ospitante. 4 API: un Interfaccia di Programmazione di un Applicazione consiste in un insieme di procedure disponibili al programmatore che consentono l interazione semplificata con l applicazione. 5 Kernel: rappresenta il nucleo di un sistema operativo e ha il compito di fornire ai processi un accesso controllato all hardware sottostante. 12

13 Capitolo 2: Piattaforme di Cloud Computing 2.1 OpenStack OpenStack è un progetto open source nato nel 2010 dalla collaborazione tra la Nasa e Rackspace Cloud, la sua rapida crescita è dovuta ai contributi provenienti dalla vasta community, che comprende un gran numero di sviluppatori e importanti aziende dell ICT. Si tratta di un sistema operativo cloud, scritto in Python e rilasciato sotto licenza Apache 2.0, modulare, in grado di controllare un esteso bacino di risorse di calcolo, memorizzazione e di rete secondo il modello IaaS. La sua potenza risiede soprattutto nell essere estremamente flessibile, offrendo supporto ad un gran numero di hypervisor e fornendo numerose estensioni e API Struttura La struttura di OpenStack è composta da diversi blocchi, che vengono inseriti in successione con l evoluzione del progetto. Il suo nucleo è costituito da tre moduli fondamentali, Compute, Network e Storage, accessibili e gestibili mediante un pannello raggiungibile da web browser, chiamato Dashboard. 13

14 Figura 4 Struttura semplificata di OpenStack In particolare, per tracciare una panoramica del sistema, si descrive il ruolo che ha ogni servizio all interno dell infrastruttura [7]: Compute (Nova): è uno dei moduli senior dell intera piattaforma e quello predisposto a controllarla. Gestisce istanze di macchine virtuali, occupandosi della loro allocazione sulle macchine fisiche (modulo nova-scheduler) e del loro ciclo di vita, comunicando con l hypervisor installato su queste ultime (modulo novacompute). In particolare, gli utenti che vogliono creare istanze di VMs chiamano l API di Nova attraverso l API di OpenStack o tramite richieste API di Amazon EC2, a questo punto i demoni Nova (worker daemons) scambiano informazioni tramite una coda di messaggi e il database per esaudirle. Storage (Swift): è l altro modulo senior della piattaforma e quello predisposto alla memorizzazione. Il ruolo di questo componente è di consentire un archiviazione di oggetti scalabile e ridondante, similmente al servizio di Amazon AWS S3. Per assicurare queste due proprietà, Swift scrive repliche di ogni oggetto in server di storage collocati in zone diverse, ossia raggruppamenti di server isolati gli uni dagli altri per prevenire guasti e controllare il surriscaldamento. Il numero di repliche per ogni oggetto e zone è configurabile. Network (Neutron): è il modulo specializzato nelle comunicazioni di rete, inizialmente molti dei suoi compiti erano svolti da Nova (nova-network), ma poi si è deciso di raggruppare le sue funzionalità in un modulo a parte. Fornisce modelli 14

15 di rete flessibili per soddisfare i bisogni delle più disparate applicazioni e gruppi di utenti, occupandosi anche, attraverso l installazione di apposite estensioni, della sicurezza di rete e del load balancing. Dashboard (Horizon): è l interfaccia web con cui dialoga l utente, anche se spesso, molti cloud providers che utilizzano OpenStack, preferiscono implementarne una propria, perché è la componente della piattaforma più esposta all esterno e direttamente visibile al cliente. La struttura globale del progetto è visibile nella figura sottostante e prevede altre funzionalità che sono state integrate nel tempo, la comunicazione tra esse avviene tramite scambio di messaggi. Figura 5 Struttura globale di OpenStack Gli altri servizi, collocati sotto il nucleo principale, com è possibile distinguere dalla figura 4, sono chiamati Open Stack Shared Services e sono: Identity (Keystone): gestisce meccanismi per l autenticazione, presentando, in quest ambito, un ampia gamma di soluzioni. Image (Glance): è il servizio di gestione delle immagini virtuali. Block Storage (Cinder): è il modulo che si occupa del salvataggio dei dati su volumi a blocchi, in precedenza era un servizio di Nova (nova-volume). 15

16 2.1.2 Elasticità OpenStack è progettato per garantire l elasticità tramite scalabilità orizzontale, bilanciando il carico tra gruppi di servizi funzionalmente identici, che comunicano tra loro tramite scambio di messaggi, ad esempio nodi nova-compute o nova-api, che come suddetto sono quelli che si occupano della creazione, eliminazione e controllo delle istanze VMs. Le decisioni sulla scalabilità sono intraprese in base alla tipologia di macchina virtuale da utilizzare, da questo punto di vista, OpenStack permette sia di definire dei modelli (flavor) personalizzabili di VM scegliendo quindi la quantità di core virtuali, di RAM, di capacità di memoria, sia di avvalersi dei flavor predefiniti. OpenStack offre anche alcune funzionalità che consentono la scalabilità verticale, come l API Resize Server [5], che converte, su richiesta dell utente, un istanza di VM preesistente a un flavor differente sia per potenziarla sia per eseguire l operazione inversa. La VM, su cui viene effettuato il ridimensionamento, viene salvata, affinché possa essere ripristinata (rollback) in caso di malfunzionamento successivo alla trasformazione. Il sistema non elimina la macchina virtuale, finché l utente non conferma l operazione di conversione, cosa che avviene automaticamente se l operazione non viene annullata e si raggiunge un tempo limite, solitamente di ventiquattro ore. Questo meccanismo però consente solo l elasticità verticale ed è un operazione che non si presta a essere automatizzata, avviene infatti su richiesta e successiva conferma, purché non siano utilizzati servizi esterni e script appositi. Nella release Havana è stata studiata un interessante funzionalità di scalabilità automatica, che tuttavia richiedere ancora di essere ben sviluppata, grazie all integrazione tra due moduli aggiuntivi di OpenStack [5]: Orchestration (Heat): implementa un motore di coordinamento per istanziare, gestire e configurare gruppi di istanze VMs, rappresentate da modelli (templates) e utilizzando i flavor esistenti, con un semplice comando. Telemetry (Ceilometer): permette il monitoraggio delle risorse all interno dell infrastruttura. Inizialmente alcune sue funzioni erano usate con lo scopo di misurare i servizi utilizzati dal consumatore per stabilirne i costi. In seguito le sue 16

17 funzionalità sono state ampliate, introducendo la possibilità di creare allarmi, basati sui valori registrati e compiere quindi delle specifiche azioni. La collaborazione tra questi due componenti permette di sviluppare logiche di autoscaling, si utilizza ad esempio Ceilometer per registrare il carico di lavoro della CPU all interno dell infrastruttura ed associare azioni quando si raggiunge una certa soglia, come istanziare un gruppo di VMs o terminarlo con Heat. Un altra funzionalità introdotta di recente, anch essa da perfezionare, riguarda l utilizzo delle cosiddette cells [5], che permettono di scalare l infrastruttura cloud in maniera ancora più semplice e distribuita. In pratica, le macchine fisiche in un infrastruttura cloud possono essere partizionate in gruppi chiamati cells, la traduzione più vicina può essere cellule. La struttura di quest assembramento è fatta ad albero, la cell al vertice (API cell) è rappresentata da un server fisico, che è l unico a eseguire il servizio nova-api, ma non nova-compute. Le cellule figlie eseguiranno tutti i servizi nova tipici, incluso compute e quelli riguardanti code di messaggi e database, eccetto però nova-api. La comunicazione tra cellule figlie e API cell avviene tramite il servizio nova-cells, presente indipendentemente dalla gerarchia, che si occupa anche di coordinare lo scheduling tra le cellule e quello effettuato normalmente dal nova-scheduler. 2.2 VMware vsphere e vcloud VMware vsphere (vsphere 5), erede di VMware Infrastructure, è un sistema operativo per il Cloud Computing, in altre parole una suite di strumenti software a pagamento, che consente di trasformare un infrastruttura informatica (IT infrastructure) in una piattaforma cloud privata, con i suoi servizi tipici Struttura L architettura di vsphere comprende diversi componenti che collaborano tra loro per garantire due tipologie di servizi [8]: 17

18 Servizi per le applicazioni: un insieme di funzionalità fornite per assicurare la continuità, la sicurezza, la scalabilità, la tolleranza agli errori di tutte le applicazioni eseguite su vsphere, indipendentemente dalla tipologia di applicazione e dal sistema operativo usato sulla VM. Servizi per l infrastruttura: l insieme degli elementi che consentono la virtualizzazione e la gestione ottimale delle risorse hardware e comprendono servizi di calcolo, storage e rete. Figura 6 Componenti di vsphere I due pilastri di vsphere sono [8]: vsphere vcenter Server: è il centro di controllo dell intera infrastruttura virtuale. Aggrega le risorse hardware dei vari server fisici sui quali è installato l hypervisor ESXi (ESXi host), presentando all amministratore di sistema un unica collezione di 18

19 risorse dinamiche da assegnare alle VM nell ambiente virtuale. Tra gli elementi costitutivi di vcenter Server, si ha un meccanismo per il controllo degli accessi utente (User Access Control) e dei relativi permessi, un set di servizi essenziali (Core Services), che vanno dalla gestione e configurazione delle VM sugli host, alla raccolta di statistiche sugli elementi dell infrastruttura e l impostazione di allarmi, fino alla pianificazione di determinate azioni, periodiche e non. Gli utenti si connettono al vcenter Server attraverso un interfaccia chiamata vserver Client, di cui è disponibile anche una versione accessibile da web browser vserver Web Client. vsphere ESXi: è un hypervisor di tipo bare-metal, installabile quindi direttamente sull hardware dei singoli server fisici (host) che compongono l infrastruttura. ESXi sostituisce la precedente versione dell hypervisor ESX, un sistema operativo vero e proprio basato su Linux Red Hat, che richiedeva frequenti aggiornamenti e un notevole dispendio in termini di risorse. La nuova versione si configura comunque come un hypervisor nativo ma è molto più leggera, priva della Service Console, utilizza strumenti di gestione remota invece della linea di comando locale e integra tutti gli agenti VMware direttamente nel kernel (VMkernel). L altro elemento che completa il quadro delle soluzioni cloud di VMware è vcloud Director, uno strumento software progettato per raggruppare le risorse dell infrastruttura virtuale creata tramite vsphere in data center virtuali (vdc), le cui risorse sono offerte ai consumatori in qualità di servizi catalogati. In pratica gli amministratori dell infrastruttura possono raggruppare i clienti in organizzazioni (organization), che rappresentano ad esempio un gruppo con una determinata policy di accesso ai servizi, come unità aziendali, divisioni o società sussidiarie. Ogni organizzazione ha le proprie risorse virtuali isolate tramite il vdc (organization vdc), una propria autenticazione sicura, specifiche politiche di controllo e cataloghi unici, facendo sì che si venga a creare un ambiente multi-tenant 6, dove più elementi condividono la stessa infrastruttura. 6 Multi-tenant: traducibile come co-proprietario, ossia un architettura in cui un applicazione software partiziona virtualmente i suoi dati e la sua configurazione in modo che ogni client lavori con una sua istanza personalizzata. 19

20 Il vdc fornitore (provider vdc) introduce nell architettura vcloud un livello di astrazione addizionale, che si interpone tra la strutturazione delle risorse al livello vsphere e quella del vdc dell organizzazione, permettendo di configurare quest ultimo secondo diversi modelli di allocazione delle risorse: Pay-as-you-go model: il vdc viene mappato su un pool di risorse senza limitazioni e queste sono assegnate solo quando viene eseguita un applicazione nel vdc. Allocation-pool model: solo una percentuale delle risorse allocate sono affidate al vdc dell organizzazione. Reservation-pool model: tutte le risorse allocate sono affidate al vdc Elasticità VMware utilizza diversi meccanismi per garantire l elasticità all interno dell infrastruttura cloud vsphere, quello principale è il DRS (Distributed Resource Scheduler) [6], che si occupa di amministrare la capacità computazionale derivante da una collezione di risorse informatiche, organizzate in raggruppamenti logici (resource pools), monitorandone l utilizzo e assegnando quelle disponibili alle VM, secondo una logica prioritaria e che riflette i bisogni dell attività aziendale. I pool di risorse possono essere organizzati gerarchicamente, infatti l amministratore della struttura può stabilire come queste devono essere distribuite tra gruppi di VM, ad esempio un ramo dell azienda potrebbe aver bisogno di più capacità computazionale rispetto a un altro, così il DRS garantisce che questa necessità sia soddisfatta. Tuttavia se quella capacità non viene sfruttata, può essere resa comunque disponibile ad un altro pool dell host. Le VM possono essere aggiunte o rimosse da un pool di risorse, oppure è possibile assegnare una VM preesistente a un nuovo raggruppamento, favorendo così la scalabilità orizzontale e la dinamicità. Oltre a raggruppare le risorse di un singolo host in pool, vsphere prevede un ulteriore raggruppamento per migliorare le politiche di allocazione delle VM e di flessibilità in generale: i VMware DRS cluster. Un DRS cluster è una collezione di host su cui è installato l hypervisor ESXi e delle 20

21 relative VMs, con risorse condivise e un interfaccia di gestione condivisa. Se il DRS è abilitato sul cluster, allora esegue periodicamente il bilanciamento del carico all interno del raggruppamento, procedendo a una redistribuzione, automatica o manuale, delle VMs tra gli host tramite migrazione (vmotion), in maniera veloce e garantendo la continuità del servizio. E possibile aggiungere o rimuovere sia host, anche se appartenenti ad altri vcenter Server, che VM al cluster, nel primo caso tutte le VMs e le risorse dell host sono aggiunti al cluster. Quando il carico di una VM aumenta, il DRS valuta prima la sua priorità riguardo l allocazione di risorse secondo le policy stabilite e, se giustificato, procede all aggiunta di capacità secondo due modalità: migrando la VM sovraccaricata verso un altro host o liberando spazio su quell host, ossia predisponendo la migrazione delle altre VM verso altri host. Un'altra funzionalità che favorisce l elasticità dell infrastruttura è l Hot Add [6], cioè l aggiunta o rimozione di risorse di calcolo, RAM o dischi alle VM a caldo, ossia senza richiederne lo spegnimento, tuttavia questo comporta un aumento dell overhead complessivo e non è sempre supportata dal guest OS. Per quanto riguarda vcloud, dalla versione vcloud Director 5.1 [9], sono stati introdotti dei cambiamenti che migliorano la flessibilità del sistema, introducendo meccanismi che consentono di espandere le risorse affidate ad un organizzazione anche senza implicare la creazione di nuovi vdc sia per il provider sia per l organizzazione. Innanzitutto VMware definisce elastici gli organization vdc, solo se possono attingere alle risorse di tutti i cluster compresi nel provider vdc. I vdc delle organizzazioni creati secondo il modello allocation-pool sono elastici di default, nel senso che è possibile ampliarli utilizzando tutti i pool di risorse associate al provider o eventualmente aggiungendone altri, inoltre le VM del vdc possono condividere le risorse inutilizzate. Nel modello pay-as-you-go, invece, ogni VM è un entità a se stante, ovvero non può condividere le risorse di altre istanze e ha dei limiti specifici. In questo caso il vdc dell organizzazione può essere esteso aggiungendo resource pool al provider, ciò consente la creazione di altre macchine virtuali. 21