ALMA MATER STUDIORUM UNIVERSITÀ DEGLI STUDI DI BOLOGNA

Transcript

1 ALMA MATER STUDIORUM UNIVERSITÀ DEGLI STUDI DI BOLOGNA Seconda Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica MODELLI E TECNOLOGIE PER LA GESTIONE DI MACCHINE VIRTUALI TRAMITE API SOFTWARE Elaborata nel corso di: Sistemi Operativi LA Tesi di Laurea di: MALDINI ELIA Relatore: Prof. ALESSANDRO RICCI Correlatore: Ing. NAZZARENO POMPEI ANNO ACCADEMICO SESSIONE III

2

3 PAROLE CHIAVE Virtual Machine API Infrastruttura

4

5 Indice Introduzione vii 1 Macchine Virtuali Introduzione Concetti base Architettura System Virtual Machine Tecnologie Esistenti Gestione di Macchine Virtuali Tramite API Introduzione Virtual Machine come sistema chiuso Virtual Machine come sistema aperto I possibili scenari Tecnologia a supporto: VMware Infrastructure SDK Panoramica Tipi di dato Organizzazione Logica Managed Object TaskManager Managed Object SearchIndex & PropertyCollector Managed Object VirtualMachine Managed Object PerformanceManager Managed Object Esempio Conclusione 41 v

6 vi

7 Introduzione Il continuo sviluppo dell Information Tecnology porta a costruire elaboratori sempre più potenti e performanti. Da tempo, al fine di ottimizzare l uso di tali risorse si ricorre alla virtualizzazione che permette, inoltre, di aumentare la sicurezza e di semplificare la gestione di una macchina. Il progresso tecnologico, tuttavia, porta inevitabilmente ad aumentare la complessità della struttura delle risorse IT. Questo problema fino ad oggi è stato risolto attraverso l impiego di personale sempre più qualificato, in grado di gestire e configurare tali risorse. In futuro, tuttavia, le sole capacità delle risorse umane potrebbero non essere più sufficienti ed allora sarà necessario cercare metodi alternativi. Uno degli approcci che si sta studiando, per ovviare a tale problema, è quello di sostituire l intervento umano attraverso entità software autonome (es. agenti) in grado di controllare in maniera automatizzata la macchina. Al fine di rendere efficente e sicuro l operato di tali entità si deve, necessariamente, astrarre dallo scenario comune di utilizzo, in cui l applicazione vive solitamente all interno del sistema stesso. In quest ottica essa è sotto il controllo del SO e le attività svolte dipendono dal corretto funzionamento della macchina. E necessario, invece, che l entità attiva viva al di fuori del sistema ma che operi come se fosse in esecuzione, ancora, al suo interno. Una possibile soluzione è quella di sfruttare i mezzi messi a disposizione dalla virtualizzazione ed in particolare i servizi offerti dal Virtual Machine Monitor. Come si vedrà esso permette di gestire l intero ciclo di vita di una macchina virtuale e di monitorarne lo stato. In questo documento si costruisce un modello per la gestione di tali macchine evidenziando le caratteristiche e gli aspetti che possono essere controllati da un applicazione mediante API software. vii

8 Nel primo capitolo si descrive in modo generale l architettura promossa dalla virtualizzazione. L attenzione è posta sul ruolo del Virtual Machine Monitor come intermediario fra il livello software e quello hardware. Viene descritto brevemente il funzionamento del sistema operativo e in particolare le modalità con le quali interagiscono le principali entità costituenti. Infine si evidenziano i benefici nell uso di tale approccio e si citano alcune soluzioni, a supporto, attualmente in commercio. Nel secondo capitolo viene descritto un modello per la gestione automatizzata di macchine virtuali il quale suddivide in due classi principali le operazioni che si possono svolgere. Si individuano le caratteristiche del sistema che possono essere rese controllabili attraverso API software e si accenna ad un possibile scenario di utilizzo per ciascuna di esse. Infine si descrive brevemente l Autonomic Computing come possibile caso in cui il modello descritto può essere impiegato. Nel terzo ed ultimo capitolo si prende in considerazione una tecnologia attuale a supporto, denominata, VMware Infrastructure SDK, la quale fornisce le API necessarie per controllare il ciclo di vita di macchine virtuali. Di tale risorsa, concepita secondo il paradigma object oriented, si descriveranno le principali classi che permettono di comandare, monitorare e configurare una macchina virtuale. Infine si mostra un possibile caso di utilizzo dell SDK studiato. viii

9 Capitolo 1 Macchine Virtuali In questo capitolo verranno descritte le principali caratteristiche dell architettura basata sulle macchine virtuali. 1.1 Introduzione La complessità che caratterizza lo studio della struttura e del comportamento di una macchina è da sempre gestita attraverso la suddivisione del problema in livelli di astrazione. L importanza e l utilità di questa tecnica si evidenzia se si considera che ciascun livello è concepito in modo da nascondere a quelli soprastanti la complessità e i dettagli della struttura alla base. Nelle macchine questa suddivisione si concretizza nel livello hardware e nel livello software. Un ruolo molto importante in questo approccio è rappresentato dalle interfacce: esse mostrano l insieme dei servizi che ciascun livello offre, rendendo invisibili le modalità con le quali, questi, vengono effettivamente realizzati. L istruction set (IS), per esempio, è l interfaccia che l hardware di una macchina, in particolare la CPU, espone, rendendo disponibile al livello software tutti i servizi necessari per interrogare le risorse della macchina. Questo approccio permette a chi deve implementare nuovi livelli, di progettare lo sviluppo in modo indipendente dalla struttura di quelli già esistenti;è il caso, per esempio, di un programmatore il quale nella realizzazione di un applicativo con 1

