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

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 IBM

Relatore:

PROF. FRANCESCO BERGADANO

Candidato:

ALBERTO SCOTTO

II

A Stefania,

Ai miei genitori,

Ai miei nonni Argene e Franco.

III

Indice

RINGRAZIAMENTI .......................................................................................................................................... V

INTRODUZIONE .............................................................................................................................................. 1

PARTE 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

IV

3.3 IBM Service Delivery Manager (v7.2.1) ...................................................................................... 39

3.4 IBM Cloud Burst .......................................................................................................................... 42

PARTE 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

V

Ringraziamenti

Desidero 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?

1

Introduzione

Il 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, a

partire 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ù o

meno 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 tesi

Vediamo maggiormente nel dettaglio come si articola il lavoro.

Nel Capitolo 1 vengono introdotti i principali concetti relativi al cloud computing. Si parte

dall’analizzare le definizioni più autorevoli che finora sono state date, ed integrandole si

2 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 il

soprannome 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).

2

giunge ad una definizione comune. Si prosegue poi definendo le caratteristiche principali

del cloud computing: anche in questo caso, analizzando prima alcune tra le teorizzazioni

più 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, ma

molto 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 presenti

sul 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 Tivoli

Service Automation Manager (TSAM) e IBM Service Delivery Manager (ISDM).

Con il Capitolo 4 inizia la seconda parte, quella pratica. In questo capitolo viene introdotta

l’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 personalizzazioni

più avanzate.

Nel Capitolo 5 si implementano i requisiti relativi all’automazione del provisioning di

MySQL Server e Client. Ciò implica lo studio di alcune nozioni di TPM che consentano di

sviluppare i provisioning workflow necessari a soddisfare i requisiti.

Il Capitolo 6 è dedicato alla personalizzazione dell’interfaccia web 2.0 di TSAM, dalla

quale vengono creati i server virtuali. Dopo uno studio approfondito dell’implementazione

dell’interfaccia, limitatamente alla parte che permette la creazione di un nuovo progetto di

server virtuali, si discute come può essere implementata una tabella che mostri all’utente

un 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.

4

PARTE I - Teoria sul cloud computing

6

Capitolo 1. Il cloud computing

1.1 Definizioni

Dietro l’espressione “Cloud computing” vi è un modello computazionale che si è evoluto

nei decenni a partire dagli anni ’60, quando John McCarthy affermò che “computing may

someday 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 con

B, era necessario che un operatore collegasse fisicamente i due capi del telefono. Ciò non

era molto scalabile né economico, ed era inoltre facile commettere errori. Oggi, grazie agli

switch, 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 la

qualità del prodotto e nel contempo di abbassare i costi, facendo dell’automobile un bene

di massa.

4 Citazione tratta dalla conferenza che John McCarthy tenne durante il centenario del MIT nel 1961.

7

Riguardo al settore bancario, una volta, se non riuscivi ad arrivare in banca prima dell’ora

di 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 a

qualunque 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 Nuvola

Infatti, nel cloud computing vengono nascosti i dettagli dell’architettura e

dell’infrastruttura che c’è dietro, mentre ciò che viene esposto all’esterno è unicamente il

concetto 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 un

certo software, all’utilizzo di un intero server (virtuale).

Cloud computing è un mix di vari modelli computazionali, con i quali viene spesso confu-

so, quali:

8

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 dell'intervento 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 e

dell’autonomic computing.

1.1.1 NIST

La 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 nella

tecnologia. 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 agenzie

governative un adeguato livello di sicurezza delle informazioni.

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

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.

9

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 Gartner

Gartner6 è una multinazionale, leader mondiale in ricerca e consulenza informatica. In [2],

Gartner definisce il cloud computing come:

In 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 Cisco

Cisco7 Systems è una multinazionale leader nella progettazione e nella vendita di apparati

di networking, dai router ai telefoni VoIP. In [3], Cisco definisce il cloud computing come:

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).

a style of computing where massively scalable IT-enabled capabilities are

delivered “as a service” to external customers using Internet technologies

IT resources and services that are abstracted from the underlying infrastruc-

ture and provided “on-demand” and “at scale” in a multitenant environment.

10

Ambiente multitenant

Osserviamo che quattro su cinque di queste parole chiavi le abbiamo già incontrate nelle

definizioni precedenti. L’unica espressione nuova è ambiente multitenant, che indica che

una singola “istanza” cloud fornisce risorse a molti utenti, facendo sì che il cloud provider

ottenga dei notevoli risparmi.

1.1.4 La nostra definizione

Dopo questa carrellata di definizioni, possiamo quindi definire il cloud computing come un

paradigma 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 cloud

9);

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 principali

Vediamo ora meglio quali sono gli elementi che caratterizzano una qualunque soluzione di

cloud computing. Come per le definizioni, anche per quanto riguarda le caratteristiche non

esiste un’unica teorizzazione, ma diverse. Procediamo quindi ad analizzare le più impor-

tanti, e alla fine cercheremo di ricavarne una sintesi.

1.2.1 NIST

In [1], il NIST affronta la questione da un punto di vista leggermente tecnico, e identifica

le seguenti caratteristiche essenziali:

8 Come vedremo nel paragrafo 1.3.1.1, il private cloud è un cloud locato e gestito internamente

all’organizzazione che lo utilizza 9 Al contrario del private cloud, il public cloud è locato e gestito esternamente all’organizzazione che lo uti-

lizza (vedi par. 1.3.1.2)

11

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 IBM

Al 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] è un

documento destinato ai partner commerciali di IBM, che hanno il compito di vendere i suoi

prodotti cloud.

Dunque, IBM identifica le seguenti cinque caratteristiche che dovrebbero essere comuni a

qualunque 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).

12

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 Sintesi

In 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 verso

l’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 permetta

all’utente di richiedere un servizio quando ne ha bisogno, in modo rapido e semplice.

1.3 Tassonomia, sugli assi cartesiani

Esistono diversi modelli di cloud computing. Li possiamo distinguere in base a due criteri

fondamentali:

a. Il luogo dove risiedono fisicamente i dati

b. Le tipologie di servizi offerti

Se immaginiamo di mettere questi due criteri sugli assi cartesiani, facendone il prodotto

cartesiano otteniamo i principali modelli di cloud esistenti. I “principali” e non “tutti” per-

13

ché, come è già stato detto, il cloud computing è una branca dell’informatica ancora in

evoluzione. 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 di

cloud (anche detti cloud deployment models) [1]:

Public

Private

Hybrid

Community

Figura 1.2: Cloud deployment models

1.3.1.1 Private cloud

Come dice la parola stessa, nel private cloud l'infrastruttura è utilizzata esclusivamente da

una sola organizzazione. Come mostrato in Figura 1.3, può essere gestita dall'organizza-

zione stessa oppure da terzi (managed private cloud); inoltre può risiedere all’interno dei

locali dell’organizzazione (on premise) o essere ospitata nei locali di terzi (off premise, ho-

sted private cloud).

14

Figura 1.3: Tipologie di Private Cloud

1.3.1.2 Public cloud

Diametralmente opposto al private, nel public l'infrastruttura cloud è messa a disposizione

di chiunque voglia usufruirne, dal privato cittadino al grande gruppo industriale, ed è di

proprietà di un'organizzazione che vende servizi cloud (i.e. il “cloud provider”).

1.3.1.3 Community cloud

L’infrastruttura cloud è condivisa tra organizzazioni diverse, facenti però tutte parte di una

stessa “comunità” con dei valori comuni (es: la mission, le policy, ecc.). Come nel caso

private, 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 cloud

Nell’hybrid, l’architettura cloud è composta da due o più cloud (ad es. una private e una

public) 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)

15

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’utente

sull’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 modo

per indicare le infinite possibilità (in termini di servizi) che il cloud computing è in grado

di offrire. Parafrasando, “XaaS” significa che “qualunque cosa può essere offerta come un

servizio”.

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 cloud

computing. Una semplice definizione di SaaS è la seguente [5]:

In [1], il NIST dà una definizione più completa:

Software deployed as a hosted service and accessed over the Internet.

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.

16

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 svantaggi

Come indicato in [6], in confronto al tradizionale modello di distribuzione del software che

prevedeva l’installazione da CD (o da altre fonti) sulla propria macchina, il modello SaaS

apporta alcuni benefici per l’utente, dal momento che, grazie alla centralizzazione, oneri

che prima erano in carico all’utente, ora sono spostati a carico del cloud provider. D’altra

parte, 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.

17

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 Docs

Un 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 una

per disegnare. In questo caso, il cloud provider (i.e. Google) ha scelto di rendere il suo

SaaS fruibile a chiunque, senza alcun costo.

11 Google è un marchio registrato di proprietà di Google Inc. (http://www.google.com)

18

1.3.2.2 Platform as a Service, o “PaaS”

Di seguito riportiamo la definizione di PaaS data dal NIST [1]:

Essenzialmente, i cloud PaaS forniscono piattaforme di sviluppo software costituite da

framework e da ambienti run-time: i primi supportano lo sviluppo vero e proprio, i secondi

permettono di eseguire, e quindi anche di testare, il software sviluppato. Gli utenti PaaS

sono quindi non solo gli sviluppatori di software, ma anche gli utenti finali che usano quel

software sviluppato. Una tipica offerta PaaS si presenta agli utenti sviluppatori in forma di

API.


Seguendo [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 della

piattaforma. Inoltre, i framework PaaS forniscono di solito dei design pattern che aiutano

gli 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.

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.

19

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 Engine

Google App Engine è l’offerta PaaS di Google, una piattaforma che permette lo sviluppo

di applicazioni web e l’hosting delle stesse presso i data center di Google. Tali applicazioni

possono così beneficiare di un alto grado di scalabilità, lo stesso di cui gode ognuna delle

Google apps. Al momento, i linguaggi di programmazione supportati sono Java12

, Python e

Go13

. 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. Il

livello 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]:

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.

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).

20


Seguendo [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 i

viaggi di lavoro, o anche processi IT quale il processo del test del software. Richiedere il

processo 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 svantaggi

I 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;

21

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 punto

di vista fisico; la sicurezza dei dati (quelli che sono memorizzati nel datacenter, ma anche

quelli 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. Il

problema 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 Richard

Stallman, 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 le

vostre 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 di

migrare i dati da un provider ad un altro (portabilità) e la difficoltà ad integrare insieme

22

più ambienti cloud di provider differenti (interoperabilità). Ciò è causato dalla mancata

adozione 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 e

del 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 un

paese. 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

23

Capitolo 2. Principali tecnologie cloud

2.1 Virtualizzazione

Il 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 sola

macchina fisica vengono eseguite molte macchine virtuali (dette anche VM, come “virtual

machine”): in questo caso, possiamo notare che abbiamo una relazione uno-molti. Ma, al

contrario, è possibile anche virtualizzare più risorse per farle sembrare una sola: trattasi del

pooling delle risorse, concetto cui abbiamo già accennato nel Capitolo 1.

2.1.1 Tecniche di virtualizzazione

In letteratura sono definite molte tipologie di virtualizzazione. Per citarne alcune: hardware

virtualization, 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 il

cloud 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 di

creare 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. Il

sistema software che si occupa dell’inserimento del livello di astrazione è chiamato hyper-

24

visor o Virtual Machine Monitor (VMM). Il sistema operativo virtuale viene detto guest

OS, mentre il sistema operativo che contiene l’hypervisor viene anche detto host.

2.1.1.1 Full virtualization

La tecnica di virtualizzazione di tipo full prevede che l’hardware sia interamente simulato

dall’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 virtualization

Per supportare a livello hardware la virtualizzazione (di tipo full in particolare), Intel15

e

AMD16

hanno rispettivamente introdotto le tecnologie Intel VT e AMD-V, che estendono

l’instruction set della CPU. Tale approccio permette di minimizzare l’overhead dovuto

all’hypervisor; presenta però lo svantaggio di non funzionare con tutte le CPU, e di essere

inoltre causa di overhead a livello del processore.

2.1.1.2 Paravirtualization

Mentre 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 a

esporre al guest OS un’interfaccia applicativa, chiamata “virtual hardware API”. Poi, nel

guest, ogni system call che accede ad una risorsa hardware dovrà essere sostituita con una

cosiddetta 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 Hypervisor

Esistono 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 e

l’hardware, il tipo 1 è quello che raggiunge le migliori performance. Il tipo 2 può essere

15 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).

25

preferibile quando è richiesto supporto per molti dispositivi di I/O, che un normale sistema

operativo host è in grado di fornire.

2.1.2 Vantaggi e svantaggi

Si stima che un moderno server sia sfruttato solo per il 15-20% delle sue capacità. Con la

virtualizzazione è possibile avere due o più server virtuali su una sola macchina fisica: di

conseguenza, 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 un

risparmio nei consumi energetici e nei costi di gestione e manutenzione dei server (ad es. i

costi per la sostituzione di periferiche guaste).

Un altro importante aspetto positivo è l’isolamento: ogni macchina virtuale è un ambiente

a sé stante, isolato rispetto alle altre VM. Questa caratteristica giova alla sicurezza, in

quanto 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 è possibile

spostare una macchina virtuale da un computer all’altro (portabilità), senza badare

all’hardware sottostante. È il caso di rilevare che questo punto viene meno se parliamo di

hardware-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 caso

di periferiche non virtualizzabili (accelerazioni grafiche comprese) [11].

2.1.3 Stato dell’arte

In questo paragrafo vedremo i principali hypervisor enterprise supportati dal Service Deli-

very Manager, il prodotto cloud di IBM che useremo nella nostra soluzione private (vedi

Parte II).

2.1.3.1 Xen

Xen è un hypervisor open source di tipo 1 che permette la virtualizzazione sui processori

x86, 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).

