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

A Stefania, Ai miei genitori, Ai miei nonni Argene e Franco.

II

Indice

RINGRAZIAMENTI ..........................................................................................................................................V INTRODUZIONE .............................................................................................................................................. 1 PARTE I - TEORIA SUL CLOUD COMPUTING......................................................................................... 4 CAPITOLO 1. IL CLOUD COMPUTING............................................................................................................ 6 1.1 1.2 1.3 Definizioni ...................................................................................................................................... 6 Caratteristiche principali ............................................................................................................. 10 Tassonomia, sugli assi cartesiani ................................................................................................. 12
Asse x: dove risiedono i dati (cloud deployment models) ............................................................... 13 Private cloud ............................................................................................................................ 13 Public cloud ............................................................................................................................. 14 Community cloud .................................................................................................................... 14 Hybrid cloud ............................................................................................................................ 14 Software as a Service, o SaaS ............................................................................................... 15 Platform as a Service, o PaaS ............................................................................................... 18 Infrastructure as a Service, o IaaS ........................................................................................ 19 Business Process as a Service, o BPaaS ............................................................................... 20 1.3.1.1 1.3.1.2 1.3.1.3 1.3.1.4 1.3.2

1.3.1

Asse y: tipologie di servizi offerti (service models) ........................................................................ 14

1.3.2.1 1.3.2.2 1.3.2.3 1.3.2.4

1.4

Vantaggi e svantaggi .................................................................................................................... 20

CAPITOLO 2. PRINCIPALI TECNOLOGIE CLOUD .......................................................................................... 23 2.1 Virtualizzazione ............................................................................................................................ 23

Tecniche di virtualizzazione ............................................................................................................... 23 Full virtualization ..................................................................................................................... 24 Paravirtualization ..................................................................................................................... 24 Hypervisor ............................................................................................................................... 24 2.1.1.1 2.1.1.2 2.1.1.3 2.1.2 2.1.3

2.1.1

Vantaggi e svantaggi .......................................................................................................................... 25 Stato dellarte ..................................................................................................................................... 25 Xen........................................................................................................................................... 25 KVM ........................................................................................................................................ 26 VMware vSphere (v4.1)........................................................................................................... 27

2.1.3.1 2.1.3.2 2.1.3.3

2.2

Automazione ................................................................................................................................. 29
Automazione del provisioning............................................................................................................ 30 Stato dellarte: IBM Tivoli Provisioning Manager (v7.2) .................................................................. 30

2.2.1 2.2.2

2.3

Service-Oriented Architecture (SOA) ........................................................................................... 32

Definizione ......................................................................................................................................... 32 SOA e il cloud computing .................................................................................................................. 34

2.3.1 2.3.2

CAPITOLO 3. STATO DELLARTE IBM PRIVATE IAAS ............................................................................ 35 3.1 3.2 Offerta private IaaS IBM ......................................................................................................... 35 IBM Tivoli Service Automation Manager (v7.2.1.1) .................................................................... 35

III

3.3 3.4

IBM Service Delivery Manager (v7.2.1) ...................................................................................... 39 IBM Cloud Burst .......................................................................................................................... 42

PARTE II PRATICA .................................................................................................................................. 44 CAPITOLO 4. LA NOSTRA SOLUZIONE PRIVATE IAAS .................................................................................. 46 4.1 4.2 4.3 Analisi .......................................................................................................................................... 46 Progettazione ............................................................................................................................... 48 Implementazione........................................................................................................................... 50
Installazione di ISDM......................................................................................................................... 50 ConfigurazionI di base di ISDM......................................................................................................... 51 Personalizzazioni e configurazioni avanzate ...................................................................................... 53

4.3.1 4.3.2 4.3.3

CAPITOLO 5. AUTOMAZIONE: IL PROVISIONING DI MYSQL PER WINDOWS E RHEL ................................ 54 5.1 Nozioni di base ............................................................................................................................. 54
Sviluppo di provisioning workflow .................................................................................................... 54 Le definizioni software nel data model ............................................................................................... 57

5.1.1 5.1.2

5.2

Implementazione........................................................................................................................... 59
Simple software product ..................................................................................................................... 59 Lautomation package hosting-environment-core ........................................................................... 60 Stack dei workflow per il provisioning di simple software products .................................................. 62 Il workflow Default_SoftwareInstallable_Install................................................................................ 64 Extension point LDO .......................................................................................................................... 65 Il nostro Default_SoftwareInstallable_InstallPre ................................................................................ 66

5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6

CAPITOLO 6. SELF SERVICE: IL PREVENTIVO ............................................................................................ 68 6.1 Linterfaccia web 2.0 di TSAM ..................................................................................................... 68
Una panoramica .................................................................................................................................. 68 Limplementazione ............................................................................................................................. 70

6.1.1 6.1.2

6.2 6.3

Dojo Toolkit.................................................................................................................................. 71 Il preventivo nel pannello CreateProjectWithServer.................................................................... 73

Il pannello per la creazione di un progetto.......................................................................................... 73 Il template ................................................................................................................................ 74 La classe Dojo CreateProjectWithServer ................................................................................. 76 6.3.1.1 6.3.1.2

6.3.1

6.3.2

Implementazione del preventivo......................................................................................................... 79 Personalizzazione del template di CreateProjectWithServer ................................................... 79 Personalizzazione della classe CreateProjectWithServer ......................................................... 80

6.3.2.1 6.3.2.2

6.4

Estensioni della Self Service Station in TSAM 7.2.2 .................................................................... 83

CAPITOLO 7. CONCLUSIONI ...................................................................................................................... 84 7.1 7.2 Ricapitoliamo ............................................................................................................................... 84 Possibili sviluppi .......................................................................................................................... 85
Preventivo: Disaccoppiare i prezzi delle licenze dei sistemi operativi ............................................... 85 Report di chargeback .......................................................................................................................... 86

7.2.1 7.2.2

BIBLIOGRAFIA ............................................................................................................................................. 87

IV

Ringraziamenti

Desidero ringraziare1: Federico Vietti, per essere stato unottima guida aka tutor aziendale, prima; il miglior 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 Brndle 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 fondamentali di una buona programmazione (OOP) tra cui il decoupling, che uso in questo stesso lavoro; Paola Gatti e Simona Castello, per il supporto burocratico; La mia famiglia, per il supporto vario ed eventuale, anche finanziario; Gli amici delluni, 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 traguardo. Infine, un ringraziamento speciale va ai miei appunti.

Troppo schematico?

Introduzione