10 2 CAPITOLO 1. MACCHINE VIRTUALI linguaggio di alto livello non si preoccupa (nei casi più comuni) dell IS della macchina sottostante. Se da un lato, quanto detto in precedenza, costituisce un vantaggio, dell uso del modello, da un altro esistono degli svantaggi. Quello più comune è quello della compatibilità: le interfacce risultano spesso compatibili solo con i livelli per i quali sono stati concepiti. L adozione di un interfaccia frapposta fra livello software e livello hardware, per esempio, ha permesso lo sviluppo di sistemi operativi in modo indipendente dalle specifiche caratteristiche fisiche della macchina sottostante, ma questa indipendenza non è sempre verificata ed esistono software e SO il cui funzionamento è in parte, ancora, legato alle caratteristiche della macchina sottostante(basti pensare ai diversi aspetti che da sempre hanno contraddistinto le piattaforme x86 e powerpc). Esistono poi diverse problematiche che nascono come conseguenza dell approccio a livelli. Una di queste riguarda il mapping: lo scenario comune è quello di avere un livello mappato su un altro (1 a 1) quindi, per esempio, di avere installato su una macchina un solo SO. Al giorno d oggi in cui le macchine hanno raggiunto livelli prestazionali elevati, questo è poco performante e porta ad un sottoutilizzo della macchina stessa. Oltre ad essere un problema di ottimizzazione, questo determina problemi di sicurezza: il fatto, per esempio, che una macchina sia sotto il controllo di un SO la rende vulnerabile ai mal funzionamenti di quest ultimo che possono essere accidentali o causati dall azione malevola di un utente. Al fine di risolvere tutte queste problematiche si ricorre da tempo alla virtualizzazione la quale, in accordo con il modello di scomposizione citato, interpone un nuovo livello fra quello software e quello hardware. Della virtualizzazione se ne parlerà approfonditamente nei prossimi paragrafi. 1.2 Concetti base Il nuovo strato, introdotto dalla virtualizzazione e denominato Virtual Machine Monitor (VMM), si concretizza in modulo software che cerca di emulare il comportamento dell hardware sottostante. Sopra al VMM si appoggiano le Virtual Machine (VM) le quali, a seconda del 2

11 CAPITOLO 1. MACCHINE VIRTUALI 3 tipo di virtualizzazione, possono incapsulare una singola applicazione (Process Virtual Machine) o nel caso più diffuso un intero sistema operativo (System Virtual Machine). Per capire le differenze fra questi due scenari e approfondire il funzionamento del VMM è necessario evidenziare, prima di tutto, il funzionamento di una macchina dal punto di vista del sistema operativo e dal punto di vista dell applicazione. Come è già stato accennnato, Figura 1.1: Iterfaccia ISA il sistema operativo dialoga con l hardware della macchina mediante l interfaccia proposta da quest ultimo, ovvero l ISA. Questa interfaccia è constituita da un set di istruzioni che il processore è in grado di interpretare ed eseguire. Le modalità con le quali il SO richiede l esecuzione di un istruzione sono tipicamente 2: Kernel Mode, User Mode. La prima modalità è privilegiata, ovvero una modalità di esecuzione in cui non sono applicate restrizioni e mediante la quale è possibile svolgere qualsiasi genere di operazione su qualunque risorsa hardware. La seconda è una modalità che è sottoposta a dei limiti e mediante la quale è possibile eseguire solo determinati tipi di operazioni. Dal punto di vista di un processo si hanno a disposizione due possibilità: interagire con il SO o colloquiare direttamente con l hardware. Il primo caso avviene tipicamente quando l applicazione vuole comunicare con una periferica I/O; per fare ciò il SO mette a disposizione un interfaccia che prende il nome di System Call Interface. Nel secondo caso, invece, il processo interagisce con l hardware mediante l interfaccia ISA in modalità user mode. Come mostra la figura so- 3

12 4 CAPITOLO 1. MACCHINE VIRTUALI Figura 1.2: Iterfaccia ABI prastante, l insieme delle due interfacce prende il nome di application binary interface (ABI). 1.3 Architettura Il virtual machine monitor deve in qualche modo emulare il comportamento dell hardware e in alcuni casi del SO. Nel caso del process Figura 1.3: Process Virtual Machine virtual machine lo strato di virtualizzazione deve fornire le medesime funzionalità offerte dall interfaccia ABI. Il VMM in questo caso si frappone fra il sistema operativo e l applicazione e traduce le richieste pervenute dall applicazione nella corrispondente richiesta al SO 4

13 CAPITOLO 1. MACCHINE VIRTUALI 5 o all hardware. Il ruolo di traduzione risulta molto importate nel caso in cui l applicazione che viene eseguita non è concepita per essere lanciata sul sistema operativo o sull hardware esistente. Il monitor intercetta ciascuna richiesta che gli perviene dal processo e la passa direttamente al sistema operativo o all hardware, se risulta compatibile con l interfaccia esposta da quest ultimi, altrimenti effettua la traduzione. Figura 1.4: System Virtual Machine Se si considera il system virtual machine, invece, lo strato di virtualizzazione si frappone fra l hardware e il SO. In questo caso il monitor deve fornire al SO la medesima funzionalità che offre l interfaccia ISA dell hardware della macchina e nei casi in cui si rende opportuno, deve effettuare la traduzione necessaria a rendere compatibile l esecuzione del SO con l hardware stesso. Al fine di garantire sicurezza e affidabilità nella gestione di una VM, la possibilità di eseguire istruzioni nella modalità privilegiata è concessa solo al VMM, in questo modo è lui che ha il controllo effettivo della macchina e quindi può intervenire traquillamente in caso di mal funzionamenti del sistema host. In tale approccio quindi il SO e le applicazioni che su di esso vengono eseguite operano in modalità user. Se si considera che molte istruzioni eseguite dal SO hanno effetti diversi a seconda della modalità con cui vengono eseguite, questo introduce inevitabilmente nuove problematiche. Per questo motivo la presenza di un modulo, all interno del monitor, al 5