26

gie, implementa in primo luogo la paravirtualizzazione; invece, per i sistemi operativi non

paravirtualizzabili (ad esempio Windows), Xen sfrutta le funzioni di virtualizzazione mes-

se a disposizione dalla CPU (hardware-assisted virtualization, o, secondo la terminologia

Xen, “hardware virtual machine”).

2.1.3.2 KVM

KVM (acronimo di “Kernel-based Virtual Machine”) è una soluzione open source di full

virtualization 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 fornisce

l’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 che

KVM è un modulo del kernel Linux (infatti si chiama “Kernel-based”), mentre Xen è un

hypervisor esterno al kernel [13]. In questo modo, KVM è in grado di utilizzare tutti gli

strumenti 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 confronto

18 Linux è un marchio registrato di Linus Torvalds (http://www.linuxfoundation.org).

19 Solaris è un marchio registrato di Oracle Corporation.

27

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 datacenter

in un'infrastruttura cloud in cui sia possibile fornire servizi IT in modo flessibile e, nello

stesso 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: l'insieme 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 compongono

vSphere: 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. il

vCenter 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).

28

VMware ESX e ESXi

ESX 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 di

VMware 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 Server

vCenter Server consente di gestire un datacenter in modo centralizzato, aggregando risorse

fisiche provenienti da varie ESX/ESXi.

Figura 2.2: Infrastruttura con VMware vCenter Server

Con 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-

29

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 Automazione

Dopo la virtualizzazione, l’automazione rappresenta il secondo step verso l’acquisizione di

un ambiente cloud.

In un’infrastruttura virtuale, l’amministrazione è una grande sfida. Se costruita senza un

adeguato 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 sopra

l’hypevisor, che continua a fare il suo lavoro, c’è un livello in più rappresentato dal sistema

di 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 ambiente

cloud dove i bisogni possono continuamente cambiare, e l’IT deve essere in grado di stare

al passo.

30

2.2.1 Automazione del provisioning

In un datacenter, l’automazione è utile principalmente in due ambiti: per l’onboarding e

per 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 rendono

nuovamente 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 il

sistema 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 console

web 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 deploy

di 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 e

strumenti 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 dispositivi

quali 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 un

ambiente di sviluppo ad hoc basato su Eclipse chiamato Automation Package Developer

Environment (APDE), che permette di creare o personalizzare gli automation package e i

provisioning workflow.

21 Tivoli è un marchio registrato da International Business Machines Corporation

(www.ibm.com/software/tivoli/)

31

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

32

Il data model è il componente che fornisce una rappresentazione di tutte le risorse fisiche

e 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. Queste

informazioni possono includere gli identificativi del computer, la dimensione del pool di

risorse, 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 provisioning

workflow, 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 Definizione

Come 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 far

comunicare e lavorare insieme in modo flessibile e disaccoppiato. Un servizio non solo

può 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”)

33

È 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 tre

attori:

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 intraprendere

In sintesi: il provider può pubblicare un servizio presso il broker; il requester può cercare

un servizio presso il broker e può poi fruirne interagendo direttamente con il provider.

34

2.3.2 SOA e il cloud computing

Nel cloud computing, intere infrastrutture IT virtuali, piattaforme e applicazioni sono im-

plementati come servizi e resi disponibili in architetture service-oriented. Abbiamo infatti

visto 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 web

e interfacce standard, come quelle definite dai web services e dai RESTful services.

35

Capitolo 3. Stato dell’arte IBM “private IaaS”

3.1 Offerta “private IaaS” IBM

Poiché 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 i

prodotti di cloud computing commercializzati da IBM, limitatamente all’ambito private

IaaS. L’offerta IBM comprende i seguenti tre prodotti, dal più personalizzabile a quello

maggiormente pre-configurato:

IBM Tivoli Service Automation Manager

IBM Service Delivery Manager

IBM Cloud Burst

3.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 hypervisor

supportati su System x22

sono VMware, Xen e KVM. TSAM fornisce i servizi essenziali

per il cloud, in particolare l’automazione del deploy di interi panorami IT, comprensivi di

server, 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. Il

self service (anche chiamata Self Service Station) è un’interfaccia web 2.0 dedicata agli

utenti 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 il

sistema è 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.

36

che una parte amministrativa, in cui gli utenti con ruolo “cloud administrator”, tra le altre

cose, 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 al

pool di risorse gestite da TSAM, la creazione o la personalizzazione dei report, l’aggiunta

di 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 prodotti

di 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.

37

Figura 3.1: Architettura di TSAM

Come 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 data

model, una serie di workflow e di applicazioni che sono collettivamente raggruppate sotto

la “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 Service

Management 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’Offering

Catalog di SRM.

Sia TSAM che SRM mettono a disposizione delle API che consentono di implementare

client di terze parti per accedere alle funzionalità di service management di TSAM. Esse

sono accessibili tramite il framework Maximo Enterprise Adapter (MEA), che fornisce

anche un’interfaccia REST. Tutto ciò è sfruttato dall’interfaccia web 2.0 di self service per

realizzare un’ulteriore astrazione rispetto a SRM (vedi Figura 3.2).

38

Figura 3.2: Come TSAM espone i servizi agli utenti finali

Infine, 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’ambiente

gestito.

Abbiamo detto che TSAM è una soluzione altamente personalizzabile. I punti di estensione

sono 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.

39

Figura 3.3: I punti di estensione di TSAM

3.3 IBM Service Delivery Manager (v7.2.1)

IBM Service Delivery Manager (ISDM) è una soluzione pre-configurata di solo software

per 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 delle

prestazioni (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 nella

rapidità e facilità di installazione, integrazione e configurazione. Infatti, ISDM si presenta

come una serie di immagini virtuali, una per ogni componente, e l’installazione consiste

semplicemente nell’importare queste immagini virtuali nell’hypervisor, avviarle, ed infine

eseguire un wizard per configurarle.

40

La Figura 3.4 mostra le immagini virtuali che compongono ISDM, con i relativi software

stack.

Figura 3.4: Software stack dei componenti di ISDM.

Notiamo che, oltre alle tre immagini per TSAM, ITM e ITUAM, vi è una quarta macchina

virtuale di supporto, che contiene un file repository, un server mail e un servizio di URL

redirection. Il file repository memorizza, tra le altre cose, i file binari usati da TSAM per il

deploy degli agenti di monitoring. Il server mail è di supporto al sistema di notifiche di

TSAM. 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 opzionalmente

avviare per abilitare le funzionalità di High Availability (vedi paragrafo 2.1.3.3, pagina

28).

41

Figura 3.5: Le relazioni tra le varie immagini di ISDM

In 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

42

Inoltre, in una configurazione che prevede l’High Availability, vi sono anche le seguenti

relazioni:

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 failover

Riguardo 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 VMware

ESX/ESXi, VMware vCenter Server, VMware vSphere, Xen e KVM. Come sistemi opera-

tivi guest, ISDM supporta Red Hat24

Linux, SUSE25

Linux, Microsoft Windows

2003/2008/7 e CentOS. Per un approfondimento riguardo alle versioni degli hypervisor e

dei SO supportati, fare riferimento a [21, p. 23].

3.4 IBM Cloud Burst

IBM 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).

44

PARTE II – Pratica

46

Capitolo 4. La nostra soluzione private IaaS

4.1 Analisi

Immaginiamo 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 vSphere

4.1, che vuole convertire in ottica cloud, in modo da snellire le procedure per creare server

virtuali. 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) ha

bisogno 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 la

cui responsabilità principale è monitorare, valutare, selezionare e suggerire al consiglio direttivo e al CEO le

tecnologie che possono essere applicate ai prodotti o ai servizi che una azienda produce.

47

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 alcune

settimane per essere completato.

Per superare queste difficoltà e lungaggini, l’ambiente cloud deve presentare

un’interfaccia user-friendly da cui sia possibile creare server virtuali senza avere alcuna

conoscenza 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 di

un CTO. Inoltre, gli utenti devono poter essere raggruppati in team, in modo che i server

creati 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 passaggi

burocratici, 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 esigenze

dell’utente che li crea. Inoltre, siccome la maggior parte delle applicazioni esistenti usa un

database MySQL come meccanismo di persistenza, C vuole che il sistema permetta

all’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 su

Windows 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 creato

ha un costo in termini di risorse (che non sono infinite), perciò vuole che il sistema invii

periodicamente agli amministratori dell’ambiente cloud e ai CTO un report di utilizzo

suddiviso per team. Questo gli consente di fare la cosiddetta Capacity Planning: cioè, tene-

48

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 dei

costi, 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 risorse

selezionate; 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 costi

parziali 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 automaticamente

ogni 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 Progettazione

Per soddisfare le esigenze del nostro cliente ipotetico, costruiremo una soluzione basandoci

su 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 alla

possibilità 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;

49

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 virtuali

all’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 di

usarli come ambienti di sviluppo usa e getta.

Un altro requisito soddisfatto dalla Self Service Station è l’approvazione da parte di un

manager delle richieste di deploy prima che vengano effettivamente processate. Siccome di

default tutte le richieste sono auto-approvate; l’implementazione di questo requisito richie-

de l’esecuzione alcuni passi di configurazione. Una volta eseguiti, le richieste dovranno

prima essere approvate da un utente con ruolo Cloud administrator, che quindi faremo

coincidere con un CTO.

50

Per quanto riguarda i requisiti relativi ai sistemi operativi, invece, per implementarli do-

vremo creare manualmente delle immagini VMware, e poi importarle in TSAM.

Per fare in modo che il sistema sia in grado di installare MySQL sui server virtuali, dovre-

mo studiare e configurare l’automazione del provisioning in TPM.

I report di utilizzo sono già predefiniti in TSAM.

Infine, per implementare il preventivo, dovremo studiare e modificare il codice della Self

Service Station.

4.3 Implementazione

L’implementazione consta di tre fasi. Nella prima si installa il prodotto IBM, nella seconda

lo si configura, e, infine, nella terza lo si personalizza.

4.3.1 Installazione di ISDM

La procedura di installazione di ISDM si articola nei seguenti passi, come indicato nella

guida IBM [21]:

1. Creare un file di configurazione XML per ogni immagine virtuale che compone

ISDM (ovvero: TSAM, ITM, ITUAM e NFS);

2. Importare le immagini virtuali nell’hypervisor;

3. Avviare le macchine virtuali.

Per il punto 1, ISDM fornisce un wizard che semplifica notevolmente la configurazione di

tutti i componenti (vedi Figura 4.1). L’output di questo step è costituito da quattro file

XML, uno per ogni immagine virtuale, che rappresentano gli OVF environment28

. Dopodi-

ché, si importano le immagini nell’hypervisor. Prima di avviarle, però, bisogna creare per

ogni immagine una ISO contenente il corrispondente file OVF environment, e montarla sul

lettore CD/DVD della macchina virtuale. Infine, avviando una dopo l’altra le macchine vir-

28 Open Virtualization Format (OVF) è uno standard aperto per la creazione e la distribuzione di applica-

zioni virtuali o più comunemente di software che possa essere eseguito su macchine virtuali. Un OVF envi-

ronment definisce alcune configurazioni della VM, come ad esempio le impostazioni IP (indirizzo IP, net-

mask, gateway, DNS, e così via), oppure la localizzazione dei server SNMP, ecc.