Il presente lavoro nasce dalla mia collaborazione con Blue Reply2, nonch dalla partnership tra Blue Reply e IBM3. Scopo della tesi progettare una soluzione di private cloud di tipo Infrastructure as a Service (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 teorici su cui si poggia il cloud computing. Dopodich, lo studio stato rivolto verso il Service Delivery Manager, che servito come base per limplementazione della soluzione. Infine, si passati allimplementazione. Questultima ha comportato in primo luogo una pi o meno semplice installazione e configurazione del prodotto IBM, in secondo luogo la scrittura di nuovo codice (funzioni Javascript/Dojo e provisioning workflow di Tivoli Provisioning Manager) per implementare le funzionalit custom. Liter 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 lanalisi, la progettazione e limplementazione 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 dallanalizzare le definizioni pi autorevoli che finora sono state date, ed integrandole si

Blue Reply una societ di consulenza informatica specializzata nellambito della sicurezza. Il nome Blue deriva dalla speciale partnership che la lega ad IBM. Infatti, questultima anche conosciuta con il soprannome di Big Blue. Blue Reply fa parte del gruppo Reply, molto attivo sia in Italia che allestero. 3 IBM un marchio registrato della International Business Machines Corporation (http://www.ibm.com).

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 analizzano i paradigmi cloud pi importanti, quali private, public, hybrid, Infrastructure as a Service (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 dallinglese di enabling) il cloud computing, ovvero quelle tecnologie che lo supportano, che sono: la virtualizzazione, lautomazione e le architetture service-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 seconda 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 limplementazione della soluzione oggetto della tesi, a partire dai requisiti. Sono quindi affrontati lanalisi, la progettazione e liniziale implementazione (installazione e configurazione di base di ISDM). Nei capitoli successivi si affrontano invece le personalizzazioni pi avanzate. Nel Capitolo 5 si implementano i requisiti relativi allautomazione 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 dellinterfaccia web 2.0 di TSAM, dalla quale vengono creati i server virtuali. Dopo uno studio approfondito dellimplementazione dellinterfaccia, limitatamente alla parte che permette la creazione di un nuovo progetto di server virtuali, si discute come pu essere implementata una tabella che mostri allutente un preventivo del progetto che va a creare. Nel Capitolo 7, infine, si tirano le somme e si presentano alcuni possibili punti di estensione della nostra soluzione.

PARTE I - Teoria sul cloud computing

Capitolo 1. Il cloud computing

1.1 Definizioni
Dietro lespressione 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 industry4. Ma Cloud computing un termine (la buzzword del momento, per usare un inglesismo) introdotto di recente nel mondo informatico: ne segue che non esiste una definizione ufficiale. Perci, in questo paragrafo analizzeremo le definizioni date da alcune tra le fonti pi autorevoli sulla scena IT mondiale, e cercheremo di giungere ad una definizione condivisa. Partiamo da unanalogia: Cloud lindustrializzazione dellIT. Pensiamo al processo di industrializzazione, a cosa cera prima e a cosa ha portato in diversi settori. Riguardo allindustria 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 automatizzato, e di conseguenza molto pi efficiente, scalabile ed economico. Nellindustria dellautomobile, Henry Ford rese pi efficiente il processo di produzione introducendo il sistema di lavoro della catena di montaggio. Questo permise di migliorare la qualit del prodotto e nel contempo di abbassare i costi, facendo dellautomobile un bene di massa.

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

Riguardo al settore bancario, una volta, se non riuscivi ad arrivare in banca prima dellora 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 computing si prefigge di fare nel campo dellInformation Technology: rendere i processi IT pi semplici, intuitivi, scalabili e rapidi nellerogazione. In generale, il termine cloud si rif alla nuvola storicamente usata per indicare graficamente Internet, che una rete di reti eterogenee.

Figura 1.1: la Nuvola

Infatti,

nel

cloud

computing

vengono

nascosti

dettagli

dellarchitettura

dellinfrastruttura che c dietro, mentre ci che viene esposto allesterno unicamente il concetto di servizio. Il servizio lentit astratta che lambiente cloud in grado di fornire, e che lutente pu richiedere. I servizi, come vedremo, possono andare dallutilizzo di un certo software, allutilizzo di un intero server (virtuale). Cloud computing un mix di vari modelli computazionali, con i quali viene spesso confuso, quali: 7

 grid computing: modello di calcolo distribuito, parallelo, in cui una serie di calcolatori eterogenei condividono le risorse computazionali; utility computing: un modello incentrato sul pay-per-use, in cui, come nel caso dellenergia elettrica, lutente 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 strumenti necessari per auto-gestirsi senza bisogno dell'intervento umano.

Dopo aver visto una panoramica generale, proseguiamo analizzando alcune definizioni autorevoli, in cui, come vedremo, si possono riconoscere i tratti del grid, dellutility e dellautonomic computing.

1.1.1 NIST La prima definizione che consideriamo quella data in [1] dal National Institute of Standards and Technology (NIST). NIST unagenzia del governo USA la cui missione promuovere linnovazione degli Stati Uniti e la competitivit industriale attraverso la definizione 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 standard 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. Cloud computing is a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

In altri termini, secondo il NIST, il cloud computing un modello di erogazione e consumo on-demand di risorse e servizi IT. Possiamo notare che nella definizione del NIST vengono evidenziati i seguenti aspetti: le risorse computazionali come unit di scambio tra utente/cliente e cloud provider5 (grid computing);

Il cloud provider il fornitore dei servizi cloud

 la rete come mezzo di accesso alle risorse; il carattere on-demand (i.e. su richiesta) dellerogazione di risorse; la rapidit nellerogazione delle risorse allutente; lo scarso livello di gestione e di interazione che richiesto al cloud provider durante lerogazione 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: a style of computing where massively scalable IT-enabled capabilities are delivered as a service to external customers using Internet technologies In questa definizione si pone in particolar modo laccento su tre aspetti: la scalabilit; il servizio come unit atomica di scambio; luso 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: IT resources and services that are abstracted from the underlying infrastructure and provided on-demand and at scale in a multitenant environment.

Qua le parole chiave sono: Risorse IT Servizi astratti On-demand Scalabilit (at-scale)

6 7

Gartner un marchio registrato di Gartner, Inc (http://www.gartner.com). Cisco un marchio registrato di Cisco Systems, Inc. (http://www.cisco.com).

 Ambiente multitenant Osserviamo che quattro su cinque di queste parole chiavi le abbiamo gi incontrate nelle definizioni precedenti. Lunica 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 disponibili su richiesta del cliente/utente, tramite una rete locale (e in questo caso si parla di private cloud8) o tramite Internet (public cloud9); Larchitettura scalabile ed elastica: cio in grado di gestire quantit variabili di carico, secondo le necessit; Una volta che lambiente cloud stato configurato opportunamente, in grado di gestirsi autonomamente, senza bisogno dellintervento 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 ununica teorizzazione, ma diverse. Procediamo quindi ad analizzare le pi importanti, 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:

Come vedremo nel paragrafo 1.3.1.1, il private cloud un cloud locato e gestito internamente allorganizzazione che lo utilizza 9 Al contrario del private cloud, il public cloud locato e gestito esternamente allorganizzazione che lo utilizza (vedi par. 1.3.1.2)

10

 Self-service on-demand: lutente finale, in ogni momento, pu autonomamente fare 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 richieste 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: lutilizzo delle risorse pu essere monitorato e controllato 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 sullutilizzo, utili sia al cloud provider che allutente finale.

1.2.2 IBM Al contrario del NIST; IBM in [4] adotta un taglio pi commerciale, di alto livello e orientato 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, public o private: Catalogo dei servizi: linterfaccia tra lutente e lambiente cloud; a sua volta, il catalogo pu essere consultato dallutente attraverso uninterfaccia web, tramite la quale lutente pu inoltrare le richieste di servizi.

10

Microsoft un marchio registrato di Microsoft Corporation (http://www.microsoft.com).

11

 Automazione: una caratteristica invisibile allutente finale, che permette di nascondere la complessit che c dietro al soddisfacimento di una richiesta di un servizio. Ne parleremo in dettaglio nel paragrafo 2.2. Virtualizzazione: tecnologia nata diversi decenni fa, lingrediente fondamentale di un ambiente cloud. La virtualizzazione sar approfondita nel paragrafo 2.1. Metering: la capacit di fornire informazioni e statistiche sullutilizzo 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 fatture a partire dai dati di utilizzo forniti dal metering, usando un insieme di policy di fatturazione stabilite a priori. Customerfocused: come nel settore retail, il cliente viene prima di tutto, perci gli deve essere completamente rivolta lattenzione di coloro che gestiscono lambiente 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 riceve la fattura.

1.2.3 Sintesi In conclusione, possiamo dire che unarchitettura cloud, per essere chiamata come tale, deve essere composta dai seguenti pilastri: virtualizzazione, automazione, billing e chargeback. Deve inoltre essere caratterizzata da un alto grado di elasticit e scalabilit (sia verso lalto che verso il basso, cio sia che lutilizzo del sistema cresca, sia che diminuisca). Infine, deve essere presente uninterfaccia user-friendly (il catalogo dei servizi) che permetta allutente 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 per12

ch, come gi stato detto, il cloud computing una branca dellinformatica 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'organizzazione stessa oppure da terzi (managed private cloud); inoltre pu risiedere allinterno dei locali dellorganizzazione (on premise) o essere ospitata nei locali di terzi (off premise, hosted private cloud).

13

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

Linfrastruttura 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 community cloud); inoltre pu essere on premise o off premise (hosted community cloud). 1.3.1.4 Hybrid cloud

Nellhybrid, larchitettura 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 rese 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 tipologie di cloud (anche detti service models) [1]: Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) 14

Questi tre, come potremo dedurre dalle relative definizioni del NIST, si differenziano sostanzialmente per il livello di controllo (in ordine crescente) che viene concesso allutente sullinfrastruttura 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) Questultimo 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]: Software deployed as a hosted service and accessed over the Internet.

In [1], il NIST d una definizione pi completa: The capability provided to the consumer is to use the providers applications 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 possible exception of limited user-specific application configuration settings.

15