14 6 CAPITOLO 1. MACCHINE VIRTUALI quale è affidato il compito di tradurre le istruzioni richieste dall host, risulta una scelta obbligata. La traduzione dinamica binaria avviene tramite un opportuno modulo che traduce tutte quelle istruzioni che, per i motivi discussi in precedenza, non è possibile eseguire direttamente. Tale modulo sostituisce le istruzioni critiche con altre che successivamente passa al VMM il quale le manda in esecuzione sulla macchina sottostante. La caratteristica principale di tale approccio è quella di effettuare tale sostituzione al volo a discapito delle performance e della complessità della struttura che aumenta notevolmente. Appare chiaro ora che lo strato di virtualizzazione interposto fra il SO (processo) e l hardware (SO) introduce un overhead che deve essere minimizzato il più possibile in modo tale da rendere impercettibile l operato del monitor ad un utente del sistema host. Una delle tecniche applicate a tal fine è quella del cashing : quest ultima viene applicata in fase di traduzione alle istruzioni che ricorrono più di frequente le quali vengono tradotte e salvate in memorie cache per essere immediatamente disponibili nel momento in cui è necessario rieseguirle. Una alternativa alla traduzione di dinamica, discussa in precedenza, è la paravirtualizzazione. Grazie a quest ultima tutte le operazioni critiche che il SO può eseguire vengono sostituite con altre più agevoli che spesso fanno riferimento ad un linguaggio specifico del Virtual Machine Monitor. A differenza della traduzione binaria la quale viene effettuata dinamicamente, ovvero nel momento in cui il SO ne richiede l esecuzione, in questo approccio la traduzione avviene staticamente operando la modifica manuale dei sorgenti del sistema operativo o dell applicazione. In questo modo la paravirtualizzazione risulta più performante poiché introduce meno overhead e richiede una struttura del monitor meno complessa, ma è più difficile da applicare. Infatti nella maggior parte dei casi risulta difficile avere a disposizione i sorgenti del SO o dell applicazione, specialmente se queste sono soluzioni proprietarie. 6

15 CAPITOLO 1. MACCHINE VIRTUALI System Virtual Machine L esigenza di virtualizzare nasce, come accennato nel paragrafo introduttivo, per risolvere diverse problematiche. In particolare la necessità di virtualizzare un intero sistema nasce dalla continua evoluzione dell hardware che porta ad avere oggi macchine potenti e performanti le quali, nella maggior parte dei casi, sono sottoutilizzate. Per molto tempo l unica soluzione possibile in ambito server era quella di avere grossi computer sui quali era installato un solo SO al quale veniva affidato il compito di gestire tutti i servizi di rete. Questa strategia, oltre ad essere poco ottimizzata era molto dispendiosa soprattutto nei casi in cui l esigenza richiedeva la presenza di sistemi con piattaforme diverse. Il fatto poi di essere in ambito distribuito implicava la presenza di numerosi utenti, i quali usufruivano contemporaneamente dei servizi offerti. Questo comportava numerosi rischi in fatto di sicurezza poichè l azione malevola di un solo utente avrebbe compromesso l attività di qualsiasi utente connesso alla rete. Tramite la virtualizzazione oggi si Figura 1.5: Scenario Server aprono nuovi scenari; vi è la possibilità di eseguire su una medesima macchina più istanze di un sistema operativo o addirittura instanze di sistemi operativi diversi. Una possibile realtà può essere quella di avere localizzate in un unico server diverse virtual machine alle quali è affidata la fruizione di diversi servizi. Questo permette di ridurre notevolmente i costi del materiale e delle licenze necessarie, e semplifica l amministrazione della rete. Per un amministratore, infatti, tale approccio risulta conveniente 7

16 8 CAPITOLO 1. MACCHINE VIRTUALI grazie alla visione monolitica della VM. Questa infatti è costituita da un insieme di file che posso essere facilmente spostati da un host all altro o addirittura replicati. Un secondo beneficio è dovuto alla particolare struttura data al sistema virtualizzato, il quale vede il VMM l unico in grado di eseguire operazioni privilegiate. In questo scenario il sistema operativo e le applicazioni hanno la facoltà di eseguire direttamente solo istruzioni in modalità user impedendo di fatto a quest ultimi, la possibilità di bloccare la macchina. La sicurezza aumenta ulteriormente, poi, se si pensa che ciascuna VM in esecuzione su un host, opera in maniera indipendente ed isolata dalle altre che sono in esecuzione nello stesso istante. La virtualizzazione non interessa solamente gli ambienti professionali, ma è una strategia che viene spesso adottata in ambito desktop. L esigenze principale che spinge un utente comune a ricorrere ad ambienti virtuali è quella dell interoperabilità. Per quanto detto nei primi paragrafi una delle problematiche che ricorre più di frequente è quella dell incompatibilità di sistemi operativi o di applicazioni con determinate piattaforme hardware o software. Figura 1.6: Scenario Desktop Questo tipo di virtualizzazione differisce in alcuni aspetti da quella descritta in precedenza. Lo strato di virtualizzazione in questo caso si pone al di sopra del sistema operativo pre-installato sulla macchina 8

17 CAPITOLO 1. MACCHINE VIRTUALI 9 host. Il virtual machine monitor non dialoga direttamente con l hardware ma utilizza l interfaccia ABI. L architettura di virtualizzazione così costruita appare sicuramente meno performante rispetto a quella precedente visto il numero maggiore di livelli da attraversare prima di eseguire l istruzione ma risulta altrettanto utile quando, per esempio, è necessario utilizzare applicazioni non concepite per essere eseguite sul tipo di macchina host. Questo tipo di virtualizzazione, inoltre, risulta utile quando si ha a disposizione un hardware non standard. Il corretto funzionamento del monitor, infatti, implica che esso riconosca (nel caso di system virtual machine) tutte le periferiche e i componenti hardware della macchina. In ambito server ove le architetture hardware sono standard queste problematiche non sussistono e il monitor contiene al suo interno tutti i driver necessari. Nello scenario desktop, invece, l hardware è vario e si presentano maggiori difficoltà. 1.5 Tecnologie Esistenti La virtualizzazione è un approccio molto diffuso al giorno d oggi sia in ambito professionale sia in quello desktop ed è in continua evoluzione. L importanza di questo settore è stata già da tempo percepita dai maggiori produttori di hardware e software, i quali continuano a proporre prodotti con funzionalità e caratteristiche che supportano e facilitano, sempre più, l esecuzione di un ambiente virtuale. Ne sono l esempio le seguenti infrastrutture software: - Virtual PC Virtual PC è un software di emulazione, sviluppato e distribuito da Microsoft che consente, in piattaforme Mac OS X o Windows, l esecuzione di sistemi operativi diversi, anche in contemporanea. L emulatore ricrea in forma virtuale un ambiente di lavoro che riproduce quasi integralmente quello di un PC basato su processore Intel. - VMware Workstation La workstation è costituita da una serie di software sviluppati da VMware Inc. che consentono di eseguire più sistemi operativi in un ambiente virtuale. VMware riesce ad emulare architetture 9

