UNIVERSITÀ DEGLI STUDI DI TORINO  FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI            CORSO DI LAUREA IN INFORMAT...
A Stefania,              Ai miei genitori,Ai miei nonni Argene e Franco.                             II
Indice   RINGRAZIAMENTI .....................................................................................................
3.3      IBM Service Delivery Manager (v7.2.1) ..............................................................................
RingraziamentiDesidero ringraziare1:         Federico Vietti, per essere stato un’ottima guida aka tutor aziendale, prima...
IntroduzioneIl presente lavoro nasce dalla mia collaborazione con Blue Reply2, nonché dalla partner-ship tra Blue Reply e ...
giunge ad una definizione comune. Si prosegue poi definendo le caratteristiche principalidel cloud computing: anche in que...
3
PARTE I - Teoria sul cloud computing                                   4
5
Capitolo 1. Il cloud computing1.1 DefinizioniDietro l’espressione “Cloud computing” vi è un modello computazionale che si ...
Riguardo al settore bancario, una volta, se non riuscivi ad arrivare in banca prima dell’oradi chiusura, non potevi dispor...
 grid computing: modello di calcolo distribuito, parallelo, in cui una serie di calco-           latori eterogenei condiv...
 la rete come mezzo di accesso alle risorse;        il carattere on-demand (i.e. “su richiesta”) dell’erogazione di riso...
 Ambiente multitenantOsserviamo che quattro su cinque di queste parole chiavi le abbiamo già incontrate nelledefinizioni ...
 Self-service on-demand: l’utente finale, in ogni momento, può autonomamente fa-           re richiesta di un servizio se...
 Automazione: è una caratteristica invisibile all’utente finale, che permette di na-         scondere la complessità che ...
ché, come è già stato detto, il cloud computing è una branca dell’informatica ancora inevoluzione. Qualunque classificazio...
Figura 1.3: Tipologie di Private Cloud1.3.1.2     Public cloudDiametralmente opposto al private, nel public linfrastruttur...
Questi tre, come potremo dedurre dalle relative definizioni del NIST, si differenziano so-stanzialmente per il livello di ...
In altre parole, SaaS è un modello di distribuzione centralizzata del software, in cui il ser-vizio cloud fornito consiste...
 Centralizzazione dell’amministrazione dell’applicazione e dei dati           Il cloud provider ha l’onere della gestione...
1.3.2.2     Platform as a Service, o “PaaS”Di seguito riportiamo la definizione di PaaS data dal NIST [1]:         The cap...
 Complessità di un’applicazione PaaS           A differenza di un’applicazione che deve essere eseguita in un ambiente lo...
Vantaggi e svantaggiSeguendo [6], analizziamo i pro e i contro dello IaaS.Tra i vantaggi possiamo citare:       la possib...
 Minori investimenti in hardware e software. Grazie al pay-per-use, il cloud       computing consente infatti di usufruir...
