1 Alma Mater Studiorum Università di Bologna SCUOLA DI SCIENZE Corso di Laurea in Informatica Una rassegna dei sistemi operativi per il Cloud Computing Tesi di Laurea in Reti di Calcolatori Relatore: Chiar.mo Prof. Fabio Panzieri Presentata da: Orgest Shehaj Sessione III Anno Accademico 2012-2013
Before you throw caution to the winds consider the disadvantage of Cloud Computing! 2
3 A me stesso, per tutte le ore di studio, per le numerose rinunce, per le notti insonni.
Indice 1 Introduzione 8 2 Il Cloud Computing 10 2.1 Cenni Storici............................ 11 2.2 Modelli di Cloud Computing.................... 11 2.2.1 Infrastructure as a Service (IaaS).............. 12 2.2.2 Platform as a Service (PaaS)................ 13 2.2.3 Software as a Service (SaaS)................ 13 2.2.4 Network as a Service (NaaS)................ 14 2.2.5 Data as a Service (DaaS).................. 14 2.2.6 Hardware as a Service (HaaS)............... 14 2.3 Modelli di Distribuzione...................... 15 2.3.1 Public Cloud........................ 16 2.3.2 Private Cloud........................ 16 2.3.3 Hybrid Cloud........................ 16 2.3.4 Community Cloud..................... 17 2.4 Vantaggi.............................. 17 2.4.1 Vantaggi Economici.................... 17 2.4.2 Vantaggi Tecnici...................... 18 2.5 Svantaggi.............................. 18 2.5.1 Vendor Lock-in....................... 19 2.5.1.1 Il problema dell hold-up............. 19 2.5.2 Collocazione dei Dati.................... 20 2.5.3 Tenere sotto controllo i propri dati............. 20 2.5.4 Segregazione dei dati.................... 21 2.5.5 Compromissione dei server................. 21 2.5.6 Conformità alle normative................. 21 2.5.7 Recupero dei dati...................... 21 4
INDICE 5 2.5.8 Inattività.......................... 21 2.5.9 Costi............................ 22 2.5.10 Casi reali.......................... 22 3 Architettura del Cloud 24 3.1 Virtualizzazione........................... 25 3.1.1 Virtual Machine...................... 25 3.1.2 Hypervisor......................... 25 3.2 Architettura di rete......................... 26 3.3 Architettura di scalabilità...................... 26 3.4 Componenti dei Cloud OS..................... 27 3.4.1 Virtual Machine Manager................. 27 3.4.2 Network Manager..................... 28 3.4.3 Information Manager.................... 28 3.4.4 Image Manager....................... 28 3.4.5 Storage Manager...................... 29 3.4.6 Federation Manager.................... 29 3.4.7 Sheduler.......................... 30 3.4.8 Service Manager...................... 31 3.4.9 Interfacce.......................... 31 3.4.10 Autenticazione e autorizzazione.............. 32 3.5 Federazione............................. 32 3.5.1 Cloud bursting....................... 33 3.5.2 Cloud broker........................ 33 3.5.2.1 Interfaccia Utente................ 34 3.5.2.2 Core Services.................. 35 3.5.2.3 Interfaccia esecutiva............... 35 3.5.3 Aggregazione di Cloud:.................. 35 3.5.4 Architettura multi-livello:................. 36 4 Analisi di Cloud OS esistenti 37 4.1 OpenStack.............................. 37 4.1.1 Releases........................... 38 4.1.2 Compute (Nova)...................... 38 4.1.3 Networking......................... 38 4.1.4 Storage........................... 38 4.1.4.1 Swift....................... 39 4.1.5 Glance........................... 39
INDICE 6 4.1.6 Dashboard......................... 39 4.2 Eucalyptus.............................. 41 4.2.1 Node Controller (NC)................... 42 4.2.2 Cluster Controller (CC).................. 43 4.2.3 Storage Controller (Walrus)................ 43 4.2.4 Cloud Controller (CLC).................. 44 4.3 OpenNebula............................. 45 4.3.1 Le caratteristiche principali................. 46 4.3.2 Xen............................. 48 4.4 CloudStack............................. 50 4.4.1 Caratteristiche principali.................. 50 4.4.2 Architettura......................... 51 4.5 Unikernels.............................. 53 4.5.1 Configurazione e distribuzione............... 53 4.5.2 Compattezza e ottimizzazione............... 53 5 Conclusioni 55 6 Ringraziamenti 56
Elenco delle figure 2.1 Modelli di Cloud.......................... 12 2.2 Modelli di Cloud Computing.................... 15 3.1 Cloud Coordinator......................... 24 3.2 Architettura del servizio di Cloud Broker............. 34 4.1 OpenStack Cloud Operating System................ 40 4.2 Struttura di Eucalyptus....................... 41 4.3 OpenNebula............................. 46 4.4 Linguaggi di programmazione................... 52 7
Capitolo 1 Introduzione Ogni ambito della Società moderna sta mutando verso la sua forma digitale. Questo cambiamento riguarda tutti i campi della vita quotidiana: dalla salute ai trasporti, dall informazione alla cultura, dai beni di prima necessità ai passatempi, e l elenco potrebbe continuare. Dagli inizi degli anni Duemila, in particolare, si è assistito ad un progressivo passaggio della fruizione dei principali media verso Internet: telefonia, reti televisive, giornali sono ora disponibili sul Web. Internet, dunque, è diventata una presenza fissa nella vita di tutti i giorni e svolge sempre più un ruolo cruciale nella comunicazione tra gli esseri umani. Un ruolo fondamentale in tutto ciò spetta al Cloud Computing. Infatti, uno dei temi più discussi ed interessanti nel mondo dell informatica al giorno d oggi è sicuramente il Cloud Computing. Nuove organizzazioni che offrono servizi di questo tipo stanno nascendo ovunque e molte aziende oggi desiderano imparare ad utilizzarli, migrando i loro centri di dati e le loro applicazioni nel Cloud. Ciò sta avvenendo anche grazie alla spinta sempre più forte che stanno imprimendo le grandi compagnie nella comunità informatica: Google, Amazon, Microsoft, Apple e tante altre ancora parlano sempre più frequentemente di Cloud Computing e si stanno a loro volta ristrutturando profondamente per poter offrire servizi Cloud adeguandosi così a questo grande cambiamento che sta avvenendo nel settore dell informatica. Inoltre, parte fondamentale del Cloud Computing sono i sistemi operativi che gestiscono le risorse sottostanti. I Cloud OS ci permettono di gestire in modo sicuro, efficiente e scalabile l infrastruttura che sta alla base del Cloud, essi gestis- 8
CAPITOLO 1. INTRODUZIONE 9 cono sia l architettura fisica che quella virtualizzata e forniscono ai vari clienti tutte le risorse virtuali che questi chiedono. Ai giorni nostri esistono diversi Cloud OS, molti utenti, sviluppatori, o amministratori di sistemi devono decidere quale tra questi adottare, perciò è necessario confrontare diversi Cloud OS per vedere quale sia la scelta migliore da adottare. L obbiettivo che ci poniamo con questa tesi è quello di esplorare il mondo del Cloud Computing, cercando di capire le principali caratteristiche architetturali e vedere in seguito i componenti fondamentali che si occupano di trasformare una infrastruttura informatica in un infrastruttura cloud, ovvero i Cloud Operating System. In questa tesi verrà inizialmente introdotta la storia del Cloud, per poi introdurre i vari modelli del Cloud e i suoi modelli implementativi, andando a valutare i vantaggi e gli svantaggi che il Cloud porta con sé. Successivamente si presentano i componenti fondamentali dell architettura del Cloud Computing e si introduce il concetto di federazione. In ultima analisi si illustrano i Cloud Operating System più diffusi in dettaglio, per poi andare a decidere quale tra i Cloud OS visti è il migliore.
Capitolo 2 Il Cloud Computing Il Cloud Computing permette a chi ne usufruisce di rilasciare ed accedere a servizi e distribuire applicazioni tramite un infrastruttura messa a disposizione da un organizzazione che si occupa di mantenerla e gestirla. Tale organizzazione è detta Cloud provider. Ciò che rende interessante l utilizzo di tali tecnologie da parte dei clienti può essere riassunto nelle seguenti caratteristiche: I clienti non si devono occupare della gestione dell infrastruttura fisica, poiché è il compito del Cloud Provider, infatti le installazioni, le configurazioni e le manutenzioni sono completamente gestite dal fornitore stesso. La scalabilità automatica e dinamica permette alle applicazioni di espandersi o di ridursi a seconda del carico a cui sono sottoposte. Pagamento pay-per-use, che permette agli utenti di pagare solo le risorse che utilizzano. 10
CAPITOLO 2. IL CLOUD COMPUTING 11 2.1 Cenni Storici Il termine Cloud risale all inizio degli anni novanta, nel campo delle telecomunicazioni, per identificare la nuvola di circuiti elettrici che servono alla permutazione del traffico, audio o dati, in modo da dare all utente finale la necessità di conoscere solo i dispositivi terminali della comunicazione, i telefoni. La storia del Cloud Computing inizia verso gli anni novanta, con la creazione del Word Wide Web. Verso la fine degli anni novanta, per l inarrestabile crescita del numero di utenti di Internet iniziano a diffondersi i primi servizi on-demand sulla rete, dando vita così al Software as a Service (SaaS). Dal 2000 in poi i giganti del IT mondiale hanno iniziato a comprendere l importanza di questa tendenza. Microsoft ha spinto soprattutto nella direzione di potenziare i propri servizi web, IBM ha concentrato le proprie risorse nella stesura dell Autonomic Computing Manifesto, un testo che descrive le tecniche principali per l auto gestione dei sistemi IT in presenza di prodotti eterogenei fra loro e successivamente gli altri a catena si sono interessati allo sviluppo del cloud. Nel 2005 Amazon lancia Amazon Web Services (AWS), con l adeguamento dei propri datacenter a nuovi principi architetturali che, oltre a portare efficienza in termini di elaborazione e consumo energetico, permettono l accesso alle strutture da parte di utenti esterni, con lo scopo di utilizzare al massimo le prestazioni computazionali. Microsoft e Google iniziano a porre le basi per il successivo declino di Client come Outlook con lo sviluppo di Hotmail (Microsoft), e Eudora con l arrivo di Gmail (Google), i servizi di posta diventano sempre più Software-as-a-service. Dal 2008, l interesse per il Cloud Computing è in costante aumento. 2.2 Modelli di Cloud Computing In questa sezione vedremo come il mondo del Cloud computing si è evoluto nel tempo. I cloud provider tipicamente organizzano i servizi da loro forniti classificandoli in tre categorie principali:
CAPITOLO 2. IL CLOUD COMPUTING 12 Figura 2.1: Modelli di Cloud Infrastructure as a Service (Iaas), Platform as a Service (PaaS) e Software as a Service (SaaS). Queste tre classi di servizi spesso vengono strutturati secondo un architettura a livelli dove IaaS è il più fondamentale e i modelli più alti astragono dettagli dai modelli inferiori. I fornitori di Cloud Computing offrono i loro servizi in base ai diversi modelli fondamentali: 2.2.1 Infrastructure as a Service (IaaS) Questo tipo di cloud è quasi un sinonimo di Grid Computing, ma con una caratteristica imprescindibile: le risorse vengono utilizzate su richiesta o domanda al momento in cui una piattaforma ne ha bisogno, non vengono assegnate a prescindere dal loro utilizzo effettivo, infatti, l infrastructure as a Service dà la possibilità ai clienti di affittare capacità di CPU, network, storage e altre risorse che l utente gestisce in seguito.
CAPITOLO 2. IL CLOUD COMPUTING 13 IaaS è il modello di servizio basilare di un infrastruttura di Cloud Computing, esso si occupa di fornire server, memorie di massa ed infrastrutture di rete virtualizzando l hardware reale, secondo il paradigma IaaS una o più macchine fisiche forniscono risorse computazionali all infrastruttura del Cloud, formando un pool di macchine virtualizzate, il cliente ha il controllo sulle risorse create virtualmente ma non ha il controllo sull infrastruttura di base del cloud, quello spetta al provider. In genere il fornitore di Cloud, mette a disposizione le risorse utilizzando un middleware che si occuperà di gestirle e orchestrarle, mentre l utilizzatore tramite delle interfacce, usufruirà delle risorse di cui necessita, creando la propria infrastruttura. Per esempio: Google Compute Engine, BT, Telstra, T-Systems (ITaaS). 2.2.2 Platform as a Service (PaaS) Il modello di servizio Platform as a Service si posiziona ad un livello più alto di IaaS, sfruttando le astrazioni che quest ultimo modello mette a disposizione, e rende invisibile all utilizzatore tutto quello che si trova al livello più basso. Il servizio PaaS consiste nella virtualizzazione di una piattaforma completa nella quale l utente potrà realizzare ed eseguire le proprie applicazioni, usufruendo dei strumenti di sviluppo o dei servizi di storage offerti dal provider. Il vantaggio di questo servizio è la possibilità di semplificare il processo di sviluppo delle applicazioni, l utente infatti non deve preoccuparsi di richiedere risorse aggiuntive o meno, a seconda della popolarità dell applicazione. Sarà compito infatti dei servizi a livello più basso scalare l infrastruttura a seconda delle effettive risorse che necessita la piattaforma in esecuzione. Per esempio: Google App Engine, Amazon EC2, Force.com 2.2.3 Software as a Service (SaaS) SaaS è un metodo di distribuzione del software che fornisce l accesso al software e le sue funzioni in remoto come un servizio Web-based. Il modello Software as a Service astrae ulteriormente tutto quello che si trova sotto il livello dell applicazione: il fornitore del servizio offre un piccolo client che permette di accedere all applicazione, in genere accessibile da un web browser. L utilizzatore accederà all applicazione senza sapere che piattaforma, sistema operativo o librerie sono necessarie per l esecuzione del software, né dovrà tener conto delle risorse computazionali necessarie per far funzionare l applicazione, in
CAPITOLO 2. IL CLOUD COMPUTING 14 quanto spetterà ai livelli sottostanti gestire e allocare le piattaforme e le risorse necessarie alla sua corretta esecuzione. In questo modo, sarà così possibile accedere alla propria applicazione da qualunque client capace di comunicare con la piattaforma di Cloud Computing. Per esempio: Yahoo! email, Google Apps, SalesForce.com, Oracle on Demand 2.2.4 Network as a Service (NaaS) Servizi di Naas includono VPN flessibile ed estesa, e larghezza di banda su richiesta, include anche la fornitura di un servizio di rete virtuale da parte dei proprietari delle infrastrutture di rete a terzi. 2.2.5 Data as a Service (DaaS) DaaS è collegato al fatto che gli utenti possono accedere ai dati in remoto in molteplici formati e da diversi terminali, in seguito possono operare sui dati come se questi ultimi fossero sul loro hard disk. Un tipico esempio è Amazon simple storage service (Amazon S3) il quale mette a disposizione degli utenti una semplice interfaccia web, la quale può essere usata per memorizzare o ricevere ogni tipo di dati, in qualunque momento. 2.2.6 Hardware as a Service (HaaS) Il HaaS è un modello pay-as-you-go per accedere all hardware che i provider mettono a disposizione. Con questo servizio l utente invia i suoi dati e un programma per processare questi dati, al venditore del servizio, il quale elabora i dati con computer messi a disposizione per fare ciò e restituisce i dati processati all utente iniziale. Hardware as a Service è flessibile, scalabile è maneggevole per soddisfare i bisogni degli utenti. Un esempio è il progetto IBM blue cloud.
CAPITOLO 2. IL CLOUD COMPUTING 15 Figura 2.2: Modelli di Cloud Computing 2.3 Modelli di Distribuzione Vengono identificate quattro modelli di distribuzione del Cloud, tali categorie sono: Public Cloud Private Cloud Community Cloud
CAPITOLO 2. IL CLOUD COMPUTING 16 Hybrid Cloud 2.3.1 Public Cloud Si tratta del tipo più comune di Cloud dove il servizio è allestito e gestito totalmente dal fornitore di servizi di cloud computing. In una Public Cloud tipicamente un organizzazione si occupa di implementare, gestire e mantenere tutta l infrastruttura, dai componenti hardware, come server e dispositivi di rete, a quelli software, come load balancer, monitor e software per la virtualizzazione. Tale organizzazione poi, sulla base dei propri piani tariffari, tipicamente payper-use, affitta le proprie risorse ad altre organizzazioni o utenti. 2.3.2 Private Cloud Questo particolare tipo di Cloud viene utilizzato quando specifici requisiti legati alla privacy o restrizioni derivanti dall ambito legislativo rendono impossibile o sconsigliabile l uso di una Public Cloud. In questo caso l infrastruttura Cloud non viene condivisa, ma è realizzata all interno di un unica organizzazione. Il cloud provider, se presente, si occupa dell installazione e mantenimento del Cloud sui dispositivi appartenenti all organizzazione committente. I servizi offerti dal Cloud sono quindi accessibili solo da quest ultima, garantendo il massimo livello di sicurezza e privacy. 2.3.3 Hybrid Cloud Una forma combinata di public cloud e private cloud, in cui i dati critici risiedono nel cloud privato, all interno dell azienda, mentre il resto dei dati vengono memorizzati nel cloud pubblico. I cloud ibridi forniscono vantaggi sulla scalabilità, affidabilità, rapida implementazione e il risparmio di un public cloud unito alla sicurezza di un private cloud. Per utilizzare al meglio questo modello è necessaria un attenta analisi di quali servizi debbano appartenere al private e quali al modello pubblico.
CAPITOLO 2. IL CLOUD COMPUTING 17 2.3.4 Community Cloud In questa implementazione di Cloud Computing, un intera infrastruttura viene fornita ad una comunità formata da diverse organizzazioni che condividono obbiettivi o progetti, potendo utilizzare ognuno le risorse a disposizioni del cloud a seconda delle necessità. In questa implementazione la gestione dell infrastruttura può essere delegata ad una o più delle organizzazioni o un terzo che si fa carico della manutenzione. 2.4 Vantaggi Parliamo dei vantaggi e degli svantaggi che un utente finale (privato o azienda) potrebbe riscontrare abbracciando il paradigma cloud. 2.4.1 Vantaggi Economici 1 Abbassamento del TCO 1 : risparmio sull acquisto, installazione, manutenzione e dismissione di hardware e software. Non è necessario possedere computer di fascia alta per far girare le applicazioni cloud : si ritorna al concetto di thin client, dove il computer non è altro che un terminale evoluto dal quale poter accedere ai servizi cloud online (i programmi girano nell infrastruttura cloud ed anche i dati sono archiviati online). Lato software, invece di acquistare costose licenze lifetime con eventuali costi di supporto/aggiornamento annuali, si pagherà in base al reale utilizzo delle risorse (con aggiornamenti e supporto sempre disponibili). Più Flessibilità: Nel caso in cui servano maggiori o minori risorse è possibile effettuare un adeguamento contrattuale, cosa impossibile o limitata in caso di infrastruttura di proprietà. Niente personale specializzato: Non è necessario assumere personale specializzato che si occupi della gestione dell infrastruttura, poiché è il provider stesso che si occupa di tutto ciò. Accelerazione del Time-to-market. Total Cost of Ownership
CAPITOLO 2. IL CLOUD COMPUTING 18 2.4.2 Vantaggi Tecnici Maggiore scalabilità: nel caso in cui servano maggiori risorse (per picchi o quant altro) il sistema di gestione e monitoring del cloud ha la possibilità di allocare le risorse necessarie a fronte delle nuove richieste. Dati ed applicazioni accessibili in mobilità: tutti i documenti sono sempre consultabili online, basta avere una connessione ad internet per poter continuare a lavorare, come se si stesse seduti alla scrivania del proprio ufficio, all ultima versione dei propri documenti (document versioning). Maggiore sicurezza: tutti i dati sono centralizzati e sottostanno alle policy di sicurezza centralizzate, pertanto si annulla la possibilità di una fuga di dati dovuta alla sottrazione fisica di materiale informatico nell azienda. Possibilità di beneficiare di piani di disaster recovery: se l azienda, scelta per la fornitura dei servizi cloud, lo prevede, è possibile mettersi al sicuro da eventuali problemi che potrebbero presentarsi nel data center. Indipendenza dalle periferiche: essendo programmi e documenti online, non si è legati all utilizzo di determinato hardware o determinate configurazione di rete. E possibile utilizzare smartphone, netbook, portatili o pc desktop, per leggere e/o modificare i propri documenti, senza preoccuparsi del formato in cui essi sono stati salvati. 2.5 Svantaggi Il Cloud Computing introduce alcuni problemi fondamentali nella sicurezza dei dati e della loro gestione. Ci sono molti svantaggi che riguardano soprattutto i potenziali rischi che provengono, da una parte dalla completa dipendenza da Internet, dall altra dalla sicurezza informatica e violazione della privacy a cui sono soggetti i dati memorizzati. Le tecnologie ed il relativo business model dietro ai servizi cloud non hanno ancora raggiunto la maturità, infatti i reparti di ricerca e sviluppo dei provider stanno ancora lavorando attivamente per dare ai clienti il livello di servizio e la qualità richiesta dai processi aziendali più critici. I servizi cloud, inoltre, poggiano su una infrastruttura hardware estremamente complessa: più un sistema è complesso, più diventa difficile comprenderne e gestirne i rischi nelle fasi di implementazione e di dispiegamento.
CAPITOLO 2. IL CLOUD COMPUTING 19 Ma l aspetto che suscita le maggiori perplessità è quello che afferisce alla riservatezza ed alla legalità, sopratutto in quelle circostanze in cui, oltre ai dati personali devono essere trattati dati sensibili. 2.5.1 Vendor Lock-in Il cloud è visto da molti come alternativa più accessibile in termini di costi rispetto ai tradizionali sistemi IT implementati in proprio. Tuttavia, ci sono molti aspetti negativi del Cloud Computing. Infatti molti potenziali clienti esitano a condividere i loro dati con i gestori del Cloud, tutto ciò perché i clienti hanno paura di perdere il controllo e la proprietà dei propri dati. Nei giorni nostri vediamo che il numero dei fornitori di Cloud Computing cresce sempre di più, in particolare i fornitori di Cloud Storage e di Servizi di Calcolo. Queste offerte legano gli utenti ad una particolare tecnologia, che non può essere né cambiata né sostituita senza costi aggiuntivi significativi. Questo è il caso per offerte PaaS, ad esempio Google App Engine, che sono strettamente legate con i servizi proprietari di Google, come gli account utenti Google e i servizi di posta elettronica. Tutto ciò porta con se il fatto che gli utenti che decidono di utilizzare questa tecnologia affidandosi al fornitore del servizio, in seguito sono legati e dipendono particolarmente dalle strategie di business e dalla serietà che il fornitore adotta. 2.5.1.1 Il problema dell hold-up Con il termine hold-up in economia ci si riferisce ad una situazione nella quale due parti stanno per effettuare una transazione che richiede investimenti specifici da una parte o dall altra. Il problema dell hold-up si verifica nel momento in cui una delle due parti rischia di perdere l investimento effettuato per quella specifica transazione per colpa di un comportamento opportunistico dell altra parte in seguito alla transazione. Vediamolo in uno scenario concreto: Se una società decide di investire in sviluppatori e applicazioni, i quali utilizzano Amazon Web Services. Questo particolare investimento potrebbe rivelarsi inutile se non può essere utilizzato da entrambi le parti, per esempio potrebbe essere impossibile utilizzare la stessa applicazione con Google App Engine.
CAPITOLO 2. IL CLOUD COMPUTING 20 Il problema è che non è possibile scrivere contratti completi, contratti che prevedono ogni caso possibile o sviluppo futuro, che potrebbe influenzare il business delle aziende stesse. Grazie ai contratti incompleti è possibile che si presentino situazioni che non siano state previste alla stesura del contratto, rendendo necessario la rinegoziazione del contratto. In questo caso una delle due parti potrebbe approfittarne ed adottare la situazione del Lock-in. 2.5.2 Collocazione dei Dati In generale, gli utenti del cloud non sono a conoscenza della posizione esatta del datacenter e non hanno alcun controllo sui meccanismi di accesso fisico a tali dati. I fornitori di servizi di cloud hanno datacenter in tutto il mondo. Tuttavia, in alcuni casi le applicazioni e i dati possono essere memorizzati in paesi che hanno una giurisdizione differente da quella dove si trova l utente finale. Ad esempio, se i dati utente vengono memorizzati in un certo paese allora i fornitori dei servizi saranno sottoposti ai requisiti di sicurezza e agli obblighi legali di quel paese. Essendo la collocazione fisica dell hardware e del software sconosciuta, se le Server Farms, dove sono memorizzati i dati personali e sensibili, appartengono ad aziende di residenza diversa da quella dell utente, in caso di violazione qualsiasi o fallimento, si potranno incontrare serie e fondate difficoltà a procedere legalmente. 2.5.3 Tenere sotto controllo i propri dati Indagare su un attività illegittima sui propri dati può essere impossibile negli ambienti cloud. I servizi cloud sono particolarmente difficili da tenere sotto controllo, perché i dati per più clienti possono essere co-localizzati e possono essere distribuiti su più datacenter. Gli utenti hanno poca conoscenza sulla topologia di rete del ambiente sottostante. E il provider del servizio può anche imporre restrizioni alla sicurezza di rete.
CAPITOLO 2. IL CLOUD COMPUTING 21 2.5.4 Segregazione dei dati I dati nel Cloud si trovano tipicamente in ambienti dove vengono condivisi con altri dati di altri clienti, quindi vengono crittografati per impedire a chi non ha l autorizzazione di accedere a questi dati. La crittografia non può essere assunta come soluzione per segregare i dati. In alcune situazioni, i clienti non desiderano crittografare i dati perché ci può essere il caso in cui la crittografia potrebbe distruggere i dati. 2.5.5 Compromissione dei server Gli utenti non hanno la possibilità di acquisire i propri dati fisicamente dal provider, nel caso in cui i server siano compromessi, il provider ha la necessità di chiudere l attività fino ad ottenere il backup precedente dei dati, in questo arco di tempo i clienti non possono accedere in alcun modo ai propri dati ma devono aspettare che il provider ritorni disponibile. 2.5.6 Conformità alle normative I fornitori di servizi sono sottoposti a certificazioni di sicurezza. Se un provider di servizi cloud non aderisce a questi controlli di sicurezza, il cliente può trovarsi in seri guai, fino a perdere i propri dati nel caso peggiore. 2.5.7 Recupero dei dati I fornitori di servizi cloud devono garantire la sicurezza dei dati in caso di catastrofi provocate dall uomo o dalla natura. In generale, i dati vengono replicati su più datacenter. Tuttavia, l erogatore del servizio deve essere in grado di poter fare un completo e rapido restauro dei dati. 2.5.8 Inattività Il Cloud Computing rende sia il singolo utente che l azienda dipendete dalla connessione a internet. Ma che succede se la connessione ad internet viene a mancare?
CAPITOLO 2. IL CLOUD COMPUTING 22 Quando i server sono offline anche i suoi utenti sono offline, in questo caso l utente non può accedere in alcun modo ai propri dati. Ed anche i fornitori di servizi di cloud più affidabili subiscono interruzioni del genere di tanto in tanto. 2.5.9 Costi Costi indiretti (ad esempio il rispetto delle regolamentazioni/leggi oppure la gestione dei backup e dei piani di disaster recovery). C è il rischio che i costi dell infrastruttura aumentino imprevedibilmente in futuro (questo è uno svantaggio nel momento in cui la migrazione verso un altro provider non è affatto trasparente). 2.5.10 Casi reali Ultimamente molti fornitori di Cloud Computing hanno subito delle interruzioni, ciò è servito da monito per dimostrare che ogni sistema è soggetto a interruzioni di servizio. Riportiamo in seguito alcuni esempi: Playstation Network Data di interruzione: 4/21/2011 Compagnia: Sony Lunghezza di interruzione: 25 giorni Utenti coinvolti: 75,000,000 Tra il 17 aprile e il 19 aprile, Sony Playstation e gli account Qriocity 2 sono stati compromessi da un accesso non autorizzato alla rete Playstation. Come risultato, Sony ha temporaneamente spento la rete Playstation e i Qriocity Services. Amazon Web Services Data di interruzione: 4/21/2011 Compagnia: Amazon.com Lunghezza di interruzione: 4 giorni Utenti coinvolti: Milioni 2 Servizio di musica online lanciato dalla Sony.
CAPITOLO 2. IL CLOUD COMPUTING 23 C erano due servizi coinvolti in questa interruzione, Amazon EC2 e Amazon RDS Service. La causa dell interruzione riguardava il mancato spazio di memorizzazione. Twitter Service Data di interruzione: 2/25/2011; 3/16/2011; 3/25/2011; 3/27/2011 Compagnia: Twitter Lunghezza di interruzione: da 1 a 4 ore Utenti coinvolti: Centinaia di migliaia Twitter stava facendo notevoli ritardi nella consegna dei messaggi. Il problema era un eccesso di capacità. Gmail and Google Apps Data di interruzione:2/27/2011 Compagnia: Google Lunghezza di interruzione: 2 giorni Utenti coinvolti: 120,000 Causato da alcuni utenti di Gmail e Google Apps che sperimentarono errori di accesso nelle caselle postali, tutto ciò è stato possibile grazie ad un bug introdotto dai sviluppatori in uno degli aggiornamenti precedenti fatti da Google. Netflix Streaming Service Data di interruzione: 3/22/2011 Compagnia: Netflix Lunghezza di interruzione: 4 a 8 ore Utenti coinvolti: 20,000,000 Netflix ha dichiarato che l interruzione era dovuta ad un problema tecnico raro, non rilasciando altri dettagli in merito. Intuit Service and Quickbooks Data di interruzione: 3/28/2011 Compagnia: Intuit Lunghezza di interruzione: 2 giorni - per alcuni utenti fino a 5 giorni Utenti coinvolti: Migliaia Il problema è stato causato da una modifica alla configurazione di rete.
Capitolo 3 Architettura del Cloud In questo capitolo vediamo gli aspetti più significativi e i componenti fondamentali che fanno parte dell architettura del Cloud. Figura 3.1: Cloud Coordinator 24
CAPITOLO 3. ARCHITETTURA DEL CLOUD 25 3.1 Virtualizzazione Le tecnologie di virtualizzazione permettono di astrarre dai componenti reali fornendone una rappresentazione virtuale, la quale interagisce con le risorse reali in maniera il più possibile trasparente per gli utilizzatori. Analogamente ad un sistema operativo, il quale fornisce un astrazione dei componenti fisici di un computer garantendo all utente un accesso di più alto livello, la virtualizzazione permette a chi ne usufruisce di utilizzare risorse tramite un interfaccia nota, senza sapere quali risorse reali siano presenti dietro lo strato di virtualizzazione. Possono essere virtualizzate sia risorse hardware, come CPU, memoria volatile, memoria di massa o interi computer, sia risorse software, come i sistemi operativi. Le piattaforme orientate alla virtualizzazione formano il nucleo di tutto il sistema Cloud. I componenti fondamentali su qui si basa la virtualizzazione sono due: Virtual Machine Hypervisor 3.1.1 Virtual Machine E la rappresentazione virtuale di un intero calcolatore, dotato di tutto l hardware necessario, e funziona da contenitore logico del sistema operativo ospite. La virtual machine può essere memorizzata come immagine del disco rigido del computer, più alcune metainformazioni, come le risorse possibili e le loro caratteristiche. E interessante notare per l ambito del Cloud Computing che una macchina virtuale può essere spostata da un server a un altro. Le macchine virtuali vengono solitamente definite tramite un insieme di parametri ed attributi, tra i quali, ad esempio, il kernel del sistema operativo da esse utilizzato, l immagine del loro disco rigido, la quantità di memoria volatile e la potenza di CPU assegnate. 3.1.2 Hypervisor Chiamato anche Virtual Machine Manager (VMM), è il componente che gestisce i sistemi operativi ospiti in esecuzione su un server fisico, e presenta loro un vista virtualizzata delle risorse hardware fisiche.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 26 Gli Hypervisor possono essere classificati in due categorie: nativi o ospiti. Gli Hypervisor nativi, chiamati anche bar-metal hypervisor, vengono eseguiti direttamente sul hardware fisico, con i privilegi massimi. Essi hanno quindi accesso e controllo diretto alle risorse fisiche della macchina sottostante. Un esempio di Hypervisor è il Xen Hypervisor, un progetto open source usato da molti Cloud provider. Gli Hypervisor ospiti invece vengono eseguiti su un sistema operativo, che è a sua volta in esecuzione sul hardware fisico. Risultano chiaramente meno performanti di quelli nativi, ragione per cui non vengono usati nell ambito Cloud, ed hanno, in generale, scopi diversi. La loro principale utilità è legata al fatto che permettono di utilizzare contemporaneamente sia il sistema operativo ospite che quello ospitante. Non vengono usati quindi per garantire isolamento, scalabilità e multi-utenza di sistemi, quanto piuttosto per fornire funzionalità tipiche di sistemi operativi diversi al sistema operativo ospitante e per avere un maggiore controllo del sistema operativo ospitato. Come esempio di Hypervisor ospite abbiamo Oracle VirtualBox. 3.2 Architettura di rete Una tipica architettura fisica di rete di un sistema Cloud si compone di un vasto numero di calcolatori, componenti di memorizzazione di massa e dispositivi di rete, collegati tra loro in maniera strutturata, formando dei cluster in modo da supportare architetture di rete virtualizzate in grado di adattarsi. 3.3 Architettura di scalabilità Per poter garantire la scalabilità del sistema, la sua architettura deve essere costruita in modo da poter utilizzare più calcolatori in grado di condividere il carico di lavoro. Queste architetture, organizzate su più livelli, sono tipicamente costituiti da vari elementi, tra i quali si trovano i Load Balancer, che hanno il compito di spartire equamente il carico di lavoro tra i server, una server farm funzionante come memcache, ovvero una memoria volatile distribuita, implementata solitamente
CAPITOLO 3. ARCHITETTURA DEL CLOUD 27 come una tabella hash distribuita, e dei server incaricati di gestire la memorizzazione persistente dei dati, appoggiandosi ai dispositivi fisici ma fornendo una rappresentazione ed un modello dei dati differenti da quelli concretamente utilizzati e nascondendo ai propri client i dettagli legati a questioni come la tolleranza ai guasti e la replicazione. I dati costituiscono proprio il punto critico di tali architetture, poiché spesso rappresentano il collo di bottiglia delle applicazioni. Per risolvere questo problema, è possibile attuare politiche di partizionamento, caching e replicazione, in modo da distribuire i dati su più server, ripartendo in tal modo anche il carico di lavoro. Tuttavia questo fa sorgere la necessità di ulteriore traffico e computazione per riuscire a gestire la consistenza dei dati, mantenendo sincronizzate le varie copie. Inoltre è opportuno, per poter ridurre la latenza dovuta al tempo di accesso ai dati, mantenere tali dati vicini agli utenti che li utilizzano, soprattutto se si hanno dati molto statici e cambiano raramente. 3.4 Componenti dei Cloud OS La complessa infrastruttura virtualizzata che sta alla base del Cloud deve essere gestita in modo da offrire servizi sicuri, efficienti e scalabili. Tale compito può essere molto complesso. E quindi necessaria la presenza di un componente che si prenda carico della gestione dell infrastruttura, governandone la virtualizzazione, l allocazione delle risorse degli utenti ed applicando le corrette politiche che gli permettano di raggiungere i requisiti fondamentali di un sistema Cloud. Tale componente è il Cloud Operating System, o Cloud OS, ed ha come obiettivo principale quello di fornire l infrastruttura come un servizio (IaaS ), sia per gli utenti del Cloud che per i livelli superiori, come PaaS e SaaS. I componenti principali dei Cloud OS sono: 3.4.1 Virtual Machine Manager La Virtual Machine Manager è responsabile dell intero ciclo di vita delle macchine virtuali e deve essere in grado di eseguire varie operazioni in base alle azioni degli utenti o alle loro politiche di scheduling. Tali operazioni comprendono l istanziazione, la migrazione, il sospendimento e la ripresa o lo spegnimento delle macchine virtuali.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 28 3.4.2 Network Manager Per poter sviluppare servizi ed applicazioni nel Cloud non c è bisogno solamente di macchine virtuali, ma occorre anche istanziare reti per interconnettere i vari componenti di un servizio, permettendo loro di comunicare, e per rendere il servizio accessibile anche da utenti esterni, se necessario. Il Network Manager deve quindi saper gestire reti private per le connessioni interne tra i componenti dei servizi ed indirizzi IP pubblici per i componenti di front-end accessibili tramite Internet. Poiché anche le reti fornite dal Network Manager sono virtuali, esso deve disporre di meccanismi e politiche che gli permettano di assegnare correttamente sia gli indirizzi MAC che quelli IP e deve anche riuscire a garantire l isolamento del traffico tra varie reti virtuali, anche se queste condividono la stessa infrastruttura di rete fisica. 3.4.3 Information Manager Responsabile del monitoraggio e della raccolta di informazioni riguardanti le macchine virtuali, i server fisici, ed altri componenti appartenenti sia alla struttura fisica che a quella virtuale. Il suo lavoro è essenziale per assicurarsi che tutti i componenti stiano funzionando correttamente e stiano fornendo buone prestazioni. Il controllo dei server fisici può essere effettuato installando determinati strumenti sui server stessi, che interagiscono con l Information Manager. Il controllo delle macchine virtuali invece può essere fatto sulla base delle informazioni fornite dall Hypervisor. L Information Manager può fornire vari sensori, ognuno dei quali è responsabile di fornire informazioni riguardo aspetti diversi del sistema, come ad esempio il carico di CPU, l uso della memoria volatile, il numero di processi in esecuzione, l uso della memoria persistente, il consumo di energia o di banda. Inoltre può permettere di creare sensori personalizzati in grado di monitorare metriche diverse. 3.4.4 Image Manager La gestione delle immagini delle macchine virtuali è molto importante.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 29 Tali sistemi infatti devono essere in grado di gestire una grande quantità di immagini, appartenenti a vari utenti, con sistemi operativi differenti e diverse configurazioni. Tale gestione deve essere sicura ed efficiente, inoltre i Cloud OS devono anche possedere degli strumenti per gestire i repository di immagini. Le immagini di macchine virtuali tipicamente vengono determinate da un insieme di attributi, come il nome, la descrizione del contenuto, il livello di condivisione (privata, pubblica o condivisa a pochi), il proprietario e la sua locazione all interno del repository. Le funzionalità di base per gestire le immagini includono la creazione di una nuova immagine in un certo repository, la sua cancellazione, la clonazione di un immagine esistente, l aggiunta o il cambiamento di determinati attributi, la condivisione di un immagine da parte di un utente con altri utenti o la sua pubblicazione per permetterne l utilizzo da parte di tutti gli utenti. 3.4.5 Storage Manager La funzione principale dello Storage Manager è quella di fornire servizi e sistemi di memorizzazione persistente virtuali, secondo le specifiche tipiche del Cloud. Ciò significa che il sistema di storage deve essere rapidamente scalabile e deve saper crescere automaticamente in base alla necessità degli utilizzatori, deve avere grande disponibilità ed affidabilità per evitare perdite di dati in caso di errori o crash, deve garantire ottime performance per supportare grossi carichi di lavoro, ad esempio nel caso di applicazioni orientate ai dati o che ne fanno un uso intensivo, e deve essere semplice da gestire, permettendo agli utenti di astrarre dalla complessità dell infrastruttura di storage sottostante, che si può comporre anche di dispositivi diversi e tra loro eterogenei. 3.4.6 Federation Manager Il Federation Manager è il componente che abilita l accesso alle infrastrutture Cloud remote, sia che si tratti di infrastrutture private sia che si tratti di Public Cloud accessibili tramite le loro interfacce. Tale componente deve fornire i meccanismi che permettano di distribuire le risorse presso Cloud remote, gestirle durante l esecuzione, ritirarle o terminarle quando necessario, monitorarle secondo i parametri desiderati, autenticare gli utenti che vi accedono e creare immagini di macchine virtuali, le quali probabilmente avranno formati diversi.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 30 In base alle capacità offerte dal Cloud remoto, che determinano il livello di interoperabilità raggiungibile nell interazione tra i due Cloud, può essere possibile fornire meccanismi anche più avanzati, come quelli per la migrazione di macchine virtuali attraverso le diverse infrastrutture, o quelli per la creazione di reti e sistemi di storage condivisi. 3.4.7 Sheduler In un infrastruttura Cloud esistono due livelli di scheduling: il primo, atto a stabilire, a livello fisico, quali macchine virtuali mandare in esecuzione e quali processori assegnare ad ogni macchina virtuale, viene gestito dallo scheduler dell Hypervisor, il secondo è di competenza dello scheduler del Cloud OS ed è responsabile di decidere su quali server fisici distribuire le macchine virtuali. Ciò viene fatto in base a vari criteri, ciascuno dei quali induce le proprie politiche di allocazione e migrazione delle macchine virtuali. I criteri sono: Riduzione del numero di server in uso, per minimizzare il dispendio energetico. Le nuove macchine virtuali dovrebbero essere allocate, quando possibile, presso server già attivi. Bilanciamento del carico di lavoro, per evitare la saturazione di alcuni server con conseguente crollo delle performance, in tal caso le macchine virtuali dovrebbero essere equamente distribuite in numero tra tutti i server disponibili. Bilanciamento dell uso della CPU, le macchine virtuali devono essere allocate presso i server con la più alta percentuale di CPU libera. Bilanciamento termico, per evitare il surriscaldamento dei server e ridurre la necessità di meccanismi di raffreddamento. Lo scheduler non è incaricato solamente di allocare i server fisici alle macchine virtuali nel momento della creazione o della loro accensione, ma deve costantemente monitorare la situazione per saper decidere quando è necessario migrare le macchine virtuali già in esecuzione.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 31 3.4.8 Service Manager Un Cloud OS deve essere in grado di gestire servizi virtualizzati, spesso costruiti su un architettura a più livelli e costituiti da più componenti legati tra loro da relazioni di dipendenza. I servizi vengono resi disponibili distribuendoli tipicamente su più macchine virtuali, le quali a loro volta ereditano o generano nuove relazioni di dipendenza, in base ai componenti o livelli che ospitano. Inoltre i servizi solitamente necessitano di appoggiarsi ad elementi di memorizzazione persistente e di comunicazione. Una delle funzionalità del Service Manager, la prima ad entrare in gioco a fronte della realizzazione di un nuovo servizio, è il controllo che viene effettuato sul servizio stesso per determinare se esso può essere accettato nel Cloud o se deve essere rifiutato, in base alle risorse che richiede, alle autorizzazioni di cui necessita ed alle disponibilità del Cloud. Una volta che un servizio è stato accettato, il Service Manager diventa responsabile del suo intero ciclo di vita, che include operazioni come il deployment, la sua sospensione o riattivazione e la sua cancellazione. Per poter effettuare il deployment del servizio il Service Manager deve interagire con lo scheduler in modo da poter determinare correttamente dove distribuire le macchine virtuali di cui tale servizio necessita. Un altra importante funzionalità del Service Manager è la gestione dell elasticità dei servizi. Il Service Manager per poter adempiere a questo compito incorpora solitamente vari meccanismi per innescare la scalabilità automatica dei servizi, i quali si basano su regole precise che determinano come scalare il servizio (verticalmente o orizzontalmente) e quando (in base al superamento di alcune soglie su determinate metriche imposte dall utente, o in maniera automatica). 3.4.9 Interfacce Le funzionalità del Cloud OS possono essere rese pubbliche ed esposte agli utenti tramite determinate interfacce. Queste interfacce costituiscono ciò che l utente del Cloud percepisce effettivamente come Infrastructure as a Service, poichè determinano l insieme dei servizi di cui egli può disporre per interagire con l infrastruttura. Solitamente ogni Cloud provider fornisce le proprie API con strumenti diversi.
CAPITOLO 3. ARCHITETTURA DEL CLOUD 32 La modalità più diretta, ma anche più complessa, per richiedere i servizi del Cloud è tramite le richieste del protocollo HTTP, il quale è diventato ormai lo standard per l interazione secondo l architettura SOA. Tuttavia, per semplificare lo sviluppo di applicazioni e per fare in modo che le richieste vengano rappresentate in una modalità più ricca di significato per i linguaggi di programmazione, spesso vengono anche fornite della librerie specifiche per ogni linguaggio. Per permettere l invocazione dei servizi direttamente dagli utenti, piuttosto che dalle applicazioni, vengono anche forniti dei tool, sia grafici sia da linea di comando. Il problema tuttavia è che, nonostante alcune di queste interfacce siano talmente diffuse e ben progettate che stanno ormai diventando quasi degli standard de facto, come le API di Amazon Web Services, che vengono infatti supportate nativamente dal Cloud OS Eucalyptus, il livello di eterogeneità è ancora molto alto e ciò rende molto complessa l interoperabilità e la portabilità attraverso Cloud diverse. 3.4.10 Autenticazione e autorizzazione Come per ogni ambiente condiviso, anche per il Cloud è importante possedere dei meccanismi in grado di riconoscere ed autenticare gli utenti e gli amministratori, per poter anche fornire loro accesso alle risorse per le quali dispongono delle autorizzazioni necessarie. I componenti che si occupano dell autenticazione in particolare hanno come obbiettivo proprio quello di verificare e confermare l identità dell utente che cerca di accedere alle risorse del Cloud. I metodi che possono essere utilizzati per implementare queste funzionalità sono svariati e vanno dalla semplice verifica di una password, a protocolli molto più complessi, che oggi si stanno largamente diffondendo a causa dell importanza sempre maggiore che sta acquisendo la sicurezza nell ambito del Cloud ed, in generale, nei sistemi altamente distribuiti ed aperti. 3.5 Federazione Ci sono varie architetture istanziate sopratutto per ottenere la federazione tra Cloud. Tali architetture non sono ancora degli standard uniformemente riconosciuti, e si possono dividere in quattro categorie principali:
CAPITOLO 3. ARCHITETTURA DEL CLOUD 33 3.5.1 Cloud bursting Viene istanziata quando c è la necessità di integrare ed espandere un infrastruttura esistente, tipicamente ma non necessariamente organizzata a sua volta come un Cloud, appoggiandosi ad un Cloud pubblico. Il livello di accoppiamento raggiunto in questo caso è debole, poiché il Cloud OS remoto interagisce con quello locale come se fosse un qualunque client. Quando si considera il CLoud Bursting, un organizzazione deve considerare soprattutto la sicurezza ed altre questioni legate alla possibilità di incompatibilità tra i diversi ambienti e la limitata disponibilità di strumenti di gestione. 3.5.2 Cloud broker In questo caso l architettura fa uso di un componente particolare che funge da mediatore, o broker appunto, il quale ha accesso a diversi Cloud pubblici. Nella sua implementazione più semplice, esso deve essere in grado di gestire le risorse degli utenti nei Cloud che essi desiderano. Broker più complessi sono anche in grado di applicare determinate politiche di scheduling, basate su criteri di ottimizzazione, ad esempio dei costi o delle prestazioni, decidendo su quali Cloud distribuire i servizi o eventualmente anche i singoli componenti. Oltre ad agire come intermediario per le trattative contrattuali, un broker potrebbe anche fornire al cliente servizi aggiuntivi, facilitando la duplicazione, la crittografia e il trasferimento dei dati del cliente al cloud e assistere con la gestione del ciclo di vita dei dati. L architettura del Cloud broker è mostrata in seguito:
CAPITOLO 3. ARCHITETTURA DEL CLOUD 34 Figura 3.2: Architettura del servizio di Cloud Broker 3.5.2.1 Interfaccia Utente L interfaccia fornisce il collegamento di accesso tra l interfaccia dell applicazione utente e il broker. L Application Interpreter traduce le esigenze di esecuzione di una applicazione utente che comprende ciò che deve essere eseguito, la descrizione degli ingressi delle attività, inclusi i file di dati remoti (se necessario), le informazioni sui processi attivi in uscita (se presenti), e la QoS 1 desiderata. Il Service Interpreter capisce le esigenze di servizio necessari per l esecuzione che comprendono la posizione del servizio, tipo di servizio, e dettagli specifici come i sistemi di invio di processi batch remoto per servizi computazionali. Il Credential Interpreter invece legge le credenziali per l accesso ai servizi necessari. 1 Qualità di servizio ( Quality of Service)
CAPITOLO 3. ARCHITETTURA DEL CLOUD 35 3.5.2.2 Core Services Consente le funzionalità principali del broker. Il Service Negotiator tratta per i servizi Cloud principali dalla Cloud Exchange. Lo scheduler determina i servizi Cloud più appropriati per l applicazione utente, basata sulle sue applicazioni e i requisiti di servizio. Il Service Monitor mantiene lo status dei servizi cloud controllando periodicamente la disponibilità dei servizi cloud noti e scopre nuovi servizi che sono disponibili. Se il Cloud locale non è in grado di soddisfare i requisiti delle applicazioni una ricerca che include i parametri QoS dell utente viene fatto al Cloud Exchange, che corrisponde alla ricerca delle possibili offerte disponibili. 3.5.2.3 Interfaccia esecutiva Fornisce il supporto di esecuzione per l applicazione utente. Il Job Dispatcher 2 crea l agente mediatore necessario e richiede file di dati (qualsiasi) per essere spediti con l applicazione utente alle risorse cloud remote per l esecuzione. Il Job Monitor rileva lo stato di esecuzione del lavoro in modo che i risultati del lavoro vengono restituiti all utente al termine del lavoro. Persistenza: Questo mantiene lo stato dell interfaccia utente, Core Services, e dell interfaccia esecutiva in un database. Inoltre facilita il recupero quando il broker fallisce e assiste a livello utente. 3.5.3 Aggregazione di Cloud: L aggregazione di Cloud viene realizzata a partire da due o più Cloud che interagiscono e uniscono in qualche modo alcune delle proprie risorse in modo da fornire agli utenti un infrastruttura virtuale più grande. L interoperabilità in questo caso è a medio livello, poiché le organizzazioni possono fornirsi vicendevolmente qualche forma di controllo avanzato, essendo in grado di distinguere le interazioni provenienti dal Cloud aggregato da quelle degli utenti comuni. 2 modulo del sistema operativo che passa effettivamente il controllo della CPU ai processi scelti dallo scheduler a breve termine
CAPITOLO 3. ARCHITETTURA DEL CLOUD 36 3.5.4 Architettura multi-livello: Questo tipo di architettura consiste in due o più Cloud, ciascuno dei quali possiede il proprio Cloud OS, che vengono a loro volta gestiti da un altro Cloud OS, posto gerarchicamente ad un livello superiore. Poiché solitamente questa architettura viene istanziata da Cloud provider che possiedono più infrastrutture separate, disposte geograficamente in regioni spesso molto distanti per garantire tolleranza ai guasti e riduzione delle latenze, il livello di interoperabilità raggiungibile è il massimo. Il Cloud OS a livello superiore ha un controllo completo delle risorse dei vari Cloud e ne fornisce un interfaccia agli utenti tale da far loro percepire la presenza di un unico Cloud sottostante.
Capitolo 4 Analisi di Cloud OS esistenti In questo capitolo vediamo alcuni dei Cloud OS più usati. 4.1 OpenStack Il progetto OpenStack mira a creare una piattaforma di cloud computing open source per cloud pubblici e privati. Questo progetto è stato cominciato nel 2010 da Rackspace Cloud e NASA che vi hanno fatto confluire alcuni altri loro progetti, tra cui Swift e Nova, i quali sono successivamente diventati parte di OpenStack. Dopo la prima release, un altro progetto ( di nome "Glance" ) è stato aggiunto per gestire la memorizzazione delle immagini. A oggi oltre 120 società si sono unite al progetto tra cui Citrix Systems, Dell, AMD, Intel, Canonical, SUSE Linux, HP, e Cisco. Inizialmente OpenStack era concentrato ad offrire Infrastructure as a Service (IaaS), il progetto infatti comprendeva tre componenti: OpenStack Compute: per utilizzare e gestire macchine virtuali (Nova). OpenStack Object Store: per l archiviazione ridondante di oggetti statici (Swift). OpenStack Image Service: fornisce servizi di interrogazione e di stoccaggio per le immagini dei dischi virtuali (Glance). Uno dei valori fondamentali alla base del progetto è la decisione del codice open source. OpenStack è stato rilasciato sotto la Licenza Apache 2.0. 37
CAPITOLO 4. ANALISI DI CLOUD OS ESISTENTI 38 4.1.1 Releases Il codice di OpenStack è stato pubblicato nel luglio del 2010, e la prima release (soprannominata "Austin") è stato rilasciato al pubblico nel novembre 2010. Dopo tre mesi, la seconda release (nome in codice "Bexar" ), ha debuttato nel febbraio 2011, seguito da "Cactus" nel mese di aprile 2011. I nomi delle release sono state decise attraverso una votazione popolare. 4.1.2 Compute (Nova) OpenStack permette ai provider di offrire risorse computazionali on-demand gestendo grandi reti di macchine virtuali. Tali risorse sono accessibili tramite delle API da parte della applicazioni e tramite un interfaccia Web da parte degli utenti ed amministratori. L architettura di computazione è progettata per scalare orizzontalmente con grande facilità, appoggiandosi ad hardware di qualità ordinaria, senza la necessità di utilizzare macchine molto costose. 4.1.3 Networking E un sistema altamente scalabile e controllabile tramite API per la gestione di reti ed indirizzi IP. Esso è progettato prestando particolare attenzione agli aspetti che permettono di fare in modo che le reti non diventino il collo di bottiglia o, in generale, una limitazione per l infrastruttura virtuale o le applicazioni. Permette sia l assegnazione di indirizzi IP statici che l adozione di protocolli di configurazione automatica, come il DHCP. 4.1.4 Storage I servizi di storage offerti da OpenStack si suddividono in due moduli. Il primo, Swift, fornisce una piattaforma di Storage a oggetti distribuita ed accessibile tramite API che può quindi essere perfettamente integrata nelle applicazioni oppure usata per altri scopi come il backup o l archiviazione di informazioni. Il secondo invece, chiamato Cinder, permette di gestire dispositivi di memorizzazione di massa virtualizzati connettendoli a specifiche macchine virtuali per aumentarne le capacità e le prestazioni.
CAPITOLO 4. ANALISI DI CLOUD OS ESISTENTI 39 Inoltre, quest ultimo modulo permette anche di gestire facilmente gli snapshot dei dispositivi, facendo in modo che essi possano essere ripristinati oppure replicati. 4.1.4.1 Swift Swift è il progetto più maturo al interno di OpenStack. Swift si occupa di fornire un archivio di oggetti altamente scalabile e ridondante concettualmente simile al Amazon S3. Per fornire questo scalabilità e ridondanza, manda più copie di ogni oggetto a più server di storage, memorizzandole in zone diverse. Le zone sono un raggruppamento logico che sono state isolate le une dalle altre per premunirsi contro gli eventuali guasti. 4.1.5 Glance Glance è tra gli ultimi servizi integrati in OpenStack. Debutta nella versione Bexar, Glance fornisce un servizio per l archiviazione e l interrogazione di immagini di dischi virtuali. Glance è stato progettato per essere un servizio autonomo per chi ha bisogno di organizzare grandi insiemi di immagini di dischi virtuali. Se usato insieme a Nova e Swift, fornisce una soluzione end-to-end per la gestione delle immagini del disco del cloud. 4.1.6 Dashboard Fornisce agli utenti ed agli amministratori un interfaccia grafica per accedere, fornire ed automatizzare le risorse. Essa è progettata in modo da essere estensibile, permettendo l installazione di software fornito da altri in modo da aumentarne le funzionalità, ad esempio tramite tool che permettano di gestire il monitoraggio o l allocazione dei costi. Essa è implementata come un applicazione Web ed è rivolta sia agli utenti, per la gestione delle proprie risorse, sia agli amministratori, ai quali fornisce una visione d insieme dell intero Cloud.
CAPITOLO 4. ANALISI DI CLOUD OS ESISTENTI 40 Figura 4.1: OpenStack Cloud Operating System
CAPITOLO 4. ANALISI DI CLOUD OS ESISTENTI 41 4.2 Eucalyptus Figura 4.2: Struttura di Eucalyptus Eucalyptus è un software open source che permette di realizzare Hybrid o Private Cloud. Esso fornisce dei servizi di tipo IaaS che vengono esposti come servizi Web. Le sue API sono sviluppate in modo da essere compatibili con quelle di Amazon Web Services, chiamato anche AWS, un Cloud provider che fornisce anch esso servizi di tipo IaaS, infatti, Eucalyptus e nato come risposta open source ad Amazon EC2. Eucalyptus implementa un Cloud OS che non contiene nessun hypervisor di default, tuttavia le ultime implementazioni usano Xen come hypervisor iniziale. Eucalyptus è stato progettato per gestire e controllare grandi collezioni di risorse distribuite.