18 10 CAPITOLO 1. MACCHINE VIRTUALI x86 a 32 o 64 bit ed emula anche processori dual-core. Supporta i SO Microsoft Windows, MAC OS X e Linux sia come sistemi host sia come guest. - Parallels Parallels Desktop è un software per piattaforme Mac OS X, che emula macchine virtuali su computer Power PC. E nato con lo scopo principale di consentire l esecuzione, su tale piattaforma, di sistemi operativi Windows, Linux, Solaris, con grandi vantaggi per quanto riguarda l interoperabilità. Il programma permette, inoltre, l esecuzione di applicazioni guest in modo trasparente all utente host. Questo significa che l applicazione emulata viene eseguita su una finesta del sistema host senza che venga mostrato il SO emulato. - VirtualBox E un software di virtualizzazione realizzato e distribuito da Innotek. Permette l emulazione di piattaforme x86 e supporta i più comuni SO sia come host sia come guest. A differenza degli altri descritti in precedenza ha il vantaggio di essere distribuito con licenza GNU GPL (General Public Licenze) e quindi Open Source. Esiste una comunità a supporto che permette a chiunque di aderire al progetto. - Bochs E un software Open Source, scritto in C++ per piattaforme x86. Permette l emulazione di sistemi 386, 486, x86 32bit o 64bit e supporta Windows e Linux come SO guest e host. Grazie alla disponibilità dei sorgenti viene spesso impiegato grazie ad opportune modifiche per eseguire sistemi operativi su piattaforme non convenzionali. 10

19 Capitolo 2 Gestione di Macchine Virtuali Tramite API In questo capitolo si riflette su i possibili scenari che possono presentarsi grazie all utilizzo di API software mediante le quali poter comandare macchine virtuali. 2.1 Introduzione Nel primo capitolo si è evidenziata la necessità e l importanza della virtualizzazione la quale ridisegna l architettura comune di una macchina introducendo un nuovo livello d astrazione fra l hardware e il software. Il nuovo approccio definisce una nuova entità, il virtual machine monitor (o hypervisor), in grado di presentare al livello soprastante una copia virtuale delle risorse fisiche disponibili. Nel caso delle system virtual machines, il monitor virtualizza tutte le risorse necessarie all esecuzione del SO guest (ad esempio la RAM, la CPU o la memoria di massa). Il metodo con cui esso mappa le risorse fisiche con quelle virtuali è basato in genere su un protocollo a divisione di tempo, con la possibilità di personalizzare il mapping. Questo significa che l hypervisor ha la facoltà di allocare alla VM meno risorse di quelle effettivamente disponibili(ad esempio solo un core della CPU o parte della RAM). Nel caso di risorse fondamentali come quelle precedenti, il mapping avviene in fase di configurazione, ovvero 11

20 12 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API Figura 2.1: Virtual Machine Monitor prima di mandare in esecuzione il SO guest, ma in altri casi, il mapping può avvenire addirittura, a caldo, ovvero durante l esecuzione. Oltre a questa capacità, l hypervisor è in grado, anche, di monitorizzare l utilizzo di tali risorse generando dati e statistiche sul carico di lavoro. Grazie alle capacità dell virtual machine monitor e hai servizi che esso mette a disposizione, l utente ha la possibilità di interagire con la macchina in maniera alternativa. Se lo scenario comune vedeva l utilizzatore accedere dall alto attraverso l interfaccia offerta al sistema, in questa nuova ottica esso può accedervi dal basso attraverso la mediazione dell hypervisor. Nello scenario di utilizzo di una macchina viene, così, introdotto un nuovo punto di vista, che assume un importante ruolo nella gestione automatizzata di macchine virtuali. Nell uso quotidiano di sistemi informatici si presenta spesso la necessità di rendere automatiche operazioni complesse o di sostituire l intervento umano, in attività ripetitive, attraverso l adozione di programmi che possano, inoltre, rendere tali operazioni più veloci e più efficienti. L unica possibilità disponibile fino ad oggi era quella di implementare routine o programmi che svolgessero le attività, eseguendo i medesimi passi percorsi dall utente, all interno del sistema operativo. 12

21 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 13 Le applicazioni così concepite dipendevano direttamente dalla volontà del sistema e l efficienza delle operazioni che eseguivano dipendevano, quindi, dal corretto funzionamento di quest ultimo. Attraverso la virtualizzazione vi è la possibilità, ora, di svolgere le medesime attività attraverso i servizi messi a disposizione dall hypervisor. In questo scenario il sistema operativo vive all interno di una virtual machine e si ha la possibilità di comandarlo attraverso un applicazione in esecuzione su un host diverso. Le applicazioni, così, concepite sono in grado di svolgere il proprio compito senza necessariamente vivere nel medesimo contesto esecutivo del sistema operativo. E chiaro che per ren- Figura 2.2: Accesso al Virtual Machine Monitor dere possibile tutto ciò il VMM deve, necessariamente, esporre opportune interfacce (API) che consentano ad una applicazione di usufruire dei servizi messi a disposizione. In questo modo l hypervisor diviene mediatore nella comunicazione fra l applicazione e il sistema operativo. L adozione di un modello astratto che descriva l insieme delle op- 13