(fonte: http://blogs.vmware.com/vapp/2009/07/selfconfiguration-and-the-ovf-environment.html)

51

tuali, vengono caricati i file xml e le macchine vengono così automaticamente configurate.

Come passaggio ulteriore, è opportuno smontare le ISO dai lettori CD/DVD delle VM.

Figura 4.1: Una schermata del wizard di configurazione di ISDM

4.3.2 ConfigurazionI di base di ISDM

Tutte le configurazioni e i passaggi descritti in questa sezione sono tratti dalle guide IBM,

in particolare da [21].

4.3.2.1 Configurazione dell’ambiente cloud

Dopo aver installato e avviato tutte le immagini che compongono ISDM, è necessario

compiere alcuni passaggi per configurare l’ambiente cloud. Innanzitutto, bisogna configu-

rare TSAM affinché si possa collegare con l’hypervisor: a tale scopo, bisogna personaliz-

zare il file DCM.xml (il che implica ad es. definire i range di IP della subnetwork che non

devono essere usati per il deploy delle VM dal self service) e importarlo in TPM. Poi, bi-

sogna importare il certificato SSL del vCenter in TPM, nel truststore della JRE. Successi-

vamente, bisogna definire e configurare il Cloud pool attraverso la personalizzazione del

file “vrpool.properties”, e importarlo in TSAM; al termine di questi passaggi, bisogna con-

validare il Cloud pool.

52

4.3.2.2 Configurazione del sistema di email di notifica

Il sistema di email di notifica di TSAM fa parte della Self Service Station. Ogni volta che

nel self service viene eseguita un’operazione relativa ai server virtuali, il sistema di notifica

invia una email agli utenti interessati dall’operazione. Ad esempio, quando viene creato un

nuovo progetto di server virtuali, il sistema, dopo aver eseguito il deploy dei server richie-

sti, invia la password dell’utente Administrator o root (a seconda che il server sia Windows

o Linux, rispettivamente) a tutti gli utenti facenti parte del team per il quale i server sono

stati creati.

La configurazione del sistema di notifica consiste nel configurare il demone SMTP che si

vuole utilizzare per l’invio delle email. Una configurazione tipica, ad esempio, implica

specificare un host che funga da relay SMTP.

4.3.2.3 Configurazione del sistema di approvazione manuale

Per disabilitare l’approvazione automatica di tutte le richieste bisogna accedere

all’interfaccia amministrativa di TSAM, selezionare Go To, System Configuration, Plat-

form Configuration, System Properties, e modificare il Global Value della proprietà

pmrdp.enable.autoapproval a ‘N’.

4.3.2.4 Creazione di utenti e team

Collegandosi alla Self Service Station come cloud administrator, è possibile creare nuovi

utenti e nuovi team. Per il nostro caso d’uso, creiamo due team, e per ognuno di essi defi-

niamo un team administrator, che potrà creare i server virtuali, e una serie di team user, che

saranno le persone incaricate di amministrare i server o di svilupparci sopra. Inoltre,

creiamo un utente con ruolo cloud administrator per rappresentare il CTO cui saranno inol-

trate le richieste di deploy per essere approvate.

4.3.2.5 Aggiunta di immagini di sistemi operativi per il deploy di server

Per aggiungere un sistema operativo a quelli selezionabili dalla Self Service Station, biso-

gna innanzitutto creare il template VMware con quel SO, se non lo si ha già a disposizione.

A tale scopo, in vCenter si crea una nuova VM vuota, si monta la ISO con il CD o DVD di

installazione del SO, si accende la VM, e si seguono i passaggi per installare il SO (per ap-

profondimenti sui vincoli che devono essere rispettati, diversi da un SO all’altro, vedere

[19], “Creating operating system image templates”, e [22]); infine si spegne la VM e la si

converte in template.

53

Dopodiché, si registra il template nell’inventario di VMware, si carica l’immagine del SO

nel datastore dell’hypervisor, e, infine, si registra il template in TSAM affinché compaia

nel service catalog di SRM e sia quindi selezionabile quando un team administrator vuole

creare un nuovo progetto di server virtuali.

Questi passaggi devono essere ripetuti per ogni sistema operativo che si vuole aggiungere:

nel nostro caso, li eseguiamo per Windows Server 2008 e per RHEL 5.6.

4.3.2.6 Configurazione degli agenti di monitoring

Per implementare il requisito relativo ai report di utilizzo, si deve prima configurare ISDM

affinché sia in grado di installare gli agenti di monitoring sui server virtuali. Questo consi-

ste nell’aggiungere in TPM la software definition dell’agente di monitoring all’interno del

software stack di nome “EsxPoolStack”.

Il risultato è che quando si crea un nuovo server virtuale, il sistema permette di scegliere se

attivare o meno le funzionalità di monitoring sulle nuove VM che si creano.

4.3.3 Personalizzazioni e configurazioni avanzate

Nei prossimi capitoli vedremo come sono state implementate le personalizzazioni più rile-

vanti e interessanti, necessarie per soddisfare i requisiti. In particolare:

L’implementazione del preventivo nella Self Service Station

L’implementazione dell’automazione del provisioning di MySQL

54

Capitolo 5. Automazione: il provisioning di

MySQL per Windows e RHEL

5.1 Nozioni di base

Nel paragrafo 2.2.2 abbiamo già accennato ai provisioning workflow; in questo paragrafo

approfondiamo l’argomento analizzando gli strumenti messi a disposizione da TPM per gli

sviluppatori e studiando i concetti di base relativi all’installazione di software su TPM.

5.1.1 Sviluppo di provisioning workflow

Figura 5.1: Relazioni tra provisioning workflow

55

Un provisioning workflow rappresenta la reale implementazione di uno specifico processo

IT. Come mostrato in Figura 5.1, un workflow non è l’unico elemento coinvolto nel pro-

cesso di automazione del provisioning.

Un device driver, o device model, è un gruppo di provisioning workflow che possono

essere applicati ad un certo asset IT. Un device driver mappa i workflow specifici di un

certo asset nei comandi generici associati (le logical management operation).

Proprio come Java ha un potente meccanismo di programmazione quale quello delle inter-

facce, anche TPM ha il suo concetto di interfaccia, chiamato Logical Device Operation

(LDO), o Logical Management Operation. Ogni asset IT viene associato ad una o più

LDO rappresentanti le azioni più comuni che possono essere eseguite su quell’asset. Una

LDO viene risolta a run time dal Deployment Engine in uno specifico provisioning

workflow. Nello scrivere un workflow, uno sviluppatore può fare chiamate ad altri

workflow o a LDO. I benefici della programmazione per interfacce sono ben noti: il prin-

cipale è che permette di realizzare decoupling, cioè un’indipendenza dalle implementazio-

ni. Alcuni tra gli LDO più comunemente usati sono Device.ExecuteCommand e Devi-

ce.CopyFile, che permettono rispettivamente di eseguire comandi e copiare file senza bi-

sogno di sapere come TPM comunica con la macchina target, se tramite ssh/scp, Tivoli

Common Agent (TCA), o RXA.

Un workflow può anche interagire con il Data Model attraverso il Data model query lan-

guage, che mette a disposizione dello sviluppatore quattro costrutti: DCMQuery, DCMIn-

sert, DCMUpdate e DCMDelete. DCMQuery permette di ricavare informazioni sugli og-

getti del data model. DCMInsert permette di aggiungere un nuovo oggetto al data model,

oppure un attributo a un oggetto esistente. DCMUpdate consente di modificare un oggetto

o un attributo già esistente. DCMDelete rimuove un oggetto dal data model.

La sintassi del Data model query language è simile a quella di XPath, un linguaggio usato

per navigare tra gli elementi e gli attributi di un documento XML. Un’espressione DCM* è

una lista, separata da slash, di nomi di elementi29

, attributi, operatori e condizioni che de-

scrivono un percorso in un database relazionale [23, p. 37]. Ad esempio, l’espressione se-

guente restituisce il nome della macchina di ID 2816.

29 Per conoscere i nomi degli oggetti e degli attributi che si possono usare in un’espressione DCM*, consulta-

re il file $TIO_HOME\xml\DcmObjectMappingsDocument.xml presente sulla macchina TSAM.

56

/server[@id="2816"]/@name

Il data model, o Data Center Model (DCM), cui già abbiamo accennato nel paragrafo

2.2.2, è implementato internamente in un database DB2 v9.5, che è un database ibrido re-

lazionale/gerarchico, e che consente di fare archiviazione di xml in modo nativo. Dunque, i

costrutti DCM* mappano semplicemente le query passate come argomento in query

SQL/XML, e le eseguono sul DB di TPM. Il DCM può essere esportato come un file XML

eseguendo uno script sul server TSAM30

. Di seguito riportiamo uno stralcio del DCM in

formato XML, contenente la definizione di un server virtuale creato dal self service di

TSAM.

<server name="172017196029" is-device-model="VMware Server" ignored-by-

resource-broker="false" failed="false" host-platform="ISDM_Cluster"

status="RUNNING">

<nic name="vNIC" failed="false" macaddress="005056001C30" managed="true"

management="false" netboot-enabled="false" group-name="vNIC" physical-

resource="vNIC">

<network-interface name="0" locale="en_US" failed="false" managed="true"

management="true" dynamic-ipaddress="false" ipaddress="172.17.196.29"

netmask="255.255.224.0" allocation="none" protocol-if-type="IPv4" />

<property component="KANAHA" name="resource.allocation.id" value="14127" />

</nic>

<property component="KANAHA" name="HostPlatformId" value="9889" />

<property component="KANAHA" name="ODSDS_auto-generated" value="true" />

<property component="KANAHA" name="VM_IMAGE_SW_INST_ID" value="10187" />

<property component="KANAHA" name="adminPassword" />

<property component="KANAHA" name="cloud-cluster-id" value="14022" />

<property component="KANAHA" name="hostname" value="vm172017196029" />

<property component="KANAHA" name="uuid" value="4204d7cc-a640-2618-d0e4-

85b420b3a41f" />

<property component="KANAHA" name="version" value="2008" />

<sap name="SSH" is-device-model="SSH Service Access Point" locale="en_US"

protocol-type="ip" app-protocol="SSH" context="NOCONTEXT" port="222" auth-

compulsory="true" role="host">

<default-sap operation-type="file-transfer" />

<default-sap operation-type="execute-command" />

</sap>

<software-resource name="VMware Template -- WIN2k8x86template" display-

name="VMware Template -- WIN2k8x86template" is-device-model="Cloud VMware

Windows Operating System" software-module="VMware Template --

WIN2k8x86template" type="INSTALLATION">

<software-capability type="OS" name="os.family" value="Windows" />

<software-capability type="OS" name="os.version" value="2008" />

<software-capability type="OS" name="os.distribution" value="Windows

Server" />

<software-requirement name="platform.virtualization.type" type="HARDWARE"

enforcement="MANDATORY" hosting="false" accept-non-existing="false">

<software-requirement-value value="VMware ESX" />

<software-requirement-value value="VMware Cluster" />

</software-requirement>

<software-resource-template name="PMRDPDefaultInstallation" software-

resource-type="INSTALLATION" software-resource-template-source="/VMware

Template -- WIN2k8x86template/Default Template/PMRDPDefaultInstallation"

multiplicity-type="Unspecified" software-configuration-type="Regular" is-

selected="true" is-default="false" is-deployable="true" />

30 Vedi https://www-304.ibm.com/support/docview.wss?uid=swg21469421&wv=1

https://www-304.ibm.com/support/docview.wss?uid=swg21469421&wv=1

57

<use-workflow workflow-id="RedHat_HostingEnvironment_Host" />

</software-resource>

<resource name="cpu" resource-type="cpu" managed="true"

partitionable="false">

<property component="KANAHA" name="cpu.type" value="32-bit" />

</resource>

<resource-allocation physical-resource="cpu" how-many="1" size="0.1" is-

shared="false">


</resource-allocation>

<resource-allocation physical-resource="rbstore" how-many="0" size="20.0" is-

shared="false">



<resource-allocation physical-resource="mem" how-many="1596" size="1596.0"

is-shared="false">



<resource-allocation physical-resource="vNIC" how-many="1" size="0.0" is-

shared="true">


</server>

L’ultimo strumento messo a disposizione degli sviluppatori è Jython, un linguaggio di

programmazione che implementa il linguaggio Python eseguendo il codice Python sulla

JVM. Jython è utile nello sviluppo di workflow per eseguire confronti, operazioni boolea-

ne, operazioni sulle stringhe e operazioni sulle variabili.

Oltre agli strumenti interni a TPM, uno sviluppatore può anche utilizzare strumenti esterni,

quali script (ad es. script bash e ksh) e classi Java. Questi file possono essere inclusi in un

automation package, e ad essi è possibile demandare alcuni compiti che sarebbe complica-

to implementare altrimenti, invocandoli dall’interno di un workflow.

5.1.2 Le definizioni software nel data model

Tutti i software che TPM gestisce sono memorizzati nel software catalog, dove ogni entry

è una software definition. Una software definition memorizza alcune informazioni su un

certo software, quali il nome, la versione, il file usato per installarlo, i requisiti che devono

essere soddisfatti per poterlo installare su una macchina target, e le opzioni di installazione.

Nello specifico, una software definition contiene le seguenti tipologie di informazioni:

Installable: il file di installazione del software; estensioni tipiche includono exe,

rpm, zip;

Requirement: un requisito che la macchina target deve soddisfare affinchè sia pos-

sibile installarci il software rappresentato dalla definition. Esempi di requisiti in-

cludono hardware o software che devono essere disponibili sul target;

58

Capability: un attributo che viene ereditato dalla macchina target quando ci si in-

stalla il software. Una capability serve a soddisfare un requirement;

Software configuration template: i parametri per l’installazione e la configura-

zione del software.

È possibile aggiungere manualmente una software definition al software catalog: questa

operazione è particolarmente utile per quei software, chiamati simple software product,

che non hanno procedure di installazione complesse. Per questo tipo di software, TPM for-

nisce alcuni template e provisioning workflow predefiniti che permettono di installarli e

configurarli senza bisogno di creare un automation package ad hoc.

Ogni volta che TPM installa un software su una macchina target che esso gestisce, aggiun-

ge contestualmente delle informazioni al DCM, chiamate software resources. Una soft-

ware resource è creata in base alle informazioni definite nei software configuration

template, che contengono i parametri di default per l’installazione. Per ogni configuration

template viene creata una software resource in cui vengono memorizzati i valori dei para-

metri attuali che sono usati durante l’installazione sul sistema target (infatti, durante

l’installazione è possibile usare dei parametri diversi da quelli di default).

Figura 5.2: Scenario di installazione da TPM

59

In Figura 5.2 vediamo uno scenario di installazione di un software. In questo esempio as-

sumiamo che nel software catalog sia memorizzata la software definition di DB2, caratte-

rizzata da un nome (“DB2 for Windows”), un requirement (Windows 2000 Server), una

capability (DB2 Versione 8.2), un installable, e tre software configuration template. Quan-

do viene installato su un target, nel DCM verranno aggiunti tre software resource (uno per

ogni software configuration template) all’interno della definizione della macchina target,

uno di tipo installation e due di tipo instance.

5.2 Implementazione

Nella trattazione dell’implementazione faremo riferimento alla sola installazione di

MySQL Server. Per MySQL Client valgono le medesime considerazioni.

5.2.1 Simple software product

Per implementare l’automazione del provisioning di MySQL Server si sono seguiti i passi

della guida per l’utente di TPM [24] relativi all’installazione di un cosiddetto simple soft-

ware product, espressione con la quale si intende un software la cui installazione richiede

un semplice scompattamento di un file compresso, o l’esecuzione di un comando di instal-

lazione “silenziosa” (cioè in background, senza interazione con l’utente).

Infatti, nel caso preso in esame, il pacchetto di installazione di MySQL Server per Win-

dows consiste in un file msi31

che può essere installato eseguendo il comando

msiexec /i mysql-5.5.12-win32.msi /q

dove il parametro “/i” indica di eseguire un’installazione, mentre il parametro “/q” indica

di non mostrare alcuna interfaccia utente.

Similmente, per l’installazione su RHEL c’è un file RPM32

che, come per tutti i pacchetti

RPM, si installa con il comando rpm. Nel nostro caso, il comando completo è

31 msi è un’estensione che identifica i file la cui installazione è gestita dal “Windows Installer”, lo strumento

ufficiale Microsoft per l’installazione di software su Windows. 32

Un file con estensione rpm è un pacchetto software che viene installato da RPM Package Manager (RPM),

un sistema di gestione dei pacchetti nato originariamente per Red Hat, ma poi esportato in altre distribuzioni

GNU/Linux come SUSE; Fedora e CentOS.

60

rpm -i MySQL-server-5.5.12-1.rhel5.i386.rpm

dove il parametro “–i” indica di eseguire un’installazione.

Configurare il provisioning di un simple software product consiste nel creare una nuova

software definition per ogni diversa piattaforma su cui si vuole installare il software [19, p.

319] (nel nostro caso, uno per Windows e uno per RHEL), specificando come software

configuration template un Hosting Configuration Template [24, p. 518] (nel nostro caso

“Hosting-Environment:WINDOWS: Install Only” per Windows, e “Hosting-

Environment:REDHAT: Install Only” per RHEL). Infine, affinché il software sia selezio-

nabile dal self service quando si crea un nuovo server virtuale, è necessario impostare nella

software definition la variabile “exposetotivsam” al valore ‘1’ [19, p. 319].

Questi passaggi, però, non sono stati sufficienti. Infatti, per esempio, eseguendo il provi-

sioning di MySQL Server per Windows, si otteneva il seguente errore:

Cannot find an implementation of the HostingEnvironment.Host LDO for the OS VMware Tem-

plate -- WIN2k8x86template. This default implementation of SoftwareInstallable.Install attempts to

invoke a HostingEnvironment.Host operation on the operating system installed on device

172017196025

Per correggerlo, basta associare il workflow “RedHat_HostingEnvironment_Host” alla de-

finizione del sistema operativo. Paradossalmente, questa soluzione funziona non solo per

RHEL ma anche nel caso di Windows.

5.2.2 L’automation package “hosting-environment-core”

Dimostriamo per assurdo l’affermazione precedente, provando ad aggiungere il workflow

Windows_HostingEnvironment_Host alla definizione del sistema operativo. In questo ca-

so, la situazione non migliora di molto, e l’errore che si presenta è:

COPCOM123E A shell command error occurred: Exit code=1,

Error stream="cygwin warning:

MS-DOS style path detected: %TEMP%\Windows_Install_Only_13346

Preferred POSIX equivalent is: %TEMP%/Windows_Install_Only_13346

CYGWIN environment variable option "nodosfilewarning" turns off this warning.

Consult the user's guide for more details about POSIX paths:

http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

rmdir: failed to remove `%TEMP%\\Windows_Install_Only_13346': Not a directory

rmdir: failed to remove `/S': No such file or directory

rmdir: failed to remove `/Q': No such file or directory

", Output stream="".

61

Il motivo di questo comportamento è che TSAM vuole che sui guest Windows sia installa-

to cygwin33

[19, p. 300] affinché possa trattare in modo uniforme tutte le VM che gestisce.

Così, i comandi inviati da TSAM alla VM Windows sono intercettati da cygwin ed eseguiti

in una shell bash.

Specificando Windows_HostingEnvironment_Host, però, vengono invocati i workflow

dell’automation package “hosting-environment-core” progettati per Windows. Di conse-

guenza, TSAM tratta le VM Windows come se non ci fosse cygwin. Nello specifico, ven-

gono invocati i seguenti workflow, in ordine sequenziale34

:

HECore_Windows_HostingEnvironment_Host

Windows_Install_Only

Create_TempDir_on_Windows

Delete_TempDir_on_Windows

In particolare, il workflow Create_TempDir_on_Windows invierà il comando

mkdir %TEMP%\Windows_Install_Only_13346

Ma cygwin, non sapendo interpretare la variabile d’ambiente Windows “%TEMP%”, ese-

gue il comando semplicemente rimuovendo il backslash (senza nemmeno sostituirgli lo

slash). Il risultato è che viene creata la cartella “%TEMP%Windows_Install_Only_13346”.

Successivamente, viene invocato il workflow LocalFileRepository_FileRepository_GetFile

(che non fa parte del package “hosting-environment-core”), che si occupa di trasferire il fi-

le di installazione dal file repository (il server NFS) alla VM. Ma il path di destinazione

che gli viene passato è “%TEMP%\Windows_Install_Only_13342”, che non esiste. Di

conseguenza, il trasferimento fallisce.

Infine, il workflow Delete_TempDir_on_Windows cerca di cancellare la cartella tempora-

nea appena creata:

rmdir "%TEMP%\Windows_Install_Only_13346" /S /Q

33 Cygwin è sostanzialmente un emulatore di un ambiente UNIX. Installandolo su Windows, permette, tra le

altre cose, di avere a disposizione una shell bash. 34

L’elenco di workflow è stato reperito consultando i log di TPM, nella sezione “Provisioning workflow sta-

tus” dell’interfaccia web di TSAM.

62

Ma, sempre a causa del path errato, anche questa operazione fallisce. Fallisce inoltre per-

ché cygwin non sa interpretare i parametri in stile windows di rmdir, “/S” e “/Q”.

Specificando invece “RedHat_HostingEnvironment_Host”, vengono ancora invocati i

workflow dell’automation package “hosting-environment-core”, ma questa volta le versio-

ni per UNIX. Nello specifico, per prima cosa il workflow LinuxUnix_Install_Only invia il

comando

test -d "/tmp/LinuxUnix_Install_Only_13343" || mkdir

"/tmp/LinuxUnix_Install_Only_13343"

e crea sulla VM Windows la cartella in cui copiare il file di installazione. Dopodiché, Lo-

calFileRepository_FileRepository_GetFile si occupa di trasferire il file di installazione con

il comando scp. Poi, LinuxUnix_Install_Only esegue il comando per installare MySQL

Server che abbiamo specificato nel software configuration template; quindi, su Windows

eseguirà:

msiexec /i mysql-5.5.12-win32.msi /q

Infine, Delete_TempDir_on_LinuxUnix rimuove la cartella temporanea e i file di installa-

zione con:

rm -rf "/tmp/LinuxUnix_Install_Only_13343"

5.2.3 Stack dei workflow per il provisioning di simple software products

Rimane ancora un problema. Abbiamo detto che per correggere l’errore “Cannot find an

implementation of the HostingEnvironment.Host LDO” basta associare il workflow Red-

Hat_HostingEnvironment_Host alla definizione del sistema operativo. Sapendo che in

TPM ogni template VMware di sistema operativo ha una sua definizione (visualizzabile

nella sezione “Provisioning computers”) e dei propri workflow associati, sembrerebbe lo-

gico che basti effettuare questa operazione per ogni nuovo template che si aggiunge, ma

che poi questa associazione sia condivisa da ognuna delle VM che usano quello stesso

(template di) SO. Invece, contrariamente alle aspettative, è necessario aggiungere

l’implementazione della LDO HostingEnvironment.Host all’interno della definizione di

ogni nuova VM che viene creata. È evidente che questa operazione non può non essere au-

tomatizzata, altrimenti verrebbe meno il concetto di self service per la creazione di server

Windows con contestuale installazione di un qualunque simple software product.

63

Seconds.Milliseconds Text Log Level

12.357 Start workflow: 'SoftwareModule$Install' debug

12.484 Start workflow: 'Default_SoftwareModule_Install' debug

12.530 Start workflow: 'SoftwareInstallable$Install' debug

12.544 Start workflow: 'SoftwareInstallable$InstallPre' debug

12.805 Start workflow: 'Default_SoftwareInstallable_InstallPre' debug

12.817 Default implementation for the

SoftwareInstallable.InstallPre logical operation.

debug

12.819 End workflow: 'Default_SoftwareInstallable_InstallPre' debug

12.827 End workflow: 'SoftwareInstallable.InstallPre' debug

14.378 Created software resource ID: 13877 info

14.540 Start workflow: 'Default_SoftwareInstallable_Install' debug

14.610 10864 info

14.617 Calling the implementation of HostingEnvironment.Host

named Windows_HostingEnvironment_Host

debug

14.619 Start workflow: 'HostingEnvironment$Host' debug

14.652 HostedSoftwareResourceID: 13877 info

14.670 Start workflow: 'Windows_HostingEnvironment_Host' debug

14.675 Start workflow:

'HECore_Windows_HostingEnvironment_Host'

debug

Tabella 5.1: I log di TPM per il provisioning di un simple software product su una VM Windows

L’obiettivo di questo paragrafo è quindi quello di studiare quali provisioning workflow

vengono invocati per installare un simple software product, con lo scopo di trovare un mo-

do per associare RedHat_HostingEnvironment_Host alla definizione del SO della VM.

Partiamo dai log di TPM relativi all’esecuzione dei provisioning workflow per installare un

simple sw product su guest Windows (vedi Tabella 5.1).

Prendendo in prestito la notazione dei class diagram UML secondo cui i nomi delle inter-

facce devono essere scritti in corsivo, presentiamo di seguito lo stack di workflow che sono

eseguiti per il provisioning di un simple software product, dove i nomi degli LDO sono

scritti in corsivo, il rientro nel testo serve a visualizzare chi ha invocato chi, e a fianco ad

ogni workflow riportiamo tra parentesi il nome dell’automation package cui appartiene.

1. SoftwareModule.Install (core)

2. Default_SoftwareModule_Install (default-device-model)

3. SoftwareInstallable.Install (core)

64

4. SoftwareInstallable.InstallPre (core)

5. Default_SoftwareInstallable_InstallPre (default-device-model)

6. Default_SoftwareInstallable_Install (default-device-model)

7. HostingEnvironment.Host

8. Windows_HostingEnvironment_Host

9. HECore_Windows_HostingEnvironment_Host

10. […]

11. SoftwareInstallable.InstallPost (core)

12. Default_SoftwareInstallable_InstallPost (default-device-model)

Come possiamo vedere, il primo workflow della serie è SoftwareModule.Install, un LDO

che serve a installare un software module su un device usando un software resource tem-

plate. Essendo un LDO, SoftwareModule.Install richiama la sua implementazione, che nel

caso dei simple software product risulta essere Default_SoftwareModule_Install. Questo

poi invoca l’LDO SoftwareInstallable.Install, che serve a installare un software product su

un device usando un software resource template. A questo punto, SoftwareInstalla-

ble.Install fa tre chiamate: la prima all’Extension point LDO35

SoftwareInstalla-

ble.InstallPre, la seconda alla sua implementazione Default_SoftwareInstallable_Install, e

la terza ed ultima all’Extension point LDO SoftwareInstallable.InstallPost.

Ciò che è importante notare è che HostingEnvironment.Host è invocato dal workflow De-

fault_SoftwareInstallable_Install. Potremmo quindi pensare di aggiungere qui il codice per

associare RedHat_HostingEnvironment_Host alla definizione del SO della VM.

5.2.4 Il workflow Default_SoftwareInstallable_Install

Il workflow Default_SoftwareInstallable_Install è l’implementazione di default della LDO

SoftwareInstallable.Install. Il suo compito è quello di richiamare il workflow HostingEnvi-

ronment.Host per il sistema operativo installato sul device. Analizziamone ora il codice.

var OperatingSystemID =

Java[SoftwareHelper#getOSSoftwareResourceInstalledOnDeviceId(DeviceID)]

Per prima cosa, grazie a una classe Java di supporto, ricava l’ID della software resource del

SO installato sulla VM.

35 Vedi paragrafo 5.2.5.

65

var WorkflowName = Java[SoftwareHelper#getWorkflowName(OperatingSystemID,

"HostingEnvironment.Host")]

Dopo aver verificato che il software resource del SO esiste, viene ricavato il nome del

workflow, associato a OperatingSystemID, che implementa HostingEnvironment.Host. Se

questo esiste, viene immediatamente invocato:

if Jython(WorkflowName != None) then

log debug "Calling the implementation of HostingEnvironment.Host named " +

WorkflowName

HostingEnvironment.Host(OperatingSystemID, SoftwareResourceTemplateID,

SoftwareResourceID)

Se però non esiste, viene lanciata un’eccezione con il messaggio di errore che trovavamo

nel paragrafo 5.2.1.

var errorMsg = Jython("Cannot find an implementation of the

HostingEnvironment.Host LDO for the OS " + OperatingSystemName + ". This

default implementation of SoftwareInstallable.Install attempts to invoke a

HostingEnvironment.Host operation on the operating system installed on

device " + DeviceName)

throw MissingHostingSupportForOperatingSystem errorMsg

Al momento questo è proprio ciò che succede, dato che l’espressione Ja-

va[SoftwareHelper#getWorkflowName(OperatingSystemID, "HostingEnviron-

ment.Host")] restituisce sempre “None”. Allora, quello che dovremmo fare è aggiungere

a OperatingSystemID il workflow RedHat_HostingEnvironment_Host prima che la varia-

bile WorkflowName sia valorizzata. Ma prima quando? Nel prossimo paragrafo discute-

remo un metodo che ci permetterà di rispondere a questa domanda.

5.2.5 Extension point LDO

Un modo per personalizzare i provisioning workflow è quello di utilizzare gli Extension

point LDO, introdotti in TPM 7.2, che consentono di inserire logica di business custom

che viene eseguita prima o dopo l’esecuzione di un certo LDO [23]. Questa è una soluzio-

ne ottimale dal punto di vista della pulizia del codice, in quanto consente di non toccare il

codice dei workflow esistenti, e quindi di evitare potenziali errori che si potrebbero riper-

cuotere su altre parti del sistema di automazione del provisioning.

Gli Extension point LDO si possono distinguere dagli LDO per il nome: infatti, condivido-

no lo stesso nome dell’LDO a cui si riferiscono eccetto per il suffisso, che può essere “Pre”

o “Post” a seconda che siano eseguiti rispettivamente prima o dopo dell’LDO. Ad esempio,

nell’automation package “core” è definita la LDO SoftwareInstallable.Install e sono defini-

66

ti i corrispondenti Extension point LDO SoftwareInstallable.InstallPost e SoftwareInstalla-

ble.InstallPre.

Per personalizzare un flusso di automazione attraverso gli Extension point LDO non biso-

gna modificare l’Extension point LDO stesso, ma il workflow che lo implementa. TPM

fornisce delle implementazioni di default vuote per tutti i possibili Extension point LDO.

Per poterle modificare dall’interfaccia web di TSAM è necessario accedere al database di

TPM e modificare nella tabella “maximo.workflow4” la riga corrispondente al workflow

che si desidera personalizzare impostando il campo “is_editable” a ‘Y’. Di default, infatti, i

workflow non sono modificabili dall’interfaccia web.

In virtù di quanto abbiamo visto nel paragrafo 5.2.3, l’Extension point LDO che fa al caso

nostro è SoftwareInstallable.InstallPre, che serve ad aggiungere logica personalizzata di

pre-processamento prima che un modulo software sia installato [23, p. 34].

L’implementazione che ci interessa è il workflow Default_SoftwareInstallable_InstallPre.

5.2.6 Il nostro Default_SoftwareInstallable_InstallPre

Il suo compito è quello di associare il workflow RedHat_HostingEnvironment_Host alla

definizione del SO della VM di ID DeviceID (parametro preso in input).

var OperatingSystemID =

Java[SoftwareHelper#getOSSoftwareResourceInstalledOnDeviceId(DeviceID)]

Per prima cosa, è necessario ricavare l’ID della definizione del SO, operazione che si può

demandare al metodo getOSSoftwareResourceInstalledOnDeviceId della classe Java Soft-

wareHelper, contenuta nell’automation package “core”.

var OldWorkflowName = Java[SoftwareHelper#getWorkflowName(OperatingSystemID,

"HostingEnvironment.Host")]

Dopodiché bisogna ricavare il nome del workflow, associato a OperatingSystemID, che

implementa l’LDO HostingEnvironment.Host.

Se la condizione “OldWorkflowName = = None” è verificata, ossia se non esiste alcun

workflow associato a OperatingSystemID, allora procediamo ad associargli manualmente

RedHat_HostingEnvironment_Host con una DCMInsert.

67

Questo ci dà modo di fare una piccola digressione approfondendo la sintassi della DCMIn-

sert. Di seguito riportiamo, rispettivamente, la sintassi per aggiungere un oggetto DCM, e

quella per aggiungere una proprietà ad un oggetto DCM.

DCMInsert <<delimiter

element

delimiter

DCMInsert parent=dcm_query <<delimiter

element

delimiter

delimiter può essere una qualunque stringa, come “EOF”;

element è l’elemento XML che si vuole aggiungere;

dcm_query è una DMQuery che restituisce l’elemento padre a cui si vuole aggiun-

gere l’elemento figlio element.

Tornando al codice del nostro workflow, l’istruzione clou è la seguente:

DCMInsert parent=DCMQuery(/SoftwareResource[@id=$OperatingSystemID]) <<EOF

<use-workflow workflow-id="RedHat_HostingEnvironment_Host" />

EOF

In questa istruzione, prima, una DCMQuery recupera l’oggetto DCM di tipo SoftwareRe-

source che rappresenta il SO della VM. Dopodiché, a questo viene aggiunto come figlio

tutto ciò che sta tra “<<EOF” e “EOF”, che in questo caso è un elemento XML con il nome

del workflow da associare a parent.

Se, invece, il nome del workflow è già esistente, ci limitiamo a stampare un log con un

messaggio di errore:

if Jython(OldWorkflowName != None) then

log error "implementation of HostingEnvironment.Host already existing: " +

OldWorkflowName

In quest’ultimo caso, si potrebbe pensare di sovrascrivere il nome del workflow attraverso

una DCMUpdate, ma a quanto pare TPM non lo consente. E, d’altronde, una modifica del

genere potrebbe causare dei danni collaterali che potremmo non essere in grado di control-

lare. In ogni caso, un modo per aggirare questa limitazione potrebbe essere quello di defi-

nire un metodo Java sulla falsariga di SoftwareHelper.getWorkflowName, il quale soppe-

riva alla mancanza di una DCMQuery per estrarre il nome del workflow associato a una

software resource.

68

Capitolo 6. Self service: Il preventivo

6.1 L’interfaccia web 2.0 di TSAM

6.1.1 Una panoramica

Come abbiamo discusso nel paragrafo 3.2, TSAM è dotato di un’interfaccia web 2.0, la

Self Service Station, dedicata agli utenti finali che desiderano inoltrare al sistema le loro

richieste di servizi.

La Figura 6.1 mostra una schermata della Self Service Station con la lista delle service of-

ferings che è possibile richiedere. Sulla destra, l’interfaccia mostra lo storico degli ultimi

progetti e delle ultime richieste che l’utente ha inoltrato al sistema; inoltre, le barre colorate

riassumono visivamente lo stato di questi progetti e richieste, permettendo così di capire a

colpo d’occhio qual è la percentuale di progetti e richieste non ancora soddisfatti, quanti

sono eventualmente in attesa dell’approvazione da parte di un amministratore, quanti sono

attivi, e quanti infine sono giunti al termine del loro ciclo di vita.

Figura 6.1: La Self Service Station e la lista dei servizi che è possibile richiedere

69

Cliccando su un’offering, si apre una schermata, chiamata offering panel, con il form in

cui inserire i dettagli della richiesta. In funzione dell’offeringe dei parametri che richiede in

input, il contenuto sarà diverso, pur conservando la stessa struttura generale.

Il servizio per noi più interessante è “Create project with VMware Servers”, la cui scher-

mata con il relativo form possiamo vedere in Figura 6.2.

Figura 6.2: La schermata con il form per creare un nuovo progetto

Da qui è possibile scegliere un nome da dare al progetto, il gruppo di utenti a cui dare ac-

cesso ai server virtuali, quando far partire il progetto e per quanto tempo deve essere attivo,

il numero di server che si vuole creare, quale sistema operativo e quali software installare

sui server, quali e quante risorse hardware (CPU, RAM, spazio disco) assegnare; si può in-

fine scegliere se monitorare o meno i server attraverso gli agenti di monitoring, e se far sì

che il sistema salvi automaticamente un’immagine con lo stato finale dei server prima che

vengano rimossi.

70

6.1.2 L’implementazione

La Self Service Station è un’applicazione web che è stata implementata usando Dojo Tool-

kit, un toolkit Javascript opensource che serve a costruire Rich Internet Applications

(RIA). Essa si compone di vari file WAR e JAR, i più importanti dei quali sono:

SimpleSRM.war

TSAM_web.war

SRMCommons.jar

SRMCommons.jar contiene il codice Java lato server e i file di configurazione della UI.

SimpleSRM.war contiene la parte più generale dell’interfaccia, legata a SRM, che può es-

sere utilizzata per vari scopi, non solo all’interno di TSAM.

TSAM_web.war contiene il codice specificamente scritto per TSAM che implementa tutte

le service offering relative alla creazione/modifica di progetti con server virtuali. Include

inoltre strumenti e widget per la gestione dei progetti, dei server virtuali e degli utenti.

Per i nostri scopi, ci concentriamo solo sull’applicazione TSAM_web. Prima di addentrar-

ci, però, è opportuno ricordare che uno strato sotto alla Self Service Station c’è SRM, il cui

scopo è semplificare l’accesso alle funzionalità di service management di TSAM, espo-

nendo un catalogo dei servizi. La Self Service Station rappresenta un’ulteriore astrazione

che nasconde il service catalog di SRM, e presenta al suo posto un’interfaccia più orientata

all’utente.

Questa stretta relazione tra SRM e Self Service Station risulta evidente studiando

l’implementazione di TSAM_web. Infatti, per ogni service offering definita nel catalogo di

SRM, TSAM_web contiene un file Javascript e, opzionalmente, un file HTML che, insie-

me, implementano una certa offering. In particolare, il file Javascript definisce la classe Ja-

vascript/Dojo che descrive l’offering, con i suoi attributi e i suoi metodi, mentre il file

HTML (chiamato “template”) definisce il layout del pannello che mostra il form relativo

all’offering.

All’interno del file WAR, sotto “js\simplesrm\tsam\dijit\request”, si trovano le classi Java-

script/Dojo che implementano tutte le varie service offering di SRM [20, p. 144]. Nella

sotto-cartella “templates” si trovano i file HTML che definiscono il layout dei pannelli.

Non tutte le service offering hanno un template associato, perchè alcuni sono condivisi tra

71

più pannelli. Ad esempio, l’offering “PMRDP_0201A_72”, alias “Create Project with

VMware Servers”, è una sotto-offering (nonché una sotto-classe) più specifica di “Create

Project with Servers”, perciò condividono lo stesso template, il file “CreateProjectWith-

Server.html”. L’esempio appena fatto è proprio quello che implementa il pannello in Figu-

ra 6.2.

Ogni service offering è caratterizzata da alcuni parametri che devono essere richiesti

all’utente. In HTML, il principale strumento per poter chiedere all’utente dei dati in input

consiste nell’utilizzare un form. Così, TSAM_web utilizza un form HTML, il cui tag form

è inserito nel template. Ciò che rende l’interazione dinamica e in stile web 2.0 è l’utilizzo

dei widget di Dojo, che si integrano con i controlli HTML quali il tag input, andando da

una parte ad abbellire graficamente il controllo, e dall’altra aggiungendogli funzionalità

user-friendly, come ad esempio il completamento automatico di una casella di testo, o vi-

sualizzando un calendario per riempire un campo con una data.

6.2 Dojo Toolkit

Come abbiamo detto, la Self Service Station è scritta in Javascript usando Dojo Toolik, una

libreria Javascript modulare progettata per facilitare lo sviluppo rapido di applicazioni web

multi piattaforma basate su Javascript e Ajax.

Essa si divide in tre parti:

dojo: il cuore del toolkit, contiene le librerie fondamentali;

dijit: la parte relativa ai widget;

dojox: include estensioni che forniscono varie funzionalità, quali grafici, crittogra-

fia, e altro.

Dijit è la parte per noi più interessante. Esso è sia un framework che consente di definire

nuovi widget a partire da quelli creati dagli sviluppatori di Dojo, sia una collezione di con-

trolli pronti all’uso. Dijit potenzia i controlli HTML quali i campi di un form, fornisce

widget per layout dinamici e widget avanzati come alberi e calendari. Dispone anche di

strumenti per creare interfacce utente dinamiche che si adattano alla finestra del browser e

che rispondono all’interazione dell’utente.

72

Una delle caratteristiche più interessanti di Dijit è il fatto che consente di creare widget con

il metodo cosiddetto “dichiarativo”, alternativo a quello “programmatico”. Il metodo pro-

grammatico consente semplicemente di istanziare una classe Dojo dal codice Javascript per

mezzo del costruttore new, come si fa in qualunque linguaggio di programmazione. Invece,

il metodo dichiarativo consente di creare un oggetto contestualmente alla sua definizione

nel codice HTML, per mezzo di attributi HTML custom come “dojoType”. Sarà poi il par-

ser di Dojo che, al momento del caricamento della pagina web (a patto di avere impostato

parseOnLoad a true nell’attributo djConfig), si occuperà di istanziare la classe specificata

come valore dell’attributo dojoType. Qui sotto, un esempio di uso del metodo dichiarativo:

<input type="text" name="firstname" value="testing testing"

dojoType="dijit.form.TextBox"

trim="true" id="firstname" propercase="true">

Dato il widget definito nel precedente esempio, per leggere il suo valore nel codice Dojo,

si usa la funzione dijit.byId che, dato l’ID di un nodo del DOM, restituisce un riferi-

mento all’oggetto, e infine si ricava il valore mediante ad esempio l’attributo value

dell’oggetto.

var fname = dijit.byId("firstname").value;

Solitamente un widget genera degli eventi, così come il controllo HTML input può gene-

rare gli eventi onchange, onclick, onfocus, ecc. Ad esempio, un oggetto dijit.form.TextBox

genera l’evento onChange quando l’utente modifica la stringa contenuta nella casella di te-

sto. Per mettersi in ascolto sugli eventi scatenati da un certo widget si può utilizzare il me-

todo connect [25], come mostrato nell’esempio seguente, in cui si specifica la funzione

foo come event handler dell’evento onChange generato dal widget di id “player”.

dojo.connect(dijit.byId('player'),'onChange',foo);

In Dojo è possibile eseguire anche questa operazione in modalità dichiarativa grazie

all’attributo dojoAttachEvent, che consente di registrare una funzione presso un elemento

del DOM contestualmente alla sua definizione nel codice HTML.

<input id="num" dojoType="dijit.form.NumberSpinner" constraints="{required: true,

min: 1}" value="1" dojoAttachEvent="onChange:_onChangeServQty">

In questo esempio la funzione _onChangeServQty è registrata presso l’elemento input, in

modo che sia richiamata quando l’evento onChange viene scatenato.

73

6.3 Il preventivo nel pannello CreateProjectWithServer

L’obiettivo di questo paragrafo è quello di modificare l’interfaccia di Figura 12 affinché

mostri all’utente un preventivo con i costi che dovrà sostenere per il progetto che va a crea-

re. In questo lavoro introduciamo il preventivo solo nel pannello dell’offering “Create pro-

ject with XYZ servers”, ma si potrebbe facilmente estendere anche ai pannelli delle offe-

ring similari quali “Modify server resources”, “Install software”, “Add XYZ servers” e al-

tre.

6.3.1 Il pannello per la creazione di un progetto

Il pannello per la creazione di un nuovo progetto è implementato dai seguenti file (a partire

dal path “js\simplesrm\tsam\dijit\request” di TSAM_web.war):

CreateProjectWithServer.js

templates\CreateProjectWithServer.html

PMRDP_0201A_72.js

PMRDP_0202A_72.js

PMRDP_0203A_72.js

PMRDP_0204A_72.js

PMRDP_0205A_72.js

PMRDP_0206A_72.js

I file PMRDP_020xA_72.js sono le classi Dojo concrete che implementano le service offe-

ring omonime “PMRDP_020xA_72” (alias “Create Project with VMware Servers”, “Crea-

te Project with KVM Servers”, ecc.) contenute nell’Offering catalog di SRM. La maggior

parte del codice è contenuto nella classe CreateProjectWithServer, che non implementa

nessuna offering particolare ma fa da sopra-classe da cui ereditano tutte le classi

PMRDP_020xA_72. Queste, infatti, oltre a ereditare da CreateProjectWithServer, si limi-

tano a ridefinire il campo hyper con l’hypervisor che usano. Ad esempio, la classe

PMRDP_0201A_72, che implementa l’offering “Create Project with VMware Servers”,

ridefinisce il campo hyper nel modo seguente:

hyper: ibm.tivoli.simplesrm.tsam.dijit.Hypervisors.VMware

Vediamo ora più in dettaglio la classe CreateProjectWithServer e il template associato.

74

6.3.1.1 Il template

Il file CreateProjectWithServer.html contiene il codice HTML che definisce il layout del

pannello per le offering “Create Project with XYZ Servers”. Questo comprende essenzial-

mente un form HTML con tutti i controlli necessari per prendere in input i parametri

dell’offering: all’interno del tag form sono quindi presenti una serie di tag input e select,

disposti all’interno di tabelle e di tag div, e una serie di widget Dijit, definiti con il metodo

dichiarativo.

Nel riquadro sottostante riportiamo il codice relativo ai primi due controlli mostrati in alto

in Figura 6.2, una casella di testo e un menù a tendina, in cui l’utente deve inserire il nome

del progetto e il team proprietario del progetto. Questi controlli sono incapsulati in due

widget Dijit, che ne potenziano la grafica e le funzionalità.

<h2 class="group_heading">${_requestStringTable.GeneralLegend}</h2>

<div class="input_row_short first">

<table class="form_table">

<tr>

<td>

<div class="input_field">

<label class="label required" for="${id}_PMRDPCLCPR_PROJECTNAME">

${requestDetails.AttributeByID.PMRDPCLCPR_PROJECTNAME.Description}

</label>

<input id="${id}_PMRDPCLCPR_PROJECTNAME"

dojoAttachPoint="_projectName" dojoType="ibm.tivoli.tip.dijit.TextInputBox"

name="PMRDPCLCPR_PROJECTNAME" constraints="{required: true, maxlen: 30}"

size="32">

</div>

</td>

<td>

<div class="input_field">

<label class="label required" for="${id}_PMRDPCLCPR_PERSONGROUP">

${requestDetails.AttributeByID.PMRDPCLCPR_PERSONGROUP.Description}

</label>

<select id="${id}_PMRDPCLCPR_PERSONGROUP"

dojoType="dijit.form.FilteringSelect" name="PMRDPCLCPR_PERSONGROUP"

autoComplete="true" ></select>

</div>

</td>

</tr>

</table>

</div>

Osserviamo il codice del primo controllo, che implementa una casella di testo:

<input id="${id}_PMRDPCLCPR_PROJECTNAME" dojoAttachPoint="_projectName"

dojoType="ibm.tivoli.tip.dijit.TextInputBox" name="PMRDPCLCPR_PROJECTNAME"

constraints="{required: true, maxlen: 30}" size="32">

Questo è un esempio di creazione di widget con il metodo dichiarativo (vedi paragrafo

6.2). La presenza dell’attributo dojoType indica che l’elemento è un oggetto Dojo che de-

ve essere istanziato; il valore dell’attributo indica quale classe istanziare (in questo caso,

“ibm.tivoli.tip.dijit.TextInputBox”). Inoltre, l’attributo dojoAttachPoint specifica che la

75

casella di testo deve essere collegata alla variabile d’istanza _projectName, in modo che a

quest’ultima sia passata la stringa di testo inserita dall’utente nel widget.

Un'altra cosa che possiamo notare è l’uso dell’espressione ${id} per stampare a runtime il

campo id nel codice HTML, come in:

<input id="${id}_PMRDPCLCPR_PROJECTNAME"

Infine, notiamo l’utilizzo delle funzioni di internazionalizzazione, che consentono anche di

realizzare decoupling tra il codice HTML/Javascript e le stringhe di testo statiche

dell’interfaccia, come in:

<h2 class="group_heading">${_requestStringTable.GeneralLegend}</h2>

_requestStringTable è una variabile della classe TSAMRequest che incapsula tutte le

stringhe localizzate, valorizzata per mezzo della funzione dojo.i18n.getLocalization.

Sono anche presenti widget che, essendo dei controlli nativi di Dijit, non potenziano alcun

controllo HTML, e per questo possono essere agganciati solo al tag div. Tra questi rientra

il widget che prende in input la quantità di spazio disco, un PopupButton con slider, come

è possibile osservare leggendo il codice HTML seguente.

<div class="resource_selection" id="${id}_DISK_CELL">

<div dojoType="ibm.tivoli.simplesrm.srm.dijit.PopupButton"

iconClass="sliderbutton" label="${_requestStringTable.SetDisk}"

showLabel="false" disabled="true"

popupClass="ibm.tivoli.simplesrm.tsam.dijit.DiskResourceSliders"

dojoAttachPoint="disksliderbutton" style="float: right; width:32px;">

</div>

<div class="title">

${_requestStringTable.ServerListDisk}

</div>

<table style="clear:both; font-size:10pt;">

<tr class="resource_row">

<td class="resource_col">

<label class="label" for="${id}_PMRDPCLCVS_STORAGE_SIZE">

${_requestStringTable.ResourceDiskLocal}

</label>

</td>

<td class="resource_col">

<span id="${id}_STORAGE_DISPLAYAREA"></span> ${_ResourceGB}

<span class="resourceBase" dojoattachpoint="diskError"></span>

<input id="${id}_PMRDPCLCVS_STORAGE_SIZE" type="hidden"

name="PMRDPCLCVS_STORAGE_SIZE">

</td>

</tr>

</table>

</div>

Osserviamo che è tuttavia definito un controllo di tipo input, ma è nascosto. Un form

HTML, infatti, non è in grado di leggere e trasmettere i dati incapsulati dai widget definiti

76

nei tag div. Allora, si forza la presenza di un tag input impostandolo come “hidden”, e ci si

copia nell’attributo value i dati che l’utente introduce attraverso il widget.

6.3.1.2 La classe Dojo CreateProjectWithServer

Nel file CreateProjectWithServer.js è definita l’omonima classe CreateProjectWithServer,

sottoclasse di TSAMRequest e di PanelStateMachine.

PanelStateMachine implementa funzionalità di base per controllare lo stato di un pannello.

Definisce cinque stati (INIT, MISS, CORRECT, ERROR e SUBMIT), ognuno dei quali

indica quali azioni è possibile eseguire sul pannello. Ad esempio, se un pannello si trova

nello stato “ERROR”, significa che almeno uno dei suoi campi contiene dati non validi, e

perciò non è possibile sottomettere il form, ma l’utente può solo modificarne i campi.

TSAMRequest eredita a sua volta dalla classe CreateCatalogRequest. Quest’ultima imple-

menta un widget che, tramite un servlet proxy, invia una XMLHttpRequest a un web servi-

ce in grado di inoltrare richieste al service catalog di SRM. TSAMRequest, invece, rappre-

senta una richiesta SRM specifica per i servizi di tipo cloud IaaS.

La gerarchia completa è:

CreateProjectWithServer

PanelStateMachine

TSAMRequest

CreateCatalogRequest

_Widget

_Templated

WidgetBase

_Widget e _Templated sono due classi predefinite di Dojo che fanno di dijit un vero e

proprio framework. Esse forniscono le funzionalità di base per i widget e per la costruzione

di un albero DOM a partire da un template, rispettivamente. Per creare un nuovo widget, è

sufficiente estendere queste classi e ridefinire le funzioni che si vuole personalizzare.

CreateProjectWithServer, essendo una sottoclasse di TSAMRequest, rappresenta una spe-

cifica richiesta SRM, di tipo cloud IaaS, per la creazione di server virtuali. “Specifica” ma

non troppo, in quanto sono le sue sottoclassi PMRDP_020xA_72 a rappresentare richieste

per reali service offering definite nell’Offering catalog di SRM.

77

A questo punto, entriamo nel vivo del codice di questa classe studiando cosa succede

quando l’utente interagisce con i widget per modificare i parametri del progetto. Per sem-

plicità, studieremo solo quelli relativi alle risorse hardware (CPU, RAM e spazio disco).

Figura 6.3: Il widget di tipo PopupButton che prende in input i dati relativi alla memoria

Questi widget sono fondamentalmente dei PopupButton, cioè dei bottoni che, se cliccati,

generano un popup; all’interno di questi popup ci sono poi i widget ResourceSliders, che

forniscono all’utente uno slider per modificare velocemente la quantità considerata. Nello

specifico, c’è un tipo particolare di ResourceSliders per ogni risorsa hardware: DiskRe-

sourceSliders, MemoryResourceSliders, CpuResourceSliders.

Analizziamo ora uno scenario di utilizzo. Consideriamo ad esempio il parametro relativo

allo spazio disco: non appena l’utente modifica la quantità di spazio disco, come possiamo

constatare dalla Console di Chrome36

(vedi Figura 6.4) , vengono invocate le seguenti fun-

zioni, in sequenza:

1. _onDiskChanged

2. _loadAvailableResources

36 La console di Figura 6.4 fa parte dei Chrome Developer Tools, e permette di visualizzare tutto ciò che c’è

dietro ai click dell’utente all’interno di una finestra del browser. In particolare, a noi è utile per vedere i log

generati dal codice Dojo di TSAM_web, che vengono stampati sulla console per mezzo delle chiamate con-

sole.warn, console.log e console.debug.

78

Figura 6.4: I log generati dal codice Dojo visualizzati sulla console di Chrome

3. _loadResourceAvailability (della classe TSAMRequest)

4. _processAvailableResources

_onDiskChanged è uno degli event handler che rispondono alle modifiche della quantità di

risorse hardware; gli altri sono:

_onCpuChanged è l’azione che viene eseguita in seguito alla modifica della CPU

_onMemoryChanged è l’azione che viene eseguita in seguito alla modifica della

quantità di RAM richiesta

_onDiskChanged è l’azione che viene eseguita in seguito alla modifica della quan-

tità di spazio disco richiesto

Tutte queste funzioni invocano alla fine _loadAvailableResources, che verifica che, da-

ti i parametri introdotti dall’utente, il sistema sia in grado di fare il deploy del progetto nel

periodo specificato, ovvero che ci siano risorse sufficienti per creare i server virtuali richie-

sti. Questo metodo provoca l’invocazione a catena di vari altri metodi, tra cui

_doLoadAvailableResources, TSAMRequest._loadResourceAvailability,

_processAvailableResources, _processServerQty, _processResources. Alla fine, il

79

risultato è che, se il sistema non dispone di risorse sufficienti, stampa sul pannello un mes-

saggio di errore, invitando l’utente a modificare il progetto.

Siccome i widget che stiamo studiando non sono agganciati a controlli HTML ma a tag

div, allora è necessario che gli event handler citati, oltre a convalidare i parametri del pro-

getto, si occupino di aggiornare l’attributo value degli input nascosti associati (vedere

spiegazione nel paragrafo 6.3.1.1). Questo compito è delegato ai seguenti metodi, i cui

nomi sono autoesplicativi:

_updatePCPU

_updateVCPU

_updateMemory

_updateSwap

_updateDisk

Non solo: questi metodi si occupano anche di aggiornare il contenuto HTML del pannello

con i nuovi valori introdotti dall’utente attraverso i widget, in modo che, quando l’utente

chiude il popup con lo slider (vedi Figura 6.3), il valore introdotto sia ancora visibile. Ri-

portiamo come esempio l’implementazione di _updateDisk:

_updateDisk: function(newvalue) {

dojo.byId(this.id + '_PMRDPCLCVS_STORAGE_SIZE').value = newvalue;

dojo.byId(this.id + '_STORAGE_DISPLAYAREA').innerHTML =

dojo.number.format(newvalue);

}

6.3.2 Implementazione del preventivo

L’implementazione consiste nella personalizzazione della classe CreateProjectWithServer

e del template associato.

6.3.2.1 Personalizzazione del template di CreateProjectWithServer

Per prima cosa, si è modificato il template aggiungendo in fondo una semplice tabella in

HTML (vedi Figura 6.5) costituita da cinque colonne (una dedicata ai totali, più una per

ogni tipo di risorsa che influenza il calcolo del chargeback: licenza SO, CPU, RAM, spazio

disco) e tre righe (una per i costi unitari, ovvero i costi orari per un singolo server, una per i

costi mensili per tutti i server del progetto, e una per quelli totali, ovvero per tutti i server

per l’intera durata del progetto).

80

Figura 6.5: La tabella con il preventivo del progetto

L’unica particolarità Javascript/Dojo (più Javascript che Dojo, in questo caso) riguarda le

celle che devono contenere i valori dei prezzi: esse sono vuote eccetto per un un tag span

in cui a runtime verrà “iniettato” il costo per mezzo di innerHTML. Ad esempio, il codice

della casella atta a contenere il costo mensile della quantità di RAM selezionata dall’utente

è il seguente:

<td class="resource_cell">

<div class="resource_row">

<span id="${id}_CHARGEBACK_DISPLAYAREA_PERMONTH_MEM"></span>

</div>

</td>

6.3.2.2 Personalizzazione della classe CreateProjectWithServer

La modifica del file javascript consiste nell’aggiungere una serie di funzioni custom che

aggiornino la tabella con il preventivo (chiamiamo _updateChargeback la funzione top

level). A questo scopo, le operazioni (ad alto livello) da eseguire sono:

1. Leggere i valori dei parametri introdotti dall’utente attraverso i widget

2. Calcolare i costi in funzione dei valori letti al punto 1

3. Scrivere i nuovi valori dei costi nella tabella

Per leggere i valori introdotti dall’utente nei widget, ci viene in aiuto il metodo getCur-

rentSettings della classe CreateProjectWithServer, che restituisce il valore delle quantità

di CPU, memoria e spazio disco richieste dall’utente, incapsulate in un oggetto. Oltre a

queste risorse, per calcolare il chargeback abbiamo bisogno di conoscere il sistema opera-

tivo selezionato, la durata temporale del progetto e il numero di server. Tutte queste infor-

mazioni si possono ricavare tramite dijit.byId, come esemplificato qua sotto:

var res = this.getCurrentSettings(),

num_vcpus = res.vcpu,

num_pcpus = res.pcpu,

mem_MB = res.memory,

disk_GB = res.disk,

image_id = dijit.byId(this.id +

"_PMRDPCLSWS_IMAGEID").getFieldValue("IMAGEID"),

num_servers = parseInt(dijit.byId(this.id+"_PMRDPCLCPR_SERVERQTY").value),

num_hrs = Math.abs(

dojo.date.difference(this._projEndDate,this._projStartDate,"hour") );

81

Il secondo passo è calcolare i costi. Ai fini del calcolo, abbiamo considerato i seguenti

prezzi orari37

:

CPU virtuale: 0.025€ per ogni CPU virtuale

CPU fisica: 0.10€ per ogni decimo di CPU fisica

RAM: 0.01€/GB

Spazio disco: 0.0001€/GB

Licenza per Windows 2008: 0.015€

Licenza per RHEL5: 0.08€

L’unico aspetto non troppo banale del calcolo è dove scrivere questi prezzi. Banalmente, si

potrebbero scrivere all’interno della funzione che esegue il calcolo, definendo una variabile

per ogni prezzo orario. Ma ciò andrebbe contro il principio di decoupling: separando i

prezzi orari dal codice, invece, è possibile modificarli quando si vuole senza toccare il co-

dice Dojo della funzione che esegue il calcolo. Tuttavia, in questo lavoro disaccoppiamo

solo i prezzi orari delle risorse hardware (CPU, RAM e spazio disco). Nel paragrafo 7.2.1

discuteremo come si potrebbe estendere il decoupling anche ai prezzi delle licenze dei si-

stemi operativi.

Un modo per implementare il decoupling è quello di scrivere i prezzi in un file di testo sul

server, e poi leggerlo dal client remoto (il browser dell’utente) grazie alla funzione

dojo.xhrGet. Essa, infatti, permette di fare una chiamata in stile AJAX per recuperare un

file dal server remoto; prende in input un oggetto con delle proprietà ben precise, tramite

cui è possibile configurare la chiamata AJAX [26]. Le proprietà più rilevanti sono:

url: la URL del file che si vuole richiedere

handleAs: il formato del file che si cerca di recuperare (text/json/xml/ecc.)

sync: booleano che indica se la funzione si deve bloccare finché non riceve i dati

load: la funzione che viene eseguita non appena il server restituisce i dati richiesti

error: la funzione che viene eseguita se la chiamata AJAX non va a buon fine

Dunque, come proprietà load dobbiamo specificare una funzione che esegua i passi 2 e 3.

Come proprietà error, invece, specifichiamo una funzione che inserisce in ogni cella della

37 Per decidere i valori dei prezzi, ci siamo ispirati a quelli pubblicati da IBM nel listino prezzi per il loro pu-

blic cloud IaaS (vedi http://www-935.ibm.com/services/it/igs/cloud-development/pricesheet.html)

82

tabella la stringa “N/A” al posto del costo. Riguardo al file di testo in cui scriviamo i prez-

zi, possiamo ad esempio decidere di dargli questo formato: quattro numero separati da vir-

gola, senza spazi, rappresentanti rispettivamente il prezzo di CPU virtuale, CPU fisica,

RAM, spazio disco. Così, possiamo usare la funzione Javascript split per convertire il

contenuto del file in un array contenente i quattro prezzi orari.

var path="",

filename="rates_per_hour.txt";

dojo.xhrGet({

url: path+filename,

load: function(data){

var ratesDaFile = data.split(",",4);

// […]

}

error: function(err){

// […]

}

});

Infine, il terzo e ultimo passo consiste nell’aggiornare la tabella del preventivo con i valori

appena calcolati. A parte questioni implementative come la gestione degli arrotondamenti

di numeri molto piccoli (es: “0.000001”), il codice per aggiornare una singola cella della

tabella con un valore calcolato al passo 2, è il seguente:

valore = dojo.number.round(coppia[1],2);

currencyOptions = {currency:"EUR",places:2,type:"currency"};

dojo.byId(coppia[0]).innerHTML = dojo.currency.format(valore,currencyOptions);

La variabile coppia è un array di stringhe costruito all’uopo precedentemente, di lunghez-

za pari a 2, dove la prima stringa (coppia[0]) è l’id di un tag HTML che corrisponde ad

una cella della tabella, mentre la seconda (coppia[1]) è il valore da inserire come text

element all'interno della cella. Siccome questo valore è una valuta, usiamo la funzione

dojo.currency.format per formattarla opportunamente, specificando in currencyOp-

tions le opzioni di formattazione. Infine, tramite dojo.byId e la proprietà innerHTML, in-

seriamo il valore formattato nella cella identificata dall’id contenuto in coppia[0].

Rimane ancora da discutere come far sì che il preventivo venga aggiornato automaticamen-

te ogni volta che l’utente modifica un parametro del progetto. Avendo studiato in prece-

denza la classe CreateProjectWithServer, sappiamo che, quando l’utente modifica un pa-

rametro del progetto, i primi metodi ad essere invocati sono gli event handler (vedi para-

grafo 6.3.1.2). Ai fini del chargeback, quelli interessanti sono:

_onCpuChanged, relativo alla quantità di CPU (virtuale e fisica)

_onMemoryChanged, relativo alla quantità di memoria (RAM e swap)

83

_onDiskChanged, relativo alla quantità di spazio disco

_onChangeReservation, relativo alla durata temporale del progetto

_onImageSelected, relativo al sistema operativo

_onChangeServQty, relativo al numero di server virtuali

È sufficiente aggiungere al fondo di ognuno di questi metodi la chiamata alla nostra fun-

zione custom _updateChargeback perché la tabella venga aggiornata automaticamente.

6.4 Estensioni della Self Service Station in TSAM 7.2.2

Nella versione 7.2.2 di TSAM sono stati introdotti alcuni nuovi punti di estensione

nell’interfaccia self-service, nonché una guida che li descrive e spiega [27].

In primis, è stato progettato un modo per permettere di personalizzare l’intera UI senza che

un upgrade di TSAM sovrascriva il codice custom, costringendo, nella migliore delle ipo-

tesi, a riapplicare le personalizzazioni al termine dell’esecuzione dell’upgrade. Questo ef-

fetto è ottenuto confinando le personalizzazioni in un file war, separato dalle applicazioni

web ufficiali quali SimpleSRM e TSAM_web.

Inoltre, è stato implementato un meccanismo (una API in Dojo) che consente di apportare

modifiche senza necessariamente avere elevate competenze di Javascript e/o di Dojo Tool-

kit. Ad esempio, per personalizzare il pannello di “Create Project with VMware Servers”

in modo da modificare i valori di default dei campi del form, basta estendere la classe

ibm.tivoli.simplesrm.tsam.dijit.request.PMRDP_0201A_72 e ridefinire la funzione tsam-

CustomInit nel modo seguente:

dojo.provide("custom.tsam.dijit.request.PMRDP_0201A_72");

dojo.require("ibm.tivoli.simplesrm.tsam.dijit.request.PMRDP_0201A_72");

dojo.declare("custom.tsam.dijit.request.PMRDP_0201A_72",

[ibm.tivoli.simplesrm.tsam.dijit.request.PMRDP_0201A_72],

{

tsamCustomInit: function() {

var pn = this.tsamGetField(“Project Name”);

pn.tsamCall(“setValue”, “DefaultProject”);

},

});

Analizzare in dettaglio queste nuove possibilità di estensione esula dagli scopi di questo

lavoro, che si basa sulla versione 7.2.1.1 di TSAM. Tuttavia, era doveroso citarli.

84

Capitolo 7. Conclusioni

7.1 Ricapitoliamo

Dopo aver approfondito, nella prima parte di questo lavoro, la teoria che regge il cloud

computing, possiamo concludere che si tratta di un solido modello di calcolo in quanto

poggia su tecnologie concrete e ben rodate (vedi Capitolo 2) come la virtualizzazione.

D’altronde, le critiche che lo accusano di essere il frutto di una campagna di marketing so-

no in parte fondate, in quanto, come discusso nel Capitolo 1, non esiste una teorizzazione

univoca, né il cloud è supportato da un buon filone di ricerca di base. Tuttavia, dobbiamo

anche considerare che è un modello nato da poco, e recentissimi sono i tentativi di standar-

dizzazione del cloud, ad esempio attraverso standard aperti. Il ruolo del NIST, in quanto

ente governativo degli U.S.A. specializzato in standard, si può percepire che sarà sempre

più importante nell’allargare il bacino di utenza del cloud.

Il cloud computing è un grande calderone in cui confluiscono un gran numero di tecnolo-

gie, protocolli e linguaggi di programmazione. Uno studio veramente approfondito del

cloud avrebbe richiesto molto più tempo, e non sarebbe stato comunque utile ai fini degli

obiettivi che ci siamo posti all’inizio. Perciò, nella trattazione della parte teorica abbiamo

adottato un taglio di piuttosto alto livello, limitandoci per lo più a toccare gli aspetti che ci

sono serviti nella parte pratica.

In questo lavoro ci siamo focalizzati sul private cloud, che, data la complessità, si applica a

contesti nuovi (startup) o molto ampi in cui è possibile applicarlo ad una nicchia per poi

espanderlo. Il private cloud prevede una standardizzazione delle richieste (altrimenti ver-

rebbe meno il carattere di autonomic computing), ma va spesso inserito in contesti che ne-

gli anni hanno fatto della “customizzazione” il loro motto, quindi è necessario usare stru-

menti che permettano un alto grado di configurabilità al fine di implementare personalizza-

zioni adatte al contesto.

85

A questo scopo, nella parte pratica abbiamo progettato e implementato una soluzione pri-

vate IaaS partendo dall’installazione e configurazione di IBM Service Delivery Manager,

prodotto che consente un buon grado di personalizzazione. Per implementare i requisiti cu-

stom abbiamo approfondito lo studio di alcuni componenti di ISDM, in particolare: TSAM,

TPM e la Self Service Station di TSAM.

Gli obiettivi che ci eravamo prefissati sono stati tutti raggiunti; non senza difficoltà, però,

giacché ISDM è un prodotto caratterizzato da un’altissima complessità che si traduce spes-

so in una scarsa chiarezza dei manuali. In particolare, il problema dei manuali IBM è la di-

spersione: ogni prodotto IBM, infatti, integra altri prodotti configurati ad hoc (ad es. ISDM

è composto da TSAM ITM e ITUAM, che a loro volta sono composti da altri software),

perciò i manuali del software di primo livello rimandano spesso ai manuali dei componenti

di secondo livello, ma a quel punto le cose possono non valere più per via delle configura-

zioni ad hoc.

7.2 Possibili sviluppi

Nel progettare e implementare la nostra soluzione, abbiamo incontrato alcuni aspetti che

possono essere migliorati. In questo paragrafo li esponiamo.

7.2.1 Preventivo: Disaccoppiare i prezzi delle licenze dei sistemi operativi

Nell’implementazione del preventivo abbiamo disaccoppiato solo i prezzi relativi alle ri-

sorse hardware; i prezzi delle licenze dei sistemi operativi, invece, sono stati scritti nel co-

dice della classe CreateProjectWithServer (vedi paragrafo 6.3.2.2). La differenza tra le due

tipologie di prezzi è che quelli delle licenze sono più dinamici, giacché dipendono dagli ID

che TPM assegna alle immagini dei sistemi operativi (ad esempio, template di VMware)

quando vengono importate. Dunque, per poter applicare correttamente i prezzi delle licen-

ze dei SO, è necessario modificare il sistema di discovery di TPM facendo sì che, conte-

stualmente all’importazione di un’immagine, chieda all’utente il prezzo orario da assegna-

re a quella licenza, e scriva quel prezzo in un file il cui path sia noto alla funzione che cal-

cola i costi del preventivo.

Disaccoppiare i prezzi delle licenze, oltre che essere positivo da un punto di vista quasi fi-

losofico, permetterebbe di gestire agilmente alcune situazioni: ad esempio, qualora ISDM

86

supportasse altri sistemi operativi, sarebbe possibile aggiungerne i relativi prezzi senza do-

ver modificare il codice della funzione che esegue il calcolo.

7.2.2 Report di chargeback

In un’ottica di utility computing, si potrebbe far generare al sistema un report di charge-

back che funga da bolletta da inviare periodicamente agli Application Manager che hanno

creato server virtuali. Un siffatto sistema di fatturazione (in cui si potrebbe usare una mo-

neta anche solo virtuale), che andasse ad intaccare il budget assegnato agli AM, complete-

rebbe l’implementazione del chargeback iniziata con l’introduzione del preventivo nel

form di creazione di server virtuali (vedi Capitolo 6). Così, si spingerebbe gli AM ad auto-

responsabilizzarsi nella razionalizzazione dei server virtuali, qualora questi, superate le

prime diffidenze che tipicamente nascono quando viene introdotto un nuovo sistema, so-

vra-utilizzino le risorse del datacenter per via della estrema facilità d’uso del cloud.

87

Bibliografia

[1] NIST, "The NIST Definition of Cloud Computing (DRAFT)," 2011. [Online].

Available: http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-

definition.pdf.

[2] Gartner, "Cloud Computing: Defining and Describing an Emerging Phenomenon,"

2008.

[3] Cisco, "Cisco Cloud Computing - Data Center Strategy, Architecture, and Solutions

(Point of View White Paper for U.S. Public Sector)," 2009. [Online]. Available:

http://www.cisco.com/web/strategy/docs/gov/CiscoCloudComputing_WP.pdf.

[4] IBM, "IBM Cloud Channel Sales Guide - IBM Software and Systems for Private

Clouds and Public Cloud Computing," 2010.

[5] Microsoft, "Architecture Strategies for Catching the Long," 2006. [Online].

Available: http://msdn.microsoft.com/en-us/library/aa479069.aspx.

[6] NIST, "Cloud Computing Synopsis and Recommendations (DRAFT)," 2011.

[Online]. Available: http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-

SP800-146.pdf.

[7] IBM, "Cloud Computing Reference Architecture v2.0," 2011. [Online]. Available:

http://www.opengroup.org/cloudcomputing/uploads/40/23840/CCRA.IBMSubmissi

on.02282011.doc.

[8] The Open Group, "Cloud Computing Explained," 2011. [Online]. Available:

https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicati

onid=12382.

[9] opencloudmanifesto.org, "Open Cloud Manifesto," 2009. [Online]. Available:

http://www.opencloudmanifesto.org/Open%20Cloud%20Manifesto.pdf.

[10] The Open Group, "Building ROI from Cloud Computing," 2010. [Online].

Available: http://www.opengroup.org/bookstore/catalog/w104.htm.

[11] Assosecurity, La virtualizzazione e i suoi aspetti di sicurezza, 2011.

88

[12] KVM, "KVM HomePage," [Online]. Available: http://www.linux-kvm.org.

[13] KVM, "KVM FAQ," [Online]. Available: http://www.linux-

kvm.org/page/FAQ#What_is_the_difference_between_KVM_and_Xen.3F.

[14] VMware, "Introduction to VMware vSphere," 2010. [Online]. Available:

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_intro_vs.pdf.

[15] VMware, «VMware ESXi 4.1 - Operations Guide,» 2011. [Online]. Available:

http://www.vmware.com/files/pdf/VMware-ESXi-41-Operations-Guide-TWP.pdf.

[16] IBM, "Tivoli Provisioning Manager 7.2 - Welcome Guide," 2010.

[17] The Open Group, "The SOA Work Group: Definition of SOA," [Online]. Available:

http://www.opengroup.org/soa/soa/def.htm.

[18] C. Baun and et al., Cloud Computing - Web-Based Dynamic IT Services, Springer.

[19] IBM, IBM Tivoli Service Automation Manager V7.2.1.1 - Installation and

Administration Guide, 2010.

[20] IBM, IBM Tivoli Service Automation Manager - Solution Guide, 2010.

[21] IBM, IBM Service Delivery Manager v 7.2.1 - Installation and Configuration Guide,

2011.

[22] VMware, "Guest Operating System Installation Guide," 2011. [Online]. Available:

http://www.vmware.com/pdf/GuestOS_guide.pdf.

[23] IBM, IBM Tivoli Provisioning Manager Version 7.2 - Provisioning workflows and

automation packages guide.

[24] IBM, IBM Tivoli Provisioning Manager Version 7.2 - User Guide, 2010.

[25] Sitepen, "Dive Into Dijit," 2010. [Online]. Available:

http://www.sitepen.com/blog/2010/07/12/dive-into-dijit/.

[26] Dojo Toolkit, "Reference guide - dojo.xhrGet," [Online]. Available:

http://dojotoolkit.org/reference-guide/dojo/xhrGet.html.

[27] IBM, "Tivoli Service Automation Manager Version 7.2.2 - Extensions Guide,"

2011. [Online]. Available:

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm.tsam_7.2.2.d

oc/out/tsam.admin.book.pdf.

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

Documents

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