In altre parole, SaaS un modello di distribuzione centralizzata del software, in cui il servizio cloud fornito consiste nellutilizzo on-demand di un software in forma di applicazione web, tipicamente accessibile attraverso un browser. Vantaggi e svantaggi Come indicato in [6], in confronto al tradizionale modello di distribuzione del software che prevedeva linstallazione da CD (o da altre fonti) sulla propria macchina, il modello SaaS apporta alcuni benefici per lutente, dal momento che, grazie alla centralizzazione, oneri che prima erano in carico allutente, ora sono spostati a carico del cloud provider. Daltra parte, per le stesse ragioni, il SaaS presenta anche dei problemi. Analizziamo prima i vantaggi: Piccole (se non nulle) conseguenze sulla macchina dellutente Lutente, 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 potenziale problema di conflittualit tra il nuovo software e lambiente locale. Questo punto rappresenta un beneficio anche per il cloud provider. Infatti, gli comporta 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 lutente nei costi di aggiornamento delle sue macchine Dato che lapplicazione viene eseguita sulle macchine del provider, lutente ottiene un risparmio in termini di risorse computazionali della sua macchina, e, di conseguenza, un risparmio nei costi di aggiornamento hardware o software della macchina, che potrebbe essere necessario per soddisfare i requisiti minimi della nuova applicazione. Ottimizzazione delle licenze software La gestione delle licenze risulta semplificata. Un cliente pu ora acquistare una singola licenza ed utilizzarla su pi computer in momenti diversi. cos possibile evitare di comprare molteplici licenze, una per ogni computer, con il rischio di non sfruttarle tutte allorquando uno di quei computer non venga utilizzato.

16

 Centralizzazione dellamministrazione dellapplicazione e dei dati Il cloud provider ha lonere della gestione e del controllo sia dellapplicazione che dei dati di ogni utente, i quali sono memorizzati sui server del cloud provider. Il lato positivo che lutente 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. Inoltre, lutente anche esonerato dal rischio di portare con s i dati durante gli spostamenti, poich essi sono sempre disponibili sulla nuvola. Infine, se supportata da logiche applicative, la gestione centralizzata agevola la condivisione dei dati con altri utenti cloud. Sullaltro lato della medaglia, troviamo tre principali punti problematici: Sicurezza dei dati La centralizzazione dei dati, se da un lato fornisce una certa sicurezza per lutente, dallaltro potrebbe costituire un grosso problema se il cloud provider non in grado di proteggerli pi che adeguatamente. Sicurezza del browser web Come abbiamo visto, lunico punto di accesso per lutente alla fruizione del SaaS il browser. Di conseguenza, esso un potenziale punto debole del sistema. Forte dipendenza dalla rete Dato che lapplicazione 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 funzionalit del software non fossero disponibili. Esempio: Google Docs Un esempio molto famoso di SaaS sono i Google11 Docs, una suite per ufficio che comprende un word processor, un foglio di calcolo, unapplicazione 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)

17

1.3.2.2

Platform as a Service, o PaaS

Di seguito riportiamo la definizione di PaaS data dal NIST [1]: The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming 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 applications and possibly application hosting environment configurations.

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. Vantaggi e svantaggi 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 responsabilit 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 seguenti problemi: Portabilit tra differenti provider PaaS Ogni cloud provider usa implementazioni proprie (es: linterfaccia delle strutture dati come la hash table) che rendono molto difficile il trasloco di un software da un provider allaltro, 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 dellefficienza, perch non permette di sfruttare appieno le possibilit offerte da uno specifico provider.

18

 Complessit di unapplicazione PaaS A differenza di unapplicazione che deve essere eseguita in un ambiente locale e isolato, unapplicazione PaaS molto pi complessa, in primo luogo perch deve accedere alla rete. Perci, lo sviluppatore deve considerare molteplici aspetti concernenti la sicurezza delle trasmissioni (la crittografia su tutti), e deve padroneggiare molte tecnologie e linguaggi di programmazione (HTML, HTTP, XML, ecc.). Esempio: Google App Engine Google App Engine lofferta PaaS di Google, una piattaforma che permette lo sviluppo di applicazioni web e lhosting 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 macchina per cominciare a sviluppare. Lutilizzo della piattaforma di Google gratuito, almeno inizialmente, ed possibile poi acquistare aggiuntive risorse computazionali, di memoria 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. Infatti, il servizio fornito dallo IaaS essenzialmente lutilizzo di una macchina virtuale. Il livello di controllo per lutente inversamente proporzionale a quello di astrazione: lutente pu infatti configurare la macchina dalle fondamenta, a partire dalla scelta del sistema operativo. Di seguito riportiamo la definizione del NIST [1]: The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

12 13