22 14 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API erazioni possibili permette di semplificare la progettazione di applicazioni per il controllo di sistemi virtualizzati. Il modello deve inoltre suggerire l infrastruttura da seguire al fine di realizzare nel migliore dei modi un sistema per la gestione di macchine virtuali. Un possibile modello distingue due tipologie di operazioni: La prima tipologia nasce dalla visione della VM come sistema chiuso. I servizi richiesti concepiscono la macchina virtuale come sistema monolitico dotato di risorse virtuali da poter monitorizzare e gestire, non ponendo alcuna attenzione sulle caratteristiche del sistema operativo host. La seconda tipologia nasce invece dalla visione della VM come sistema aperto. I servizi richiesti consentono di avere una visione dettagliata dello stato della macchina con particolare riguardo al sistema operativo. Offrono la possibilità di eseguire operazioni su quest ultimo in sostituzione all azione dell utente. 2.2 Virtual Machine come sistema chiuso Considerare una VM come sistema chiuso significa considerarla per come appare vista dall esterno, cioè costituita da un insieme di risorse virtuali a disposizione del sistema host. L interfaccia che offre i servizi, in questo caso, deve permettere di gestire e monitorizzare l hardware virtuale creato dall hypervisor, cioè rendere disponibili tutti i servizi offerti da quest ultimo. Le principali operazioni che fanno parte di questo insieme sono: - Accensione - Spegnimento - Reset - Sospensione Queste rappresentano le operazioni basilari che possono essere svolte su una VM e che nella maggior parte dei casi sono di competenza dell utente host. Esistono, poi, una serie di altre operazioni molto più 14

23 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 15 importanti che sono di carattere amministrativo e vengono di seguito esposte: - Configurazione Questa operazione si occupa di impostare le caratteristiche dell hardware virtuale. E possibile quindi settare nella fase di inizializzazione la quantità di memoria fisica e di massa oppure il numero di processori da assegnare alla virtual machine. E possibile inoltre collegare o scollegare, durante l esecuzione, periferiche quali per esempio schede di rete o lettori ottici. - Creazione Con questa operazione è possibile creare una nuova istanza di macchina virtuale. Le informazioni necessarie alla creazione vengono stabilite in fase di configurazione, oppure possono essere reperite attraverso un template, il quale incapsula tutte le specifiche relative alla configurazione di una VM. - Spostamento In una infrastruttura complessa in cui sono presenti più macchine host connesse in rete può rendersi utile poter spostare le virtual machines da una postazione all altra. In questo scenario ogni macchina virtuale deve necessariamente essere rappresentata da un riferimento univoco che permetta di idividuarla facilmente anche nel caso di architetture di rete articolate. - Creazione di punti di ripristino L esistenza di una configurazione virtuale dell hardware associata a ogni VM permette di creare per ciascuna di esse punti di ripristino che memorizzino lo stato in cui si trovano tali risorse in un dato momento. Grazie a questa operazione è possibile ripristinare la virtual machine nel caso in cui si presentino mal funzionamenti o problemi del sistema host. - Monitoraggio Ricorrendo alle capacità dell hypervisor questa operazione permette di conoscere lo stato delle risorse virtuali. Permette, inoltre, ad una applicazione di recuperare i dati necessari per 15

24 16 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API generare statistiche sul carico di lavoro del sistema guest. In particolare fornisce, ad esempio, le informazioni sul carico di utilizzo della CPU o le informazioni sulla memoria RAM disponibile e occupata, oppure ancora, i dati relativi all utilizzo del file system e quindi della memoria secondaria. Queste operazioni costituisco uno dei fattori principali che promuove l utilizzo di una infrastruttura a macchine virtuali. Esse rendono semplici e veloci molte operazioni che vengono, invece, abitualmente svolte da un utente umano. La possibilità poi di rendere automatizzate alcune di queste, implementando programmi ad-hoc, apre nuovi scenari nella gestione delle macchine. 2.3 Virtual Machine come sistema aperto Le potenzialità del modello vengono alla luce nel momento in cui si considera la VM come sistema aperto, cioè non limitandosi a considerarla dall esterno ma ponendo attenzione al SO guest. La visione monolitica della VM lascia il posto ad una visione più complessa che vede la presenza di un sistema operativo in esecuzione sull hardware virtuale. Le sole capacità dell hypervisor, descritte fin qui, non sono sufficienti, ma si rende necessario l utilizzo di moduli aggiuntivi che permettano a quest ultimo di vedere il sistema operativo. Il VMM non è più, solo, un intermediario, fra l hardware e il software, ma diviene un entità in grado di interagire con l host in modo efficace. Un insieme delle possibili operazioni che possono essere rese disponibili tramite interfaccia software sono: - Gestione dei processi Questa operazione fornisce la possibilità di visualizzare i processi in esecuzione, la memoria e la cpu richiesta da ciascuno di essi. Permette di terminare o avviare un applicazione in esecuzione o di risalire all utente che la esegue. L applicazione che usufruisce di tale servizio è in grado, per esempio, di monitorizzare i processi attivi, di chiuderli nel caso questi si blocchino o se necessario di aumentarne la priorità. 16

