i
INTRODUZIONE
Il Cloud Computing rappresenta un modello di servizio in grado di semplificare la vita delle imprese pubbliche e private, svincolandole dalla gestione degli aspetti informatici, poiché comprende l’insieme di infrastrutture e applicazioni che permettono l’utilizzo di risorse hardware e software distribuite in remoto che possono essere utilizzate su richiesta, senza che il cliente debba dotarsene interamente. La fruizione di tali servizi può avvenire anche attraverso postazioni di lavoro thin, cioè terminali a basso costo dotate di minima capacità elaborativa e di memoria.
Le tecnologie di Cloud Computing, basate sull’utilizzo di risorse computazionali messe a disposizione dai moderni Data Center, permettono l’erogazione di un servizio sicuro e flessibile mirato alla fornitura di infrastrutture e risorse di calcolo, di hardware, di software e di rete tagliate sulle esigenza dell’utente finale e in grado di ospitare le sue applicazioni, con logiche di tariffazione che possono essere basate sull’effettivo utilizzo dei servizi offerti.
In sintesi il Cloud Computing abilita un nuovo modo di “fare informatica” per le aziende.
Questo lavoro di tesi si dipana attraverso tre parti principali.
La prima parte, che comprende i capitoli 1 e 2, riguarda lo studio del Cloud Computing nei sui aspetti formali e generali e serve ad introdurre il cosiddetto servizio di infrastruttura, meglio noto come Infrastructure as a Service (IaaS), che intendiamo riprodurre nel nostro laboratorio.
La seconda parte, che include il capitolo 3, riguarda l’analisi dettagliata della configurazione del datacenter di laboratorio per la creazione di un cloud privato per servizi IaaS, attraverso l’uso dei prodotti VMware, leader
ii
nella produzione di software per la virtualizzazione e per la costruzione di servizi cloud-based.
Infine, l’ultima parte, rappresentata dal capitolo 4, investiga alcune problematiche di rete e di storage attraverso l’analisi del traffico generato, con particolare attenzione a fenomeni tipici di questi ambienti virtualizzati, come la migrazione di Virtual Machine.
Introduzione
1
CAPITOLO 1 – INTRODUZIONE AL CLOUD COMPUTING
1.1 Cos’è il Cloud Computing?
Cloud Computing è la parola del momento. Tutto è fatto su cloud computing, ogni cosa è cloud computing. Al di là dell’abuso di terminologia, il cloud computing è realmente una delle attività di interesse principale nell’industria dell’ ICT (Information and Comunication Technology).
Il cloud computing è un nuovo modo di fornire potenza di calcolo, storage e applicazioni tramite l’infrastruttura Internet, in una maniera simile alla distribuzione dell’acqua, dell’energia elettrica o del servizio telefonico. Quando colleghiamo un apparecchio alla presa della corrente, non ci preoccupiamo su come venga generata la potenza elettrica o su come arrivi fino a noi, in un certo senso l’elettricità è virtualizzata. Allo stesso modo, vogliamo estendere questo concetto alle tecnologie dell’informazione per avere a disposizione un socket che ci fornisca potenza di calcolo e, allo stesso tempo, ci nasconda come ciò venga attuato.
La potenza di calcolo diviene così virtualizzata e i computer diventano costituiti da componenti distribuiti come processori, schede di memoria e software. Tecnologie come i cluster, il grid e, adesso, il cloud computing hanno consentito l’accesso a una grande quantità di potenza di calcolo in maniera del tutto virtualizzata. Queste “nuvole” sono l’evoluzione naturale dei tradizionali Data Centers, ma si distinguono dagli stessi per offrire un servizio basato sugli standard Web e di tipo pay-per-use: gli utenti che usufruiscono del servizio vengono così tassati in base al loro effettivo utilizzo delle risorse o mediante una quota mensile (tariffa flat). I principali
2
fornitori di questo servizio sono le grosse compagnie di telecomunicazioni come Telecom Italia, France Telecom, Amazon, Google, Microsoft.
I principi basilari dietro questo modello sono l’offerta di computing, storage e software “come un servizio”. Molti professionisti appartenenti alle sfere accademiche o commerciali hanno tentato di fornire una definizione formale di “cloud computing”.
R. Buyya, nel suo “Future Generation Computer Systems”, l’ha definito come segue: “Il cloud è un sistema di calcolo distribuito che consiste di un insieme di interconnessioni e computer virtualizzati che sono dinamicamente presentati come una o più risorse di calcolo unificate, basate sui service-level agreements (SLA) stabiliti mediante negoziazione tra provider e consumatore”.
L.M. Vaquero parla invece del “cloud come una grossa piscina di risorse virtualizzate e facilmente accessibili. Queste risorse possono essere dinamicamente riconfigurate per venire incontro ad esigenze di carico (per scalare), consentendo un’ottimale utilizzazione delle risorse. Tale ‘piscina di risorse’ è tipicamente sfruttata secondo un modello pay-per-use, in cui le garanzie sono offerte dal provider dell’infrastruttura attraverso dei personalizzati SLA”.
Più in generale, Armbrust definisce il cloud come un “data center hardware e software che fornisce servizi”.
Ogni definizione, a suo modo, pone l’accento su un aspetto importante: il passaggio dalla potenza di calcolo generata “in casa”, a quella fornita attraverso Internet, come un servizio Web. Questo modello porta benefici sia al consumatore che al provider del servizio IT (Information Technology). Il consumatore può ottenere una riduzione dei costi correlati al servizio IT, scegliendo di ottenere un servizio da un provider esterno
Introduzione al Cloud Computing
3 invece di investire sull’infrastruttura IT e sull’assunzione del personale. La componente “on-demand” di questo modello consente, inoltre, di adattare l’utilizzo del servizio alle proprie esigenze.
Il fornitore, invece, dispone di un’infrastruttura software e hardware che espleta diversi servizi, per molti utenti, in maniera efficiente, e questo conduce ad un veloce ritorno degli investimenti (ROI - return of investment) e ad un abbassamento totale dei costi di gestione (TCO - total cost of ownership).
1.2 Le fondamenta del cloud computing
Il successo del cloud computing è strettamente collegato alla maturazione di altre tecnologie, specialmente in ambito hardaware (virtualizzazione e
paravirtualizzazione), Internet (Web services, Service-Oriented
Architetture, Web 2.0), calcolo distribuito (clusters e grid) e sistemi di management (autonomic computing).
4
1.2.1 Virtualizzazione e Paravirtualizzazione
I servizi di cloud computing sono generalmente forniti da data center composti da milioni di computer, utilizzati per ospitare le più disparate applicazioni e servire gli utenti che ne necessitano. In quest’ottica, la virtualizzazione dell’hardware rappresenta un trend senz’altro suggestivo. L’idea di operare su macchine virtuali (VMs-Virtual Machines) permette di migliorare la condivisione e l’utilizzazione di un sistema, consentendo di far girare su una singola piattaforma fisica più sistemi operatavi e più stack software.
Il Virtual Machin Monitor (VMM), anche detto hypervisor, rappresenta l’elemento chiave nella virtualizzazione.
Grazie a software come VMware ESXi, Xen o KVM è possibile trasformare, ovvero "virtualizzare", le risorse hardware di un computer x86, compresi la CPU, la RAM, il disco rigido e il controller di rete, e creare una macchina virtuale completamente operativa in grado di eseguire i propri sistemi operativi e applicazioni al pari di un computer "reale". Quando le macchine cercano di accedere al “loro” hardware, l’hypervisor intercetta le richieste e le riformula correttamente.
Introduzione al Cloud Computing
5 Il VMM deve operare in maniera trasparente senza pesare con la propria attività sul funzionamento e sulle prestazioni dei sistemi operativi. Esso si presenta come un sottile strato software implementato direttamente nell'hardware del computer (soluzione Bare-matel) o nel sistema operativo host (soluzione Hosted). Questo strato contiene un sistema di monitoraggio che consente l'allocazione dinamica e trasparente delle risorse.
Il software di paravirtualizzazione, invece, agisce direttamente
sull'hardware in modo da gestire la condivisione delle risorse destinate alle varie virtual machine.
Il sistema di paravirtualizzazione si distingue da quello
di virtualizzazione per il differente approccio utilizzato. In questo caso non si cerca di creare un'emulazione dell'hardware di un generico computer x86, ma, piuttosto, si regola e controlla l'accesso alle risorse fisiche della macchina da parte delle varie istanze delle VM: l’hypervisor viene by-passato, il che consente di ridurre l’overhead e i tempi di risposta dell’hardware.
La paravirtualizzazione prevede che il “sistema di virtualizzazione” esponga ad ogni macchina virtuale interfacce hardware simulate funzionalmente simili, ma non identiche, alle corrispondenti interfacce fisiche: “il sistema di virtualizzazione” espone una libreria di chiamate (Virtual Hardware API) che implementa una semplice astrazione delle periferiche. Occorre necessariamente modificare il cuore (kernel) ed i driver dei sistemi operativi ospiti per renderli compatibili con la “Virtual Hardware API” del “sistema di virtualizzazione” utilizzato. La complicazione di dovere modificare il cuore (kernel) dei sistemi ospite viene ripagata con un incremento della velocità di elaborazione.
6
L’avvento di queste tecnologie innovative, insieme alla diffusione di chips multi-core ed a tecniche per la migrazione on-line di VMs, sta contribuendo sempre di più all’uso della virtualizzazione sui sistemi che fungono da server. Si pensa di poter arrivare fin anche a 100 VMs su un unico server fisico invece di 100 server fisici con conseguenti ed evidenti risparmi in termini di energia elettrica, aria condizionata e di potenza in generale. Tipicamente, i benefici che si percepiscono sono una migliore utilizzazione e condivisione del sistema, una migliore gestione, e una più alta affidabilità. Ad onore del vero, la virtualizzazione non è un concetto esattamente nuovo. Già negli anni ‘60 IBM Cambridge Scientific Center inizia lo sviluppo del CP-40, il primo sistema operativo che realizza una completa virtualizzazione. Negli anni ‘70, poi, alcune compagnie fornivano potenza di calcolo mediante mainframe su cui potevano girare dozzine di applicazioni, lavorando spesso vicino al 100% delle loro capacità (e così doveva essere dato il costo elevato di queste macchine all’epoca).
Successivamente l’era dei mainframe collassò, a causa dell’avvento dei veloci ed economici microprocessori che spinsero i data center a fornire servizi IT mediante singoli server fisici. Inoltre, anche l’incompatibilità tra diversi stack software e diversi sistemi operativi condusse ad un isolamento del carico di lavoro in server dedicati.
In seguito, l’avvento di reti veloci e affidabili (spesso in fibra ottica) e di nuove tecnologie per la condivisione delle capacità di processing hanno concesso una ‘seconda chance’ alla virtualizzazione, pronta, questa volta, ad essere sfruttata appieno.
Introduzione al Cloud Computing
7
Figura 1.2 Hypervisor di tipo 1 e tipo 2
1.2.2 Service-Oriented Architecture – SOA
Un’architettura orientata ai servizi indica generalmente un’architettura software adatta a supportare l’uso di servizi Web per garantire l’interoperabilità tra diversi sistemi così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente. Nell’ambito di un’architettura SOA è quindi sempre possibile modificare, con uno sforzo ragionevole, le modalità di interazione tra i servizi, oppure la combinazione con cui i servizi vengono utilizzati nel processo. Risulta, altresì, agevole aggiungere nuovi servizi e modificare i processi per rispondere alle concrete esigenze di business.
Nel dominio del Software as a Service, un’ applicazione cloud può essere composta da una collezione di servizi che, insieme, formano una complessa logica di business.
E così i servizi più svariati come autenticazione d’utente, e-mail e chat vengono integrati a piacere dall’utente, proprio come nello spirito del SOA.
8
1.2.3 Grid Computing
I sistemi Grid sono un’infrastruttura di calcolo distribuito, utilizzati per l’elaborazione di grandi quantità di dati, mediante l’uso di una vasta quantità di risorse.
In particolare, tali sistemi permettono la condivisione coordinata di risorse all’interno di un’organizzazione virtuale (VO).
La condivisione non è limitata solo allo scambio dei file, ma si estende all’accesso diretto a computer, a software, ed in generale a tutto l’hardware necessario alla risoluzione di un problema scientifico, ingegneristico o industriale. Gli individui e le istituzioni, che mettono a disposizione della griglia le loro risorse per la medesima finalità, fanno parte della stessa VO. In altri termini, viene fornito una sorta di ‘super calcolatore’ mettendo insieme più macchine di potenza minore.
Il cloud computing ha una connotazione un po’ diversa rispetto al grid: esso nasce per fornire servizi di calcolo all’utente finale, non aggregando più macchine ma, addirittura, ‘separando’ una macchina fisica in molte macchine virtuali e consentendo di abbattere i costi proprio perché più utenti condividono la stessa macchina fisica.
Molti progetti di grid computing come TeraGrid o neuGRID prevedevano l’utilizzo condiviso di risorse di calcolo e di storage, distribuite su differenti domini amministrativi, per lo sviluppo e l’implementazione di applicazioni di carattere scientifico, come modelli per il clima o lo studio di malattie neurodegenerative.
D’altro canto, attività associate ad un utente o ad una VO possono influenzare in maniera incontrollata le performance percepite da un altro utente che usa le risorse di calcolo della stessa piattaforma. Pertanto,
Introduzione al Cloud Computing
9 l’impossibilità di garantire una certa qualità del servizio (QoS), può divenire un problema, specialmente in certe applicazioni definite time-critical. Un altro problema è dato dal fatto che, spesso, la ‘griglia’ mette a disposizioni risorse con configurazioni software differenti, inclusi sistemi operativi, librerie, compilatori e via dicendo. Di conseguenza, una barriera di ‘portabilità’ rende spesso frustrante l’utilizzo del grid.
La virtualizzazione dell’hardware può essere identificata come la soluzione ottimale a questi problemi. In questa direzione spingono molti progetti di ricerca (per esempio Globus Virtual Workspace), con lo scopo di consentire al grid di supportare la virtualizzazione di risorse di calcolo, di rete e di storage.
1.2.4 Autonomic Computing
I grandi data center dei provider dei cloud computing devono essere sottoposti a manutenzione in maniera efficiente. La crescente complessità dei sistemi ha spinto verso l’autonomic computing.
In altre parole, il monitoraggio della ‘nuvola’ avviene in maniera del tutto automatizzata, grazie ad una elaborata rete di sensori, e così il sistema si auto-configura, si auto-ottimizza, si auto-cura e si auto-protegge. Il tutto, ovviamente, viene controllato, a livello più alto, dall’uomo.
1.3 Caratteristiche di un’infrastruttura cloud
Poiché il termine cloud non si riferisce ad una tecnologia in particolare, ma ad un paradigma di provisioning di risorse, bisogna investigare quali sono le caratteristiche che contraddistinguono un servizio di tipo cloud. Alcune di
10
queste caratteristiche possono essere definite essenziali (fondamentali in un ambiente cloud) altre rilevanti (auspicabili in un ambiente cloud).
Più in generale possiamo distingure aspetti non-funzionali, economici e tecnologici che un sistema cloud devrebbe avere.
Gli aspetti non-funzionali rappresentano le qualità o proprietà di un sistema, che prescindono dalle tecnologia che ne sta alla base. Essi possono essere realizzati in diverse maniere e interpretati in modo diverso, il che può portare a problemi di incompatibilità e interoperabilità tra i diversi provider. Gli aspetti non-funzionali sono uno dei motivi chiave per cui il ‘cloud’ differisce così fortemente nella sua interpretazione.
Gli aspetti economici sono il motivo che hanno dato spinta al business attraverso il cloud. Particolare interesse tipicamente giace nella riduzione dei costi attraverso la remotizzazione delle risorse e la gestione automatizzata delle stesse, cercando, al solito, di trovare un giusto compromesso tra la perdita di controllo e la riduzione degli sforzi.
Infine, ovviamente, le sfide tecnologiche che nascono dagli aspetti non-funzionali ed economici, quando si tenta di realizzarli. Diversamente dagli altri aspetti, tipicamente, le sfide tecnologiche implicano una specifica realizzazione, anche se esistono ancora degli approcci non standard ed ulteriori deviazioni rispetto alle ‘normali’ soluzioni esistenti possono manifestarsi.
Un utente si dice che utilizza dei servizi di tipo cloud se può accedere in qualsiasi momento alle risorse di cui ha bisogno, se per queste risorse è previsto un sistema di tariffazione in base all’utilizzo effettuato, se l’utente ha l’impressione di aver accesso ad una quantità infinita di risorse che può personalizzare a piacere.
Introduzione al Cloud Computing
11 1.4 Aspetti non-Funzionali
1.4.1 Self-Service
I consumatori di servizi di cloud computing si aspettano di poter accedere alle risorse di cui hanno bisogno on-demand, ed avere un provisioning quasi istantaneo. Per supportare queste aspettative, un’infrastruttura cloud deve consentire un accesso self-service ai servizi che offre all’utente, che può richiederli, pagarli, personalizzarli senza l’intervento di alcun operatore. 1.4.2 Elasticità
Un ambiente cloud deve dare l’illusione di avere diponibile una quantità infinita di risorse. Gli utenti pertanto si aspettano di poter attingere in qualsiasi momento ad una quantità anche molto grande di risorse. In particolare, ci si aspetta che una quantità addizionale di risorse possa essere fornita, possibilmente automaticamente, quando il carico di lavoro di un’applicazione cresca, e rilasciata nel caso opposto.
1.4.3 Affidabilità
L’affidabilità è essenziale per ogni sistema cloud, essa denota la capacità di assicurare costantemente un servizio senza interruzioni o perdite di dati. L’affidabilità è sovente conseguita mediante una predisposizione ridondante delle risorse di calcolo, di storage o di networking, mentre meccanismi più complessi di fault-tolarance e disaster recovery consentono praticamente di azzerare il downtime del servizio.
12
1.4.4 Qualità del Servizio
La qualità del servizio è una caratteristica desiderabile (o rilevante per quanto detto prima) nei casi in cui certe risorse debbano essere consegnate con certi requisiti prestazionali, come il tempo di risposta o il throughput sul breve periodo.
1.4.5 Agilità
L’agilità di un’infrastruttura cloud è un aspetto connesso a quello di elasticità: il sistema deve essere pronto a soddisfare quasi istantaneamente cambiamenti di richieste, ma anche adattarsi velocemente ad una nuova ridistribuzione delle risorse. Ad esempio una macchina virtuale può essere spostata da un server fisico ad un altro ma non deve perdere la connettività con l’utente, è sarà quindi compito del sistema di management del cloud far si che tutte le connessione vengano reinstradate sul giusto path.
1.4.6 Personalizzazione
È chiaro che una volta che un utente ha a disposizione le risorse dal cloud, vuole che queste siano personalizzabili. Nel caso di IaaS ( Infrastucture as a Service ) un utente che ‘compra’ una macchina virtuale vuole poter installare un sistema operativo a piacere, sviluppare specifiche applicazioni ed avere accesso privilegiato ( root ) al server virtuale. Altre classi di servizi ( PaaS e SaaS ) offrono minore flessibilità in tal senso, ma ci si aspetta comunque un certo livello di personalizzazione.
Introduzione al Cloud Computing
13 1.5 Aspetti Economici
1.5.1 Pay per use
La capacità di determinare il costo di un servizio IT in base al suo consumo è una delle grandi caratteristiche del cloud. L’utilizzo di servizi cloud deve essere fatturato sulla base del consumo e della qualità di servizio richiesta. Le misurazioni possono essere fatte differentemente in base alle risorse utilizzate (storage, processing o banda di rete). Tutto, poi, deve essere riportato in maniera trasparente all’utente.
1.5.2 Return of Investment – ROI
Una delle grandi promesse del cloud è un rapido ritorno degli investimenti per il provider, anche se questo non può essere sempre garantito. Sviluppare un sistema cloud comporta inizialmente dei costi addizionali, dovuti sostanzialmente al miglioramento dell’infrastruttura per essere “cloud-ready”. Questo sforzo economico deve essere superato dai benefici che un ambiente cloud offre da un punto di vista commerciale.
1.5.3 Migliorare il Time to Market
Il Time To Market (o TTM) è una espressione anglòfona che indica il
tempo che intercorre dall'ideazione di un prodotto alla sua
effettiva commercializzazione. Migliorare il TTM può essere essenziale per piccole e medie aziende che vogliono vendere i loro servizi IT in maniera rapida e veloce. Un piccolo ritardo può essere causato dall’acquisto e dalla preparazione dell’infrastruttura, ma esso è senz’altro accettabile e consente di mantenere la competitività nei confronti di aziende più grandi.
14
1.5.4 Trasformare CAPEX in OPEX
Per un’impresa pensare di passare al cloud, o non passarci, è un po’ come decidere se comprare una casa o prenderne una in affitto. Di sicuro c’è che, soprattutto per le nuove piccole e medie imprese, che non dispongono già di un’infrastruttura efficiente per subentrare nel business, una soluzione di tipo cloud permette di usufruire di un prodotto, hardware o software in modalità as a service, che consente di convertire i massicci costi di capitale (Capital expenditure - CAPEX) in costi operativi ( Operational expenditure - OpEx), necessari per gestire un prodotto od un business.
1.6 Aspetti Tecnologici 1.6.1 Virtualizzazione
Come già detto più volte, la virtualizzazione consiste nella creazione di una versione virtuale di una risorsa normalmente fornita fisicamente e appartenente a un sistema ad architettura x86. Un ambiente cloud nasconde la complessità di questa tecnologia all’utente finale che si limita ad utilizzare le macchine virtuali, perdendo il controllo del sistema fisico.
1.6.2 Multi-Tenancy
Avere un’architettura multi-tenancy significa offrire un’applicazione che si comporta come se fosse totalmente dedicata a un cliente quando in realtà ne serve molti in parallelo utilizzando lo stesso codice.
Ai tempi del modello ASP (Application Service Provisioning), una delle principali sfide che le aziende si trovavano a dover affrontare era il problema della scalabilità. Per ogni nuovo cliente che veniva aggiunto, era spesso necessario disporre di una versione totalmente nuova di interfaccia
Introduzione al Cloud Computing
15 utente, una nuova logica di business, oltre all'esigenza di avere un database completamente diverso. Queste problematiche rendevano difficile il modello di business associato alle applicazioni ASP, perché non c'era modo per l'hosting provider di trarre vantaggio da reali economie di scala.
Tuttavia, il software come servizio (SaaS) si è evoluto dai giorni del modello ASP. Uno degli elementi chiave è stato proprio quello legato alle economie di scala che spesso viene affrontato con il concetto di multi-tenancy, è cioè disporre di un'applicazione che si comporta come se fosse totalmente dedicata a un cliente quando in realtà ne serve molti in parallelo. Questo principio si basa sul concetto one-to-many, piuttosto che sul modello one-to-one utilizzato in applicazioni premise-based tradizionali. I vantaggi assicurati dalle architetture multi-tenant sono duplici: l'infrastruttura sottostante è condivisa dando luogo a notevoli economie di scala con una ripartizione ottimale del carico. E, poiché gli elevati costi di sviluppo di infrastrutture e applicazioni sono condivisi, questa applicazione “enterprise-grade” può essere resa disponibile anche alle aziende più piccole. Un'architettura multi-tenant è progettata per consentire la messa a punto di configurazioni specifiche per ogni utente senza modificare il codice, perché lo stesso codice viene condiviso tra tutti i 'tenutari', trasformando così la personalizzazione del software in configurazione dello stesso.
Per trarre vantaggio da reali economie di scala con il modello SaaS è necessario essere in grado di fare tutto questo in un ambiente one-to-many.
16
1.6.3 Sicurezza e Privacy
Ogni utente si aspetta che i proprio dati siano mantenuti in maniera riservata, per cui le tecnologie con cui vengono assicurate sicurezza e privacy rappresentano un nodo gordiano nei sistemi cloud.
1.7 Tipologie di Cloud Computing
I servizi del cloud possono essere distinti in tre categorie, che si differenziano in base al livello di astrazione fornito all’utente. In particolare, il cloud offre accesso alle infrastrutture, alle piattaforme e alle applicazioni, per cui si parla rispettivamente di IaaS (Infrastucture as a Service), Paas (Platform as a service) e SaaS (Software as a Service).
Introduzione al Cloud Computing
17 1.7.1 Infrastucture as a Service
Un provider di Infrastucture as a Service (IaaS) offre ‘crude’ risorse di computing, storage e networking che l’utente può manipolare in maniera del tutto arbitraria. Nella pila di servizi offerti da un’infrastruttura cloud, l’IaaS si trova al livello più basso e consente il più alto grado di controllo.
In questo scenario abbiamo bisogno di conoscere bene i requisiti di cui abbiamo bisogno per far girare le nostre applicazioni e sfruttare le potenzialità dell’IaaS al meglio. Sarà compito dell’utente occuparsi di problemi di scala e di elasticità, muovendosi nei limiti delle risorse richieste. Infatti, è come se avessimo a disposizione un mini fai-dai-te data center.
Amazon Web Service è probabilmente il maggiore provider di IaaS con il suo Elastic Compute Cloud (EC2). Quando l’utente richiede un server con certi requisiti, AWS gli offre delle VMs con uno stack software personalizzabile, in maniera simile a come si personalizza un server fisico. AWS si basa sulla pura virtualizzazione, sebbene questo non sia un prerequisito per fornire servizi di infrastruttura. All’utente sono concessi diversi privilegi come avviare e stoppare l’istanza della macchina virtuale, personalizzarla installando dei pacchetti software a proprio piacimento, configurare procedure di controllo degli accessi e politiche di firewall. Tutto questo con il vantaggio di richiedere la VM on-demand e rilasciarla quando si vuole, pagando solo per l’utilizzo che se ne è fatto. Il prezzo può essere stabilito per uso o mediante abbonamento: la capacità di calcolo, lo spazio di storage e la banda di rete (relativa ai movimenti dei dati) sono alcune delle risorse che possono essere tassate in base all’utilizzo.
18
1.7.2 Platform as a service
Il Platform as a Service fornisce (PaaS) offre delle piattaforme software dove l’utente può costruire, debuggare e sviluppare le sue applicazioni. In questo modello di cloud gli utenti non devono occuparsi di problemi di scalabilità o del carico di lavoro dell’hardware sottostante: tutto ciò viene garantito in maniera assolutamente trasparente.
Le piattaforme offerte da rivenditori di PaaS come Google (con il suo App-Engine) o Force.com richiedono che le applicazioni seguano il proprio API (Application Programming Interface) e siano scritte in uno specifico linguaggio. Questa situazione, sebbene propenda verso un cambiamento, costringe l’utente a preoccuparsi di eventuali problemi di lock-in delle applicazioni. Inoltre, non è semplice migrare applicazioni esistenti da un certo ambiente PaaS ad un altro. Di conseguenza il PaaS vede gran parte del suo successo legato allo sviluppo di applicazioni proprio nell’ambito del cloud computing.
1.7.3 Software as a Service
Il SaaS rappresenta l’ultimo livello di servizi offerti dall’infrastruttura cloud. L’utente sostanzialmente utilizza dei programma in remoto, spesso attraverso un web browser. Come utente del SaaS, non ci si deve preoccupare su quale macchina giri il software, di quale sistema operativo vengo utilizzato, né tantomeno se il programma è stato scritto il Java, PHP o .NET. Soprattutto, non si deve installare nulla sul computer.
Per esempio, Gmail non è altro che un programma per email utilizzato via Web.
Introduzione al Cloud Computing
19 1.8 Modelli di sviluppo del cloud
Sebbene il cloud computing sia emerso principalmente per offrire servizi al pubblico, altri modelli di sviluppo, differenti per locazione fisica e per utilizzo dell’infrastruttura, possono essere adottati.
In questo senso un cloud può essere classificato come pubblico, privato o ibrido.
Figura 1.5 Modelli di Cloud Computing
1.8.1 Cloud pubblici
I cloud pubblici sono delle evoluzioni dei classici web service provider, basati su un modello di tassazione pay-per-use. In più un cloud pubblico offre la possibilità non solo di ospitare un sito web, ma anche tutte le nostre applicazioni avendo a disposizione una macchina virtuale su cui possiamo caricare le nostre applicazioni. Con il vantaggio di avere a disposizione un’infrastruttura ad alta affidabilità, con rete elettrica ed internet di backup.
20
Esempi di cloud pubblici: Amazon Ec2, Google app, Microsoft Azure, Oracle Cloud Computing.
1.8.2 Cloud privati
I cluod privati sono costruiti, gestiti e controllati da un’organizzazione per scopi interni. Come i cloud pubblici essi offrono fornitura on-demand di risorse computazionali e usano tecnologie di virtualizzazione per rilasciare queste risorse. Contrariamente ai cloud pubblici, non vendono la loro capacità di calcolo attraverso interfacce pubblicamente accessibili, ma si concentrano per offrire questi servizi agli utenti interni all’organizzazione. È una struttura utile per quelle compagnie che vogliono avere il totale controllo su ogni aspetto della loro infrastruttura. Il vantaggio chiave dei cloud privati è, per l’appunto, il controllo: ho il pieno controllo della mie risorse e usufruisco dei vantaggi della virtualizzazione.
Alcuni detrattori dei cloud privati non lo considerano un vero e proprio servizio di tipo cloud, perché gli manca la fondamentale e virtualmente illimitata flessibilità del cloud computing. Come sostiene James Urquhart i cloud privati potrebbero diventare una scusa per non migrare nel cloud “vero e proprio”.
Un esempio di cloud privato è eBay.
Una variante dei cloud privati è rappresentata dai cloud privati virtuali (virtual private cloud), che sono caratterizzati da un insieme di risorse isolate e sicure, create come un overlay sopra l’infrastruttura del cloud pubblico, utilizzando avanzate tecniche di networking per risorse virtuali. Alcuni dei rivenditori pubblici che offrono questa variante sono Amazon Virtual Private Cloud, OpSource Cloud e Skytap Virtual Lab.
Introduzione al Cloud Computing
21 1.8.3 Cloud ibridi
Sebbene i cloud pubblici consentano alle imprese di spostare parte della loro infrastruttura verso il cloud provider, allo stesso tempo certe imprese vorrebbe evitare di perdere il controllo su certe risorse. I cloud ibridi rappresentano una soluzione intermedia rispetto ai cloud pubblici e privati. Sono sostanzialmente cloud privati che hanno un’estensione su cloud pubblici, per il mantenimento di dati e risorse che non richiedono un elevato livello di controllo.
1.9 I Ruoli in un ambiente Cloud
I ruoli in un ambiente cloud possono essere definiti in maniera simile alla tipica distribuzione dei ruoli in una SOA . E così distinguiamo:
Cloud Provider: è colui che possiede l’infrastruttura fisica e offre l’ambiente cloud (pubblico) al consumatore, sia mediante APIs dedicate (PaaS), sia mediante la fornitura di macchine virtuali o un accesso diretto alle risorse (IaaS). Generalmente ai fornitori di servizi avanzati (SaaS) ci si riferisce con il termine Service Provider, sebbene ciò può creare una certa ambiguità di interpretazione tra Service Provider e Cloud Provider.
Rivenditori o Aggregatori Cloud: aggregano piattaforme cloud di diversi fornitori per offrire un substrato di risorse più ampio agli utenti o per abilitare servizi più avanzati.
Cloud Adopters o Softwrae/Service Vendors: migliorano la distribuzione dei propri servizi, utilizzando una piattaforma cloud messa a disposizione dal cloud provider o da un cloud aggregator. Questo consente di offrire un servizio che scala dinamicamente in base alle domande: ad esempio una nuova azienda che si tuffa nel business non ha bisogno di dimensionare a
22
priori le risorse, utilizzerà il servizio offerto dall’adopters, e al resto ci penserà il cloud! Il coud, per gli end users, diventa un SaaS.
Utenti o Clienti Cloud: sono coloro che utilizzano direttamente le capacità del cloud, per eseguire calcoli complessi o per conservare in maniera remotizzata e condivisa i dati.
Si pensi ad esempio ad un’azienda che remotizza la proprio infrastruttura per ridurre i costi e gli sforzi di gestione.
Tool Provider per il Cloud: non utilizzano direttamente una piattaforma cloud, ma forniscono gli strumenti per la gestione di un ambiente cloud (VMWare ad esempio).
Introduzione al Cloud Computing
24
CAPITOLO 2 – INFRASTRUCTURE AS A SERVUCE (IaaS)
Il lavoro di questa tesi, è incentrato principalmente sullo studio dell’ IaaS, per cui è opportuno investigare con maggior dettaglio il “servizio di infrastruttura”.
Amazon, con il suo Elastic Computing Cloud (EC2), è senza dubbio il leader di questo servizio e offre uno spunto interessante per capire realmente di cosa stiamo parlando.
Un IaaS deve offrire risorse di calcolo, di storage e di networking, pronte ad essere assemblate in maniera altamente personalizzabile. Questo scenario è equivalente a quello di un hosting provider, che fornisce i server fisici su cui poter installare sistema operativo, servizi web e via dicendo.
Amazon affitta dei server virtuali con diverse specifiche hardware, equipaggiati con diversi sistemi operativi o applicazioni, per cui bisogna solo scegliere ciò di cui si ha bisogno.
Ovviamente è possibile anche partire dall’hardware “spoglio”, e personalizzarlo da soli.
Il modello IaaS offre il maggior grado di controllo rispetto a PaaS e SaaS. Bisogna pertanto conoscere bene le risorse di cui avremo bisogno, poiché scalabilità ed elasticità saranno un problema dell’utilizzatore e non del cloud provider!
Amazon, come già detto, utilizza una soluzione completamente virtualizzata per il suo servizio, per cui quella che ci viene affidata è proprio l’istanza di una macchina virtuale, da gestire attraverso una web interface.
Per usare Amazon basta semplicemente:
- selezionare e sviluppare un template o un’immagine
_____________________________________________
Infrastructure as a Service
25 una Amazon Machine Image (AMI) che contenga l’hardware (spesso si parla anche di HaaS), le applicazioni, le librerie e i dati desiderati.
- configurare un accesso di rete sicuro verso la proprio istanza - scegliere quale e quanti tipi di istanza della prorpia AMI si vuole
avviare e con che sistema operativo.
- monitorare tutto mediante una semplice interfccia web, o da una grande varietà tool di management.
- pagare solo per le risorse effettivamente consumate
Amazon ci consente di aumentare o diminuire le capacità di calcolo nel giro di pochi minuti, non ore o giorni. È possibile commissionare una, cento o mille istanze simultaneamente e se ne ha il completo controllo. È possibile eseguire l’accesso come root su ciascuna istanza ed avviarle o stopparle da remoto utilizzando delle web service APIs.
Amazon EC2 lavora insieme ad Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDB), Amazon SimpleDB e Amazon Simple Queue Service (Amazon SQS) che insieme formano i cosiddetti Amazon Web Service e rappresentano una soluzione completa per il provisioning di calcolo, strutture dati, storage e tecniche di accodamento delle richieste.
Amazon EC2 offre una struttura altamente affidabile e tenta di assicurare un uptime del servizio annuale almeno pari al 99.95% del SLA.
Ovviamente tutto ciò non è una semplice pubblicità ad Amazon ed al suo EC2, ma un viatico per capire quali devono essere le caratteristiche di un buon provider IaaS.
26
2.1 Caratteristiche di un IaaS Provider
Le offerte di un IaaS si possono distinguere in base alla disponibilità di feature particolari che influenzano il rapporto costo/benefici che può o non può spingere un utente a muoversi nel cloud. I principali aspetti che vanno considerati sono la distribuzione geografica di un data center, la varietà di interfacce utente ed API per poter accedere al sistema, la presenza di componenti e servizi aggiuntivi che abilitano particolari applicazioni (ad esempio load balancing e firewall), la piattaforma di virtualizzazione utilizzata e il metodo di billing.
2.1.1 Distribuzione Geografica
Per migliorare la disponibilità e la reattività, un provider di servizi globali tipicamente costruisce data center distribuiti in tutto il mondo.
Amazon, ad esmpio, distingue i concetti di availability zones e regions per il servizio EC2. Le avialability zones sono “luoghi distinti che sono ingegnerizzati per essere isolati dai guasti di altre availability zones. Lanciando diverse istanze in zone differenti è possibile proteggere le nostre applicazioni dai problemi che si hanno quando si usa una singola locazione. Le regions consistono di una o più availability zones disperse su diverse aeree geografiche. Amazon EC2 è allo stato attuale, disponibile in sette regioni distinte: US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), South America (Sao Paulo).
_____________________________________________
Infrastructure as a Service
27 2.1.2 Interfacce Utente e Accesso ai Server
Generalmente un IaaS propone più modalità di accesso al suo cloud, in modo da accogliere le diverse esigenze o preferenze dei consumatori. Differenti interfacce utente (User Interface - UI) forniscono diversi livelli di astrazione. Le più comuni sono la graphical user interface (GUI), la command-line interface (CLI) e le API Web service (WS).
Le GUI sono preferite da quegli utenti che hanno bisogno di lanciare, personalizzare e monitorare pochi server virtuali e non hanno bisogno di ripetere il processo troppe volte. D’altra parte la CLI offre più flessibilità e la possibilità di automatizzare compiti ripetitivi mediante degli script (ad esempio accendere e spengere un certo numero di VM ad intervalli regolari). Le API WS offrono un accesso mediante richieste http e consentono di costruire complessi servizi sopra un IaaS.
Il modo principale di accesso al cloud di Amazon è mediante API WS. Amazon fornisce diversi tools interattivi in cima alle sue API WS, che includono:
- Amazon Web Service Console (http://console.aws.amazon.com)
- ElasticFox Firefox Plug-in
- Amazon Command Line tools
2.1.3 Prenotazione di risorse
La prenotazione delle risorse in anticipo consente ad un utente di richiedere ad un IaaS provider che certe risorse siano disponibili in un determinato istante.
Molti provider supportano solo richieste di tipo best-effort.
Amazon Reserved Instances è una feature che consente la prenotazione anticipata di certe risorse e presuppone che gli utenti paghino in anticipo
28
una certa quota, che gli consente di avere disponibili le capacità necessarie durante un periodo di tempo opportunamente concordato. In ogni caso, solo lunghi periodi di tempo sono offerti, da uno a tre anni.
2.1.4 Scaling Automatico e Laod Balncing
Come detto precedentemente, l'elasticità è una delle caratteristche fondamentali del cloud computing. Le applicazioni spesso hanno bisogno di eseguire uno scale-up o uno scale-down, per seguire le variazioni del carico di lavoro.
Lo scaling automatico è una feature altamente consigliata in un ambiente IaaS.
Si basa generalmente su delle metriche specifiche, come il numero di transazioni al secondo, la latenze della richieste, o il numero di utenti connessi a una certa applicazione. In Amazon, ad esempio, è Amazon CloudWatch il servizio preposto alla raccolta di queste metriche.
Quando il numero dei server virtuali aumenta, il traffico entrante deve essere automaticamente ridistribuito su tutti i server disponibili. Questa operazione abilita le applicazioni a rispondere prontamente alle richieste che le arrivano.
2.1.5 Service-Level Agreement
I service-level agreement sono offerti dagli IaaS provider per esprimere il loro impegno a fornire una certa QoS. Per i consumatori rappresentano una garanzia. Un SLA solitamente include disponibilità e garanzie sulle prestazioni.
Inoltre deve essere pattuito anche cosa fare nel caso in cui questi accordi non vengano rispettati.
_____________________________________________
Infrastructure as a Service
29 Ad esempio Amazon dice che "se la percentuale di uptime per un consumatore scende al di sotto del 99.95% del servizio annuale pattuito, allora quel consumatore riceverà un credito per il servizio pari al 10% del suo pagamento".
2.1.6 Storage dei dati
Un aspetto sempre molto sensibile quando si parla di IaaS, ma più in generale di cloud è lo storage. La presenza di più modalità con cui effettuare lo storage può essere essenziale per incontrare le diverse esigenze degli utenti.
Amazon fornisce tre diversi tipi di storage nella sua infrastruttura cloud: - Persistent cloud storage
- Ephemeral instance storage - Elastic block storage
Amazon S3 è il meccanismo con cui Amazon offre storage persistente. E' una soluzione cloud-based indipendente dagli altri servizi. Essa ti permette di buttare dati nel cloud e di recuperli nel momento in cui se ne ha bisogno, senza sapere come viene effettuato lo storage o dove vengano salvati i dati. Quando lanciamo una nuova istanza EC2, di default essa presenta uno storage di tipo ephemeral (passeggero) la cui durata di vita coincide con quella dell'istanza. In altre parole, se si perde o si termina l'istanza, verranno persi anche tutti i dati presenti nell'ephemeral storage.
L'Elastic Block Storage (EBS) è un dispositivo di storage di tipo network-based, simile ad una SAN in un'infrastruttura fisica.
E' possibile creare volumi da 1 GB fino a 1TB, e montare un qualunque numero di volumi ad un'istanza EC2. Non si può, però, condividere un volume tra due istanze EC2. (Figura Storage a confronto)
30
2.1.7 Importazione di VM
La possibilità di importare o spostare VM da un ambiente all'altro è un'altra opzione desiderabile per un utente che vuole utilizzare un IaaS.
In questo modo, è possibile continuare ad utlizzare le VM sviluppate in un altro ambiente senza soluzione di continuità.
Amazon utilizza la funzione di VM import per ottemperare questo servizio e così le VM dell'utente diventano delle istanze pronte all'uso.
2.1.8 Hypervisor
Tradizionalmente, i provider di servizi di infrastruttura utilizzano Xen come hypervisor, un software open-source, altamente personalizzabile che fa uso della paravirtualizzazione. Più recentemente stanno emergendo anche altre piattaforme per la creazione e gestione di un IaaS, come VMWare vCloud Director e Citrix Cloud Center.
2.2 Cloud Infrastucture Management
Uno degli aspetti chiave con cui un IaaS provider deve misurarsi quando decide di costruire un’infrastruttura cloud è come effettuare il management delle risorse fisiche e virtuali in maniera compatta.
Il componente software che agisce da direttore d’orchestra è il virtual infrastructure manager (VIM).
Questo software assomiglia ad un sistema operativo, ma invece di avere a che fare con un singolo computer, aggrega le risorse di più host fisici, e le presenta in maniera compatta e trasparente all’amministratore di sistema.
_____________________________________________
Infrastructure as a Service
31 Spesso ci si riferisce ad esso come “cloud operating system” o “virtual infrastructure engine”.
Sotomayor, un illustre studioso dei sistem di cloud computing, ha proposto una differenziazione in due categorie dei tool generalmente offerti come VIM.
La prima categoria include quei tool software che, cito testualmente, “espongono un’interfaccia remota e sicura per creare, controllare e monitorare risorse virtualizzate” ma non sono specializzate nel management della VI.
La seconda tipologia fornisce invece feature avanzate per il load balancing o per il consolidamento dei carichi di lavoro, ma non espongo delle interfacce cloud-like.
Nonostante questa distinzione possa apparire un semplice vezzo formale, durante lo sviluppo ed il set up del nostro ambiente cloud, ci siamo effettivamente confrontati con due toolkit differenti per la gestione delle risorse, il vCenter Server e il vCloud Director (che esamineremo meglio in seguito).
Il primo è un potente tool di gestione delle risorse, e rientra decisamente nella seconda categoria: tra le varie features presenta un avanzato sistema di monitoring delle risorse che utilizza per ridistribuire i carichi di lavoro in maniera equa sui vari servizi, in maniera del tutto automatica, mediante il cosiddetto Distributed Resource Scheduler (DSR). In più per rifarci alla definizione di Sotomayor come interfaccia di management utilizza un’applicazione Windows-based, il vSphere client.
Il secondo toolkit che abbiamo utilizzato, introduce un nuovo livello di virtualizzazione (il senso sarà più chiaro in seguito), e, interagendo con il
32
vCenter in maniera trasparente, offre un interfaccia web per il management delle risorse user friendly.
In ogni caso, in questo capitolo, non faremo differenze tra le due categorie e parleremo in generale di VIM. Ogni VIM ha delle feature di base per il management del ciclo di vita delle VM, mentre la presenza di feature più avanzate dovrebbe privilegiare la scelta di un VIM anziché un altro quando si pensa di volerlo utilizzare per produzioni cloud in larga scala.
2.3 Caratteristiche di un VIM
Esploriamo adesso alcune caratteristiche desiderabili per un VIM, che, come vedremo in seguito, saranno presenti anche nel vCenter Server, il VIM che abbiamo utilizzato per il setup del nostro datacenter di laboratorio.
2.3.1 Supporto di virtualizzazione
La caratteristica di multi-tenancy di un cloud richiede che più utilizatori con disparati requisiti siano serviti da una singola infrastruttura hardware. Le risorse virtualizzate possono essere allocate e riallocate con una certa flessibilità. Pertanto la virtualizzazione hardware è la tecnologia ideale per creare una infrastruttura virtuale e creare delle partizioni del datacenter tra più tenuatari.
Questo implicitamente significa che la virtualizzazione hardware, non è un prerequisito essenziale per lo sviluppo di una nuvola, ma è senz’altro altamente consigliabile.
_____________________________________________
Infrastructure as a Service
33 2.3.2 Self Service, On-Demand Resource Provisioning
Accesso Self-Service alle risorse di un cloud è apparso senz’altro come uno degli aspetti più interessanti per l’utente. Questa feature consente di ottenere servizi direttamente dal cloud, eliminando superflue perdite di tempo o interazioni con amministratori di sistemi.
Pertanto, esporre un’interfaccia self-service, attraverso cui l’utente possa facilmente interagire con il sistema, è una cosa altamente desiderabile per un VIM.
2.3.3 Supporto di più hypervisor
Differenti modelli di virtualizzazione offrono differenti benefici e limitazioni. Così, alcuni VIM fornisco un livello di management uniforme, senza riguardi di quale tecnologia di virtualizzazione, alias l’hypervisor, venga utilizzato. Questa caratteristica è più visibile in VI manager open source, che spesso consentono l’aggiunta di driver per la gestione di hypervisor differenti.
2.3.4 Virtualizzazione dello Storage
Virtualizzare uno storage significa astrarre uno storage logico a partire da uno storage fisico. Riuscire a consolidare tutto lo storage disponibile consente di creare dischi virtuali indipendenti dal dispositvo fisico e dalla sua locazione. Comunemente i dispositivi di storage in un data center sono organizzati in Storage Area Network (SAN) fruibile dai server mediante protocolli come Fiber Channel, iSCSI e NFS; uno storage controller fornisce il livello di astrazione tra lo storage fisico e virtuale.
Tra i VIM, solo una ristretta area di prodotti commerciale, come VMWare e Citrix, supportano la virtualizzazione dello storage.
34
2.3.5 Interfacce verso le Cloud Pubbliche
I ricercatori hanno capito che mettere a disposizione delle interfacce per avere in prestito delle risorse da cloud pubbliche ed estendere così l’infrastruttura privata può essere vantaggioso. In quest’ottica le organizzazioni possono fare buon uso delle risorse a disposizione e, nel caso di picchi di domanda, il carico di lavoro extra può essere svolto su risorse affittate.
Un VI manager può essere utilizzato per dar vita a un cloud ibrido se offre un interfaccia per la gestione del ciclo di vita della risorse virtuali fornitegli da un cloud pubblico.
2.3.6 Virtual Networking
Le reti virtuali (VLAN) consentono di isolare il traffico scambiato da certe macchine virtuali che condividono uno switch di rete (reale o virtuale) con altre macchine virtuale.
In questo modo è possibile separare i domini di broadcast. Nel caso di switch virtuali questo determina un alleggerimento sul processing dell’host che gestisce i pacchetti della macchina virtuale in questione, poiché non deve replicarli per tutte le VM. Invece, per gli switch reali la presenza di pacchetti taggati con una certa VLAN consente di inoltrare i pacchetti solo sulle porte che appartengono a quella VLAN.
Il supporto per creare e configurare delle reti virtuali è presente nella maggior parte dei VIM. Inoltre, i toolkit che offrono delle interfacce verso i cloud pubblici spesso supportano anche sicure Virtual Private Network (VPN) per collegare VMs locali e remote.
_____________________________________________
Infrastructure as a Service
35 2.3.7 Allocazione dinamica delle risorse
La crescente attenzione verso i consumi energetici all’interno del data center ha incoraggiato la pratica di consolidare VM, complementari nelle esegenze, in un piccolo numero di server, mantenendo gli altri in stand-by. Tuttavia, improvvise variazione nel carico di lavoro richiedono di spostare in tempi brevi le VM su server scarichi in modo da poter garantire gli impegni stabiliti con i SLA.
È pertanto necessario che un buon VIM includa delle feature per l’allocazione dinamica delle risorse e che monitori sempre l’utilizzazione delle risorse da parte delle VM, sottraendo o allocando risorse al momento giusto.
2.3.8 Alta Affidabilità e Data Recovery
La feature di High Availability (HA) consente di minimizzare il downtime delle applicazioni e prevenire perdite nel business. Solo pochi VIM realizzano ciò fornendo un meccanismo di failover, che riconosce i guasti sia degli host fisici che dei server virtuali e fa ripartire le VMs su degli host funzionanti.
Per applicazioni particolari, potrebbe non essere sufficiente un meccanismo di failover che comporti il restart della VM su un altro server fisico. In questi casi la soluzione può essere quella di far girare su un altro server la stessa VM in sincrono, mantenendo pronta a rimpiazzare la VM primaria in caso di guasto.
Il back up dei dati in ambienti cloud deve tener conto della grande moli di dati da gestire. Frequenti backup di un grosso numero di VM, ciascuna eventualmente con più virtual disk, dovrebbe essere fatto in modo da inficiare il meno possibile le performance del sistema. In questo senso,
36
diversi VIM offrono un meccanismo di protezione dati che realizza un backup incrementale delle immagini delle VM. Il compito di effettuare questi backup è spesso demandato a server proxy, il che consente di ridurre l’overhead di rete e di processing.
37
CAPITOLO 3 – CONFIGURAZIONE DATACENTER
3.1 Software di Virtualizzazione
3.1.1 VMware vSphere
Per la creazione del nostro datacenter abbiamo scelto di utilizzare Vmware vSphere 5 come software di virtualizzazione.
Come indica la numerazione, questa è la quinta generazione di prodotti per virtualzzazione offerti da Vmware e porta in dote una notevole dose di novità.
Con Vmware vSphere 5 è possibile attuare una raffinata allocazione delle risorse (CPU, memoria, network e storage I/O) conformemente ai carichi di lavoro delle varie VM.
Gli amministratori dell'infrastruttura virtuale hanno a disposizione numerosi tool per la gestione distribuita delle risorse, per conferire alta affidabilità all'infrastruttura e per cooperare con le VM al fine di aumentarne le prestazioni.
Tra i vari prodotti che fanno parte del pacchetto vSphere meritano una menzione particolare Vmware ESXi e Vmware vCenter Server.
3.1.2 VMWare ESXi
Il cuore di vSphere 5 è l'hypervisor , che è il livello di virtualizzazione e che serve come fondamento per l'implementazione di tutti gli altri prodotti. In vSphere 5 l'hypervisor è ESXi 5.0.
Nelle precedenti versioni di vSphere l'hypervisor era disponibile in due differenti opzioni: ESX e ESXi. Entrambe le versioni utilizzano lo stesso kernel, supportano lo stesso set di features, sono entrambe consideratie
38
hypervisor di tipo 1 o bare-matel, ma hanno una fondamentale differenza architetturale.
In Vmware ESX, Vmware utilizza una Service Console di tipo Linux-derived per fornire un interfacciamento con il kernel. La Service Console Linux-based include alcuni servizi che si trovano generalmente nei vari sistemi operativi come il firewall, il protocollo SNMP e un servizio web. In Vmware ESXi 5 la Service Console è stata rimossa, riducendo a meno di 32 MB il footprint sulla memoria. Nonostante l'assenza della Service Console, ESXi è comunque in grado di supportare tutte le funzionalità di ESX e di proporne di nuove, grazie al fatto che il cuore della virtualizzazione non risiede nella Service Console, ma nel VMkernel. L'architettura ESXi è pertanto costituita dal VMkernel e dai processi che girano su di esso, tra cui ovviamente le VM.
Figura 3.1 Architettura ESXi 5.0
3.1.3 VMkernel
Il VMkernel è un sistema operativo di tipo POSIX-like, sviluppato da VMWare e fornisce funzionalità simili ad altri sistemi operativi tra cui la crezione e il controllo di processi, la gestione di un proprio file system.
____________________________________________
Configurazione Datacenter
39 Ovviamente ha delle peculiarità che consentono il supporto di più VM mediante un efficiente Resource Scheduler: è il VMkernel che gestisce l'hardware del server e che schedula l'accesso delle VM a queste risorse. Il VMkernel usa un semplice in-memory filesystem per mantenere i file di log e di configurazione di ESXi. Per mantenere l'analogia con le precedenti versioni, il file system è stato mantenuto uguale a quello utilizzato nella service console di ESX. Per esempio i file di configurazione in ESXi si trovano in /etc/vmware mentre quelli di log si trovano in /etc/log/vmware. Poichè questo tipo di in-memory file system non persiste quando spegniamo il sistema, i file di log non sopravvivono al riavvio:ESXi ha comunque la possibilita' di configurare un server syslog remoto per il salvataggio di tutte le informazione di log.
Il filesystem usato dal VMkernel è indipendente dal filesystem utilizzato per lo store delle macchine virtuali (VMFS). Proprio come con ESX è possibile creare un datastore VMFS su di un disco locale dell'host oppure su un dispositvo remoto di storage condiviso.
I principali processi che girano sul Vmkernel sono:
la Direct Console User Interface (DCUI) è un'interfaccia di tipo BIOS-like che consente un basso livello di configurazione e viene principalmente utilizzata per l'impostazione delle configurazioni iniziali e per semplici operazioni di troubleshooting. Uno degli utenti di sistema definito nel Vmkernel è dcui, che viene usato dalla DCUI per identificare se stesso quando parla con altre componenti dl sistema. Tra i vari compiti che si possono svolgere dalla DCUI abbiamo:
- il settaggio della password dell'utente root
- le configurazioni di networking, se non sono eseguite
40
- semplici test di rete (ping, risoluzione nomi con il DNS) - il riavvio degli host
- la visione di file di log
il Virtual Machine Monitor, è il processo che fornisce l'ambiente di esecuzione per le VM ed agisce insieme ad un altro processo noto come VMX. Ogni VM che gira sul Vmkernel ha un proprio processo VMM e VMX
Diversi Agents che consentono il management da applicazioni remote, ad esempio il processo vpxa utilizzato per connettersi al vCenter Server
3.2 Installazione di ESXi
Un ambiente ESXi può essere sviluppato sostanzialmente in tre modi diversi:
- utilizzando per ogni host l'immagine disco dell'hypervisor - utilizzando uno script d'installazione
- utilizzando un dispositivo in cui l'hypervisor è già stato installato (soluzione embedded)
In figura 5.2 viene proposto il contenuto dell'immagine di sistema. Sia che ESXi sia salvato su una flash memory che su un hard disk sono presenti gli stessi componenti:
- 4 MB per il bootloader, utilizzato all'avvio del sistema - 48 MB per il boot, che contiene i 32 MB del VMkernal - un'ulteriore partizione di 48 MB, inizialmente vuota - una partizione di 540 MB per lo storage di file ausiliari
- 110 MB, normalmente vuoti utilizzati per mantenere dati di diagnostica in caso di problemi
____________________________________________
Configurazione Datacenter
41 Il sistema ESXi utilizza i due banchi di memoria durante l'upgrade del sistema: la nuova versione viene caricata nella porzione inizialmente inattiva e, al riavvio, il sistema è configurato per eseguire il boot da quella porzione di memoria. Se dei problemi vengono riscontrati durante il boot, il sistema automaticamente esegue il boot dall'altro banco di memoria. Quando viene eseguito il boot per la prima volta, il VMkernel ispeziona l'hardware dell'host e seleziona i driver più appropriati. Inoltre, se i dischi locali sono vuoti, li formatta automaticamente e li predispone per lo storage delle VM. Durante il boot iniziale , il VMkernel crea i file di configurazione utilizzando dei valori default (ad esempio usa il DHCP per le configurazioni di rete).
Nella versione Embedded, la configurazione viene salvata in un'area della memoria accessibile in scrittura e lettura.
42
3.2.1 Installazione su pen-drive USB
Per la creazione del nostro datacenter abbiamo deciso di installare l'hypervisor su delle pen-drive USB.
La procedura di installazione non ha nulla di diverso rispetto all'installazione di un qualunque sistema operativo. Ciò di cui abbiamo bisogno è il CD-ROM di installazione di ESXi (oppure dell'immagine ISO del sistema operativo remotizzato e reso disponibile) e, come già detto, di una pen-drive USB . I passi da seguire sono quindi i seguenti:
- Impostiamo il nostro host in modo da eseguire il boot dal lettore ROM, dopo di che riavviamo il sistema con inserito il CD-ROM di installazione;
- accettiamo gli End User License Agreement (EULA) premendo F11.;
- il software di installazione ci proporrà una lista di dischi disponibile su cui porre l'hypervisor, tra cui la nostra pen-drive (nello specifico una SanDisk da 8 GB)
- configuriamo le impostazioni della tastiera
- inseriamo (e confermiamo) una password per l'utente root; - premiamo ancora F11 per procedere con l'installzione
- dopo il riavvio del server, ESXi è correttamente installato. Come già detto, il VMkernel è configurato per ottenere le informazionei di rete dal DHCP. Nel nostro caso non facciamo uso di un sever DHCP per cui abbiamo riconfigurato l'interfaccia di management dalla DCUI, nella sezione "Reconfiguring the Managemnet Network".
____________________________________________
Configurazione Datacenter
43 In particolare per ciascuno dei due host abbiamo scelto degli indirizzi IP statici appartenenti alla sottorete 131.114.52.0/22, quella dell'Università di Pisa.
Utilizzare una pen-drive comporta una seria di vantaggi, quali:
- gli host ESXi possono non disporre di dischi locali: per questi server un hypervisor come ESXi può essere caricato da una SAN (Storage Area Network) o da una pen-drive USB
- più spazio sul disco locale: installando e facendo girare il software ESXi su una penna USB possiamo avere il 100% dello spazio disponibile per lo storage di immagini ISO o, se non facciamo uso di uno storage condiviso, per lo storage di VM. E' anche vero, come detto poc'anzi, che lo spazio allocato per l'installazione di ESXi occupa meno di 1 GB, per cui in realtà il vantaggio da questo punto di vista è davvero irrisorio
- portabilità e flessibilità: è questo, invero, il grande vantaggio dell'utilizzo di memory stick USB. Possiamo immaginare, ad esempio, di poter sostituire una penna USB con una versione di ESXi con un'altra contenente una versione più aggiornata, senza intaccare i dati presenti nel disco locale.
3.2.2 Configurazioni di post-installazione – vSphere Client
Come è facile notare dall'esiguo numero di operazioni che è possibile effettuare dalla DCUI, ESXi è stato progettato per essere utilizzato insieme al vSphere Client.
Il vSphere Client è una applicazione Windows-only che consente di collegarci direttamente all'host ESXi o al vCenter Server. E' possibile installare vSphere Client utilizzando il media di installazione del vCenter
44
Server oppure, usando un web browser, connettendoci all'indirizzo IP di un host ESX/ESXi o del vCenter Server.
Per il nostro datacenter, non disponendo del media di installazione del vCenter Server, e non avendo ancora installato lo stesso (sviluppando la sua Virtual Appliance), ci siamo collegati ad un host ESXi, ed abbiamo scaricato i file di installazione cliccando sul link apposito.
Figura 3.3 Accesso Web all’interfaccia di management
3.2.3 Riconfigurare la rete di Management
Durante l'installazione di ESXi, l'installer crea un virtual switch, anche detto vSwitch, collegandolo ad una interfaccia di rete. La parte noiosa di questa configurazione è che, a seconda del nostro hardware, l'installer può scegliere una interfaccia di rete differente da quella che noi pensiamo di usare per il traffico di management. Consideriamo, ad esempio, lo scenario
____________________________________________
Configurazione Datacenter
45 dipinto nella figura 5.4. Se per qualunque ragione il vSwitch non viene collegato all'interfaccia giusta non saremo in grado di collegarci con l'host ESXi mediante il vSphere Client. Per risolvere questo possibile problema dobbiamo usare la DCUI e selezionare la NIC adeguata.
Figura 3.4 Errore di configurazione per la rete di Management
3.3 Installazione vCenter Server
All'aumentare della dimensione della nostra infrastruttura, l'abilità di monitorare tutto da una sola piattaforma diventa particolarmente importante. Il vCenter Server è un'applicazione Windows-Based che serve come tool per il management centralizzato degli host ESXi e delle loro VM. Il vCenter Server si comporta come un proxy che performa compiti sui singoli host che sono stati aggiunti come membri del datacenter.
46
Molte delle più avanzate feature che l'ambiente vSphere è in grado di offrire sono possibili solo in presenza del vCenter. Ad esempio, il vCenter Server è essenziale per il management delle risorse (attraverso l'implementazione del DSR, Distributed Scheduler Resource), per lo sviluppo e il management di VM, attraverso feature come vMotion e vSphere High Avaiabilty.
Tra le opportunità di implementazione del vCenter Server, per il nostro datacenter abbiamo scelto di sviluppare la sua Virtual Appliance, ovvero una VM Linux-Based contente una versione 5.0 del vCenter Server pronta all'uso.
In questo modo invece che creare una VM, installarci un sistema operativo e poi ancora il vCenter Server, non dobbiamo fare altro che sviluppare il template OVF.
I template OVF non sono altro che dei formati standardizzati per la distribuzione di "prepackeged VMs".
Per installare il vCenter Server si può procedere nella seguente maniera: - connettiamoci con il vSphere Client ad un host ESXi
- dal menu File selezioniamo Deploy OVF Template
- nella prima schermata del wizard per lo sviluppo del template, clicchiamo su Browse e selezioniamo il file .ovf del vCenter Server Virtual Appliance (che abbiamo precedentemente scaricato insieme ad i file .vmx e .vmdk)
- la schermata seguente mostra i dettagli della VM, in particolare abbiamo a che fare con una VM versione 7, con 2 vCPU, 8 GB di RAM, 90 GB di hard disk e sistema operativo Novell SUSE Linux Enterprise 11 (64-bit)
- forniamo un nome alla macchina virtuale e andiamo avanti - selezioniamo un Datastore di destinazione