Java un marchio registrato di Oracle (http://www.oracle.com). Go un linguaggio di programmazione imperativo nato nel 2009 e sviluppato da Google.

19

Vantaggi e svantaggi 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 applicazioni che si possono portare nel cloud (es: legacy). Tra gli svantaggi, invece, citiamo: luso 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 problemi 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 lintero processo, 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 paragrafo 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 allottimizzazione delle tempistiche di progetto;

20

 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 particolare, positivo per le start-up e per le PMI (Piccole e Medie Imprese), le quali non si possono economicamente permettere uninfrastruttura 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 allorganizzazione: 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 dellinfrastruttura; Migliore controllo economico sugli asset IT, grazie al sistema di billing e chargeback; Minore spreco di tempo e di risorse umane per la piccola manutenzione, grazie allautomazione. Parlando invece dei problemi insiti nel cloud computing, il pi rilevante legato alla sicurezza, e costituisce probabilmente il principale ostacolo alladozione del cloud. La sicurezza 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 elettronico; 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 controllo. 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 21

pi ambienti cloud di provider differenti (interoperabilit). Ci causato dalla mancata adozione di standard aperti da parte dei cloud provider. Uniniziativa che va in tale direzione 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, questo manifesto supportato da oltre 400 organizzazioni14. Lultimo 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 prevedere quali saranno i livelli di utilizzo dei servizi cloud. In questa sede non ci addentriamo nellargomento; per un approfondimento vedere [10]. Infine, a tutti questi problemi se ne pu aggiungere un altro: il problema del digital divide, in particolare nellaccezione che indica la scarsa qualit delle infrastrutture di rete di un paese. Un esempio lItalia, dove la banda larga arrivata a 20Mbps in downlink solo recentemente e solo in poche aree.

14

http://www.opencloudmanifesto.org/supporters.htm

22

Capitolo 2. Principali tecnologie cloud

2.1

Virtualizzazione

Il primo passo verso ladozione del cloud consiste nel virtualizzare linfrastruttura. 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, network virtualization, storage virtualization, operating system virtualization, full virtualization, paravirtualization, partial virtualization. Senza perderci in inutili nozionismi, focalizzeremo 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 virtualization. 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 applicazioni. In un contesto cloud, usata nel modello IaaS. Esistono due tecniche implementative principali: full virtualization e paravirtualization. Il sistema software che si occupa dellinserimento del livello di astrazione chiamato hyper23

visor o Virtual Machine Monitor (VMM). Il sistema operativo virtuale viene detto guest OS, mentre il sistema operativo che contiene lhypervisor viene anche detto host. 2.1.1.1 Full virtualization

La tecnica di virtualizzazione di tipo full prevede che lhardware sia interamente simulato dallhypervisor. Questultimo 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 linstruction set della CPU. Tale approccio permette di minimizzare loverhead dovuto allhypervisor; 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 processo completamente trasparente al guest OS, la paravirtualizzazione richiede una sostanziale modifica del codice del sistema operativo guest. Infatti, questa tecnica si limita a esporre al guest OS uninterfaccia 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, dallaltra, lhypervisor 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 sullhardware, come un sistema operativo Tipo 2 (o hosted): viene eseguito allinterno di un sistema operativo host Come si pu immaginare, non essendoci alcuna intermediazione tra lhypervisor e lhardware, il tipo 1 quello che raggiunge le migliori performance. Il tipo 2 pu essere

15 16

Intel un marchio registrato di Intel Corporation (http://www.intel.com). AMD un marchio registrato di Advanced Micro Devices, Inc. (http://www.amd.com).

24

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 server, 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 lisolamento: 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 lindipendenza dallhardware. Ci vuol dire che possibile spostare una macchina virtuale da un computer allaltro (portabilit), senza badare allhardware sottostante. il caso di rilevare che questo punto viene meno se parliamo di hardware-assisted virtualization. Tra gli svantaggi principali bisogna citare loverhead introdotto dallhypervisor e la conseguente riduzione delle prestazioni globali; inoltre, i problemi che possono sorgere in caso di periferiche non virtualizzabili (accelerazioni grafiche comprese) [11].

2.1.3 Stato dellarte In questo paragrafo vedremo i principali hypervisor enterprise supportati dal Service Delivery 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 operativi guest, inclusi Windows17, Linux18, Solaris19, e varie versioni di BSD. Come tecnolo-

17

Windows un marchio registrato di Microsoft Corporation (http://www.microsoft.com).

25

gie, implementa in primo luogo la paravirtualizzazione; invece, per i sistemi operativi non paravirtualizzabili (ad esempio Windows), Xen sfrutta le funzioni di virtualizzazione messe 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 virtualizzazione (Intel VT o AMD-V). KVM composto da un modulo kernel che fornisce linfrastruttura virtuale di base (kvm.ko), e da un modulo specifico per il processore (kvmintel.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 memoria, e ci fa s che risulti molto pi leggero di Xen.

Figura 2.1: Xen (a sinistra) e KVM (a destra) a confronto

18 19

Linux un marchio registrato di Linus Torvalds (http://www.linuxfoundation.org). Solaris un marchio registrato di Oracle Corporation.

26

2.1.3.3

VMware vSphere (v4.1)

VMware20 attualmente lazienda leader di mercato nel settore della platform virtualization 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 virtualizzazione 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 allocare risorse hardware e risorse infrastrutturali. I principali sono: VMware vCompute: insieme di servizi che astraggono e aggregano le risorse provenienti da diverse macchine fisiche VMware vStorage: permette un utilizzo e una gestione efficiente dello storage in ambienti virtuali VMware vNetwork: semplifica e migliora il networking in un ambiente virtuale 2. Application Services: garantiscono disponibilit, sicurezza, e scalabilit per le applicazioni. Es: High Availability e Fault Tolerance 3. VMware vCenter Server: punto di controllo dellintero datacenter, fornisce i servizi essenziali per un datacenter, quali il controllo degli accessi, il monitoring delle prestazioni, e la configurazione 4. Clients: laccesso a vSphere pu avvenire attraverso VMware vSphere Client (un software per Windows che funge da interfaccia) o attraverso Web Access (unapplicazione 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 anche 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 consente di controllare tutti gli ESX da un unico punto.

20

VMware un marchio registrato di VMware, Inc. (http://www.vmware.com).

27

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 larchitettura. Infatti, oltre al VMkernel, ESX contiene un kernel Linux che funge da console amministrativa (console operating system, o COS) e da bootstrap per il VMkernel. ESXi, invece, non ha il COS, e risulta perci 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 laffidabilit dei servizi monitorando costantemente sia i server fisici con ESX/ESXi sia le macchine virtuali che vi poggiano so28

pra. Non appena avverte un potenziale guasto del server fisico o un errore del sistema 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 lesecuzione da un ESX allaltro senza alcuna interruzione di servizio, mantenendo costante la disponibilit e lintegrit delle transazioni; vMotion Storage: permette la migrazione live dei file delle VM, da un datastore allaltro, 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 dallutente, 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 consumo 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, lautomazione rappresenta il secondo step verso lacquisizione di un ambiente cloud. In uninfrastruttura virtuale, lamministrazione una grande sfida. Se costruita senza un adeguato approccio amministrativo, la virtualizzazione pu aumentare la complessit dellinfrastruttura e pu quindi essere fonte di ulteriori costi, anzich di risparmio. Lautomazione la risposta a questi problemi, in quanto una tecnica che semplifica la gestione dellambiente fisico che fornisce le risorse ai server virtuali. Ci vuol dire che sopra lhypevisor, che continua a fare il suo lavoro, c un livello in pi rappresentato dal sistema di automazione del provisioning, che guida la mano dellhypervisor nel creare e distruggere macchine virtuali, storage virtuale e infrastrutture di rete virtuali. Un altro grande beneficio apportato dallautomazione la capacit di fornire servizi IT ondemand con un alto grado di agilit e scalabilit, requisiti fondamentali in un ambiente cloud dove i bisogni possono continuamente cambiare, e lIT deve essere in grado di stare al passo. 29

2.2.1 Automazione del provisioning In un datacenter, lautomazione utile principalmente in due ambiti: per lonboarding e per loffboarding. Lonboarding quel processo in cui, dopo aver creato una VM, si installa e configura il sistema operativo, la rete, lo storage e le applicazioni che si desiderano. Loffboarding il processo opposto, ovvero quello in cui si distrugge una VM e si rendono nuovamente disponibili le risorse hardware che teneva occupate. In genere, lonboarding di unapplicazione inizia con il provisioning (fornitura) di un server. Se fatto manualmente, un processo lungo, complesso e soggetto ad errori, che richiede amministratori con elevate competenze nelle aree dei sistemi, delle reti e dello storage. Grazie allautomazione, 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 dellarte: IBM Tivoli Provisioning Manager (v7.2) Tivoli21 Provisioning Manager (TPM) comprende un server di provisioning, una console web delloperatore e dellamministratore, e un ambiente di sviluppo [16]. Lelemento base di tutto il sistema il cosiddetto provisioning workflow, un pezzo di codice 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 uninfrastruttura 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 software o di ununit fisica. possibile utilizzare i pacchetti di automazione per automatizzare 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 sistemi 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/)

30

In Figura 2.3 vengono illustrati i componenti principali di TPM, e il modo in cui interagiscono con linfrastruttura IT e con le altre applicazioni dellambiente.

Figura 2.3: Larchitettura di TPM

31

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 dellhardware e delle relative assegnazioni alle applicazioni e delle modifiche alla configurazione. Quando un provisioning workflow completa correttamente una modifica richiesta, il data model viene aggiornato per riflettere linfrastruttura corrente. Inoltre, il data model memorizza le informazioni 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 informazioni. I componenti che si occupano del deployment sono due, uno alternativo allaltro. Il deployment engine (modalit agent-less) esegue i pacchetti di automazione e i provisioning workflow, comunicando al termine il successo o meno delloperazione. Invece, linfrastruttura di distribuzione scalabile (Scalable Distribution Infrastructure, SDI) sfrutta i Tivoli Common Agent (TCA), presenti sulle macchine target, per eseguire il deploy.

2.3

Service-Oriented Architecture (SOA)

2.3.1 Definizione Come dice la parola stessa, SOA uno stile architetturale orientato al servizio che definisce come i servizi sono offerti e utilizzati. In altri termini, SOA unarchitettura i cui componenti 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 dellorganizzazione che lo espone, ma anche da un altro servizio o da unapplicazione. Spesso, i servizi sono orchestrati come processi di business. Un servizio [17]: una rappresentazione logica di unattivit di business ripetibile con un risultato ben preciso (es.: verificare la carta di credito del cliente oppure fornire informazioni metereologiche) 32

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 piattaforme 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 runtime. 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 lente che fornisce un servizio Service requester lente che usufruisce di un servizio Service broker lente che permette lincontro 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.

33

2.3.2 SOA e il cloud computing Nel cloud computing, intere infrastrutture IT virtuali, piattaforme e applicazioni sono implementati 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 models, 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.

34

Capitolo 3. Stato dellarte IBM private IaaS

3.1

Offerta private IaaS IBM

Poich lobiettivo perseguito in questo lavoro progettare e implementare un sistema private cloud IaaS partendo da una soluzione IBM, in questo capitolo analizzeremo solo i prodotti di cloud computing commercializzati da IBM, limitatamente allambito private IaaS. Lofferta 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 personalizzabile, 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 lautomazione del deploy di interi panorami IT, comprensivi di server, reti, sistemi operativi, middleware e software applicativi, e una piattaforma userfriendly 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) uninterfaccia 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 dallessere basati su processori x86.

35

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 includono [19, p. 9]: Creare server virtuali allinterno di un nuovo progetto di deployment, o aggiungere nuovi server virtuali ad un progetto esistente, con la possibilit di posticipare in un momento futuro leffettivo 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 essere utilizzate da altri server; Salvare unimmagine 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 dellambiente cloud, e consente 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, laggiunta di stack di software che possono essere installati sui server virtuali. Dopo una panoramica generale, vediamo pi da vicino larchitettura di TSAM. Innanzitutto, 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.

36

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 deploy e lundeploy di server virtuali). Grazie a SRM, le complesse funzionalit di Service Management fornite da TSAM sono presentate agli utenti nella forma astratta di service offerings, ossia come servizi che possono essere richiesti dagli utenti attraverso lOffering 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 uninterfaccia REST. Tutto ci sfruttato dallinterfaccia web 2.0 di self service per realizzare unulteriore astrazione rispetto a SRM (vedi Figura 3.2).

37

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 sullambiente 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 allinterno dellOffering Catalog di SRM; 4. Gli Offering panel (classi Dojo) dellinterfaccia web 2.0 di self service; 5. Le object structure di MEA, che consentono laccesso ai Maximo Business Object (MBO). Nella seconda parte di questo lavoro, sfrutteremo i punti 2 e 4 (rispettivamente, nel Capitolo 6 e nel Capitolo 5) per implementare le personalizzazioni richieste.

38

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 lanalisi delle prestazioni (ITM), e un sistema di accounting e tracking dellutilizzo (ITUAM), che consente laddebitamento 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 linstallazione consiste semplicemente nellimportare queste immagini virtuali nellhypervisor, avviarle, ed infine eseguire un wizard per configurarle.

39

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

40

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. Lagente di monitoring di ITM risiedente su TSAM invia i dati sullutilizzo (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 lIP di TSAM 4. Lagente di monitoring che gira su ITUAM invia dati al server ITM 5. NFS fa il redirect dellinterfaccia utente di ITUAM verso il suo IP 6. Lagente di monitoring che gira su NFS invia dati al server ITM 41

Inoltre, in una configurazione che prevede lHigh Availability, vi sono anche le seguenti relazioni: 7. Lagente di monitoring che gira su NFS-HA (la VM di NFS che gestisce lHigh 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. Lagente di monitoring che gira su TSAM-HA (la VM di TSAM che gestisce lHigh 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 hypervisor 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 operativi 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 hardware (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 integrato in ITM per ottimizzare i costi operazionali. Per il resto, del tutto uguale a ISDM.

23 24

IBM Tivoli System Automation un prodotto IBM che fornisce un ambiente con High Availability. Red Hat un marchio registrato di Red Hat, Inc (http://www.redhat.com). 25 SuSE un marchio registrato di SuSE Linux AG (http://www.suse.com).

42

43

PARTE II Pratica

44

45

Capitolo 4. La nostra soluzione private IaaS

4.1

Analisi

Immaginiamo di avere un cliente, che chiameremo C, che ci fornisca i requisiti. C attualmente 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 allApplication Manager26 (AM) di riferimento. Questultimo mette in moto il processo burocratico e tecnico che porta alla creazione del server, che consta dei seguenti passaggi (alcuni burocratici, altri tecnici): 1. LAM compila un form su un portale web specificando i requisiti hardware e software del server di cui ha bisogno, quali: virtual hardware, sistema operativo, software 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. Dellinstallazione 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 nellutilizzare quellapplicazione. 27 Il Chief Technical Officer (CTO) un manager di primo livello e membro del direttivo di unazienda 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.

46

c. System integrator per lintegrazione 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 lunghi: infatti, ognuno dei passaggi mostrati sopra pu richiedere da alcuni giorni ad alcune settimane per essere completato. Per superare queste difficolt e lungaggini, lambiente cloud deve presentare uninterfaccia 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 virtuali, il cui deploy deve avvenire non prima che sia stata data lapprovazione 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 carattere tecnico, dallaltra consente di preservare, e nello stesso tempo velocizzare, i passaggi burocratici, che sono comunque necessari per una corretta gestione formale di una qualunque organizzazione. C vuole che i server virtuali che si possono creare via cloud abbiano come sistema operativo Windows Server 2008 o Red Hat Enterprise Linux 5.6, in funzione delle esigenze dellutente 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 allutente di scegliere se il server da creare debba essere equipaggiato del solo sistema operativo, o se ci deve essere anche installato MySQL Server e/o MySQL Client (sia su Windows che su RHEL). Se da un lato, con ladozione del cloud, si vuole semplificare e rendere trasparente il processo di deploy di server virtuali, dallaltro 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 dellambiente cloud e ai CTO un report di utilizzo suddiviso per team. Questo gli consente di fare la cosiddetta Capacity Planning: cio, tene47

re sotto controllo lambiente, capire quali sono i livelli di utilizzo dellinfrastruttura, e pianificare la capacit (in termini di risorse hardware) che sar necessario supportare in futuro. In questottica, C vuole iniziare ad introdurre nellambiente cloud il chargeback. Inizialmente, vuole solo che linterfaccia da cui vengono creati i server mostri un preventivo dei costi, in modo da far familiarizzare lutente 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 richiesti, per il periodo specificato dallutente. Deve inoltre mostrare il dettaglio dei costi parziali per ogni tipo di risorsa (CPU, memoria, spazio disco, licenza del sistema operativo). Il preventivo deve essere dinamico, nel senso che si deve aggiornare automaticamente ogni volta che lutente modifica la quantit di una risorsa: cos, egli ha la possibilit di calibrare la configurazione hardware e software dei server in modo da massimizzare il rapporto 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 installazione di ISDM, otteniamo un ambiente cloud private IaaS perfettamente funzionante. Il requisito relativo allinterfaccia user-friendly viene gratuitamente soddisfatto da ISDM, che, attraverso TSAM, equipaggiato della Self Service Station (vedi paragrafo 3.2). Questultima 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 sistema di gestione degli utenti che definisce quattro ruoli distinti [19, p. 2]: Cloud administrator: amministratore dellintero sistema cloud; ha pieni poteri, e in particolare lunico che pu eseguire i seguenti compiti: o creare nuovi team e nuovi utenti; o modificare le proprie informazioni; o registrare e de-registrare immagini software;

48

o permettere lallocazione 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 appartenenza); 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 appartiene); 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 appartiene); 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 administrator saranno gli Application Manager che devono poter creare nuovi server virtuali allinterno di progetti (seguendo la terminologia di TSAM); i Team user saranno i componenti 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 lapprovazione da parte di un manager delle richieste di deploy prima che vengano effettivamente processate. Siccome di default tutte le richieste sono auto-approvate; limplementazione di questo requisito richiede lesecuzione 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. 49

Per quanto riguarda i requisiti relativi ai sistemi operativi, invece, per implementarli dovremo 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, dovremo studiare e configurare lautomazione 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

Limplementazione 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 nellhypervisor; 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). Loutput di questo step costituito da quattro file XML, uno per ogni immagine virtuale, che rappresentano gli OVF environment28. Dopodich, si importano le immagini nellhypervisor. 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 laltra le macchine vir-

28

Open Virtualization Format (OVF) uno standard aperto per la creazione e la distribuzione di applicazioni virtuali o pi comunemente di software che possa essere eseguito su macchine virtuali. Un OVF environment definisce alcune configurazioni della VM, come ad esempio le impostazioni IP (indirizzo IP, netmask, 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)

50

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

Dopo aver installato e avviato tutte le immagini che compongono ISDM, necessario compiere alcuni passaggi per configurare lambiente cloud. Innanzitutto, bisogna configurare TSAM affinch si possa collegare con lhypervisor: a tale scopo, bisogna personalizzare 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, bisogna importare il certificato SSL del vCenter in TPM, nel truststore della JRE. Successivamente, bisogna definire e configurare il Cloud pool attraverso la personalizzazione del file vrpool.properties, e importarlo in TSAM; al termine di questi passaggi, bisogna convalidare il Cloud pool. 51

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 unoperazione relativa ai server virtuali, il sistema di notifica invia una email agli utenti interessati dalloperazione. Ad esempio, quando viene creato un nuovo progetto di server virtuali, il sistema, dopo aver eseguito il deploy dei server richiesti, invia la password dellutente 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 linvio 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 lapprovazione automatica di tutte le richieste bisogna accedere allinterfaccia amministrativa di TSAM, selezionare Go To, System Configuration, Platform 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 duso, creiamo due team, e per ognuno di essi definiamo 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 inoltrate 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, bisogna 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 approfondimenti sui vincoli che devono essere rispettati, diversi da un SO allaltro, vedere [19], Creating operating system image templates, e [22]); infine si spegne la VM e la si converte in template. 52

Dopodich, si registra il template nellinventario di VMware, si carica limmagine del SO nel datastore dellhypervisor, 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 consiste nellaggiungere in TPM la software definition dellagente di monitoring allinterno 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 rilevanti e interessanti, necessarie per soddisfare i requisiti. In particolare: Limplementazione del preventivo nella Self Service Station Limplementazione dellautomazione del provisioning di MySQL

53

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 largomento analizzando gli strumenti messi a disposizione da TPM per gli sviluppatori e studiando i concetti di base relativi allinstallazione di software su TPM.

5.1.1 Sviluppo di provisioning workflow

Figura 5.1: Relazioni tra provisioning workflow

54

Un provisioning workflow rappresenta la reale implementazione di uno specifico processo IT. Come mostrato in Figura 5.1, un workflow non lunico elemento coinvolto nel processo 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 interfacce, 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 quellasset. 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 principale che permette di realizzare decoupling, cio unindipendenza dalle implementazioni. Alcuni tra gli LDO pi comunemente usati sono Device.ExecuteCommand e Device.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 language, che mette a disposizione dello sviluppatore quattro costrutti: DCMQuery, DCMInsert, DCMUpdate e DCMDelete. DCMQuery permette di ricavare informazioni sugli oggetti 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. Unespressione DCM* una lista, separata da slash, di nomi di elementi29, attributi, operatori e condizioni che descrivono un percorso in un database relazionale [23, p. 37]. Ad esempio, lespressione seguente restituisce il nome della macchina di ID 2816.

29

Per conoscere i nomi degli oggetti e degli attributi che si possono usare in unespressione DCM*, consultare il file $TIO_HOME\xml\DcmObjectMappingsDocument.xml presente sulla macchina TSAM.

55

/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 relazionale/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-byresource-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" physicalresource="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-d0e485b420b3a41f" /> <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" authcompulsory="true" role="host"> <default-sap operation-type="file-transfer" /> <default-sap operation-type="execute-command" /> </sap> <software-resource name="VMware Template -- WIN2k8x86template" displayname="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" softwareresource-type="INSTALLATION" software-resource-template-source="/VMware Template -- WIN2k8x86template/Default Template/PMRDPDefaultInstallation" multiplicity-type="Unspecified" software-configuration-type="Regular" isselected="true" is-default="false" is-deployable="true" />

30

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

56

<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" isshared="false"> <property component="KANAHA" name="ODSDS_auto-generated" value="true" /> </resource-allocation> <resource-allocation physical-resource="rbstore" how-many="0" size="20.0" isshared="false"> <property component="KANAHA" name="ODSDS_auto-generated" value="true" /> </resource-allocation> <resource-allocation physical-resource="mem" how-many="1596" size="1596.0" is-shared="false"> <property component="KANAHA" name="ODSDS_auto-generated" value="true" /> </resource-allocation> <resource-allocation physical-resource="vNIC" how-many="1" size="0.0" isshared="true"> </resource-allocation> </server>

Lultimo 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 booleane, 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 complicato implementare altrimenti, invocandoli dallinterno 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 possibile installarci il software rappresentato dalla definition. Esempi di requisiti includono hardware o software che devono essere disponibili sul target;

57

 Capability: un attributo che viene ereditato dalla macchina target quando ci si installa il software. Una capability serve a soddisfare un requirement; Software configuration template: i parametri per linstallazione e la configurazione 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 fornisce 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, aggiunge contestualmente delle informazioni al DCM, chiamate software resources. Una software resource creata in base alle informazioni definite nei software configuration template, che contengono i parametri di default per linstallazione. Per ogni configuration template viene creata una software resource in cui vengono memorizzati i valori dei parametri attuali che sono usati durante linstallazione sul sistema target (infatti, durante linstallazione possibile usare dei parametri diversi da quelli di default).

Figura 5.2: Scenario di installazione da TPM

58

In Figura 5.2 vediamo uno scenario di installazione di un software. In questo esempio assumiamo che nel software catalog sia memorizzata la software definition di DB2, caratterizzata da un nome (DB2 for Windows), un requirement (Windows 2000 Server), una capability (DB2 Versione 8.2), un installable, e tre software configuration template. Quando viene installato su un target, nel DCM verranno aggiunti tre software resource (uno per ogni software configuration template) allinterno della definizione della macchina target, uno di tipo installation e due di tipo instance.

5.2

Implementazione

Nella trattazione dellimplementazione faremo riferimento alla sola installazione di MySQL Server. Per MySQL Client valgono le medesime considerazioni.

5.2.1 Simple software product Per implementare lautomazione del provisioning di MySQL Server si sono seguiti i passi della guida per lutente di TPM [24] relativi allinstallazione di un cosiddetto simple software product, espressione con la quale si intende un software la cui installazione richiede un semplice scompattamento di un file compresso, o lesecuzione di un comando di installazione silenziosa (cio in background, senza interazione con lutente). Infatti, nel caso preso in esame, il pacchetto di installazione di MySQL Server per Windows 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 uninstallazione, mentre il parametro /q indica di non mostrare alcuna interfaccia utente. Similmente, per linstallazione 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 unestensione che identifica i file la cui installazione gestita dal Windows Installer, lo strumento ufficiale Microsoft per linstallazione 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.

59

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

dove il parametro i indica di eseguire uninstallazione. 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 HostingEnvironment:REDHAT: Install Only per RHEL). Infine, affinch il software sia selezionabile 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 provisioning di MySQL Server per Windows, si otteneva il seguente errore:
Cannot find an implementation of the HostingEnvironment.Host LDO for the OS VMware Template -- 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 definizione del sistema operativo. Paradossalmente, questa soluzione funziona non solo per RHEL ma anche nel caso di Windows.

5.2.2 Lautomation package hosting-environment-core Dimostriamo per assurdo laffermazione precedente, provando ad aggiungere il workflow Windows_HostingEnvironment_Host alla definizione del sistema operativo. In questo caso, la situazione non migliora di molto, e lerrore 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="".

60

Il motivo di questo comportamento che TSAM vuole che sui guest Windows sia installato 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 dellautomation package hosting-environment-core progettati per Windows. Di conseguenza, TSAM tratta le VM Windows come se non ci fosse cygwin. Nello specifico, vengono 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 dambiente Windows %TEMP%, esegue 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 file 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 temporanea 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 Lelenco di workflow stato reperito consultando i log di TPM, nella sezione Provisioning workflow status dellinterfaccia web di TSAM.

61

Ma, sempre a causa del path errato, anche questa operazione fallisce. Fallisce inoltre perch cygwin non sa interpretare i parametri in stile windows di rmdir, /S e /Q. Specificando invece RedHat_HostingEnvironment_Host, vengono ancora invocati i workflow dellautomation package hosting-environment-core, ma questa volta le versioni 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, LocalFileRepository_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 installazione 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 lerrore Cannot find an implementation of the HostingEnvironment.Host LDO basta associare il workflow RedHat_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 logico 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 limplementazione della LDO HostingEnvironment.Host allinterno della definizione di ogni nuova VM che viene creata. evidente che questa operazione non pu non essere automatizzata, altrimenti verrebbe meno il concetto di self service per la creazione di server Windows con contestuale installazione di un qualunque simple software product.

62

Seconds.Milliseconds 12.357 12.484 12.530 12.544 12.805 12.817 12.819 12.827 14.378 14.540 14.610 14.617

Text Start workflow: 'SoftwareModule$Install' Start workflow: 'Default_SoftwareModule_Install' Start workflow: 'SoftwareInstallable$Install' Start workflow: 'SoftwareInstallable$InstallPre' Start workflow: 'Default_SoftwareInstallable_InstallPre' Default implementation for the SoftwareInstallable.InstallPre logical operation. End workflow: 'Default_SoftwareInstallable_InstallPre' End workflow: 'SoftwareInstallable.InstallPre' Created software resource ID: 13877 Start workflow: 'Default_SoftwareInstallable_Install'

Log Level debug debug debug debug debug debug debug debug info debug

10864 info Calling the implementation of HostingEnvironment.Host debug named Windows_HostingEnvironment_Host Start workflow: 'HostingEnvironment$Host' HostedSoftwareResourceID: 13877 Start workflow: 'Windows_HostingEnvironment_Host' Start workflow: 'HECore_Windows_HostingEnvironment_Host' debug info debug debug

14.619 14.652 14.670 14.675

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

Lobiettivo di questo paragrafo quindi quello di studiare quali provisioning workflow vengono invocati per installare un simple software product, con lo scopo di trovare un modo per associare RedHat_HostingEnvironment_Host alla definizione del SO della VM. Partiamo dai log di TPM relativi allesecuzione 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 interfacce 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 dellautomation package cui appartiene.

1. SoftwareModule.Install (core) 2. Default_SoftwareModule_Install (default-device-model) 3. SoftwareInstallable.Install (core) 63

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 template. Essendo un LDO, SoftwareModule.Install richiama la sua implementazione, che nel caso dei simple software product risulta essere Default_SoftwareModule_Install. Questo poi invoca lLDO SoftwareInstallable.Install, che serve a installare un software product su un device usando un software resource template. A questo punto, SoftwareInstallable.Install fa tre chiamate: la prima allExtension point LDO35 SoftwareInstallable.InstallPre, la seconda alla sua implementazione Default_SoftwareInstallable_Install, e la terza ed ultima allExtension point LDO SoftwareInstallable.InstallPost. Ci che importante notare che HostingEnvironment.Host invocato dal workflow Default_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 limplementazione di default della LDO SoftwareInstallable.Install. Il suo compito quello di richiamare il workflow HostingEnvironment.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 lID della software resource del SO installato sulla VM.

35

Vedi paragrafo 5.2.5.

64

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 uneccezione 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 lespressione Java[SoftwareHelper#getWorkflowName(OperatingSystemID, ment.Host")] "HostingEnviron-

restituisce sempre None. Allora, quello che dovremmo fare aggiungere

a OperatingSystemID il workflow RedHat_HostingEnvironment_Host prima che la variabile WorkflowName sia valorizzata. Ma prima quando? Nel prossimo paragrafo discuteremo 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 lesecuzione di un certo LDO [23]. Questa una soluzione 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 ripercuotere su altre parti del sistema di automazione del provisioning. Gli Extension point LDO si possono distinguere dagli LDO per il nome: infatti, condividono lo stesso nome dellLDO a cui si riferiscono eccetto per il suffisso, che pu essere Pre o Post a seconda che siano eseguiti rispettivamente prima o dopo dellLDO. Ad esempio, nellautomation package core definita la LDO SoftwareInstallable.Install e sono defini-

65

ti i corrispondenti Extension point LDO SoftwareInstallable.InstallPost e SoftwareInstallable.InstallPre. Per personalizzare un flusso di automazione attraverso gli Extension point LDO non bisogna modificare lExtension 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 dallinterfaccia 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 dallinterfaccia web. In virt di quanto abbiamo visto nel paragrafo 5.2.3, lExtension 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]. Limplementazione 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 lID della definizione del SO, operazione che si pu demandare al metodo getOSSoftwareResourceInstalledOnDeviceId della classe Java SoftwareHelper, contenuta nellautomation package core.
var OldWorkflowName = Java[SoftwareHelper#getWorkflowName(OperatingSystemID, "HostingEnvironment.Host")]

Dopodich bisogna ricavare il nome del workflow, associato a OperatingSystemID, che implementa lLDO 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.

66

Questo ci d modo di fare una piccola digressione approfondendo la sintassi della DCMInsert. 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 lelemento XML che si vuole aggiungere; dcm_query una DMQuery che restituisce lelemento padre a cui si vuole aggiungere lelemento figlio element.

Tornando al codice del nostro workflow, listruzione 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 loggetto DCM di tipo SoftwareResource 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 questultimo caso, si potrebbe pensare di sovrascrivere il nome del workflow attraverso una DCMUpdate, ma a quanto pare TPM non lo consente. E, daltronde, una modifica del genere potrebbe causare dei danni collaterali che potremmo non essere in grado di controllare. In ogni caso, un modo per aggirare questa limitazione potrebbe essere quello di definire un metodo Java sulla falsariga di SoftwareHelper.getWorkflowName, il quale sopperiva alla mancanza di una DCMQuery per estrarre il nome del workflow associato a una software resource.

67

Capitolo 6. Self service: Il preventivo

6.1

Linterfaccia web 2.0 di TSAM

6.1.1 Una panoramica Come abbiamo discusso nel paragrafo 3.2, TSAM dotato di uninterfaccia 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 offerings che possibile richiedere. Sulla destra, linterfaccia mostra lo storico degli ultimi progetti e delle ultime richieste che lutente ha inoltrato al sistema; inoltre, le barre colorate riassumono visivamente lo stato di questi progetti e richieste, permettendo cos di capire a colpo docchio qual la percentuale di progetti e richieste non ancora soddisfatti, quanti sono eventualmente in attesa dellapprovazione 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

68

Cliccando su unoffering, si apre una schermata, chiamata offering panel, con il form in cui inserire i dettagli della richiesta. In funzione dellofferinge 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 schermata 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 accesso 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 infine scegliere se monitorare o meno i server attraverso gli agenti di monitoring, e se far s che il sistema salvi automaticamente unimmagine con lo stato finale dei server prima che vengano rimossi. 69

6.1.2 Limplementazione La Self Service Station unapplicazione web che stata implementata usando Dojo Toolkit, 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 dellinterfaccia, legata a SRM, che pu essere utilizzata per vari scopi, non solo allinterno 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 sullapplicazione TSAM_web. Prima di addentrarci, per, opportuno ricordare che uno strato sotto alla Self Service Station c SRM, il cui scopo semplificare laccesso alle funzionalit di service management di TSAM, esponendo un catalogo dei servizi. La Self Service Station rappresenta unulteriore astrazione che nasconde il service catalog di SRM, e presenta al suo posto uninterfaccia pi orientata allutente. Questa stretta relazione tra SRM e Self Service Station risulta evidente studiando limplementazione 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, insieme, implementano una certa offering. In particolare, il file Javascript definisce la classe Javascript/Dojo che descrive loffering, con i suoi attributi e i suoi metodi, mentre il file HTML (chiamato template) definisce il layout del pannello che mostra il form relativo alloffering. Allinterno del file WAR, sotto js\simplesrm\tsam\dijit\request, si trovano le classi Javascript/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 70

pi pannelli. Ad esempio, loffering 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 CreateProjectWithServer.html. Lesempio appena fatto proprio quello che implementa il pannello in Figura 6.2. Ogni service offering caratterizzata da alcuni parametri che devono essere richiesti allutente. In HTML, il principale strumento per poter chiedere allutente dei dati in input consiste nellutilizzare un form. Cos, TSAM_web utilizza un form HTML, il cui tag form inserito nel template. Ci che rende linterazione dinamica e in stile web 2.0 lutilizzo 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 dallaltra aggiungendogli funzionalit user-friendly, come ad esempio il completamento automatico di una casella di testo, o visualizzando 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, crittografia, 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 controlli pronti alluso. 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 allinterazione dellutente.

71

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 programmatico 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 parser di Dojo che, al momento del caricamento della pagina web (a patto di avere impostato
parseOnLoad

a true nellattributo djConfig), si occuper di istanziare la classe specificata

come valore dellattributo 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 lID di un nodo del DOM, restituisce un riferimento alloggetto, e infine si ricava il valore mediante ad esempio lattributo value delloggetto.
var fname = dijit.byId("firstname").value;

Solitamente un widget genera degli eventi, cos come il controllo HTML input pu generare gli eventi onchange, onclick, onfocus, ecc. Ad esempio, un oggetto dijit.form.TextBox genera levento onChange quando lutente modifica la stringa contenuta nella casella di testo. Per mettersi in ascolto sugli eventi scatenati da un certo widget si pu utilizzare il metodo connect [25], come mostrato nellesempio seguente, in cui si specifica la funzione foo come event handler dellevento 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 allattributo 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 lelemento input, in modo che sia richiamata quando levento onChange viene scatenato.

72

6.3

Il preventivo nel pannello CreateProjectWithServer

Lobiettivo di questo paragrafo quello di modificare linterfaccia di Figura 12 affinch mostri allutente un preventivo con i costi che dovr sostenere per il progetto che va a creare. In questo lavoro introduciamo il preventivo solo nel pannello delloffering Create project with XYZ servers, ma si potrebbe facilmente estendere anche ai pannelli delle offering similari quali Modify server resources, Install software, Add XYZ servers e altre.

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 offering omonime PMRDP_020xA_72 (alias Create Project with VMware Servers, Create Project with KVM Servers, ecc.) contenute nellOffering 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 limitano a ridefinire il campo hyper con lhypervisor che usano. Ad esempio, la classe PMRDP_0201A_72, che implementa loffering 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.

73

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 essenzialmente un form HTML con tutti i controlli necessari per prendere in input i parametri delloffering: allinterno del tag form sono quindi presenti una serie di tag input e select, disposti allinterno 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 lutente 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 dellattributo dojoType indica che lelemento un oggetto Dojo che deve essere istanziato; il valore dellattributo indica quale classe istanziare (in questo caso, ibm.tivoli.tip.dijit.TextInputBox). Inoltre, lattributo dojoAttachPoint specifica che la 74

casella di testo deve essere collegata alla variabile distanza _projectName, in modo che a questultima sia passata la stringa di testo inserita dallutente nel widget. Un'altra cosa che possiamo notare luso dellespressione ${id} per stampare a runtime il campo id nel codice HTML, come in:
<input id="${id}_PMRDPCLCPR_PROJECTNAME"

Infine, notiamo lutilizzo delle funzioni di internazionalizzazione, che consentono anche di realizzare decoupling tra il codice HTML/Javascript e le stringhe di testo statiche dellinterfaccia, 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 75

nei tag div. Allora, si forza la presenza di un tag input impostandolo come hidden, e ci si copia nellattributo value i dati che lutente introduce attraverso il widget. 6.3.1.2 La classe Dojo CreateProjectWithServer

Nel file CreateProjectWithServer.js definita lomonima 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 lutente pu solo modificarne i campi. TSAMRequest eredita a sua volta dalla classe CreateCatalogRequest. Questultima implementa un widget che, tramite un servlet proxy, invia una XMLHttpRequest a un web service in grado di inoltrare richieste al service catalog di SRM. TSAMRequest, invece, rappresenta 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 specifica 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 nellOffering catalog di SRM.

76

A questo punto, entriamo nel vivo del codice di questa classe studiando cosa succede quando lutente interagisce con i widget per modificare i parametri del progetto. Per semplicit, 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; allinterno di questi popup ci sono poi i widget ResourceSliders, che forniscono allutente uno slider per modificare velocemente la quantit considerata. Nello specifico, c un tipo particolare di ResourceSliders per ogni risorsa hardware: DiskResourceSliders, MemoryResourceSliders, CpuResourceSliders. Analizziamo ora uno scenario di utilizzo. Consideriamo ad esempio il parametro relativo allo spazio disco: non appena lutente modifica la quantit di spazio disco, come possiamo constatare dalla Console di Chrome36 (vedi Figura 6.4) , vengono invocate le seguenti funzioni, 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 dellutente allinterno 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 console.warn, console.log e console.debug.

77

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 lazione che viene eseguita in seguito alla modifica della CPU _onMemoryChanged lazione che viene eseguita in seguito alla modifica della quantit di RAM richiesta _onDiskChanged lazione che viene eseguita in seguito alla modifica della quantit di spazio disco richiesto Tutte queste funzioni invocano alla fine _loadAvailableResources, che verifica che, dati i parametri introdotti dallutente, 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 richiesti. Questo metodo provoca linvocazione a catena di vari altri metodi, tra cui
_doLoadAvailableResources, TSAMRequest._loadResourceAvailability,

_processAvailableResources, _processServerQty, _processResources.

Alla fine, il 78

risultato che, se il sistema non dispone di risorse sufficienti, stampa sul pannello un messaggio di errore, invitando lutente 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 progetto, si occupino di aggiornare lattributo 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 dallutente attraverso i widget, in modo che, quando lutente chiude il popup con lo slider (vedi Figura 6.3), il valore introdotto sia ancora visibile. Riportiamo come esempio limplementazione 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 Limplementazione 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 lintera durata del progetto).

79

Figura 6.5: La tabella con il preventivo del progetto

Lunica 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 dallutente 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 nellaggiungere 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 dallutente 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 dallutente nei widget, ci viene in aiuto il metodo getCurrentSettings

della classe CreateProjectWithServer, che restituisce il valore delle quantit

di CPU, memoria e spazio disco richieste dallutente, incapsulate in un oggetto. Oltre a queste risorse, per calcolare il chargeback abbiamo bisogno di conoscere il sistema operativo selezionato, la durata temporale del progetto e il numero di server. Tutte queste informazioni 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") );

80

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

Lunico aspetto non troppo banale del calcolo dove scrivere questi prezzi. Banalmente, si potrebbero scrivere allinterno 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 codice 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 sistemi 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 dellutente) 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 public cloud IaaS (vedi http://www-935.ibm.com/services/it/igs/cloud-development/pricesheet.html)

81

tabella la stringa N/A al posto del costo. Riguardo al file di testo in cui scriviamo i prezzi, possiamo ad esempio decidere di dargli questo formato: quattro numero separati da virgola, 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 nellaggiornare 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 alluopo precedentemente, di lunghezza pari a 2, dove la prima stringa (coppia[0]) lid 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 tions

per formattarla opportunamente, specificando in currencyOp-

le opzioni di formattazione. Infine, tramite dojo.byId e la propriet innerHTML, in-

seriamo il valore formattato nella cella identificata dallid contenuto in coppia[0]. Rimane ancora da discutere come far s che il preventivo venga aggiornato automaticamente ogni volta che lutente modifica un parametro del progetto. Avendo studiato in precedenza la classe CreateProjectWithServer, sappiamo che, quando lutente modifica un parametro del progetto, i primi metodi ad essere invocati sono gli event handler (vedi paragrafo 6.3.1.2). Ai fini del chargeback, quelli interessanti sono:
_onCpuChanged,

relativo alla quantit di CPU (virtuale e fisica) relativo alla quantit di memoria (RAM e swap) 82

_onMemoryChanged,

_onDiskChanged,

relativo alla quantit di spazio disco relativo alla durata temporale del progetto

_onChangeReservation, _onImageSelected, _onChangeServQty,

relativo al sistema operativo relativo al numero di server virtuali

sufficiente aggiungere al fondo di ognuno di questi metodi la chiamata alla nostra funzione 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 nellinterfaccia self-service, nonch una guida che li descrive e spiega [27]. In primis, stato progettato un modo per permettere di personalizzare lintera UI senza che un upgrade di TSAM sovrascriva il codice custom, costringendo, nella migliore delle ipotesi, a riapplicare le personalizzazioni al termine dellesecuzione dellupgrade. Questo effetto 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 Toolkit. 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 tsamCustomInit

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.

83

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. Daltronde, le critiche che lo accusano di essere il frutto di una campagna di marketing sono 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 standardizzazione 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 nellallargare il bacino di utenza del cloud. Il cloud computing un grande calderone in cui confluiscono un gran numero di tecnologie, 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 allinizio. 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 verrebbe meno il carattere di autonomic computing), ma va spesso inserito in contesti che negli anni hanno fatto della customizzazione il loro motto, quindi necessario usare strumenti che permettano un alto grado di configurabilit al fine di implementare personalizzazioni adatte al contesto.

84

A questo scopo, nella parte pratica abbiamo progettato e implementato una soluzione private IaaS partendo dallinstallazione e configurazione di IBM Service Delivery Manager, prodotto che consente un buon grado di personalizzazione. Per implementare i requisiti custom 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 unaltissima complessit che si traduce spesso in una scarsa chiarezza dei manuali. In particolare, il problema dei manuali IBM la dispersione: 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 configurazioni 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 Nellimplementazione del preventivo abbiamo disaccoppiato solo i prezzi relativi alle risorse hardware; i prezzi delle licenze dei sistemi operativi, invece, sono stati scritti nel codice 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 licenze dei SO, necessario modificare il sistema di discovery di TPM facendo s che, contestualmente allimportazione di unimmagine, chieda allutente il prezzo orario da assegnare a quella licenza, e scriva quel prezzo in un file il cui path sia noto alla funzione che calcola i costi del preventivo. Disaccoppiare i prezzi delle licenze, oltre che essere positivo da un punto di vista quasi filosofico, permetterebbe di gestire agilmente alcune situazioni: ad esempio, qualora ISDM 85

supportasse altri sistemi operativi, sarebbe possibile aggiungerne i relativi prezzi senza dover modificare il codice della funzione che esegue il calcolo.

7.2.2 Report di chargeback In unottica di utility computing, si potrebbe far generare al sistema un report di chargeback 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 moneta anche solo virtuale), che andasse ad intaccare il budget assegnato agli AM, completerebbe limplementazione del chargeback iniziata con lintroduzione del preventivo nel form di creazione di server virtuali (vedi Capitolo 6). Cos, si spingerebbe gli AM ad autoresponsabilizzarsi nella razionalizzazione dei server virtuali, qualora questi, superate le prime diffidenze che tipicamente nascono quando viene introdotto un nuovo sistema, sovra-utilizzino le risorse del datacenter per via della estrema facilit duso del cloud.

86

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_clouddefinition.pdf. Gartner, "Cloud Computing: Defining and Describing an Emerging Phenomenon," 2008. 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. IBM, "IBM Cloud Channel Sales Guide - IBM Software and Systems for Private Clouds and Public Cloud Computing," 2010. Microsoft, "Architecture Strategies for Catching the Long," 2006. [Online]. Available: http://msdn.microsoft.com/en-us/library/aa479069.aspx. NIST, "Cloud Computing Synopsis and Recommendations (DRAFT)," 2011. [Online]. Available: http://csrc.nist.gov/publications/drafts/800-146/Draft-NISTSP800-146.pdf. IBM, "Cloud Computing Reference Architecture v2.0," 2011. [Online]. Available: http://www.opengroup.org/cloudcomputing/uploads/40/23840/CCRA.IBMSubmissi on.02282011.doc. The Open Group, "Cloud Computing Explained," 2011. [Online]. Available: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicati onid=12382. opencloudmanifesto.org, "Open Cloud Manifesto," 2009. [Online]. Available: http://www.opencloudmanifesto.org/Open%20Cloud%20Manifesto.pdf.

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

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

87

[12] KVM, "KVM HomePage," [Online]. Available: http://www.linux-kvm.org. [13] KVM, "KVM FAQ," [Online]. Available: http://www.linuxkvm.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.

88