25 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 17 - Gestione della memoria principale Attraverso questa operazione è possibile reperire informazioni dettagliate della memoria principale e in particolare è possibile avere una visione globale della struttura di tale risorsa. Accedendo alla tabella di paginazione tale operazione è in grado di fornire indicazioni sui metodi di allocazione del sistema operativo e mostrare l occupazione in memoria di ciascun processo. L applicazione che usufruisce di tale servizio può affiancare il SO nell attività di ottimizzazione della risorsa. - Gestione del File System Una limitazione del VMM è quella di vedere la memoria di massa del sistema guest come un unico file di grandi dimensioni. Tale operazione permette ad un applicazione di superare tale limite consentendole di vedere dettagliatamente la struttura del file system. L operazione permette di svolgere operazioni su i singoli file ed eventualmente tener traccia delle modifiche apportate a quest ultimi. Si possono creare applicazioni in grado di effettuare backup differenziali di directory o applicazioni in grado per esempio di gestire autonomamente le partizioni del disco. - Gestione della rete L operazione permette di creare, chiudere e modificare connessioni. Permette inoltre di monitorizzare e filtrare il traffico di rete. Grazie a questa operazione un applicazione può, per esempio, monitorizzare i pacchetti in transito su una connessione e bloccare quelli che non provengono da una fonte certa. In ambito server, un applicazione, a fronte di un elevato traffico su una connessione, può alleggerirne il carico, ripartendo l onere su più connessioni. - Gestione del sistema I/O Anche se le periferiche principali possono essere gestite tramite le funzionalità del hypervisor nella visione della macchina virtuale come sistema chiuso, si rende necessario prevedere questa operazione per i casi in cui occore che un applicazione comunichi 17

26 18 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API direttamente con un dispositivo e non si limiti alla semplice funzionalità di collegamento e scollegamento dinamico. L utilità di questa operazione si evidenzia nel fatto che è possibile creare applicazioni in grado di comunicare con periferiche e dispositivi di I/O sfruttando i driver presenti nel SO guest. - Configurazione Grazie a questa operazione viene fornita la possibilità di configurare dal punto di vista software il sistema operativo guest. Si ha la possibilità di installare o rimuovere programmi dal sistema, o per esempio di settate secondo regole precise la configurazione del sistema. L applicazione che fa ricorso a tale operazione può, per esempio, sostiture l azione di un amministratore di rete e configurare in modo automatico più macchine secondo le stesse specifiche (questo approccio può essere un alternativa, qual ora non sia possibile copiare su più host la medesima VM). La presenza di un ponte che mette in comunicazione il monitor con il sistema host e la contemporanea esistenza di interfacce software che rendano disponibili i servizi offerti dal SO apre nuove ed affascinanti strade. In quest ottica è possibile gestire un sistema operativo senza necessariamente vivere al suo interno e in modo del tutto trasparente all utente. Nello scenario comune l applicazione in esecuzione sul SO è soggetta al controllo di quest ultimo, il quale è reciprocamnte influenzato sia dalle operazioni che essa svolge, sia dall esecuzione dell applicazione stessa. In tale realtà, infatti, l esecuzione del processo comporta al SO una serie di attività di gestione che riguardano, per esempio, lo scheduling, l allocazione della memoria oppure l assegnazione delle risorse di I/O. Grazie alla virtualizzazione e alle API messe a disposizione l applicazione può essere eseguita su un host diverso; in questo modo il sistema operativo controllato non ha più l onere di gestire il processo ma è solamente soggetto agli effetti delle operazioni che questo esegue su di esso. Anche dal punto di vista dell utente questo porta benefici, infatti nel primo caso l azione del processo, anche se nascosto, è percettibile dall utente che può eventualmente anche disturbarne l azione, nel secondo caso l applicazione svolge il proprio com- 18

27 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 19 pito in maniera del tutto invisibile agli occhi dell utente, il quale può solamente osservare gli effetti i tali operazioni. 2.4 I possibili scenari Il continuo sviluppo dell Information Tecnology conduce alla creazione di sistemi sempre più potenti e performanti a discapito, però, della struttura e del funzionamento che divengo più complessi. In un futuro in cui, oltre a gestire queste problematiche si dovrà affrontare l esigenza di avere tali sistemi connessi in rete fra loro, sarà indispensabile cercare metodi alternativi per l amministrazione e l ottimizzazione delle risorse. Una possibile soluzione a queste problematiche è proposta da IBM attraverso l Autonomic Computing. Questa disciplina ha l obiettivo di creare sistemi autonomi in grado di modificare il proprio comportamento in funzione dello stato interno e delle condizioni dell ambiente esterno. In tale scenario il ruolo di amministrazione dell utente lascia il posto a quello di supervisione poichè l Autonomic System sarà in grado di gestirsi autonomamente; avrà la facoltà di modificare il proprio comportamento in funzione, per esempio, del carico di lavoro, del verificarsi di errori software o hardware, o degli input ricevuti dall esterno. Sarà in grado di monitorizzare il proprio stato al fine di individuare possibili miglioramenti e di imparare dalle decisioni prese in passato. Le attività che secondo IBM tali sistemi dovranno essere in grado di svolgere autonomamente sono riassunte in 4 voci principali esposte di seguito: Configurazione (Self-configuration) L installazione e la configurazione di nuovi componenti all interno di sistemi complessi richiede tempo e notevoli risorse. L Autonomic System è in grado di gestire autonomamente l integrazione di nuovi componenti, di configurarli e di adattare il comportamento del resto del sistema in funzione della nuova entità. E in grado di valutare se le modifiche apportate sono convenienti e se la macchina continua a funzionare correttamente. 19

28 20 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API Ottimizzazione (Self-optimization) Numerose infrastrutture software (es. middleware) per poter funzionare bene necessitano di una fase iniziale di configurazione in cui, tipicamente, l amministratore è chiamato a settare correttamente i parametri richiesti. La conseguenza di ciò è che tale operazione risulta difficile ed onerosa e porta spesso a non ottenere buoni risultati in termini di efficienza. Un Autonomic System è in grado svolgere autonomamente la fase di configurazione, è in grado di ricercare la soluzione migliore per ottimizzare le performance ed è in grado di imparare dalle decisioni prese. Protezione (Self-protection) Nonostante le precauzioni adottate tramite l uso di firewall o antivirus i sistemi odierni risultano ancora vulnerabili ad attacchi provenienti dall ambiente circostante o a mal funzionamenti delle entità che lo compongono. L autonomic system è in grado di proteggersi autonomamente in due modi: attraverso l individuazione di situazioni anomale che ne compromettono il funzionamento, oppure, grazie alla prevenzione ottenuta mediante l utilizzo di opportuni sensori in grado di segnalare in anticipo il problema. Una volta individuato, il sistema lo isola e ne cerca una soluzione. Cura (Self-healing) L idividuazione dei problemi che affliggono un sistema (software o hardware) richiede l intervento di numerose persone e lo sfruttamento di ingenti risorse che spesso non permettono il raggiungimento degli obiettivi prefissati. L Autonomic System rileva autonomamente ogni problema che mette a rischio il corretto funzionamento della macchina. Basandosi, poi, sulle informazioni che possiede sulla propria configurazione è in grado di risolvere il problema, di tenere traccia dell accaduto e di comunicarlo all esterno. Grazie alla virtualizzazione e al modello descritto nei paragrafi precedenti, si ha la possibilità di costruire applicazioni che permettano di gestire in modo automatizzato una macchina e in particolare il sistema 20