più ambienti cloud di provider differenti (interoperabilità). Ciò è causato dalla mancataadozione di standard aperti da pa...
Capitolo 2. Principali tecnologie cloud2.1     VirtualizzazioneIl primo passo verso l’adozione del cloud consiste nel virt...
visor o Virtual Machine Monitor (VMM). Il sistema operativo virtuale viene detto guestOS, mentre il sistema operativo che ...
preferibile quando è richiesto supporto per molti dispositivi di I/O, che un normale sistemaoperativo host è in grado di f...
gie, implementa in primo luogo la paravirtualizzazione; invece, per i sistemi operativi nonparavirtualizzabili (ad esempio...
2.1.3.3        VMware vSphere (v4.1)VMware20 è attualmente l’azienda leader di mercato nel settore della platform virtuali...
VMware ESX e ESXiESX e ESXi sono due hypervisor di tipo 1 che applicano la tecnica della full virtualization.Il componente...
pra. Non appena avverte un potenziale guasto del server fisico o un errore del si-         stema operativo guest, si occup...
2.2.1 Automazione del provisioningIn un datacenter, l’automazione è utile principalmente in due ambiti: per l’onboarding e...
In Figura 2.3 vengono illustrati i componenti principali di TPM, e il modo in cui interagi-scono con l’infrastruttura IT e...
Il data model è il componente che fornisce una rappresentazione di tutte le risorse fisichee logiche gestite da TPM, quali...
     È un ente a sé stante, indipendente         Può essere composto a sua volta da altri servizi         Per i suoi co...
2.3.2 SOA e il cloud computingNel cloud computing, intere infrastrutture IT virtuali, piattaforme e applicazioni sono im-p...
Capitolo 3. Stato dell’arte IBM “private IaaS”3.1        Offerta “private IaaS” IBMPoiché l’obiettivo perseguito in questo...
che una parte amministrativa, in cui gli utenti con ruolo “cloud administrator”, tra le altrecose, possono aggiungere o ri...
Figura 3.1: Architettura di TSAMCome si può osservare dalla Figura 3.1, in quanto applicazione di Service Management,TSAM ...
Figura 3.2: Come TSAM espone i servizi agli utenti finaliInfine, per soddisfare le richieste di servizi, TSAM sfrutta TPM ...
Figura 3.3: I punti di estensione di TSAM3.3       IBM Service Delivery Manager (v7.2.1)IBM Service Delivery Manager (ISDM...
La Figura 3.4 mostra le immagini virtuali che compongono ISDM, con i relativi softwarestack.                          Figu...
Figura 3.5: Le relazioni tra le varie immagini di ISDMIn Figura 3.5 vediamo le relazioni esistenti tra le VM che compongon...
Inoltre, in una configurazione che prevede l’High Availability, vi sono anche le seguentirelazioni:     7. L’agente di mon...
43
PARTE II – Pratica                     44
45
Capitolo 4. La nostra soluzione private IaaS4.1       AnalisiImmaginiamo di avere un cliente, che chiameremo C, che ci for...
c. System integrator per l’integrazione di WebSphere e Oracle;   5. I tecnici del reparto networking si occupano della val...
re sotto controllo l’ambiente, capire quali sono i livelli di utilizzo dell’infrastruttura, e pia-nificare la capacità (in...
o permettere l’allocazione di risorse;           o controllare lo stato dei progetti e monitorare i server di tutti gli ut...
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)
Upcoming SlideShare
Loading in...5
×

Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)

1,786

Published on

Tesi di laurea di I livello discussa all'Università degli Studi di Torino, Facoltà di Scienze MFN, Corso di Studi di Informatica. Questo lavoro nasce dalla mia collaborazione con Blue Reply, nonché dalla partnership tra Blue Reply e IBM.
Scopo della tesi è progettare una soluzione di private cloud di tipo Infrastructure as a Service usando un prodotto IBM, il Service Delivery Manager 7.2.1, a partire da una serie di requisiti.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,786
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
68
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laurea di Alberto Scotto)

  1. 1. UNIVERSITÀ DEGLI STUDI DI TORINO FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA Anno Accademico 2010/2011 RELAZIONE DI TIROCINIO CLOUD COMPUTING: UNA SOLUZIONE “PRIVATE” BASATA SU SOFTWARE IBMRelatore:PROF. FRANCESCO BERGADANO Candidato: ALBERTO SCOTTO
  2. 2. A Stefania, Ai miei genitori,Ai miei nonni Argene e Franco. II
  3. 3. Indice RINGRAZIAMENTI ..........................................................................................................................................V INTRODUZIONE .............................................................................................................................................. 1PARTE I - TEORIA SUL CLOUD COMPUTING......................................................................................... 4 CAPITOLO 1. IL CLOUD COMPUTING............................................................................................................ 6 1.1 Definizioni ...................................................................................................................................... 6 1.2 Caratteristiche principali ............................................................................................................. 10 1.3 Tassonomia, sugli assi cartesiani ................................................................................................. 12 1.3.1 Asse x: dove risiedono i dati (“cloud deployment models”) ............................................................... 13 1.3.1.1 Private cloud ............................................................................................................................ 13 1.3.1.2 Public cloud ............................................................................................................................. 14 1.3.1.3 Community cloud .................................................................................................................... 14 1.3.1.4 Hybrid cloud ............................................................................................................................ 14 1.3.2 Asse y: tipologie di servizi offerti (“service models”) ........................................................................ 14 1.3.2.1 Software as a Service, o “SaaS” ............................................................................................... 15 1.3.2.2 Platform as a Service, o “PaaS” ............................................................................................... 18 1.3.2.3 Infrastructure as a Service, o “IaaS” ........................................................................................ 19 1.3.2.4 Business Process as a Service, o “BPaaS” ............................................................................... 20 1.4 Vantaggi e svantaggi .................................................................................................................... 20 CAPITOLO 2. PRINCIPALI TECNOLOGIE CLOUD .......................................................................................... 23 2.1 Virtualizzazione ............................................................................................................................ 23 2.1.1 Tecniche di virtualizzazione ............................................................................................................... 23 2.1.1.1 Full virtualization ..................................................................................................................... 24 2.1.1.2 Paravirtualization ..................................................................................................................... 24 2.1.1.3 Hypervisor ............................................................................................................................... 24 2.1.2 Vantaggi e svantaggi .......................................................................................................................... 25 2.1.3 Stato dell’arte ..................................................................................................................................... 25 2.1.3.1 Xen........................................................................................................................................... 25 2.1.3.2 KVM ........................................................................................................................................ 26 2.1.3.3 VMware vSphere (v4.1)........................................................................................................... 27 2.2 Automazione ................................................................................................................................. 29 2.2.1 Automazione del provisioning............................................................................................................ 30 2.2.2 Stato dell’arte: IBM Tivoli Provisioning Manager (v7.2) .................................................................. 30 2.3 Service-Oriented Architecture (SOA) ........................................................................................... 32 2.3.1 Definizione ......................................................................................................................................... 32 2.3.2 SOA e il cloud computing .................................................................................................................. 34 CAPITOLO 3. STATO DELL’ARTE IBM “PRIVATE IAAS” ............................................................................ 35 3.1 Offerta “private IaaS” IBM ......................................................................................................... 35 3.2 IBM Tivoli Service Automation Manager (v7.2.1.1) .................................................................... 35 III
  4. 4. 3.3 IBM Service Delivery Manager (v7.2.1) ...................................................................................... 39 3.4 IBM Cloud Burst .......................................................................................................................... 42PARTE II – PRATICA .................................................................................................................................. 44 CAPITOLO 4. LA NOSTRA SOLUZIONE PRIVATE IAAS .................................................................................. 46 4.1 Analisi .......................................................................................................................................... 46 4.2 Progettazione ............................................................................................................................... 48 4.3 Implementazione........................................................................................................................... 50 4.3.1 Installazione di ISDM......................................................................................................................... 50 4.3.2 ConfigurazionI di base di ISDM......................................................................................................... 51 4.3.3 Personalizzazioni e configurazioni avanzate ...................................................................................... 53 CAPITOLO 5. AUTOMAZIONE: IL PROVISIONING DI MYSQL PER WINDOWS E RHEL ................................ 54 5.1 Nozioni di base ............................................................................................................................. 54 5.1.1 Sviluppo di provisioning workflow .................................................................................................... 54 5.1.2 Le definizioni software nel data model ............................................................................................... 57 5.2 Implementazione........................................................................................................................... 59 5.2.1 Simple software product ..................................................................................................................... 59 5.2.2 L’automation package “hosting-environment-core” ........................................................................... 60 5.2.3 Stack dei workflow per il provisioning di simple software products .................................................. 62 5.2.4 Il workflow Default_SoftwareInstallable_Install................................................................................ 64 5.2.5 Extension point LDO .......................................................................................................................... 65 5.2.6 Il nostro Default_SoftwareInstallable_InstallPre ................................................................................ 66 CAPITOLO 6. SELF SERVICE: IL PREVENTIVO ............................................................................................ 68 6.1 L’interfaccia web 2.0 di TSAM ..................................................................................................... 68 6.1.1 Una panoramica .................................................................................................................................. 68 6.1.2 L’implementazione ............................................................................................................................. 70 6.2 Dojo Toolkit.................................................................................................................................. 71 6.3 Il preventivo nel pannello CreateProjectWithServer.................................................................... 73 6.3.1 Il pannello per la creazione di un progetto.......................................................................................... 73 6.3.1.1 Il template ................................................................................................................................ 74 6.3.1.2 La classe Dojo CreateProjectWithServer ................................................................................. 76 6.3.2 Implementazione del preventivo......................................................................................................... 79 6.3.2.1 Personalizzazione del template di CreateProjectWithServer ................................................... 79 6.3.2.2 Personalizzazione della classe CreateProjectWithServer ......................................................... 80 6.4 Estensioni della Self Service Station in TSAM 7.2.2 .................................................................... 83 CAPITOLO 7. CONCLUSIONI ...................................................................................................................... 84 7.1 Ricapitoliamo ............................................................................................................................... 84 7.2 Possibili sviluppi .......................................................................................................................... 85 7.2.1 Preventivo: Disaccoppiare i prezzi delle licenze dei sistemi operativi ............................................... 85 7.2.2 Report di chargeback .......................................................................................................................... 86 BIBLIOGRAFIA ............................................................................................................................................. 87 IV
  5. 5. RingraziamentiDesidero ringraziare1:  Federico Vietti, per essere stato un’ottima guida aka tutor aziendale, prima; il mi- glior capo che si possa volere, poi. In particolare, per essere stato un buon cliente immaginario (vedi Capitolo 4);  Francesco Bergadano, per avermi aiutato in tutte le questioni legate alla tesi e allo stage, da quelle teoriche a quelle burocratiche;  Chiara Brändle e Giuseppe Clerici, di IBM, per il supporto tecnico;  Giovanna Petrone, per il supporto teorico;  Viviana Bono, per avermi aiutato, fin da ProgI, a interiorizzare i concetti fonda- mentali di una buona programmazione (OOP) tra cui il decoupling, che uso in que- sto stesso lavoro;  Paola Gatti e Simona Castello, per il supporto burocratico;  La mia famiglia, per il supporto vario ed eventuale, anche finanziario;  Gli amici dell’uni, in particolare Niccolò;  Dulcis in fundo, Stefania, la mia compagna nel viaggio che chiamano vita, per il continuo sostegno che è stato per me fondamentale per raggiungere questo traguar- do.Infine, un ringraziamento speciale va ai miei appunti.1 Troppo schematico? V
  6. 6. IntroduzioneIl presente lavoro nasce dalla mia collaborazione con Blue Reply2, nonché dalla partner-ship tra Blue Reply e IBM3.Scopo della tesi è progettare una soluzione di private cloud di tipo Infrastructure as a Ser-vice (vedi paragrafo 1.3) usando un prodotto IBM, il Service Delivery Manager 7.2.1, apartire da una serie di requisiti.Per raggiungere questo obiettivo, è stato necessario prima di tutto studiare i rudimenti teo-rici su cui si poggia il cloud computing. Dopodiché, lo studio è stato rivolto verso il Servi-ce Delivery Manager, che è servito come base per l’implementazione della soluzione. Infi-ne, si è passati all’implementazione. Quest’ultima ha comportato in primo luogo una più omeno semplice installazione e configurazione del prodotto IBM, in secondo luogo la scrit-tura di nuovo codice (funzioni Javascript/Dojo e provisioning workflow di Tivoli Provisio-ning Manager) per implementare le funzionalità custom.L’iter seguito durante il tirocinio si riflette in questo lavoro, che si suddivide in due parti: I. Una prima parte teorica in cui si analizzano le definizioni di cloud computing che sono state date da più parti, e si approfondiscono alcuni aspetti preponderanti; II. La seconda, più pratica, in cui viene sviluppata l’analisi, la progettazione e l’implementazione della soluzione cloud, obiettivo della tesiVediamo maggiormente nel dettaglio come si articola il lavoro.Nel Capitolo 1 vengono introdotti i principali concetti relativi al cloud computing. Si partedall’analizzare le definizioni più autorevoli che finora sono state date, ed integrandole si2 Blue Reply è una società di consulenza informatica specializzata nell’ambito della sicurezza. Il nome“Blue” deriva dalla speciale partnership che la lega ad IBM. Infatti, quest’ultima è anche conosciuta con ilsoprannome di “Big Blue”. Blue Reply fa parte del gruppo Reply, molto attivo sia in Italia che all’estero.3 IBM è un marchio registrato della International Business Machines Corporation (http://www.ibm.com). 1
  7. 7. giunge ad una definizione comune. Si prosegue poi definendo le caratteristiche principalidel cloud computing: anche in questo caso, analizzando prima alcune tra le teorizzazionipiù autorevoli, e poi giungendo ad una serie di caratteristiche condivise. Infine, si analizza-no i paradigmi cloud più importanti, quali private, public, hybrid, Infrastructure as a Servi-ce (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS).Nel Capitolo 2 si approfondiscono le tecnologie cosiddette abilitanti (non bellissima, mamolto usata traduzione dall’inglese di “enabling”) il cloud computing, ovvero quelle tecno-logie che lo supportano, che sono: la virtualizzazione, l’automazione e le architetture servi-ce-oriented (SOA).Nel Capitolo 3 si descrivono le principali soluzioni IBM in ambito private IaaS presentisul mercato. In particolare, vengono qui introdotti i prodotti che saranno usati nella secon-da parte per progettare e implementare la nostra soluzione di cloud computing: IBM TivoliService Automation Manager (TSAM) e IBM Service Delivery Manager (ISDM).Con il Capitolo 4 inizia la seconda parte, quella pratica. In questo capitolo viene introdottal’implementazione della soluzione oggetto della tesi, a partire dai requisiti. Sono quindi af-frontati l’analisi, la progettazione e l’iniziale implementazione (installazione e configura-zione di base di ISDM). Nei capitoli successivi si affrontano invece le personalizzazionipiù avanzate.Nel Capitolo 5 si implementano i requisiti relativi all’automazione del provisioning diMySQL Server e Client. Ciò implica lo studio di alcune nozioni di TPM che consentano disviluppare i provisioning workflow necessari a soddisfare i requisiti.Il Capitolo 6 è dedicato alla personalizzazione dell’interfaccia web 2.0 di TSAM, dallaquale vengono creati i server virtuali. Dopo uno studio approfondito dell’implementazionedell’interfaccia, limitatamente alla parte che permette la creazione di un nuovo progetto diserver virtuali, si discute come può essere implementata una tabella che mostri all’utenteun preventivo del progetto che va a creare.Nel Capitolo 7, infine, si tirano le somme e si presentano alcuni possibili punti di esten-sione della nostra soluzione. 2
  8. 8. 3
  9. 9. PARTE I - Teoria sul cloud computing 4
  10. 10. 5
  11. 11. Capitolo 1. Il cloud computing1.1 DefinizioniDietro l’espressione “Cloud computing” vi è un modello computazionale che si è evolutonei decenni a partire dagli anni ’60, quando John McCarthy affermò che “computing maysomeday be organized as a public utility just as the telephone system is a public utility.[…] The computer utility could become the basis of a new and important industry”4. Ma“Cloud computing” è un termine (la buzzword del momento, per usare un inglesismo) in-trodotto di recente nel mondo informatico: ne segue che non esiste una definizione ufficia-le. Perciò, in questo paragrafo analizzeremo le definizioni date da alcune tra le fonti più au-torevoli sulla scena IT mondiale, e cercheremo di giungere ad una definizione condivisa.Partiamo da un’analogia: Cloud è l’industrializzazione dell’IT. Pensiamo al processo di in-dustrializzazione, a cosa c’era prima e a cosa ha portato in diversi settori.Riguardo all’industria delle telecomunicazioni, un tempo, affinché A potesse parlare conB, era necessario che un operatore collegasse fisicamente i due capi del telefono. Ciò nonera molto scalabile né economico, ed era inoltre facile commettere errori. Oggi, grazie agliswitch, il processo di collegamento di due apparati telefonici è completamente automatiz-zato, e di conseguenza molto più efficiente, scalabile ed economico.Nell’industria dell’automobile, Henry Ford rese più efficiente il processo di produzione in-troducendo il sistema di lavoro della catena di montaggio. Questo permise di migliorare laqualità del prodotto e nel contempo di abbassare i costi, facendo dell’automobile un benedi massa.4 Citazione tratta dalla conferenza che John McCarthy tenne durante il centenario del MIT nel 1961. 6
  12. 12. Riguardo al settore bancario, una volta, se non riuscivi ad arrivare in banca prima dell’oradi chiusura, non potevi disporre dei tuoi risparmi per quel giorno. Oggi, grazie agli ATM(Automated Teller Machine) e ai bancomat, è possibile effettuare prelievi o versamenti aqualunque ora del giorno e della notte.Queste forme di innovazione o di industrializzazione esemplificano ciò che il cloud com-puting si prefigge di fare nel campo dell’Information Technology: rendere i processi IT piùsemplici, intuitivi, scalabili e rapidi nell’erogazione.In generale, il termine “cloud” si rifà alla nuvola storicamente usata per indicare grafica-mente Internet, che è una rete di reti eterogenee. Figura 1.1: la NuvolaInfatti, nel cloud computing vengono nascosti i dettagli dell’architettura edell’infrastruttura che c’è dietro, mentre ciò che viene esposto all’esterno è unicamente ilconcetto di servizio. Il servizio è l’entità astratta che l’ambiente cloud è in grado di fornire,e che l’utente può richiedere. I servizi, come vedremo, possono andare dall’utilizzo di uncerto software, all’utilizzo di un intero server (virtuale).Cloud computing è un mix di vari modelli computazionali, con i quali viene spesso confu-so, quali: 7
  13. 13.  grid computing: modello di calcolo distribuito, parallelo, in cui una serie di calco- latori eterogenei condividono le risorse computazionali;  utility computing: un modello incentrato sul pay-per-use, in cui, come nel caso dell’energia elettrica, l’utente utilizza delle risorse (computazionali), e alla fine del periodo di utilizzo paga per ciò che ha consumato;  autonomic computing: modello che prevede che il calcolatore abbia in sé gli stru- menti necessari per auto-gestirsi senza bisogno dellintervento umano.Dopo aver visto una panoramica generale, proseguiamo analizzando alcune definizioni au-torevoli, in cui, come vedremo, si possono riconoscere i tratti del grid, dell’utility edell’autonomic computing.1.1.1 NISTLa prima definizione che consideriamo è quella data in [1] dal National Institute of Stan-dards and Technology (NIST). NIST è un’agenzia del governo USA la cui missione èpromuovere l’innovazione degli Stati Uniti e la competitività industriale attraverso la defi-nizione di nuovi standard e attraverso il progresso nella scienza della misurazione e nellatecnologia. In particolare, in ambito ICT, il NIST è responsabile della definizione di stan-dard e di linee guida, inclusi i requisiti minimi, con lo scopo di fornire a tutte le agenziegovernative un adeguato livello di sicurezza delle informazioni. Cloud computing is a model for enabling ubiquitous, convenient, on‐demand net- work access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.In altri termini, secondo il NIST, il cloud computing è un modello di erogazione e consu-mo on-demand di risorse e servizi IT. Possiamo notare che nella definizione del NIST ven-gono evidenziati i seguenti aspetti:  le risorse computazionali come unità di scambio tra utente/cliente e cloud provi- der5 (grid computing);5 Il cloud provider è il fornitore dei servizi cloud 8
  14. 14.  la rete come mezzo di accesso alle risorse;  il carattere on-demand (i.e. “su richiesta”) dell’erogazione di risorse;  la rapidità nell’erogazione delle risorse all’utente;  lo scarso livello di gestione e di interazione che è richiesto al cloud provider du- rante l’erogazione delle risorse (autonomic computing)1.1.2 GartnerGartner6 è una multinazionale, leader mondiale in ricerca e consulenza informatica. In [2],Gartner definisce il cloud computing come: a style of computing where massively scalable IT-enabled capabilities are delivered “as a service” to external customers using Internet technologiesIn questa definizione si pone in particolar modo l’accento su tre aspetti:  la scalabilità;  il servizio come unità atomica di scambio;  l’uso di Internet come mezzo fisico di propagazione dei servizi.1.1.3 CiscoCisco7 Systems è una multinazionale leader nella progettazione e nella vendita di apparatidi networking, dai router ai telefoni VoIP. In [3], Cisco definisce il cloud computing come: IT resources and services that are abstracted from the underlying infrastruc- ture and provided “on-demand” and “at scale” in a multitenant environment.Qua le parole chiave sono:  Risorse IT  Servizi astratti  On-demand  Scalabilità (“at-scale”)6 Gartner è un marchio registrato di Gartner, Inc (http://www.gartner.com).7 Cisco è un marchio registrato di Cisco Systems, Inc. (http://www.cisco.com). 9
  15. 15.  Ambiente multitenantOsserviamo che quattro su cinque di queste parole chiavi le abbiamo già incontrate nelledefinizioni precedenti. L’unica espressione nuova è ambiente multitenant, che indica cheuna singola “istanza” cloud fornisce risorse a molti utenti, facendo sì che il cloud providerottenga dei notevoli risparmi.1.1.4 La nostra definizioneDopo questa carrellata di definizioni, possiamo quindi definire il cloud computing come unparadigma di computazione tale che:  I servizi (o, da un punto di vista più tecnico, le risorse computazionali) sono dispo- nibili su richiesta del cliente/utente, tramite una rete locale (e in questo caso si parla di private cloud8) o tramite Internet (public cloud9);  L’architettura è scalabile ed elastica: è cioè in grado di gestire quantità variabili di carico, secondo le necessità;  Una volta che l’ambiente cloud è stato configurato opportunamente, è in grado di gestirsi autonomamente, senza bisogno dell’intervento umano (salvo che si voglia erogare nuovi servizi, o modificare quelli già esistenti).1.2 Caratteristiche principaliVediamo ora meglio quali sono gli elementi che caratterizzano una qualunque soluzione dicloud computing. Come per le definizioni, anche per quanto riguarda le caratteristiche nonesiste un’unica teorizzazione, ma diverse. Procediamo quindi ad analizzare le più impor-tanti, e alla fine cercheremo di ricavarne una sintesi.1.2.1 NISTIn [1], il NIST affronta la questione da un punto di vista leggermente tecnico, e identificale seguenti caratteristiche essenziali:8 Come vedremo nel paragrafo 1.3.1.1, il private cloud è un cloud locato e gestito internamenteall’organizzazione che lo utilizza9 Al contrario del private cloud, il public cloud è locato e gestito esternamente all’organizzazione che lo uti-lizza (vedi par. 1.3.1.2) 10
  16. 16.  Self-service on-demand: l’utente finale, in ogni momento, può autonomamente fa- re richiesta di un servizio senza bisogno di interagire con operatori umani del cloud provider;  Accesso di rete: i servizi cloud sono disponibili sulla rete e sono accessibili tramite client eterogenei (es: telefoni cellulari, computer portatili, palmari, ecc.);  Pool di risorse: le risorse computazionali del cloud provider sono organizzate in un pool di risorse in modo che possano essere assegnate e riassegnate in base alle ri- chieste dei vari utenti. Il termine pool indica un insieme di risorse potenzialmente eterogenee (anche dal punto di vista della localizzazione geografica), che vengono trattate come se fossero omogenee;  Rapidità ed elasticità: la fornitura di servizi avviene in maniera rapida ed elastica; in altre parole, il cloud computing è in grado di soddisfare velocemente e agilmente le richieste degli utenti;  Monitoraggio delle risorse: l’utilizzo delle risorse può essere monitorato e con- trollato a vari livelli (a livello di spazio disco, piuttosto che tempo di CPU, oppure ancora a livello di banda). Inoltre, possono essere prodotti dei report sull’utilizzo, utili sia al cloud provider che all’utente finale.1.2.2 IBMAl contrario del NIST; IBM in [4] adotta un taglio più commerciale, di alto livello e orien-tato al cliente. Infatti, come suggerisce il titolo (“IBM cloud channel sales guide”), [4] è undocumento destinato ai partner commerciali di IBM, che hanno il compito di vendere i suoiprodotti cloud.Dunque, IBM identifica le seguenti cinque caratteristiche che dovrebbero essere comuni aqualunque soluzione di cloud computing, sia essa di IBM, di Microsoft10 o di Amazon, pu-blic o private:  Catalogo dei servizi: è l’interfaccia tra l’utente e l’ambiente cloud; a sua volta, il catalogo può essere consultato dall’utente attraverso un’interfaccia web, tramite la quale l’utente può inoltrare le richieste di servizi.10 Microsoft è un marchio registrato di Microsoft Corporation (http://www.microsoft.com). 11
  17. 17.  Automazione: è una caratteristica invisibile all’utente finale, che permette di na- scondere la complessità che c’è dietro al soddisfacimento di una richiesta di un ser- vizio. Ne parleremo in dettaglio nel paragrafo 2.2.  Virtualizzazione: tecnologia nata diversi decenni fa, è l’ingrediente fondamentale di un ambiente cloud. La virtualizzazione sarà approfondita nel paragrafo 2.1.  Metering: la capacità di fornire informazioni e statistiche sull’utilizzo dei servizi cloud da parte di ogni utente. Strettamente legato al metering, vi è il billing (detto anche chargeback), termine con cui si intende il processo di generazione delle fat- ture a partire dai dati di utilizzo forniti dal metering, usando un insieme di policy di fatturazione stabilite a priori.  Customer‐focused: come nel settore retail, il cliente viene prima di tutto, perciò gli deve essere completamente rivolta l’attenzione di coloro che gestiscono l’ambiente cloud. Bisogna cioè fare in modo che le esperienze del cliente siano sempre positive, dal momento in cui richiede un servizio fino al momento in cui ri- ceve la fattura.1.2.3 SintesiIn conclusione, possiamo dire che un’architettura cloud, per essere chiamata come tale, de-ve essere composta dai seguenti pilastri: virtualizzazione, automazione, billing e charge-back. Deve inoltre essere caratterizzata da un alto grado di elasticità e scalabilità (sia versol’alto che verso il basso, cioè sia che l’utilizzo del sistema cresca, sia che diminuisca). Infi-ne, deve essere presente un’interfaccia user-friendly (il catalogo dei servizi) che permettaall’utente di richiedere un servizio quando ne ha bisogno, in modo rapido e semplice.1.3 Tassonomia, sugli assi cartesianiEsistono diversi modelli di cloud computing. Li possiamo distinguere in base a due criterifondamentali: a. Il luogo dove risiedono fisicamente i dati b. Le tipologie di servizi offertiSe immaginiamo di mettere questi due criteri sugli assi cartesiani, facendone il prodottocartesiano otteniamo i principali modelli di cloud esistenti. I “principali” e non “tutti” per- 12
  18. 18. ché, come è già stato detto, il cloud computing è una branca dell’informatica ancora inevoluzione. Qualunque classificazione non può quindi essere considerata come definitiva.1.3.1 Asse x: dove risiedono i dati (“cloud deployment models”)In base al luogo dove risiedono fisicamente i dati, possiamo distinguere quattro tipologie dicloud (anche detti cloud deployment models) [1]:  Public  Private  Hybrid  Community Figura 1.2: Cloud deployment models1.3.1.1 Private cloudCome dice la parola stessa, nel private cloud linfrastruttura è utilizzata esclusivamente dauna sola organizzazione. Come mostrato in Figura 1.3, può essere gestita dallorganizza-zione stessa oppure da terzi (managed private cloud); inoltre può risiedere all’interno deilocali dell’organizzazione (on premise) o essere ospitata nei locali di terzi (off premise, ho-sted private cloud). 13
  19. 19. Figura 1.3: Tipologie di Private Cloud1.3.1.2 Public cloudDiametralmente opposto al private, nel public linfrastruttura cloud è messa a disposizionedi chiunque voglia usufruirne, dal privato cittadino al grande gruppo industriale, ed è diproprietà di unorganizzazione che vende servizi cloud (i.e. il “cloud provider”).1.3.1.3 Community cloudL’infrastruttura cloud è condivisa tra organizzazioni diverse, facenti però tutte parte di unastessa “comunità” con dei valori comuni (es: la mission, le policy, ecc.). Come nel casoprivate, può essere gestita dalle organizzazioni stesse, oppure da terzi (managed commu-nity cloud); inoltre può essere on premise o off premise (hosted community cloud).1.3.1.4 Hybrid cloudNell’hybrid, l’architettura cloud è composta da due o più cloud (ad es. una private e unapublic) integrate tra loro attraverso degli standard o mediante tecnologie proprietarie, e re-se così inter-operabili.1.3.2 Asse y: tipologie di servizi offerti (“service models”)In base al tipo di servizi offerti dal cloud provider, possiamo distinguere tre principali tipo-logie di cloud (anche detti service models) [1]:  Software as a Service (SaaS)  Platform as a Service (PaaS)  Infrastructure as a Service (IaaS) 14
  20. 20. Questi tre, come potremo dedurre dalle relative definizioni del NIST, si differenziano so-stanzialmente per il livello di controllo (in ordine crescente) che viene concesso all’utentesull’infrastruttura del provider.Altre classificazioni includono anche:  Business Process as a Service (BPaaS)  Storage as a Service (SaaS)  Communications as a service (CaaS)  Network as a Service (NaaS)  Monitoring as a Service (MaaS)  …  Everything as a Service (XaaS o *aaS)Quest’ultimo non è un vero e proprio service model. In realtà, è semplicemente un modoper indicare le infinite possibilità (in termini di servizi) che il cloud computing è in gradodi offrire. Parafrasando, “XaaS” significa che “qualunque cosa può essere offerta come unservizio”.Entriamo ora nel dettaglio, definendo i modelli più significativi citati sopra.1.3.2.1 Software as a Service, o “SaaS”Il termine “SaaS” esiste dagli anni ’90, da prima che si cominciasse a parlare di cloudcomputing. Una semplice definizione di SaaS è la seguente [5]: Software deployed as a hosted service and accessed over the Internet.In [1], il NIST dà una definizione più completa: The capability provided to the consumer is to use the provider’s applica- tions running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the pos- sible exception of limited user-specific application configuration settings. 15
  21. 21. In altre parole, SaaS è un modello di distribuzione centralizzata del software, in cui il ser-vizio cloud fornito consiste nell’utilizzo on-demand di un software in forma di applicazio-ne web, tipicamente accessibile attraverso un browser.Vantaggi e svantaggiCome indicato in [6], in confronto al tradizionale modello di distribuzione del software cheprevedeva l’installazione da CD (o da altre fonti) sulla propria macchina, il modello SaaSapporta alcuni benefici per l’utente, dal momento che, grazie alla centralizzazione, oneriche prima erano in carico all’utente, ora sono spostati a carico del cloud provider. D’altraparte, per le stesse ragioni, il SaaS presenta anche dei problemi.Analizziamo prima i vantaggi:  Piccole (se non nulle) conseguenze sulla macchina dell’utente L’utente, infatti, non deve più installare il software prima di utilizzarlo, ma gli basta avere un browser e una connessione di rete. In questo modo si evita qualunque po- tenziale problema di conflittualità tra il nuovo software e l’ambiente locale. Questo punto rappresenta un beneficio anche per il cloud provider. Infatti, gli com- porta una forte riduzione dei costi per la distribuzione del software. Questa, a sua volta, può portare a maggiori investimenti nello sviluppo e nel miglioramento del software, e quindi rappresenta un ulteriore beneficio per gli utenti.  Risparmio per l’utente nei costi di aggiornamento delle sue macchine Dato che l’applicazione viene eseguita sulle macchine del provider, l’utente ottiene un risparmio in termini di risorse computazionali della sua macchina, e, di conse- guenza, un risparmio nei costi di aggiornamento hardware o software della macchi- na, che potrebbe essere necessario per soddisfare i requisiti minimi della nuova ap- plicazione.  Ottimizzazione delle licenze software La gestione delle licenze risulta semplificata. Un cliente può ora acquistare una sin- gola licenza ed utilizzarla su più computer in momenti diversi. È così possibile evi- tare di comprare molteplici licenze, una per ogni computer, con il rischio di non sfruttarle tutte allorquando uno di quei computer non venga utilizzato. 16
  22. 22.  Centralizzazione dell’amministrazione dell’applicazione e dei dati Il cloud provider ha l’onere della gestione e del controllo sia dell’applicazione che dei dati di ogni utente, i quali sono memorizzati sui server del cloud provider. Il lato positivo è che l’utente ha minori responsabilità in merito alla sicurezza dei dati: ora, è il cloud provider che deve provvedere ad eseguire il backup dei dati a intervalli regolari, predisporre delle misure adeguate di disaster recovery, ecc. Inol- tre, l’utente è anche esonerato dal rischio di portare con sé i dati durante gli spo- stamenti, poiché essi sono sempre disponibili sulla nuvola. Infine, se supportata da logiche applicative, la gestione centralizzata agevola la condivisione dei dati con al- tri utenti cloud.Sull’altro lato della medaglia, troviamo tre principali punti problematici:  Sicurezza dei dati La centralizzazione dei dati, se da un lato fornisce una certa sicurezza per l’utente, dall’altro potrebbe costituire un grosso problema se il cloud provider non è in grado di proteggerli più che adeguatamente.  Sicurezza del browser web Come abbiamo visto, l’unico punto di accesso per l’utente alla fruizione del SaaS è il browser. Di conseguenza, esso è un potenziale punto debole del sistema.  Forte dipendenza dalla rete Dato che l’applicazione viene eseguita sui server del provider, la disponibilità della stessa dipende a sua volta dalla disponibilità della rete. È possibile mitigare in parte questo problema prevedendo una modalità di lavoro offline; tuttavia, per la natura intrinseca del SaaS, sarebbe del tutto naturale se in questa modalità molte delle fun- zionalità del software non fossero disponibili.Esempio: Google DocsUn esempio molto famoso di SaaS sono i Google11 Docs, una suite per ufficio che com-prende un word processor, un foglio di calcolo, un’applicazione per le presentazioni e unaper disegnare. In questo caso, il cloud provider (i.e. Google) ha scelto di rendere il suoSaaS fruibile a chiunque, senza alcun costo.11 Google è un marchio registrato di proprietà di Google Inc. (http://www.google.com) 17
  23. 23. 1.3.2.2 Platform as a Service, o “PaaS”Di seguito riportiamo la definizione di PaaS data dal NIST [1]: The capability provided to the consumer is to deploy onto the cloud infra- structure consumer-created or acquired applications created using program- ming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed ap- plications and possibly application hosting environment configurations.Essenzialmente, i cloud PaaS forniscono piattaforme di sviluppo software costituite daframework e da ambienti run-time: i primi supportano lo sviluppo vero e proprio, i secondipermettono di eseguire, e quindi anche di testare, il software sviluppato. Gli utenti PaaSsono quindi non solo gli sviluppatori di software, ma anche gli utenti finali che usano quelsoftware sviluppato. Una tipica offerta PaaS si presenta agli utenti sviluppatori in forma diAPI.Vantaggi e svantaggiSeguendo [6], analizziamo i pro e i contro di una simile soluzione.I vantaggi per gli utenti sono gli stessi del SaaS, ovvero: minori costi iniziali, nessuna re-sponsabilità e nessun coinvolgimento nel setup e nella manutenzione dei componenti dellapiattaforma. Inoltre, i framework PaaS forniscono di solito dei design pattern che aiutanogli sviluppatori a costruire software altamente scalabile in grado di gestire picchi di carico.Per quanto riguarda gli svantaggi, oltre a quelli evidenziati per il SaaS, si aggiungono i se-guenti problemi:  Portabilità tra differenti provider PaaS Ogni cloud provider usa implementazioni proprie (es: l’interfaccia delle strutture dati come la hash table) che rendono molto difficile il “trasloco” di un software da un provider all’altro, malgrado il linguaggio di programmazione dei due PaaS possa essere lo stesso. Come rimedio, gli sviluppatori possono cercare di programmare per interfacce (che è in generale una buona pratica di programmazione), ma ciò può andare a scapito dell’efficienza, perché non permette di sfruttare appieno le possibi- lità offerte da uno specifico provider. 18
  24. 24.  Complessità di un’applicazione PaaS A differenza di un’applicazione che deve essere eseguita in un ambiente locale e isolato, un’applicazione PaaS è molto più complessa, in primo luogo perché deve accedere alla rete. Perciò, lo sviluppatore deve considerare molteplici aspetti con- cernenti la sicurezza delle trasmissioni (la crittografia su tutti), e deve padroneggia- re molte tecnologie e linguaggi di programmazione (HTML, HTTP, XML, ecc.).Esempio: Google App EngineGoogle App Engine è l’offerta PaaS di Google, una piattaforma che permette lo sviluppodi applicazioni web e l’hosting delle stesse presso i data center di Google. Tali applicazionipossono così beneficiare di un alto grado di scalabilità, lo stesso di cui gode ognuna delleGoogle apps. Al momento, i linguaggi di programmazione supportati sono Java12, Python eGo13. Per ognuno di questi linguaggi, Google ha pubblicato dei software development kit(SDK) ad hoc, che si possono scaricare liberamente dal sito e installare sulla propria mac-china per cominciare a sviluppare. L’utilizzo della piattaforma di Google è gratuito, alme-no inizialmente, ed è possibile poi acquistare aggiuntive risorse computazionali, di memo-ria e di banda, in funzione delle esigenze.1.3.2.3 Infrastructure as a Service, o “IaaS”In questa rassegna di service models, IaaS rappresenta il livello di astrazione più basso. In-fatti, il servizio fornito dallo IaaS è essenzialmente l’utilizzo di una macchina virtuale. Illivello di controllo per l’utente è inversamente proporzionale a quello di astrazione:l’utente può infatti configurare la macchina dalle fondamenta, a partire dalla scelta del si-stema operativo. Di seguito riportiamo la definizione del NIST [1]: The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).12 Java è un marchio registrato di Oracle (http://www.oracle.com).13 Go è un linguaggio di programmazione imperativo nato nel 2009 e sviluppato da Google. 19
  25. 25. Vantaggi e svantaggiSeguendo [6], analizziamo i pro e i contro dello IaaS.Tra i vantaggi possiamo citare:  la possibilità di affittare hardware virtuale in modo efficiente e flessibile;  il totale controllo sulle VM, che porta una grande flessibilità riguardo alle applica- zioni che si possono portare nel cloud (es: legacy).Tra gli svantaggi, invece, citiamo:  l’uso della rete e le problematiche associate, quali la sicurezza delle comunicazioni e la grande dipendenza dalla connessione di rete (disponibilità e prestazioni);  se sulle VM si eseguono delle applicazioni legacy, ne possono derivare dei proble- mi di sicurezza dovuti alle vulnerabilità di quelle stesse applicazioni.1.3.2.4 Business Process as a Service, o “BPaaS”BPaaS offre come servizi i processi di business. BPaaS sta un gradino sopra a SaaS, poichéè ad un livello di astrazione più alto.Ad esempio, possono essere forniti processi per la gestione dei benefit dei dipendenti, per iviaggi di lavoro, o anche processi IT quale il processo del test del software. Richiedere ilprocesso del test del software come servizio cloud vuol dire esternalizzare l’intero proces-so, comprese le persone che lo svolgono [7].1.4 Vantaggi e svantaggiI pro e contro specifici per ogni service model sono già stati discussi nel corso del paragra-fo 1.3.2. Ora analizziamo quelli più generali, a livello di architettura cloud.Come indicato in [8], il cloud computing presenta numerosi vantaggi:  Tempi di provisioning più rapidi, che portano anche a un minore time-to-market per nuovi prodotti software e servizi, e all’ottimizzazione delle tempistiche di pro- getto; 20
  26. 26.  Minori investimenti in hardware e software. Grazie al pay-per-use, il cloud computing consente infatti di usufruire di risorse computazionali arbitrariamente grandi per un determinato periodo di tempo: basti pensare che il costo di 100 ore di un server è del tutto equivalente al costo di 1 ora per 100 server. Tutto ciò, in parti- colare, è positivo per le start-up e per le PMI (Piccole e Medie Imprese), le quali non si possono economicamente permettere un’infrastruttura IT molto potente;  Ambienti di test più facili da creare e distruggere, e meno costosi. Ciò vale in modo particolare se servono per limitati periodi di tempo;  Minore carico di lavoro per il data center interno all’organizzazione: adottando una soluzione hybrid si possono esternalizzare i picchi di carico;  Minore impatto ambientale, grazie al risparmio energetico dovuto principalmente al consolidamento dei server, attraverso la virtualizzazione dell’infrastruttura;  Migliore controllo economico sugli asset IT, grazie al sistema di billing e charge- back;  Minore spreco di tempo e di risorse umane per la piccola manutenzione, grazie all’automazione.Parlando invece dei problemi insiti nel cloud computing, il più rilevante è legato alla sicu-rezza, e costituisce probabilmente il principale ostacolo all’adozione del cloud. La sicurez-za comprende molti aspetti: la sicurezza dei data center e dei dati che ospitano da un puntodi vista fisico; la sicurezza dei dati (quelli che sono memorizzati nel datacenter, ma anchequelli in transito tra il datacenter e le macchine degli utenti) da un punto di vista elettroni-co; il dovere che hanno alcune organizzazioni di adeguarsi a degli standard di sicurezza;vincoli di carattere legale che impongono di avere i dati in determinate zone geografiche. Ilproblema della sicurezza vale specialmente nel caso del public cloud, ma bisogna dire cheè comune a qualunque forma di outsourcing, e si può riassumere con una frase di RichardStallman, noto sostenitore del software libero:Una ragione per la quale non si dovrebbero usare le applicazioni web è che si perde con- trollo. Non va bene, così come non va bene usare programmi proprietari. Fate le vostre computazioni su un computer vostro, con la vostra copia di un programma che rispetta levostre libertà. Se usate un programma proprietario o il server di qualcun altro, siete senza difese. Vi state mettendo nelle mani di chiunque abbia sviluppato quel software.Un altro problema è il cosiddetto lock-in, termine che riassume la difficoltà per gli utenti dimigrare i dati da un provider ad un altro (portabilità) e la difficoltà ad integrare insieme 21
  27. 27. più ambienti cloud di provider differenti (interoperabilità). Ciò è causato dalla mancataadozione di standard aperti da parte dei cloud provider. Un’iniziativa che va in tale dire-zione è quella supportata da opencloudmanifesto.org, in cui è pubblicato un manifesto [9]contenente una serie di principi a favore di standard aperti per il cloud. Al momento, que-sto manifesto è supportato da oltre 400 organizzazioni14.L’ultimo problema che citiamo è dato dalla difficoltà di fare una stima precisa dei costi edel rapporto tra costi e benefici. In un contesto pay-per-use può infatti essere difficile pre-vedere quali saranno i livelli di utilizzo dei servizi cloud. In questa sede non ci addentria-mo nell’argomento; per un approfondimento vedere [10].Infine, a tutti questi problemi se ne può aggiungere un altro: il problema del digital divide,in particolare nell’accezione che indica la scarsa qualità delle infrastrutture di rete di unpaese. Un esempio è l’Italia, dove la banda larga è arrivata a 20Mbps in downlink solo re-centemente e solo in poche aree.14 http://www.opencloudmanifesto.org/supporters.htm 22
  28. 28. Capitolo 2. Principali tecnologie cloud2.1 VirtualizzazioneIl primo passo verso l’adozione del cloud consiste nel virtualizzare l’infrastruttura.In generale, “virtualizzare” significa astrarre i dettagli fisici ponendoli su un piano logico.Questo processo di astrazione di una risorsa (fisica) permette ai suoi utenti un accesso piùsemplice, efficiente e sicuro.Per fare degli esempi, il caso più conosciuto di virtualizzazione è quello in cui su una solamacchina fisica vengono eseguite molte macchine virtuali (dette anche VM, come “virtualmachine”): in questo caso, possiamo notare che abbiamo una relazione uno-molti. Ma, alcontrario, è possibile anche virtualizzare più risorse per farle sembrare una sola: trattasi delpooling delle risorse, concetto cui abbiamo già accennato nel Capitolo 1.2.1.1 Tecniche di virtualizzazioneIn letteratura sono definite molte tipologie di virtualizzazione. Per citarne alcune: hardwarevirtualization, server virtualization, application virtualization, desktop virtualization, net-work virtualization, storage virtualization, operating system virtualization, full virtualiza-tion, paravirtualization, partial virtualization. Senza perderci in inutili nozionismi, focaliz-zeremo il nostro studio sulle tecniche di virtualizzazione che interessano i data center e ilcloud computing, in particolare il modello IaaS. Parleremo perciò di platform virtualiza-tion.La virtualizzazione di tipo platform (anche detta di tipo hardware, o server) permette dicreare un ambiente virtuale e di farci girare qualunque tipo di sistema operativo e di appli-cazioni. In un contesto cloud, è usata nel modello IaaS.Esistono due tecniche implementative principali: full virtualization e paravirtualization. Ilsistema software che si occupa dell’inserimento del livello di astrazione è chiamato hyper- 23
  29. 29. visor o Virtual Machine Monitor (VMM). Il sistema operativo virtuale viene detto guestOS, mentre il sistema operativo che contiene l’hypervisor viene anche detto host.2.1.1.1 Full virtualizationLa tecnica di virtualizzazione di tipo full prevede che l’hardware sia interamente simulatodall’hypervisor. Quest’ultimo presenta al guest OS risorse (BIOS, CPU, RAM, dischi,schede di rete) virtuali, che il guest vede come se fossero risorse fisiche vere e proprie.Hardware-assisted virtualizationPer supportare a livello hardware la virtualizzazione (di tipo full in particolare), Intel15 eAMD16 hanno rispettivamente introdotto le tecnologie Intel VT e AMD-V, che estendonol’instruction set della CPU. Tale approccio permette di minimizzare l’overhead dovutoall’hypervisor; presenta però lo svantaggio di non funzionare con tutte le CPU, e di essereinoltre causa di overhead a livello del processore.2.1.1.2 ParavirtualizationMentre nella full virtualization, come abbiamo appena visto, la virtualizzazione è un pro-cesso completamente trasparente al guest OS, la paravirtualizzazione richiede una sostan-ziale modifica del codice del sistema operativo guest. Infatti, questa tecnica si limita aesporre al guest OS un’interfaccia applicativa, chiamata “virtual hardware API”. Poi, nelguest, ogni system call che accede ad una risorsa hardware dovrà essere sostituita con unacosiddetta hyper call. Così, se da una parte è necessario modificare il codice del guest OS,dall’altra, l’hypervisor risulta meno complesso e, grazie alle hyper call, più efficiente.2.1.1.3 HypervisorEsistono due tipi di hypervisor:  Tipo 1 (o “bare metal”): viene eseguito direttamente sull’hardware, come un sistema operativo  Tipo 2 (o “hosted”): viene eseguito all’interno di un sistema operativo “host”Come si può immaginare, non essendoci alcuna intermediazione tra l’hypervisor el’hardware, il tipo 1 è quello che raggiunge le migliori performance. Il tipo 2 può essere15 Intel è un marchio registrato di Intel Corporation (http://www.intel.com).16 AMD è un marchio registrato di Advanced Micro Devices, Inc. (http://www.amd.com). 24
  30. 30. preferibile quando è richiesto supporto per molti dispositivi di I/O, che un normale sistemaoperativo host è in grado di fornire.2.1.2 Vantaggi e svantaggiSi stima che un moderno server sia sfruttato solo per il 15-20% delle sue capacità. Con lavirtualizzazione è possibile avere due o più server virtuali su una sola macchina fisica: diconseguenza, il principale vantaggio della virtualizzazione sta nel consolidamento dei ser-ver, che significa ridurre il numero di server fisici utilizzati. A sua volta, ciò comporta unrisparmio nei consumi energetici e nei costi di gestione e manutenzione dei server (ad es. icosti per la sostituzione di periferiche guaste).Un altro importante aspetto positivo è l’isolamento: ogni macchina virtuale è un ambientea sé stante, isolato rispetto alle altre VM. Questa caratteristica giova alla sicurezza, inquanto la falla di una VM, anche se sfruttata, non può coinvolgere le altre VM.Infine, un terzo beneficio è l’indipendenza dall’hardware. Ciò vuol dire che è possibilespostare una macchina virtuale da un computer all’altro (portabilità), senza badareall’hardware sottostante. È il caso di rilevare che questo punto viene meno se parliamo dihardware-assisted virtualization.Tra gli svantaggi principali bisogna citare l’overhead introdotto dall’hypervisor e la con-seguente riduzione delle prestazioni globali; inoltre, i problemi che possono sorgere in casodi periferiche non virtualizzabili (accelerazioni grafiche comprese) [11].2.1.3 Stato dell’arteIn questo paragrafo vedremo i principali hypervisor enterprise supportati dal Service Deli-very Manager, il prodotto cloud di IBM che useremo nella nostra soluzione private (vediParte II).2.1.3.1 XenXen è un hypervisor open source di tipo 1 che permette la virtualizzazione sui processorix86, x86_64, IA64, ARM, e su altre architetture. Supporta un vasto insieme di sistemi ope-rativi guest, inclusi Windows17, Linux18, Solaris19, e varie versioni di BSD. Come tecnolo-17 Windows è un marchio registrato di Microsoft Corporation (http://www.microsoft.com). 25
  31. 31. gie, implementa in primo luogo la paravirtualizzazione; invece, per i sistemi operativi nonparavirtualizzabili (ad esempio Windows), Xen sfrutta le funzioni di virtualizzazione mes-se a disposizione dalla CPU (hardware-assisted virtualization, o, secondo la terminologiaXen, “hardware virtual machine”).2.1.3.2 KVMKVM (acronimo di “Kernel-based Virtual Machine”) è una soluzione open source di fullvirtualization per Linux che funziona solo su hardware x86 che abbia le estensioni di vir-tualizzazione (Intel VT o AMD-V). KVM è composto da un modulo kernel che forniscel’infrastruttura virtuale di base (kvm.ko), e da un modulo specifico per il processore (kvm-intel.ko o kvm-amd.ko) [12].Come evidenziato in Figura 2.1, la differenza principale rispetto a Xen sta nel fatto cheKVM è un modulo del kernel Linux (infatti si chiama “Kernel-based”), mentre Xen è unhypervisor esterno al kernel [13]. In questo modo, KVM è in grado di utilizzare tutti glistrumenti standard insiti nel kernel Linux, compreso lo scheduler e la gestione della memo-ria, e ciò fa sì che risulti molto più leggero di Xen. Figura 2.1: Xen (a sinistra) e KVM (a destra) a confronto18 Linux è un marchio registrato di Linus Torvalds (http://www.linuxfoundation.org).19 Solaris è un marchio registrato di Oracle Corporation. 26
  32. 32. 2.1.3.3 VMware vSphere (v4.1)VMware20 è attualmente l’azienda leader di mercato nel settore della platform virtualiza-tion delle architetture x86.vSphere è definito come un sistema operativo cloud in grado di trasformare un datacenterin uninfrastruttura cloud in cui sia possibile fornire servizi IT in modo flessibile e, nellostesso tempo, affidabile [14]. In pratica, si tratta di una suite di applicazioni per la virtua-lizzazione che include VMware ESX/ESXi e VMware vCenter Server.VMware vSphere è costituito da vari layer [14]: 1. Infrastructure Services: linsieme di servizi forniti per astrarre, aggregare e alloca- re risorse hardware e risorse infrastrutturali. I principali sono:  VMware vCompute: insieme di servizi che astraggono e aggregano le ri- sorse provenienti da diverse macchine fisiche  VMware vStorage: permette un utilizzo e una gestione efficiente dello sto- rage in ambienti virtuali  VMware vNetwork: semplifica e migliora il networking in un ambiente virtuale 2. Application Services: garantiscono disponibilità, sicurezza, e scalabilità per le ap- plicazioni. Es: High Availability e Fault Tolerance 3. VMware vCenter Server: punto di controllo dell’intero datacenter, fornisce i ser- vizi essenziali per un datacenter, quali il controllo degli accessi, il monitoring delle prestazioni, e la configurazione 4. Clients: l’accesso a vSphere può avvenire attraverso VMware vSphere Client (un software per Windows che funge da interfaccia) o attraverso Web Access (un’applicazione web)Nel resto del paragrafo analizzeremo meglio i due prodotti VMware che compongonovSphere: VMware ESX/ESXi e VMware vCenter Server. ESX è un hypervisor che può an-che essere usato come prodotto a sé stante per virtualizzare un singolo server fisico. ilvCenter Server è utile quando si possiedono più macchine con ESX/ESXi, in quanto con-sente di controllare tutti gli ESX da un unico punto.20 VMware è un marchio registrato di VMware, Inc. (http://www.vmware.com). 27
  33. 33. VMware ESX e ESXiESX e ESXi sono due hypervisor di tipo 1 che applicano la tecnica della full virtualization.Il componente fondamentale di entrambi i prodotti è il VMkernel, un kernel proprietario diVMware che fornisce le funzioni di virtualizzazione.ESX e ESXi differiscono per la data di introduzione sul mercato (ESX è la versione piùvecchia, introdotta nel 2001) e, soprattutto, per l’architettura. Infatti, oltre al VMkernel,ESX contiene un kernel Linux che funge da console amministrativa (console operating sy-stem, o “COS”) e da bootstrap per il VMkernel. ESXi, invece, non ha il COS, e risulta per-ciò più leggero e più sicuro [15].VMware vCenter ServervCenter Server consente di gestire un datacenter in modo centralizzato, aggregando risorsefisiche provenienti da varie ESX/ESXi. Figura 2.2: Infrastruttura con VMware vCenter ServerCon vCenter Server è possibile beneficiare delle seguenti funzionalità avanzate:  High Availability (HA) garantisce l’affidabilità dei servizi monitorando costante- mente sia i server fisici con ESX/ESXi sia le macchine virtuali che vi poggiano so- 28
  34. 34. pra. Non appena avverte un potenziale guasto del server fisico o un errore del si- stema operativo guest, si occupa, rispettivamente, di spostare tutte le VM su altri ESX o di riavviare la VM su cui si è presentato un problema;  vMotion permette la migrazione “live” delle VM trasferendo l’esecuzione da un ESX all’altro senza alcuna interruzione di servizio, mantenendo costante la dispo- nibilità e l’integrità delle transazioni;  vMotion Storage: permette la migrazione “live” dei file delle VM, da un datastore all’altro, senza alcuna interruzione di servizio;  Distributed Resources Scheduler (DRS) è uno strumento di load balancing che consente di distribuire in modo dinamico le risorse assegnate ad ogni singola VM, secondo priorità definite dall’utente, in modo da garantire sempre un alto livello di servizio e scalabilità alle VM ad alta priorità;  Distributed Power Management (DPM): in funzione del DRS, ottimizza il con- sumo di energia del datacenter consolidando le VM in un minor numero di ESX, e spegnendo quelli non necessari (ad esempio durante la notte o nei fine settimana).2.2 AutomazioneDopo la virtualizzazione, l’automazione rappresenta il secondo step verso l’acquisizione diun ambiente cloud.In un’infrastruttura virtuale, l’amministrazione è una grande sfida. Se costruita senza unadeguato approccio amministrativo, la virtualizzazione può aumentare la complessitàdell’infrastruttura e può quindi essere fonte di ulteriori costi, anziché di risparmio.L’automazione è la risposta a questi problemi, in quanto è una tecnica che semplifica la ge-stione dell’ambiente fisico che fornisce le risorse ai server virtuali. Ciò vuol dire che sopral’hypevisor, che continua a fare il suo lavoro, c’è un livello in più rappresentato dal sistemadi automazione del provisioning, che guida la mano dell’hypervisor nel creare e distrugge-re macchine virtuali, storage virtuale e infrastrutture di rete virtuali.Un altro grande beneficio apportato dall’automazione è la capacità di fornire servizi IT on-demand con un alto grado di agilità e scalabilità, requisiti fondamentali in un ambientecloud dove i bisogni possono continuamente cambiare, e l’IT deve essere in grado di stareal passo. 29
  35. 35. 2.2.1 Automazione del provisioningIn un datacenter, l’automazione è utile principalmente in due ambiti: per l’onboarding eper l’offboarding. L’onboarding è quel processo in cui, dopo aver creato una VM, si instal-la e configura il sistema operativo, la rete, lo storage e le applicazioni che si desiderano.L’offboarding è il processo opposto, ovvero quello in cui si distrugge una VM e si rendononuovamente disponibili le risorse hardware che teneva occupate.In genere, l’onboarding di un’applicazione inizia con il provisioning (fornitura) di un ser-ver. Se fatto manualmente, è un processo lungo, complesso e soggetto ad errori, che richie-de amministratori con elevate competenze nelle aree dei sistemi, delle reti e dello storage.Grazie all’automazione, è possibile mitigare i rischi legati a tale processo, lasciando che ilsistema di automazione si occupi di tutto quanto in maniera completamente trasparente.2.2.2 Stato dell’arte: IBM Tivoli Provisioning Manager (v7.2)Tivoli21 Provisioning Manager (TPM) comprende un server di provisioning, una consoleweb dell’operatore e dell’amministratore, e un ambiente di sviluppo [16].L’elemento base di tutto il sistema è il cosiddetto provisioning workflow, un pezzo di co-dice che descrive tutte le operazioni e le azioni che devono essere intraprese per il deploydi un sistema operativo, piuttosto che di un software, o di un’infrastruttura di rete.Un automation package è una raccolta di provisioning workflow, script e altri comandi estrumenti che si applicano al funzionamento di un determinato tipo di componente soft-ware o di un’unità fisica. È possibile utilizzare i pacchetti di automazione per automatizza-re il provisioning di software, patch, immagini e sistemi operativi, nonché di dispositiviquali computer, unità di rete e archivi.Di default, TPM contiene un buon numero di pacchetti di automazione per i più noti siste-mi operativi e applicazioni. Inoltre, per particolari esigenze, TPM mette a disposizione unambiente di sviluppo ad hoc basato su Eclipse chiamato Automation Package DeveloperEnvironment (APDE), che permette di creare o personalizzare gli automation package e iprovisioning workflow.21 Tivoli è un marchio registrato da International Business Machines Corporation(www.ibm.com/software/tivoli/) 30
  36. 36. In Figura 2.3 vengono illustrati i componenti principali di TPM, e il modo in cui interagi-scono con l’infrastruttura IT e con le altre applicazioni dell’ambiente. Figura 2.3: L’architettura di TPM 31
  37. 37. Il data model è il componente che fornisce una rappresentazione di tutte le risorse fisichee logiche gestite da TPM, quali computer, switch, sistemi di bilanciamento del carico,software applicativi, VLAN e politiche di sicurezza. Tiene traccia dell’hardware e delle re-lative assegnazioni alle applicazioni e delle modifiche alla configurazione. Quando un pro-visioning workflow completa correttamente una modifica richiesta, il data model viene ag-giornato per riflettere l’infrastruttura corrente. Inoltre, il data model memorizza le informa-zioni sui computer allocati e deallocati in pool di risorse per la gestione dei livelli. Questeinformazioni possono includere gli identificativi del computer, la dimensione del pool dirisorse, il numero dei computer disponibili e inattivi, la priorità dei computer e altre infor-mazioni.I componenti che si occupano del deployment sono due, uno alternativo all’altro. Il de-ployment engine (modalità agent-less) esegue i pacchetti di automazione e i provisioningworkflow, comunicando al termine il successo o meno dell’operazione. Invece,l’infrastruttura di distribuzione scalabile (Scalable Distribution Infrastructure, SDI)sfrutta i Tivoli Common Agent (TCA), presenti sulle macchine target, per eseguire il de-ploy.2.3 Service-Oriented Architecture (SOA)2.3.1 DefinizioneCome dice la parola stessa, SOA è uno stile architetturale orientato al servizio che defini-sce come i servizi sono offerti e utilizzati. In altri termini, SOA è un’architettura i cui com-ponenti sono implementati come servizi indipendenti e interoperabili, che è possibile farcomunicare e lavorare insieme in modo flessibile e disaccoppiato. Un servizio non solopuò essere consumato da un cliente dell’organizzazione che lo espone, ma anche da un al-tro servizio o da un’applicazione. Spesso, i servizi sono orchestrati come processi di busi-ness.Un servizio [17]:  È una rappresentazione logica di un’attività di business ripetibile con un risultato ben preciso (es.: “verificare la carta di credito del cliente” oppure “fornire informa- zioni metereologiche”) 32
  38. 38.  È un ente a sé stante, indipendente  Può essere composto a sua volta da altri servizi  Per i suoi consumatori è una “black box”Tipicamente, le architetture di tipo SOA presentano le seguenti caratteristiche [18]:  Sono costituite da componenti distribuiti (i servizi);  I fornitori e i consumatori dei servizi sono eterogenei e interoperano attraverso piat- taforme diverse; tuttavia, ogni servizio può essere implementato con un suo proprio linguaggio di programmazione e una sua piattaforma;  I servizi sono accoppiati in maniera lasca, e sono legati in modo dinamico a runti- me. Di conseguenza, SOA consente modifiche dinamiche con effetti locali ma non globali.Uno schema standard di SOA è quello rappresentato in Figura 2.4, che vede coinvolti treattori:  Service provider è l’ente che fornisce un servizio  Service requester è l’ente che usufruisce di un servizio  Service broker è l’ente che permette l’incontro tra domanda e offerta di servizi Figura 2.4: Gli attori coinvolti in una SOA e le azioni che possono intraprendereIn sintesi: il provider può pubblicare un servizio presso il broker; il requester può cercareun servizio presso il broker e può poi fruirne interagendo direttamente con il provider. 33
  39. 39. 2.3.2 SOA e il cloud computingNel cloud computing, intere infrastrutture IT virtuali, piattaforme e applicazioni sono im-plementati come servizi e resi disponibili in architetture service-oriented. Abbiamo infattivisto nel paragrafo 1.3.2 che, nel definire le varie tipologie di cloud, si parla di service mo-dels, che è un modo per distinguere il tipo di servizi offerti nella nuvola.Nello specifico, i servizi sono resi disponibili attraverso la rete, sulla base di protocolli webe interfacce standard, come quelle definite dai web services e dai RESTful services. 34
  40. 40. Capitolo 3. Stato dell’arte IBM “private IaaS”3.1 Offerta “private IaaS” IBMPoiché l’obiettivo perseguito in questo lavoro è progettare e implementare un sistema pri-vate cloud IaaS partendo da una soluzione IBM, in questo capitolo analizzeremo solo iprodotti di cloud computing commercializzati da IBM, limitatamente all’ambito privateIaaS. L’offerta IBM comprende i seguenti tre prodotti, dal più personalizzabile a quellomaggiormente pre-configurato:  IBM Tivoli Service Automation Manager  IBM Service Delivery Manager  IBM Cloud Burst3.2 IBM Tivoli Service Automation Manager (v7.2.1.1)Tivoli Service Automation Manager (TSAM) è una soluzione minimale, altamente perso-nalizzabile, in grado di fare di un ambiente virtualizzato un ambiente cloud. Gli hypervisorsupportati su System x22 sono VMware, Xen e KVM. TSAM fornisce i servizi essenzialiper il cloud, in particolare l’automazione del deploy di interi panorami IT, comprensivi diserver, reti, sistemi operativi, middleware e software applicativi, e una piattaforma user-friendly di self-service che permette di inoltrare al sistema le richieste di servizi.TSAM offre due interfacce utente, una per gli amministratori e una per gli utenti finali. Ilself service (anche chiamata Self Service Station) è un’interfaccia web 2.0 dedicata agliutenti finali, coloro i quali inoltrano richieste di servizi al sistema. Tramite il self service èpossibile accedere al service catalog, un catalogo che contiene tutti i servizi cloud che ilsistema è in grado di offrire, e che gli utenti possono richiedere. Il self service prevede an-22 I server IBM con brand “System x” si caratterizzano dall’essere basati su processori x86. 35
  41. 41. che una parte amministrativa, in cui gli utenti con ruolo “cloud administrator”, tra le altrecose, possono aggiungere o rimuovere immagini di server virtuali al/dal service catalog.Nello specifico, le operazioni che si possono effettuare attraverso la self service UI inclu-dono [19, p. 9]:  Creare server virtuali all’interno di un nuovo progetto di deployment, o aggiungere nuovi server virtuali ad un progetto esistente, con la possibilità di posticipare in un momento futuro l’effettivo deploy;  Installare sui server virtuali creati una immagine software, comprensiva di sistema operativo, più eventuali applicazioni;  Installare dei software addizionali sulle VM create;  Eliminare un server virtuale quando non è più utile, liberando così le risorse per es- sere utilizzate da altri server;  Salvare un’immagine di un server virtuale, e poi, con essa, ripristinarlo ad uno stato precedente;  Cancellare un progetto e rimuovere tutti i server virtuali associati;  Avviare, fermare, riavviare i server virtuali;  Resettare la password di admin su un server virtuale;  Aggiungere, eliminare e modificare utenti e team.La seconda interfaccia utente è riservata agli amministratori dell’ambiente cloud, e consen-te di effettuare operazioni quali la discovery, che serve ad aggiungere risorse fisiche alpool di risorse gestite da TSAM, la creazione o la personalizzazione dei report, l’aggiuntadi stack di software che possono essere installati sui server virtuali.Dopo una panoramica generale, vediamo più da vicino l’architettura di TSAM. Innanzitut-to, TSAM è composto da:  Tivoli Process Automation Engine (TPAe)  Tivoli Provisioning Manager (TPM)  Tivoli Service Request Manager (SRM)TSAM si colloca nel filone dei prodotti attinenti al Service Management. Tutti i prodottidi Service Management di IBM sono costruiti sopra a Tivoli Process Automation Engine(TPAe), che funge da piattaforma comune che fornisce una serie di servizi di base. 36
  42. 42. Figura 3.1: Architettura di TSAMCome si può osservare dalla Figura 3.1, in quanto applicazione di Service Management,TSAM si basa su TPAe e, per automatizzare la gestione di servizi IT, implementa un datamodel, una serie di workflow e di applicazioni che sono collettivamente raggruppate sottola “TivSAM Admin User Interface”.SRM è il componente che si occupa di gestire le richieste di servizi (in particolare, il de-ploy e l’undeploy di server virtuali). Grazie a SRM, le complesse funzionalità di ServiceManagement fornite da TSAM sono presentate agli utenti nella forma astratta di service of-ferings, ossia come servizi che possono essere richiesti dagli utenti attraverso l’OfferingCatalog di SRM.Sia TSAM che SRM mettono a disposizione delle API che consentono di implementareclient di terze parti per accedere alle funzionalità di service management di TSAM. Essesono accessibili tramite il framework Maximo Enterprise Adapter (MEA), che fornisceanche un’interfaccia REST. Tutto ciò è sfruttato dall’interfaccia web 2.0 di self service perrealizzare un’ulteriore astrazione rispetto a SRM (vedi Figura 3.2). 37
  43. 43. Figura 3.2: Come TSAM espone i servizi agli utenti finaliInfine, per soddisfare le richieste di servizi, TSAM sfrutta TPM (vedi paragrafo 2.2.2), cheè il componente che esegue fisicamente le operazioni di deploy e undeploy sull’ambientegestito.Abbiamo detto che TSAM è una soluzione altamente personalizzabile. I punti di estensionesono cinque (vedi Figura 3.3) [20]: 1. Le Service Definition della TivSAM Admin User Interface; 2. I provisioning workflow di TPM; 3. Le service offering contenute all’interno dell’Offering Catalog di SRM; 4. Gli Offering panel (classi Dojo) dell’interfaccia web 2.0 di self service; 5. Le object structure di MEA, che consentono l’accesso ai Maximo Business Object (MBO).Nella seconda parte di questo lavoro, sfrutteremo i punti 2 e 4 (rispettivamente, nel Capito-lo 6 e nel Capitolo 5) per implementare le personalizzazioni richieste. 38
  44. 44. Figura 3.3: I punti di estensione di TSAM3.3 IBM Service Delivery Manager (v7.2.1)IBM Service Delivery Manager (ISDM) è una soluzione pre-configurata di solo softwareper fare di un ambiente virtualizzato un ambiente cloud. È composto da:  IBM Tivoli Service Automation Manager (TSAM)  IBM Tivoli Usage and Accounting Manager (ITUAM)  IBM Tivoli Monitoring (ITM)Rispetto a TSAM, ISDM comprende anche un sistema di monitoring per l’analisi delleprestazioni (ITM), e un sistema di accounting e tracking dell’utilizzo (ITUAM), che con-sente l’addebitamento dei costi dei servizi ai rispettivi richiedenti.Rispetto a TSAM-ITUAM-ITM presi singolarmente, il valore aggiunto di ISDM sta nellarapidità e facilità di installazione, integrazione e configurazione. Infatti, ISDM si presentacome una serie di immagini virtuali, una per ogni componente, e l’installazione consistesemplicemente nell’importare queste immagini virtuali nell’hypervisor, avviarle, ed infineeseguire un wizard per configurarle. 39
  45. 45. La Figura 3.4 mostra le immagini virtuali che compongono ISDM, con i relativi softwarestack. Figura 3.4: Software stack dei componenti di ISDM.Notiamo che, oltre alle tre immagini per TSAM, ITM e ITUAM, vi è una quarta macchinavirtuale di supporto, che contiene un file repository, un server mail e un servizio di URLredirection. Il file repository memorizza, tra le altre cose, i file binari usati da TSAM per ildeploy degli agenti di monitoring. Il server mail è di supporto al sistema di notifiche diTSAM. Infine, il servizio di URL redirection fa sì che sia sufficiente un solo IP per colle-garsi alle interfacce utente di tutti i componenti di ISDM.Su macchine IBM System x esistono poi due altre immagini che è possibile opzionalmenteavviare per abilitare le funzionalità di High Availability (vedi paragrafo 2.1.3.3, pagina28). 40
  46. 46. Figura 3.5: Le relazioni tra le varie immagini di ISDMIn Figura 3.5 vediamo le relazioni esistenti tra le VM che compongono ISDM [21]. 1. TSAM e ITUAM sono in relazione biunivoca:  ITUAM importa da TSAM i dati per il chargeback  TSAM si collega a ITUAM per generare i report 2. L’agente di monitoring di ITM risiedente su TSAM invia i dati sull’utilizzo (es: quanto tempo è stata accesa una VM) al server ITM 3. Tra TSAM e NFS (la VM di supporto) vi è una relazione biunivoca:  TSAM, nel momento in cui riceve una richiesta per il provisioning di un servizio, prende i file binari necessari dal repository presente su NFS  NFS fa il redirect delle interfacce utente di TSAM e di TPM verso l’IP di TSAM 4. L’agente di monitoring che gira su ITUAM invia dati al server ITM 5. NFS fa il redirect dell’interfaccia utente di ITUAM verso il suo IP 6. L’agente di monitoring che gira su NFS invia dati al server ITM 41
  47. 47. Inoltre, in una configurazione che prevede l’High Availability, vi sono anche le seguentirelazioni: 7. L’agente di monitoring che gira su NFS-HA (la VM di NFS che gestisce l’High Availability) invia dati al server ITM 8. Tivoli System Automation23 necessita di scambiare continuamente dati tra NFS e NFS-HA, per gestire prontamente le situazioni di failover 9. L’agente di monitoring che gira su TSAM-HA (la VM di TSAM che gestisce l’High Availability) invia dati al server ITM 10. Tivoli System Automation23 necessita di scambiare continuamente dati tra TSAM e TSAM-HA, per gestire prontamente le situazioni di failoverRiguardo agli ambienti di virtualizzazione supportati da ISDM su System x, tra gli hyper-visor troviamo tutti quelli che abbiamo analizzato nel paragrafo 2.1.3, ovverosia VMwareESX/ESXi, VMware vCenter Server, VMware vSphere, Xen e KVM. Come sistemi opera-tivi guest, ISDM supporta Red Hat24 Linux, SUSE25 Linux, Microsoft Windows2003/2008/7 e CentOS. Per un approfondimento riguardo alle versioni degli hypervisor edei SO supportati, fare riferimento a [21, p. 23].3.4 IBM Cloud BurstIBM Cloud Burst è un pacchetto all-in-one che comprende sia software (ISDM) che hard-ware (System x o Power Systems). Per la parte software, oltre a ISDM, include anche“IBM Tivoli Monitoring for Energy Management”, un sistema di Energy Management in-tegrato in ITM per ottimizzare i costi operazionali. Per il resto, è del tutto uguale a ISDM.23 IBM Tivoli System Automation è un prodotto IBM che fornisce un ambiente con High Availability.24 Red Hat è un marchio registrato di Red Hat, Inc (http://www.redhat.com).25 SuSE è un marchio registrato di SuSE Linux AG (http://www.suse.com). 42
  48. 48. 43
  49. 49. PARTE II – Pratica 44
  50. 50. 45
  51. 51. Capitolo 4. La nostra soluzione private IaaS4.1 AnalisiImmaginiamo di avere un cliente, che chiameremo C, che ci fornisca i requisiti. C è at-tualmente dotato di un datacenter di medie dimensioni, virtualizzato con VMware vSphere4.1, che vuole convertire in ottica cloud, in modo da snellire le procedure per creare servervirtuali. C ha quindi bisogno di una soluzione di private cloud di tipo IaaS.Al momento, quando un dipendente (che sia egli o ella un sistemista o uno sviluppatore) habisogno di un nuovo server virtuale, deve inoltrare la richiesta all’Application Manager26(AM) di riferimento. Quest’ultimo mette in moto il processo burocratico e tecnico che por-ta alla creazione del server, che consta dei seguenti passaggi (alcuni burocratici, altri tecni-ci): 1. L’AM compila un form su un portale web specificando i requisiti hardware e soft- ware del server di cui ha bisogno, quali: virtual hardware, sistema operativo, soft- ware necessari, tipologia di monitoraggio, tipologia di backup; 2. La richiesta viene inoltrata ad un Chief Technical Officer27 (CTO), che ne decide la liceità; 3. Se approvata, la richiesta viene inoltrata ai tecnici VMware che creano una nuova VM con il sistema operativo richiesto; 4. Dell’installazione del software se ne occupano i gestori middleware. Ad esempio, se la richiesta comprende WebSphere e Oracle, essa viene inoltrata a: a. Sistemista WebSphere; b. Sistemista Oracle;26 Application Manager (AM) è la figura che coordina le attività per una certa applicazione, a cui gli utenti(tra gli altri) si devono rivolgere per ogni problema che incontrano nell’utilizzare quell’applicazione.27 Il Chief Technical Officer (CTO) è un manager di primo livello e membro del direttivo di un’azienda lacui responsabilità principale è monitorare, valutare, selezionare e suggerire al consiglio direttivo e al CEO letecnologie che possono essere applicate ai prodotti o ai servizi che una azienda produce. 46
  52. 52. c. System integrator per l’integrazione di WebSphere e Oracle; 5. I tecnici del reparto networking si occupano della validazione della VM sulla rete più appropriata; 6. Infine, in un contesto business critical, la richiesta passa al reparto che gestisce la sicurezza per la validazione del tutto.Il risultato di questo processo è che i tempi per creare un server virtuale sono piuttosto lun-ghi: infatti, ognuno dei passaggi mostrati sopra può richiedere da alcuni giorni ad alcunesettimane per essere completato.Per superare queste difficoltà e lungaggini, l’ambiente cloud deve presentareun’interfaccia user-friendly da cui sia possibile creare server virtuali senza avere alcunaconoscenza di virtualizzazione, né di automazione, né tantomeno sapere quale hypervisor èusato, e come si pilota. Questa interfaccia deve poter essere usata da tutti i dipendenti di C,ma solo agli Application Manager devono essere concessi i permessi per creare server vir-tuali, il cui deploy deve avvenire non prima che sia stata data l’approvazione da parte diun CTO. Inoltre, gli utenti devono poter essere raggruppati in team, in modo che i servercreati da un AM siano condivisi solo tra i componenti del suo gruppo di lavoro. Tutto ciòpermette da una parte di superare le difficoltà e le lungaggini dovute ai passaggi di caratte-re tecnico, dall’altra consente di preservare, e nello stesso tempo velocizzare, i passaggiburocratici, che sono comunque necessari per una corretta gestione formale di una qualun-que organizzazione.C vuole che i server virtuali che si possono creare via cloud abbiano come sistema operati-vo Windows Server 2008 o Red Hat Enterprise Linux 5.6, in funzione delle esigenzedell’utente che li crea. Inoltre, siccome la maggior parte delle applicazioni esistenti usa undatabase MySQL come meccanismo di persistenza, C vuole che il sistema permettaall’utente di scegliere se il server da creare debba essere equipaggiato del solo sistema ope-rativo, o se ci deve essere anche installato MySQL Server e/o MySQL Client (sia suWindows che su RHEL).Se da un lato, con l’adozione del cloud, si vuole semplificare e rendere trasparente il pro-cesso di deploy di server virtuali, dall’altro C è consapevole del fatto che ogni server creatoha un costo in termini di risorse (che non sono infinite), perciò vuole che il sistema inviiperiodicamente agli amministratori dell’ambiente cloud e ai CTO un report di utilizzosuddiviso per team. Questo gli consente di fare la cosiddetta Capacity Planning: cioè, tene- 47
  53. 53. re sotto controllo l’ambiente, capire quali sono i livelli di utilizzo dell’infrastruttura, e pia-nificare la capacità (in termini di risorse hardware) che sarà necessario supportare in futu-ro.In quest’ottica, C vuole iniziare ad introdurre nell’ambiente cloud il chargeback. Inizial-mente, vuole solo che l’interfaccia da cui vengono creati i server mostri un preventivo deicosti, in modo da far familiarizzare l’utente con il concetto di chargeback. Nello specifico,il preventivo deve includere: i costi orari per un singolo server equipaggiato con le risorseselezionate; il costo mensile per tutti i server richiesti; infine, i costi per tutti i server ri-chiesti, per il periodo specificato dall’utente. Deve inoltre mostrare il dettaglio dei costiparziali per ogni tipo di risorsa (CPU, memoria, spazio disco, licenza del sistema operati-vo). Il preventivo deve essere dinamico, nel senso che si deve aggiornare automaticamenteogni volta che l’utente modifica la quantità di una risorsa: così, egli ha la possibilità di ca-librare la configurazione hardware e software dei server in modo da massimizzare il rap-porto qualità/prezzo, se lo ritiene opportuno.4.2 ProgettazionePer soddisfare le esigenze del nostro cliente ipotetico, costruiremo una soluzione basandocisu IBM Service Delivery Manager (ISDM) v7.2.1. Come abbiamo visto nel paragrafo 3.3,ISDM è un prodotto software pre-configurato di private cloud di tipo IaaS. Con la sola in-stallazione di ISDM, otteniamo un ambiente cloud private IaaS perfettamente funzionante.Il requisito relativo all’interfaccia user-friendly viene gratuitamente soddisfatto da ISDM,che, attraverso TSAM, è equipaggiato della Self Service Station (vedi paragrafo 3.2).Quest’ultima soddisfa da sola anche altri requisiti, come quelli relativi ai permessi e allapossibilità di organizzare gli utenti in team. Infatti, la Self Service Station è dotata di un si-stema di gestione degli utenti che definisce quattro ruoli distinti [19, p. 2]:  Cloud administrator: amministratore dell’intero sistema cloud; ha pieni poteri, e in particolare è l’unico che può eseguire i seguenti compiti: o creare nuovi team e nuovi utenti; o modificare le proprie informazioni; o registrare e de-registrare immagini software; 48
  54. 54. o permettere l’allocazione di risorse; o controllare lo stato dei progetti e monitorare i server di tutti gli utenti; o approvare o negare le richieste di provisioning fatte dai team administrator.  Cloud manager: amministratore in modalità read-only; può: o modificare le proprie informazioni (eccetto il ruolo e il team di appartenen- za); o controllare lo stato dei progetti e monitorare i server di tutti gli utenti.  Team administrator: amministra uno o più team; può: o creare nuovi account per altri utenti; o modificare le proprie informazioni (eccetto il ruolo e il team a cui appartie- ne); o fare richieste per il provisioning di server e controllare lo stato dei progetti creati; o monitorare i server richiesti; o modificare lo stato o la password di un server; o usare i server richiesti.  Team user: utente generico; può: o modificare le proprie informazioni (eccetto il ruolo e il team a cui appartie- ne); o visualizzare i progetti creati per il proprio team; o controllare lo stato dei server creati per il proprio team; o usare i server creati per il proprio team.In particolare, a noi interessano i ruoli Team administrator e Team user: i Team admini-strator saranno gli Application Manager che devono poter creare nuovi server virtualiall’interno di “progetti” (seguendo la terminologia di TSAM); i Team user saranno i com-ponenti del gruppo di lavoro degli AM, aventi il compito di amministrare quei server o diusarli come ambienti di sviluppo usa e getta.Un altro requisito soddisfatto dalla Self Service Station è l’approvazione da parte di unmanager delle richieste di deploy prima che vengano effettivamente processate. Siccome didefault tutte le richieste sono auto-approvate; l’implementazione di questo requisito richie-de l’esecuzione alcuni passi di configurazione. Una volta eseguiti, le richieste dovrannoprima essere approvate da un utente con ruolo Cloud administrator, che quindi faremocoincidere con un CTO. 49

×