29 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 21 operativo. Il vantaggio principale portato da tale approccio è quello di fornire le risorse necessarie a sviluppare entità software attive in grado di comandare macchine, senza necessariamente essere influenzate dal comportamento del SO o da quello dell utente. L applicazione così costruita è in grado configurare, ottimizzare, proteggere e curare in maniera autonoma il sistema e per queste ragioni, quindi, la virtualizzazione costituisce uno dei possibili mezzi per la realizzazione di un Autonomic System. 21

30 22 CAPITOLO 2. GESTIONE DI MACCHINE VIRTUALI TRAMITE API 22

31 Capitolo 3 Tecnologia a supporto: VMware Infrastructure SDK In questo capitolo si descrive il funzionamento delle principali API software messe a disposizione da VMware per controllare macchine virtuali. 3.1 Panoramica L infrastruttura promossa da VMware per la virtualizzazione si concretizza in due piattaforme software, principali, denominate: ESX Server e VirtualCenter Server. Quest ultime oltre a provvedere alla virtualizzazione delle computing resources e permettere quindi l esecuzione di virtual machine, forniscono strumenti per monitorizzare e gestire le risorse virtuali. Il tipico scenario di funzionamento prevede l accesso a tali servizi mediante un interfaccia grafica opportuna disponibile su web browser o client software. Tale interfaccia permette ad un utente di interagire con l hypervisor e in particolare di usufruire dei servizi messi a disposizione da quest ultimo per gestire e monitorizzare le macchine virtuali in esecuzione su di esso. Un metodo alternativo a questo è quello di gestire una VM attraverso le API software messe a disposizione da VMware, mediante le quali è possibile interfacciare un applicazione al virtual machine 23

32 24 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK monitor. L architettura adotta un modello noto come: VMware Infrastructure Object Model il quale specifica: I protocolli da adottare per la comunicazione. L insieme delle strutture dati disponibili a disposizione. L insieme delle operazioni possibili sulle entità virtuali. Tale modello, concepisce l infrastruttura virtuale come un ambiente distribuito in cui diversi host connessi in rete eseguono in contemporanea più macchine virtuali. Al fine di supportare nel migliore dei modi questo scenario, il modello prevede l utilizzo di un web service installato sulla macchina host con il compito di rendere disponibile un iterfaccia software attraverso la quale un applicazione è in grado di usufruire dei servizi offerti dal VMM installato sulla medesima macchina. L insieme delle interfacce software previste prende il nome: VMware Infrastructure SDK (VI SDK). Quest ultime sono concepite in un ottica Object Oriented e sono indipendenti dal linguaggio di programmazione adottato. Le caratteristiche di tali API sono: Utilizzo della tecnologia basata su web services che permette all applicazione di interagire con l hypervisor. Definizione di interfacce in linguaggio WSDL per la comunicazione con il web service (questo porta a creare client stub in linguaggio astratto indipendente dalla tecnica di programmazione adottata e permette di semplificare la richiesta dei servizi). Comunicazione client-server attraverso protocollo SOAP (si semplifica la comunicazione e si garantisce l interoperabilità del software grazie alla comunicazione basata su scambio di messaggi XML). Utilizzo del protocollo di rete HTTP o HTTPS per la comunicazione fra client e server. 24

33 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK Tipi di dato Come acennato, l SDK è concepito secondo il paradigma di programmazione Object Oriented. In accordo con tale paradigma ciascun dato rappresenta un oggetto il quale incapsula sia informazioni riguardanti lo stato, sia metodi che rentono tale entità in grado di eseguire operazioni. I principali tipi di dato previsti dall SDK di VMware sono i seguenti: - Managed Objects Rappresentano gli oggetti principali attorno ai quali ruota il funzionamento dell intera infrastruttura. Essi costituisco le entità alle quali rivolgersi per reperire informazioni od eseguire operazioni. Le istanze di tali oggetti vivono lato server e interagiscono con il virtual machine monitor. - References to Managed Objects Gli oggetti di questo tipo, invece, vivono nel client e costituiscono un riferimento agli oggetti disponibili sul server. Essi permettono ad un applicazione di reperire informazioni sullo stato di un managed object o di eseguire operazioni su quest ultimo (tipicamente viene rappresenta il valore di ritorno per operazioni di connessione o richiesta al web service). - Data Objects Sono oggetti adibiti ad incapsulare esclusivamente informazioni. Vengono impiegati, per esempio, per comunicare l esito di operazioni o situazioni di errore; contengono al loro interno tipi di dato semplice o composto. 3.3 Organizzazione Logica Nelle realtà più complesse in cui più host sono connessi in rete nasce la necessità di organizzare dal punto di vista logico, l intera infrastruttura virtuale. In tali scenari, infatti, la presenza di diverse macchine virtuali in esecuzione su ciascun host rende difficile il compito di amministrazione e gestione. Per porre rimedio a tali problematiche il modello proposto da VMware fornisce gli strumenti per organizzare 25

34 26 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK in gruppi logici (tipicamente alberi) le infrastrutture virtuali. I due Figura 3.1: Organizzazione Logica elementi principali sono i Folders e i Datacenter che rappresentano dei contenitori ove inserire le entità dell infrastruttura. Tali oggetti costituiscono i nodi dell albero e attraverso le API messe a disposizione dall SDK è possibile gestirne la struttura (come si vedrà in seguito questo approccio si rendde utile nel momento in cui è necessario cercare un managed object all interno dell infrastruttura virtuale). 3.4 Managed Object Si è già detto, in precedenza, che i managed object costituisco le entità più importanti del framework. Essi permettono ad un applicazione di interagire con l hypervisor e in particolare di eseguire operazioni o di monitorizzare lo stato delle risorse. In accordo con il paradigma ad oggetti questi tipi di dato vengono mappati in classi specifiche che contengono al loro interno sia metodi con i quali accedere ai servizi sia parametri grazie ai quali è possibile monitorare lo stato. Il framework mette a disposizione numerose tipologie diverse di managed object ma tutte fanno riferimento ad un unica classe astratta denominata ManagedEntity. Questa relazione mette in evidenza che esistono alcune operazioni che sono in comune ad ogni entità; per 26

35 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK 27 Figura 3.2: ManagedEntity Base Class esplicitare questa caratteristica tali metodi sono raccolti in un unica classe astratta che assume il ruolo di classe base, estesa da ciascun managed object. In accordo con le osservazioni fatte nel capitolo precedente (nella visione chiusa della macchina virtuale) i managed object, di interesse, devono consentire ad un applicazione di monitorizzare e comandare una macchina virtuale. A tal fine vengono descritti i seguenti tipi di oggetto: TaskManager Managed Object SearchIndex & PropertyCollector Managed Object VirtualMachine Managed Object PerformanceManager Managed Object 27

36 28 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK 3.5 TaskManager Managed Object Figura 3.3: TaskManager Object La tecnologia proposta rappresenta le operazioni che un applicazione esegue attraverso oggetti denominati Task. Il TaskManager permette di tenere traccia dello stato in cui si trova un Task, nonché di reperire la lista di quelli eseguiti fino ad un dato istante. L attività di valorizzare tale oggetto è a carico dal web service il quale per ogni richiesta pervenuta crea un riferimento all operazione eseguita. Come si vedrà più avanti, ciascuna operazione che viene richiesta restituisce come valore di ritorno un oggetto di tipo Task mediante il quale è possibile risalire alle informazioni sullo stato dell operazione richiesta. L impiego di tale oggetto risulta indispensabile nel momento in cui l applicazione viene concepita per lavorare in modo asincrono. In 28

37 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK 29 tale circostanza le chiamate che questa effettuta non sono bloccanti e richiesta l esecuzione di un operazione al web service l applicazione continua a lavorare nel suo flusso esecutivo. Mediante il riferimento al Task ottenuto, l applicazione può in ogni momento interrogare il TaskManager per conoscere lo stato di completamento dell operazione richiesta. A fianco a del TaskManager lavora, infine, lo ScheduledTaskManager il quale permette di pianificare l esecuzione di Task in momenti diversi. 3.6 SearchIndex & PropertyCollector Managed Object Come si è detto in precedenza l applicazione client non comunica direttamente con le entità che vivono sul server ma comunica con queste attraverso oggetti-riferimento (References to Managed Object). A supporto di ciò, il framework mette a disposizione un oggetto de- Figura 3.4: SearchIndex Object nominato SearchIndex Object che consente di risalire all istanza della managed entity attraverso l utilizzo di parametri univoci specificati dall utente come, per esempio, il DNS name, l IP address o lo UUID (universally unique identifier). Il metodo findbyuuid, ad esempio, consente di recuperare il riferimento, attraverso l UUID. /*Attraverso il codice univoco specificato e l oggetto che rappresenta *la connessione al web service viene recuperato *il riferimento alla Virtual Machine*/ String uuid = "502c4e80-aa5b-3aa1-56ca-e05fdcbd6e54"; 29

38 30 CAPITOLO 3. TECNOLOGIA A SUPPORTO: VMWARE INFRASTRUCTURE SDK ManagedObjectReference vmref = my_conn.findbyuuid(_sic.getsearchindex(), null, uuid, true); Una volta recuperata l istanza dell entità da gestire, l applicazione ha la possibilità di invocare operazioni oppure di monitorizzare lo stato. In particolare, in quest ultimo caso, il reperimento delle informazioni avviene mediante la creazione di opportuni filtri che permettono di specificare le caratteristiche che si vogliono visualizzare e la posizione nella gerarchia virtuale dove cercale. Il tipo di dato che permette di specificare i parametri di ricerca è il propertyfiterspec un oggetto che incapsula a sua volta due tipi di dati denominati rispettivamente PropertySpec e ObjectSpec. Il primo permette di specificare il tipo di oggetto da monitorizzare (es. Virtual Machine) e il tipo di informazione da recuperare (es. stato della macchina). /*Si costruisce il filtro che permette di specificare il *tipo di risorsa da monitorare e l informazione da recuperare*/ PropertySpec[] pspec = new PropertySpec[] { new PropertySpec() }; pspec[0].settype("virtualmachine"); pspec[0].setpathset(new String[] {"runtime.powerstate"}); Il secondo permette invece di specificare la posizione ove iniziare la ricerca che può essere per esempio un Folder o un DataCenter. /*Viene specificata la posizione nell albero logico dove *iniziare la ricerca*/ ObjectSpec[] obspec = new ObjectSpec[] { new ObjectSpec() }; obspec[0].setobj(_rootfolder); obspec[0].setskip(new Boolean(true)); Una volta costruito il filtro, si rende necessario il PropertyCollector mediante il quale è possibile recuperare le informazioni. Esso mette a disposizione il metodo RetriveProperties il quale ricevuto come parametro di ingresso il filtro restituisce il data object che incapsula tutti i dati richiesti. /*Attraverso il filtro e il PropertyCollector vengono recuperate *le informazioni richieste sull entità specificata*/ PropertyFilterSpec spec = new PropertyFilterSpec(); spec.setpropset(pspec); 30