Studio ed analisi del Cloud Computing

Transcript

1 UNIVERSITA DEGLI STUDI DI SIENA FACOLTA DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Studio ed analisi del Cloud Computing Relatore Prof. Marco Maggini Correlatori Carlo Bardi Cesare Bertoni Tesi di Laurea di Elvio Stumpo A.A. 2008/2009

2 Introduzione: Il calcolo distribuito Introduzione: Il calcolo distribuito Negli ultimi anni, lo sviluppo tecnologico-scientifico, per poter progredire, ha richiesto l impiego di un numero sempre crescente di uomini e macchine. Nella scienza moderna l impiego di calcolatori è diventato di vitale importanza; infatti, ad essi vengono affidate tutte quelle attività che l uomo non è in grado di fare con la stessa perizia propria di questi strumenti. L utilizzo sistematico di queste apparecchiature negli ambienti scientifici ha da sempre generato una richiesta costante di macchine sempre più efficienti e sempre più potenti. Il costante bisogno di calcolatori sempre più performanti, soprattutto agli albori dell Informatica, risultò essere un problema di notevole portata. A quei tempi, immettere sul mercato un elaboratore era uno sforzo ingente sia di capitali che di mano d opera, tanto che non si era in grado di soddisfare tutte le potenziali richieste. In quel periodo (o era informatica) il rapporto macchina-uomo era uno a molti, vale a dire, un calcolatore per molti utilizzatori. Questa situazione generò non pochi conflitti per l accaparramento della risorsa da parte degli utenti. Intorno agli anni 80 ci fu un sostanziale abbattimento dei costi hardware che generò una diffusione su larga scala degli elaboratori così che si iniziò a parlare di personal computer, di conseguenza il rapporto macchina-uomo passò da uno a molti a uno ad uno. L era informatica seguente fu caratterizzata da una semplice conclusione sul confronto di prestazioni: si misero a paragone i supercomputer, all epoca ancora molto costosi, e semplici reti di personal computer molto più economiche, ed emerse che queste ultime riuscivano a fornire prestazioni uguali ed a volte addirittura superiori a quelle proprie dei supercomputer. Si iniziarono a preparare le basi per quello che oggi chiamiamo reti di calcolatori. L introduzione di tali reti modificò il rapporto macchina-uomo che passò a molti a uno. Nell ultima era, l attuale, la nuova frontiera è il calcolo distribuito. Quest ultimo può essere facilmente confuso con il calcolo parallelo, vale a dire, la capacità di esecuzione di più task simultaneamente su più processori contenuti, però, nella stessa macchina. L idea di fondo della teoria del calcolo distribuito, invece, è quella di frammentare il carico di lavoro in un Fig.1. Esempio di connettività. numero arbitrario di sotto task indicati solitamente con il nome di job da distribuire ad un numero imprecisato di macchine, eterogenee tra loro, sparse potenzialmente in tutto il mondo. Al contrario del calcolo parallelo, in cui l assegnazione dei task è certa, nel calcolo distribuito non vi è l assoluta sicurezza che le macchine della rete siano sempre disponibili (tempi di latenza diversi, crash imprevedibili di rete o dei computer, ecc. ) quindi è necessario un continuo monitoraggio dell architettura. Il problema fondamentale che nasce dall impiego di questo genere di tecnologia è tutto concentrato sulla gestione corretta del traffico (cioè priva di errori sia in trasmissione che in ricezione) di qualsiasi tipo (dati, job, comandi, ecc). Studio ed analisi del Cloud Computing Stumpo Elvio

3 Introduzione: Il calcolo distribuito Un ulteriore problematica deriva da una caratteristica fondamentale del calcolo distribuito: la coesistenza nella rete di macchine che supportano diversi sistemi operativi spesso incompatibili con altri. Per porre rimedio a tale ostacolo si è lavorato su due fronti diversi: il primo, implementando nella rete la possibilità di trasmissione di software scalabile ed adattabile (scalabilità e portabilità) fra macchine diverse; il secondo, invece, basando tutta l architettura su applicazioni di tipo web (web-oriented). Una corretta condivisione delle risorse su scala mondiale permette di generare una potenza di considerevole dimensione, che può essere impiegata per risolvere problemi con grandi moli di dati d ingresso. L utilizzatore del calcolo distribuito ignora completamente come le risorse siano reperite: infatti, per l utente, l impiego di tale tecnologia consiste solamente nell operazione di connessione tramite internet ad una macchina non meglio identificata che gli fornirà la potenza necessaria. Il fruitore standard del calcolo distribuito, infatti, non sarà in grado di sapere se le risorse impiegate per il suo programma provengano dalla sua macchina, da un cluster di computer dall altro capo del mondo, dal vicino di casa o da una elaborata unione di queste varie realtà. L utente, inoltre, non conosce lo stato d opera dei processi eseguiti tramite il calcolo distribuito, ma ha la reale possibilità di conoscere l istante in cui il job è stato lanciato e quando esso terminerà effettivamente (con successo o crash). Attualmente sono presenti diverse tipologie di sistemi di interconnessione per il calcolo distribuito: Client-Server: la macchina client contatta la macchina server grazie ad un programma specifico lanciato in remoto sul client stesso, il quale si occupa di contattare i vari sistemi e/o servizi per ottenere dati, configurazioni varie ed inoltre è fornito di una interfaccia utente riassuntiva della rete consultabile dal fruitore. Architettura a 3 strati (3-iter architecture): sistema a tre stati nel quale le informazioni del client vengono inserite in uno stato intermedio in cui sono presenti, a sua volta, client inattivi in attesa di utilizzo (ad esempio per l accesso ai dati). Questo sistema semplifica molto il processo dello sviluppo applicativo. La maggior parte delle applicazioni web di richiesta sono strutturate a 3-strati. Architettura a N strati (N-iter architecture): si riferisce tipicamente ad applicazioni di tipo web che fondamentalmente inoltrano le loro richieste a terze parti. Questo metodo per richiedere informazioni è stato la chiave del successo delle applicazioni server. Accoppiamento stretto (tight coupling): si riferisce tipicamente ad un cluster di macchine strettamente connesse, che gestisce un processo condiviso in parallelo. La frammentazione del task originario è molto elastica e strettamente legata al tipo di risorse che ogni elemento delle rete è in grado di offrire. A conclusione di tutti i job su tutte le macchine, tramite un processo di merge, si ha il risultato finale. Peer-to-peer: un'architettura dove non sono presenti macchine speciali o macchine che offrono un servizio o gestiscono le risorse di rete. Tutte le attività, invece, sono divise uniformemente fra tutte le macchine, note come peers (pari). I peers possono comportarsi alternativamente sia da client che da server. Un altro aspetto di base dell architettura di calcolo distribuito è il metodo di comunicazione e coordinamento del lavoro con processi simultanei. Attraverso l impiego di vari protocolli di Studio ed analisi del Cloud Computing Stumpo Elvio

4 Introduzione: Il calcolo distribuito comunicazione, i processi possono sincronizzarsi e comunicare direttamente con l'un l'altro, solitamente secondo il criterio client/server. Con il continuo aumento di apparecchiature contenenti un microprocessore e una connessione ad alta velocità è facile dedurre che l impiego del calcolo distribuito attuerà un processo di riduzione dei tempi di computazione, fino ad arrivare a ottenere risposte in realtime a problemi che attualmente richiedono ore, giorni o anni. Alcune applicazioni del calcolo distribuito hanno avuto un tale impatto sul mondo scientifico da meritare di essere descritti individualmente. Studio ed analisi del Cloud Computing Stumpo Elvio

5 Capitolo 1 Architetture di calcolo distribuito Capitolo 1 Architetture di calcolo distribuito 1.1-Grid computing I sistemi Grid sono le prime grandi infrastrutture di calcolo distribuito, utilizzate per l elaborazione di un gran numero di dati, mediante l uso di una vasta quantità di risorse. In particolare, tali sistemi permettono la condivisione coordinata di risorse all interno di un organizzazione virtuale. La condivisione non è limitata solo allo scambio dei files, ma si estende all accesso diretto al computer, al software, ed in generale a tutto l hardware necessario alla risoluzione di un problema scientifico, ingegneristico o industriale. Il sistema grid si articola essenzialmente in due fasi Fig.1-1. Classica disposizione di una rete a griglia (Grid Computing). principali: creazione e testing. Nella prima fase, mediante un opportuna interfaccia grafica, l utente è in grado di inserire le caratteristiche del sistema grid desiderato. Al termine della prima fase, data dall inserimento delle caratteristiche, inizia la seconda fase, relativa alla simulazione. Durante la simulazione i dati vengono elaborati e viene presentato all utente un report contente tutte le informazioni e le risposte del sistema, cioè il risultato raggiunto dalla rete per il problema propostole. Il problema alla base del concetto di griglia è la condivisione coordinata di risorse all interno di una dinamica e multiistituzionale organizzazione virtuale (Virtual Organization, brevemente indicata con VO). L utente conosce il numero delle macchine che verranno impiegate per la propria simulazione (tale valore fa parte della configurazione statica della rete che è scelta dall utente), ma ignora la loro posizione geografica. Attualmente, la più importante grid europea è quella del CERN di Ginevra (ora diventata EGEE); il software più famoso ed utilizzato è BOINC (Berkeley Open Infrastructure for Network Computing). Questo è un software di grid computing sviluppato dall'università della California (Berkeley) ed è classificato come un open source, anche se sarebbe meglio parlare di software gratuito e completamente personalizzabile. L idea che guida questo genere di sistema, infatti, è quello di donare, a progetti che la richiedono 1, la potenza computazionale inutilizzata delle proprie apparecchiature connesse in rete (ora è disponibile anche in remoto). Per aderire a tale progetto le operazioni fondamentali sono due : inizializzazione e elaborazione. Nella prima fase (inizializzazione) si compiono diverse operazioni, alcune delle quali una tantum (download del client BOINC e sua relativa GUI, creazione di credenziali valide per la rete, configurazione della macchina ecc.) altre, invece, mutabili nel tempo 1 Un classico esempio di impiego dell architettura grid è Seti@home. Tale progetto consiste nell ascolto del rumore cosmico proveniente dallo spazio alla ricerca di un qualsiasi tipo di segnale contenente informazioni. La distinzione tra il rumore spaziale ed i potenziali segnali artificiali (segnali non di origine naturale, ma generati per un scopo ben preciso) viene eseguita mediante una monitorizzazione continua dello spettro conosciuto. Studio ed analisi del Cloud Computing Stumpo Elvio

6 Capitolo 1 Architetture di calcolo distribuito (scelta dei progetti a cui si intende partecipare, pacchetti di dati da analizzare (work unit dette WU), ecc ). Nella seconda fase il client di BOINC, in remoto, analizza costantemente le risorse impiegate, per adoperare le rimanenti risorse inutilizzate per eseguire le work unit. Queste donazioni di risorse vanno a fondo perduto, l utente standard di BOINC non ha nessun ritorno oggettivo (economico, computazionale ecc). Gli unici beneficiari del servizio sono i committenti dei progetti a cui gli utenti collaborano. BOINC è il classico esempio di grid computing anche se unidirezionale (utente=forza lavoro). Esistono anche reti a griglia che, diversamente dal BOINC, consentono agli utenti, che ne fanno espressa richiesta, di sfruttare le risorse per progetti propri (l utente è forza lavoro ma anche utilizzatore della rete grid). L elemento fondamentale che caratterizza il grid, ed anche uno dei componenti più critici del sistema di gestione delle risorse, è lo schedulatore di risorse. Esso ha il compito di assegnare le risorse ai job, in modo da soddisfare le esigenze delle applicazioni e del sistema. Le risorse delle griglie sono strettamente connesse tra loro, geograficamente distribuite, eterogenee ed, inoltre, appartengono a diversi individui o organizzazioni, ciascuno con le proprie politiche di scheduling, modelli di costo di accesso differenti, carichi di lavoro e disponibilità di risorse che variano dinamicamente nel tempo. La mancanza di un controllo centralizzato, insieme alla presenza di utenti che generano job, molto diversi l uno dall altro, rendono la schedulazione più complicata rispetto a quella dei sistemi di calcolo tradizionali. Il calcolo a griglia, rispetto ad altri tipi di tecnologie, ha già subito un processo di standardizzazione univoca che quindi permette l iter-connessione delle griglie stesse senza problemi di interfacciamento. Fra le caratteristiche che sono state formalizzate e che, quindi, qualsiasi sistema grid deve garantire vi è il carico minimo: il fornitore delle rete certifica che il proprio prodotto in situazione di estremo carico garantisce per ogni progetto in corso l esecuzione di un determinato carico di lavoro. Sono tuttavia emersi alcuni difetti di questo tipo di rete (la non completa trasparenza delle macchine ma soprattutto la loro assegnazione molto rigida e statica) che hanno portato allo sviluppo di altri tipi di reti, le reti cloud. Studio ed analisi del Cloud Computing Stumpo Elvio

7 Capitolo 1 Architetture di calcolo distribuito 1.2-Cloud computing Il cloud computing (calcolo a nuvola, o nube) è visto dagli esperti del settore come la vera innovazione del web 2.0. Spesso, per una migliore comprensione della nube, la si paragona alle Google Apps. Questa comparazione è ammissibile solo a livello teorico-nozionistico, ma non è del tutto corretta, anche se vi sono effettivamente dei punti di contatto tra le due tecnologie. Il cloud computer può essere visto come un super computer (inteso come grandi risorse di tipo informatico) che ha come sua ubicazione la rete internet. Il clouding in realtà, non basandosi su una architettura rigida, racimola, su richiesta, le risorse disponibili ovunque nella rete, sia provenienti da un PC, da un notebook, da un netbook, da un palmare e, addirittura, anche da un Fig.1-2. Rappresentazione dello sviluppo del word wide web cellulare connesso ad internet. Il pioniere del cloud computing fu John McCarthy che fornì una sua prima formalizzazione nel Solo negli anni 90 il termine cloud iniziò ad entrare nei linguaggi di tipo commerciale per riferirsi alle grandi reti di ATM. Negli ultimi anni, iniziò ad apparire il termine "cloud computing", anche se la maggior parte dell interesse verso questa emergente innovazione era finalizzata alla realizzazione di un software che offrisse un servizio. Fig.1-3. Rappresentazione schematica dell evoluzione architetturale di Internet Per l'alto livello concettuale, infatti, la nube di calcolo è definita come "una combinazione di hardware, software, dati e persone, che fornisce servizi on-line". Importante è notare la strettissima coesistenza che esiste nel cloud computing tra i consumatori e i produttori dei servizi. Le architetture cloud sono enormi aggregati di diverse reti (universitarie, Studio ed analisi del Cloud Computing Stumpo Elvio

8 Capitolo 1 Architetture di calcolo distribuito commerciali), di supercomputer e di cluster di computer. Esse sono utilizzate da un numero enorme di persone sia in qualità di utenti (solo Microsoft Live ha più di 300 milioni di utenti) e sia in qualità di sviluppatori (Amazon EC2 ha attualmente più di sviluppatori di applicazioni). Attualmente nel web centinaia di milioni di utenti si collegano a Google regolarmente ogni giorno (20 Petabytes di dati giornalieri); a questi si aggiungono le operazioni che gli utenti dei servizi di ebay compiono (1 Terabyte di log giornalieri solo nel 2000): tali fenomeni generano enormi flussi di dati e di informazioni che in qualche modo devono essere gestiti. Possiamo concludere che il cloud computing, per le sue caratteristiche intrinseche, ha una massiccia partecipazione ad analizzare tali dati, tanto da collaborare attivamente alla creazione di una mega-struttura onnipresente, sempre disponibile, che lavora con circa 100 di milioni di utenti. Diversamente dal calcolo a griglia, ogni utente partecipa alla rete per avere un proprio beneficio, quindi, più risorse. In queste condizioni il cloud pone grandi sfide, ma offre opportunità senza precedenti a tutta la comunità informatica-scientifica che gravita attorno a questa architettura. Il cloud computing, infatti, rappresenta un nuovo approccio alle infrastrutture in cui grandi insiemi di sistemi sono collegati tra loro per fornire servizi IT. L esigenza di tali ambienti è sempre più sentita per la crescita esponenziale delle apparecchiature connesse in rete e dei processi di streaming di dati in tempo reale e anche per la diffusione di architetture e applicazioni web 2.0 orientate al servizio, ai progetti di collaborazione e di ricerca. I progressi nelle prestazioni dei componenti digitali hanno provocato un enorme aumento della portata degli ambienti IT, e di conseguenza, è nata l esigenza di poterli gestire uniformemente in un unica nuvola (cloud). Le potenzialità del calcolo a nube, inoltre, risultano essere particolarmente adatte ad un gran numero di progetti, ma soprattutto a quelli di carattere scientifico, tanto da essere impiegate massicciamente per il calcolo intensivo. La scienza ha da sempre impiegato le migliori risorse disponibili per raggiungere i propri obiettivi; essa, infatti, può essere suddivisa in tre grandi periodi: empirico, teorico e sperimental-simulativo. Il primo periodo è stato principalmente applicativo, ovvero, privo di una qualunque struttura astratta; il secondo periodo, quello delle grandi scoperte, è stato caratterizzato dalla formulazione delle principali teorie scientifiche. Oggi ci troviamo nel terzo periodo, quello della scienza sperimentale in cui si creano flussi di dati da utilizzare per la simulazione, ma soprattutto si sta attuando un processo di condivisione e di collaborazione tra gli scienziati ad un livello senza precedenti. L evoluzione di mega strutture di dati, ha generato fenomeni sociali articolati su vasta scala denominata social computing. In tali condizioni sono presenti tutti gli stimoli necessari per creare un nuovo tipo di ricerca scientifica basata sul web la web-scienza. Se tale ricerca vedrà la luce, il calcolo a nube ricoprirà un ruolo fondamentale in questa nuova dimensione scientifica. L'emergere delle architetture a nube consentirà, infatti, nuove prospettive stimolanti in ingegneria, in medicina e per molti problemi di ordine sociale. La nascita della nube di calcolo rinvigorirà la ricerca accademica e fornirà un forte spinta alla creazione di collaborazioni, di metodi innovativi e di nuovi comportamenti. Le attività accademiche attualmente sono ben Studio ed analisi del Cloud Computing Stumpo Elvio

9 Capitolo 1 Architetture di calcolo distribuito al di sotto delle loro effettive potenzialità, questo perché gli scienziati devono confrontarsi con una vasta quantità di dati provenienti non solo dal web, ma anche da un numero crescente di strumenti e sensori. L utilizzo del cloud computing permetterà agli scienziati di fruire di un sostanziale aumento dei dati d ingresso per le loro simulazioni, che forniranno risultati con un accuratezza mai raggiunta. Questo perché il cloud computing può essere impiegato per gestire carichi di lavoro già esistenti, ma anche per quelli emergenti, altamente scalabili e basati su grandi quantità di dati. Considerate le numerose applicazioni del cloud, fornire una definizione univoca che lo caratterizzi al meglio risulta essere un operazione estremamente difficile. Una sua possibile definizione è comparsa sul ACM Computer Communication Review Le nubi sono grandi contenitori di risorse virtuali di facile utilizzo ed accesso (come lo posso essere vari software ma anche l hardware, le piattaforme di sviluppo e/o di servizio). Queste risorse possono essere dinamicamente riconfigurate per adattarsi ad un carico di lavoro variabile (scalabilità) lasciando spazio anche ad un'utilizzazione ottimale di risorse. Questo contenitore di risorse è impiegato tipicamente secondo il modello pay-for-use (pagare per usare) nel quale tutto è garantito dal provider dell infrastruttura. Un errore che spesso si compie è quello di confondere il cloud computing con altri tipi di architetture di calcolo distribuito, primo fra tutti il grid computing. La confusione tra il cloud computing e le altre architetture è giustificata dalla non remota possibilità che il cloud si comporti, a volte, come un grid e mostri alcune caratteristiche tipiche di altri generi di reti. Dagli studi compiuti su questa architettura traspare che il cloud computing può essere a tutti gli effetti definito come la vera e naturale evoluzione del modello grid computing, anche se le tipologie delle reti sono estremamente diverse tra loro. Come per le reti a griglia, la progettazione e la creazione di una rete cloud è un operazione di non facile realizzazione. I sistemi cloud migliori, ad esempio, dispongono di una piccola infrastruttura centralizzata, ma a volte ne sono addirittura privi o possono persino appoggiarsi ad un qualsiasi sistema, anche esterno, come le reti peer-to-peer o Skype. La maggior parte delle infrastrutture basate sulla nube forniscono agli utenti servizi affidabili in funzione del livello di virtualizzazione richiesto. I servizi sono accessibili in qualsiasi parte del mondo, questo perché il sistema cloud è visto come un singolo punto d accesso che permette di raggiungere una rete talmente grande da contenere le risorse necessarie per tutti gli utenti della nube. Le offerte commerciali basate sul cloud computing forniscono ai loro clienti, servizi di qualità e Fig.1-4. Rappresentazione della comunicazione standard tra i soprattutto adatti al livello computer e la rete cloud Studio ed analisi del Cloud Computing Stumpo Elvio

10 Capitolo 1 Architetture di calcolo distribuito virtuale che l utente sceglie di utilizzare. I sistemi di tipo open - source che utilizzano il cloud computing rendono critico lo sviluppo dello stesso perché attualmente non esistono ancora degli standard di regolamentazione unici. Il grande pregio di questo tipo di tecnologia è che gli utenti finali possono avere accesso a grandi risorse di qualsiasi tipo (calcolo, memorizzazione etc.) in maniera del tutto virtuale, quindi, abbattendo completamente tutti i costi delle infrastrutture fisse (acquisto, mantenimento, potenziamento etc.). L utente finale, infatti, pagherà l uso delle risorse virtuali solo all atto del loro effettivo utilizzo. Alcuni provider del cloud computing sono Amazon, Google e Yahoo e, ultimamente, anche Microsoft con Azure. Amazon ha giocato un ruolo chiave nella conoscenza e nello sviluppo del cloud computing compiendo una modernizzazione dei suoi centri di calcolo. I suoi sviluppatori, infatti, avevano trovato una nuova architettura di tipo cloud che ha dato luogo a significativi miglioramenti in termini d efficienza interna ed, inoltre, ha offerto ai propri clienti l accesso ai sistemi di Amazon Web Services da impiegare per scopi di calcolo di tipo non avanzato. Il 2007 è stato l anno dell aumento delle attività finalizzate all architettura a nube, infatti sia Google, sia IBM, che un discreto numero di università decisero di investire grandi risorse per la ricerca e lo sviluppo e, nel giro di poco tempo, il cloud cominciò a guadagnare popolarità presso la stampa, fino ad arrivare nel 2008, anno in cui diventa un argomento di discussione tanto da essere presente in numerosi eventi. Nell agosto 2008 gli esperti del settore hanno osservato che le organizzazioni stavano cambiando hardware e software per utilizzarne altri, orientati verso modelli di servizio e che in questo ambito l impiego del clouding avrebbe dato luogo ad una crescita così sorprendente da essere drammatica per tutte le altre aree dell IT Problematiche d impiego Attualmente la nube attraversa numerosi confini di vario tipo e può essere definita come "l'ultima forma di globalizzazione". E come tale è soggetta a problemi complessi di tipo geopolitico. I provider, infatti, devono soddisfare una miriade di ambienti diversi e regolare i vari servizi in funzione dei continui cambiamenti del mercato globale. Le diverse richieste di sicurezza da impiegare nella nube risultano fortemente basate sul territorio geografico d impiego, e quindi sul tipo di utenti. Gartner, analista di tecnologia e consulente d azienda, ha elencato sette problemi di sicurezza sui quali si dovrebbe discutere con le aziende che forniscono il cloud computer: 1) Individuazione dell utente privilegiato: colui che è in grado di accedere a tutte le risorse della rete cloud. 2) Comprovata serietà: verifica dell effettiva serietà dei produttori del servizio anche mediante l impiego di società specializzate, eventualmente anche esterne al fornitore della rete. 3) Ubicazione dei dati: conoscenza del luogo ove viene allocato lo spazio di memoria e se queste località godano di un adeguato servizio di sorveglianza territoriale. Studio ed analisi del Cloud Computing Stumpo Elvio

11 Capitolo 1 Architetture di calcolo distribuito 4) Crittografia: garanzia che la cifratura sia disponibile a tutti i livelli e che tale crittografia sia fornita da esperti del ramo. 5) Recupero dati: l iter da seguire dalla rete e/o dalle aziende in caso di perdita di dati. 6) Controllo investigativo: conoscenza della possibilità della nube di essere impiegata per controllare le attività legali o illegali degli utenti. 7) Autosufficienza: conoscenza di quanto accada alla nube qualora la società che fornisce il servizio fallisca Componenti Volendo formalizzare gli elementi che formano una qualsiasi rete cloud si sono definiti i seguenti componenti: Cloud client: consiste nell hardware (dispositivi di qualsiasi tipo connessi a internet) e nel software (un qualsiasi browser come google crome firefox ecc.) di cui il sistema cloud necessita per funzionare correttamente. Client Services Application Platform Storage Infrastructure Cloud services: consiste nei servizi web: un sistema software Fig.1-5. Componenti progettato per sostenere interazioni di tipo machine-tomachine di interoperabilità su una rete. Questi software fondamentali del cloud possono essere ottenuti da un altra nube il cui scopo principale è quello di calcolare componenti software, software per servizi, o informazioni sugli utenti finali (identità, integrazione, pagamenti, mappature, ricerca, etc). Cloud application: architetture software, che eliminano il bisogno di installare e gestire le procedure client sul computer dell utente, alleviando così il carico di manutenzione del software, delle operazione in corso, etc. (Facebook, Google Apps, Salesforce, Microsoft Servizi On-line). Cloud platform: è un servizio che consegna una piattaforma di calcolo e/o pile di soluzioni utilizzando una serie di domande da rivolgere all utente senza che quest ultimo debba avere una conoscenza profonda degli strati del software (Ajax (Caspio), Python Django (Google App Engine), Ruby on Rails (Heroku), Web hosting (Mosso), Proprietary (Azure, Force.com)). Cloud storage: comporta la capacità di memorizzazione dei dati come un servizio offerto dalla rete (calcolati per gigabyte per mese) (Database, Synchronisation Web Service). Cloud infrastructure: il servizio che mette a disposizione reti di computer virtuali (Grid computing (Sun Grid), Compute (Amazon Elastic Compute Cloud), Blue Cloud (IBM), Azure (Microsoft)). Studio ed analisi del Cloud Computing Stumpo Elvio

12 Capitolo 1 Architetture di calcolo distribuito Architettura Analizzando la rete a nube a livello funzionale osserviamo che l architettura del cloud computing è un sistema software finalizzato alla realizzazione di nubi di calcolo, comprensive sia di hardware (virtuale) che di software, disegnati da un architetto che tipicamente lavora per garantire la completa integrazione tra le Fig.1-6. Descrizione degli elementi caratteristici che compongono una classica architettura cloud diverse nubi. Il sistema cloud comporta componenti multipli che comunicano l'un l'altro su interfacce di programmazione, di solito mediante web services. Questo approccio ricorda da vicino la filosofia Unix: avere programmi multipli che lavorano bene insieme su interfacce universali. La complessità è controllata ed i sistemi risultanti sono più maneggevoli dei sistemi di tipo monolitico. Definiamo, infine, le entità fondamentali presenti nell ambiente dell architettura a nube: Cloud Provider: è l entità che possiede e gestisce le risorse delle reti cloud assegnando sia le risorse di calcolo che i servizi per ogni utente; inoltre, possiede ed implementa sistemi di calcolo di cloud live per distribuire servizi a terze parti. Di solito questo richiede risorse significative ed esperienza nella costruzione di centri di calcolo. Nonostante tutto, alcune grosse organizzazioni hanno notato che il possedere un provider cloud porta all azienda che ne fa un uso esclusivo numerosi benefici in termini di efficienza, soprattutto nella gestione dei casi di picchi di carico. Questi benefici sono controbilanciati da una notevole complessità, sia di tipo economico (acquisto, mantenimento e aggiornamento delle macchine) che prettamente architetturale. Una delle prime grandi aziende a superare gli ostacoli iniziali è stata Amazon che nel 2002 ha basato il suo Amazon Web Services su architetture di tipo cloud. Cloud User: è il fruitore della nube. Un problema rilevante per questa entità è la privacy dell utente che potrebbe essere violata. Una possibile soluzione è la creazione di comunità che garantiscano i diritti degli utenti. Cloud Vendor: è l entità che vende prodotti e servizi che facilitano l uso, l'adozione e l'uso di nube di calcolo. Studio ed analisi del Cloud Computing Stumpo Elvio

13 Capitolo 2 Analisi sulle offerte cloud Capitolo 2 Analisi sulle offerte cloud L architettura a nube è stata per molti colossi informatici il candidato migliore per la risoluzione di alcuni problemi generati dall elaborazione di dati su vasta scala. Tale speranza ha portato lo stanziamento di risorse di ogni tipo, soprattutto di ordine economico, atte allo studio e, successivamente, alla realizzazione di un architettura a nube che rispondesse il più possibile alle richieste degli investitori. Attualmente sul mercato sono presenti diverse aziende che offrono servizi cloud: da colossi come Amazon, IBM, Google, Microsoft, fino a realtà cloud offerte da società minori come la GoGrid. 2.1-GoGrid L architettura GoGrid è basata su un infrastruttura a nube che offre un servizio di hosting e mette a disposizione macchine virtuali di tipo Linux e Windows, in cui di default sono già preinstallati programmi come IIS, Java, C#, Apache, PHP, Microsoft SQL Server, e MySQL. Gli elaboratori virtuali (o immagini server) sono gestiti tramite un pannello di controllo multi-sistema 2 che permette con estrema facilità il settaggio della macchina come singolo server o come componente di un cluster. Fig.2-1. Schema rappresentativo dell architettura GoGrid GoGrid, attualmente, mette a disposizione due tipi distinti di hardware (virtuali) Fig RAM CPU Storage Space L utilizzo dei primi 10 GB di spazio disco sono 4GB 8GB 3 Xeon 6 Xeon 240GB 480 GB completamente gratis per ogni account. Alcune delle caratteristiche hardware sono Fig.2-2. Elenco delle possibili configurazioni disponibili in GoGrid. fisse (RAM e CPU) mentre lo spazio di immagazzinamento dati risulta essere altamente scalabile (senza nessun limite d assegnamento o d impiego) e completamente a disposizione delle reti cloud sia di tipo Windows che di tipo Linux. GoGrid permette anche l espansione della memoria di massa anche dopo la costruzione della nube. 2 L'API Client di GoGrid sono gestite tramite tecnologia REST simile alla interfaccia query. Le invocazioni dei metodi di GoGrid sono fatte attraverso Internet spedendo richieste di HTTP GET o HTTP POST direttamente al Server GoGrid API REST il quale, a sua volta, risponde mediante la medesima procedura. Studio ed analisi del Cloud Computing Stumpo Elvio

14 Capitolo 2 Analisi sulle offerte cloud Un altra caratteristica della rete completamente personalizzabile è l elasticità. Infatti l utente, qualora volesse, può scegliere, in maniera del tutto autonoma, il tipo di soluzione di rete (software e hardware) da adottare nella propria nube, impiegando reti preesistenti o creandone di ibride. La rete cloud offerta da GoGrid garantisce, inoltre, persistenza nello stoccaggio dei dati. Questo vuol dire che l hard disk virtuale, associato ad ogni account, non perderà i dati critici durante un riavvio improvviso del server o di un nodo. Se, accidentalmente, il server o un nodo della rete smettesse improvvisamente di funzionare, i dati rimarrebbero intatti e sarebbero disponibili solamente quando l elemento danneggiato non fosse ripristinato o sostituito. Ad ogni cliente di GoGrid è assegnata una sua squadra di esperti che seguono l utente in caso di necessità. L associazione team tecnico cliente è rigida, nel senso che ogni volta che l utente ha bisogno di supporto, tratterà sempre con la stessa squadra di esperti di cloud, i quali sono in possesso di tutte le informazioni del cliente, della rete ad esso associata e della sua eventuale evoluzione. Il servizio di assistenza tecnica è del tutto gratuito e sempre disponibile. In definitiva, le società che scelgono GoGrid come cloud provider sono sempre seguite da esperti del settore e possono creare rapidamente soluzioni di tipo hosting su provider di calcolo a nube che sono scalabili, affidabili, facili da maneggiare ed economici. 2.2-IBM Blue Cloud Cenni sull organizzazione della nube Il progetto Blue Cloud, forte della grande esperienza di IBM nell ambito del calcolo intensivo, si basa su open standard e software open source supportati da servizi, tecnologie e software IBM. Il cuore del Blue Cloud è il BladeCenter vale a dire i sistemi di cluster di server adibiti alle reti a nube. Blue Cloud, inoltre, usa, virtualizzazione di sistemi operativi Fig.2-3. Schema riassuntivo dell architettura Blue Cloud Linux con Xen e PowerVM, in combinazione con lo schedulatore per carichi paralleli Hadoop. Blue Cloud è supportato dal software IBM Tivoli per la gestione dinamica dei server. Viene impiegato anche Google MapReduce per l assegnazione e l esecuzione di vari task su cluster di macchine. Il progetto cloud dell IBM, nonostante la fortissima dipendenza (software, ma soprattutto hardware) con l azienda che lo ha creato, prevede anche la stretta collaborazione con varie istituzioni, tra le quali sono presenti le università che impiegano l architettura a nube per accelerare i loro progetti e le iniziative di ricerca. Molto interessanti sono gli ambienti di cloud computing di tipo accademico della Carnegie Mellon University, la Qatar University, la Texas A&M University, la University of Pretoria e l'health Alliance. Studio ed analisi del Cloud Computing Stumpo Elvio

15 Capitolo 2 Analisi sulle offerte cloud Carnegie Mellon University, Qatar University, Texas A&M University (Qatar) La stretta collaborazione tra queste tre università, tutte nel Qatar, ha dato origine ad un progetto che si prefigge di portare il cloud computing in Medio Oriente. Le università potranno avvalersi anche di collaborazioni esterne, come gruppi di esperti, ricercatori e, addirittura, semplici clienti IBM per sviluppare una soluzione cloud in grado di contribuire a risolvere varie tipologie di problemi. Il Qatar Cloud Computing Center (è l organismo costituito dalla sinergia delle tre università prima citate) ha tra i suoi scopi principali la ricerca e lo sviluppo del data mining, della modellizzazione scientifica e della simulazione, della biologia computazionale, della modellizzazione finanziaria e del modello previsionale. Sono stati inoltre identificati cinque progetti di applicazione pilota sui quali concentrarsi: modellizzazione sismica ed esplorazione per la ricerca di gas e petrolio soluzioni operative di produzione integrate per i settori petrolifero e del gas motore di ricerca web in lingua araba test e migrazione di varie applicazioni utilizzando i metodi di programmazione Hadoop/MapReduce creazione di un percorso di formazione sul cloud computing presso le università University of Pretoria (Sud Africa) Il Computational Intelligence Research Group, presso la University of Pretoria, utilizzerà il cloud computing per la ricerca medica di futura generazione. Attraverso questa iniziativa, gli studenti troveranno i modi per rallentare l'avanzamento di malattie gravi studiando le percentuali di assorbimento dei farmaci e il ripiegamento della struttura proteica del DNA una volta introdotto un certo tipo di farmaco. La soluzione cloud computing consentirà anche di gestire meglio i progetti e i carichi di lavoro. In passato, non si disponeva di sistemi dedicati alla gestione dei progetti di ricerca, e si doveva inoltre raccogliere manualmente i risultati dei dati relativi agli esperimenti a causa della scarsa disponibilità di applicazioni per la gestione delle informazioni. I tempi di ricerca ora si sono ridotti da settimane a giorni e le diverse variazioni dei test di ricerca sono disponibili nella soluzione cloud per trarne risultati utili dal punto di vista statistico The Higher Education Alliance for Leadership Through Health (Africa Orientale) L'HEALTH Alliance, è un consorzio di sette università, che lavora con IBM ed esperti del settore per ampliare le offerte formative attraverso laboratori informatici virtuali in modo tale da consentire agli studenti l'accesso remoto. Tramite questo cloud, gli studenti dell'alliance potranno accedere ai materiali informatici formativi più avanzati, selezionare applicazioni software e risorse informatiche e di storage senza dover sostenere spese di manutenzione e alimentazione di ambienti informatici. L'HEALTH Alliance, si dedica, tra le altre cose, a promuovere l'uso strategico della tecnologia per impieghi inerenti alla sanità pubblica, prevedendo di insediare un Public Healthcare Studio ed analisi del Cloud Computing Stumpo Elvio

16 Capitolo 2 Analisi sulle offerte cloud Center of Excellence in grado di fornire assistenza sanitaria e servizi formativi facilmente disponibili ai paesi dell'africa sub-sahariana. 2.3-Google App Engine Visto lo sviluppo della rete a nube, anche Google offre, ormai, da diversi mesi il suo nuovo prodotto cloud: Google App Engine (GAE). GAE è stato studiato come il metodo da seguire per creare applicazioni web (HTTP-driven) da ospitare sui web server di Google. A differenza di EC2, e GoGrid, GAE scende nel campo delle piattaforme cloud fornendo un framework di tecnologie rigide, con le quali creare applicazioni senza preoccuparsi della loro architettura e dei picchi di traffico e carico. Il software è realmente open source, infatti nelle pagine dedicate alla cloud di Google si trova tutto, ivi compresi i listati Fig.2-4. Confronto schematico tra GAE e una tipica rete cloud dei sorgenti (Python) Le risorse La prima caratteristica della rete che si riscontra è la mancata scalabilità hardware della rete stessa. Per ogni account, infatti, il Google App Engine associa solo una CPU 3 di tipo monocore. Attualmente non è prevista la possibilità dell impiego di architetture multi-core tipiche del cloud. Nonostante questa grossa limitazione che rende la rete abbastanza rigida, le sue caratteristiche sono tutte monitorate, come: il carico della CPU, la banda trasmissiva impiegata, le risorse realmente impiegate per ogni singola applicazione. Un dettagliato pannello di controllo, infatti, riporta un lungo elenco di voci che indicano i consumi effettivi (in continuo aggiornamento). Un ulteriore caratteristica che discosta GAE dalle comuni reti cloud è la completa mancanza di virtualizzazione di sistemi operativi di ogni tipo; esso, infatti, permette la sola esecuzione di codice Python, eventualmente associato ad un framework proprietario o ad una versione alleggerita di Django. Per usufruire della rete GAE e, quindi, iniziare a sviluppare le applicazioni, è necessario scaricare l'ambiente di sviluppo, che ricreerà le stesse condizioni tecniche di GAE sulla propria macchina locale; l'sdk contiene, infatti, un web server, un database, le strutture per recuperare indirizzi HTTP(s), quelle per l'invio di e per la manipolazione d immagini. 3 Ad ogni singola CPU è associato un processore Intel con clock pari a 1.2 GHz con architettura X86 (32-bit). Studio ed analisi del Cloud Computing Stumpo Elvio

17 Capitolo 2 Analisi sulle offerte cloud I componenti fondamentali Per poter controllare il consumo effettivo di risorse, GAE mette a disposizione tutta una serie di servizi che le applicazioni possono sfruttare: Il Datastore: database un po particolare denominato BigTable, formato da una piattaforma distribuita operante sul file system proprietario, GFS. Ha un linguaggio simile a SQL con delle limitazioni a carattere operativo chiamato GQL. Nonostante le limitazioni, comunque, è consentito un uso standard abbastanza vasto del database da parte delle applicazioni. Google Accounts: è una API che permette di avere automaticamente un sistema di login per le applicazioni, basato sugli accounts Google. Potrebbe essere un problema di sicurezza basare l identificazione dell utente solo sull impiego dell account, ma considerato che non esiste una versione business di GAE, il problema passa in secondo piano. URL Fetch: le applicazioni possono accedere all'esterno, recuperando il contenuto di URLs remoti sfruttando API basate sulla stessa infrastruttura che Google usa per altri suoi prodotti. E' comunque possibile usare le librerie standard di Python se non si vuole usufruire dell infrastruttura Google (e dei suoi limiti). Mail: usata per inviare con o senza allegati anche verso l "admins" delle applicazioni. Memcache: è uno storage di tipo in-memory key-value. Permette di inserire in cache strutture, valori, risultati di query complesse e rendere, quindi, il recupero degli stessi più veloce. Image Manipulation: permette di ridimensionare, ruotare ed effettuare operazioni basilari su immagini in formato JPEG e PNG. Ogni richiesta HTTP ha 30 secondi di tempo per essere evasa, l'sdk permette anche il deploy delle applicazioni per svilupparle in locale, fino al momento dello spostamento sui server di Google, riducendo al minino il carico della rete. Sandbox:. è un ambiente sicuro, affidabile, indipendente dall hardware, dal sistema operativo e dalla ubicazione fisica del sistema di servizio di web in cui vengono conservate le richieste di rete dei vari utenti. Questo metodo garantisce accessi sicuri, contemporanei e multipli alla rete GAE. Studio ed analisi del Cloud Computing Stumpo Elvio

18 Capitolo 2 Analisi sulle offerte cloud Costi per l impiego della rete GEA Ogni operazione (richiesta) sottoposta all GAE, sia in entrata che in uscita, consuma un certo livello di risorse addizionali che vengono addebitate sul proprio account. R I C H I E S T E D A T A S T O R E E M A I L Risorsa Richieste Larghezza di banda uscente (fatturabile, incluso Http) Larghezza di banda entrante (fatturabile, incluso Http) Limite quotidiano 1,300,000 richieste Frequenza massima 7,400 richieste/minuto 10 gigabytes 56 megabytes/minuto 10 gigabytes 56 megabytes/minuto Tempo di CPU (fatturabile) 46 ore-cpu 15 minuti CPU/minuto Chiamate di API Datastore 10,000,000 chiamate 57,000 chiamate/minuto Limite quotidiano 43,000,000 richieste max 1,046 gigabytes max 1,046 gigabytes max 1,729 ore-cpu 140,000,000 chiamate Frequenza massima 30,000 richieste/minuto 740 megabytes/minuto 740 megabytes/minuto 72 minuti CPU/minuto 129,000 chiamate/minuto Stored Data (fatturabile) 1 gigabyte nessuna nessun limite max nessuna Dati inviati all'api 12 gigabytes 68 megabytes/minuto 72 gigabytes Dati ricevuti dall'api 115 gigabytes 659 megabytes/minuto 695 gigabytes 153 megabytes/minuto 1,484 megabytes/minuto Tempo di CPU di Datastore 60 ore-cpu 20 minuti CPU/minuto 1,200 ore-cpu 50 minuti CPU/minuto Chiamate API mail 7,000 chiamate 32 chiamate/minuto Destinatari (fatturabili) Quota gratis predefinita 2,000 destinatari 8 destinatari/minuto Quota a pagamento predefinita 1,700,000 chiamate max 7,400,000 destinatari 4,900 chiamate/minuto 5,100 destinatari/minuto Admins 5, /minuto 3,000,000 9,700 /minuto Invio messaggi Body Data 60 megabytes 340 kilobytes/minuto 29 gigabytes 84 megabytes/minuto Invio allegati 2,000 allegati 8 allegati/minuto 2,900,000 allegati 8,100 allegati/minuto U R L I M A G E M E M C A C H E F E T C H M A N I P U L A T I O N Invio dati allegati 100 megabytes 560 kilobytes/minuto 100 gigabytes Chiamate UrlFetch API 657,000 chiamate 3,000 chiamate/minuto 46,000,000 chiamate Invio dati all'urlfetch 4 gigabytes 22 megabytes/minuto 1,046 gigabytes Ricezione dati dall'urlfetch 4 gigabytes 22 megabytes/minuto 1,046 gigabytes Chiamate all'api Manipolazione d'immagini 864,000 chiamate 4,800 chiamate/minuto 45,000,000 chiamate Invio dati all'api 1 gigabytes 5 megabytes/minuto 560 gigabytes Ricezione dati dall'api 5 gigabytes 28 megabytes/minuto 427 gigabytes Esecuzione trasformazione 2,500,000 trasformazioni Chiamate all'api Memcache 8,600,000 14,000 trasformazioni/minuto 48,000 chiamate/minuto 47,000,000 trasformazioni 96,000,000 Dati inviati all'api 10 gigabytes 56 megabytes/minuto 60 gigabytes Data ricevuti dall'api 50 gigabytes 284 megabytes/minuto 315 gigabytes 300 megabytes/minuto 32,000 chiamate/minuto 740 megabytes/minuto 740 megabytes/minuto 31,000 chiamate/minuto 400 megabytes/minuto 300 megabytes/minuto 32,000 trasformazioni/minuto 108,000 chiamate/minuto 128 megabytes/minuto 640 megabytes/minuto Fig.2-5. Tabella riassuntiva delle caratteristiche offerte e monitorizzate da GAE L idea fondo è all incirca la stessa dei cellulari prepagati. Esistono due tipi di abbonamento o profilo quello Free (o gratis) e quello Billing (o a pagamento). Il profilo gratis è associato per default ad ogni account. Se le risorse consumate dall utente sono inferiori a quelle previste per il profilo free l utente non paga nulla, altrimenti, se supera il limite, va in burst e cambia automaticamente profilo e passa a quello billing. Chiaramente esiste un metodo per controllare la tariffazione Studio ed analisi del Cloud Computing Stumpo Elvio

19 Capitolo 2 Analisi sulle offerte cloud delle risorse addizionali ed è accessibile anche all utente: Google Checkout. Esso indirizza l utente al Max Daily Budget il quale può configurare e controllare le somme stanziate per le singole risorse addizionali che l utente è disposto ad acquistare ogni giorno. Configurando il Max Daily Budget su valori ben precisi, si ottiene un tetto massimo di spesa. Raggiunto tale valore, le applicazioni vengono bloccate. Anche in questo caso vale il paradigma pay-for use vale a dire che è addebitata solo la risorsa che effettivamente viene consumata Ulteriori dettagli Un sistema rigido come la Rete GAE comporta anche diversi limiti. Non si tratta, infatti, di un prodotto completamente nuovo: la piattaforma, infatti, è la stessa alla base di molti attuali servizi di casa Google, come Google Earth, Google Sites, o Google Finance e al suo interno integra una serie di applicazioni e funzionalità che Google utilizza già da tempo in tutto il mondo. Google ha comunque espresso la volontà di migliorare le potenzialità del proprio servizio cloud. Attualmente Google è in continua ricerca di soci validi per il progetto cloud, aziende del settore interessate (si è appena associata ad Salesforce), o singoli utenti e/o sviluppatori disposti a testare ed eventualmente migliorare i servizi forniti dalla rete. Il sistema GAE è ancora in fase di studio ed è offerto a tutti nella versione previous release che permette ai team tecnici un continuo testing real-time del prodotto e quindi l individuazione delle carenze dell architettura stessa. 2.4-EC2 Amazon Elastic Compute Cloud (noto anche come "EC2") è un servizio web che permette ai clienti di noleggiare computer su cui eseguire le proprie applicazioni informatiche. EC2 consente, tramite un processo completamente scalabile, la realizzazione di applicazioni web, fornendo servizi di interfaccia attraverso cui i clienti possono richiedere un numero arbitrario di macchine virtuali, vale a dire istanze del server su cui si può caricare qualsiasi tipo di software. Amazon Elastic Compute Cloud, inoltre, ha la capacità di ridimensionare il proprio carico di lavoro in nubi di calcolo. L obiettivo del cloud di Amazon è quello di fornire applicazioni software sempre più semplici ed intuitive, sia dal lato utente che dal lato sviluppatore. Esso, infatti, fornisce il controllo completo delle risorse di elaborazione e consente di eseguire le istanze direttamente su Amazon. L EC2 riduce il tempo richiesto per ottenere le istanze; tale condizione permette una rapida scalabilità delle capacità, sia verso l alto che verso il basso, in funzione del comportamento dell utilizzatore. Attualmente gli utenti possono creare, avviare e chiudere le istanze del server in maniera del tutto autonoma, da qui il termine "elastico. Amazon.com prevede che EC2 sarà uno dei suoi numerosi servizi web, commercializzato con il termine Amazon Web Services (AWS); infatti EC2 è diventato disponibile al pubblico il 23 ottobre 2008 con il supporto per Microsoft Windows Server. Studio ed analisi del Cloud Computing Stumpo Elvio

20 Capitolo 2 Analisi sulle offerte cloud Funzionalità Amazon EC2 Amazon EC2 presenta un vero e proprio ambiente virtuale che consente di utilizzare le interfacce di servizi web per lanciare le istanze sotto una varietà di sistemi operativi, impiegando per ogni ambiente applicazioni specifiche. Per utilizzare Amazon EC2, basta semplicemente: Creare un Amazon Machine Image (AMI), che contenga le applicazioni, le librerie, i dati e le impostazioni di configurazione, o in alternativa, caricare una macchina virtuale già pre-configurata per ottenere una AMI che sia immediatamente funzionante. Caricare l'ami in Amazon S3. EC2 fornisce gli strumenti che rendono semplice la memorizzazione della stessa. Amazon S3 fornisce un sicuro, affidabile e veloce magazzino per memorizzare le immagini. Utilizzare il servizio web di Amazon EC2 per la configurazione della sicurezza e l accesso alla rete. Scegliere il tipo di istanze da utilizzare, il sistema operativo che si desidera, poi farle eseguire (lancio istanza - termino istanza); controllare il numero di istanze dell AMI utilizzando, se necessario, il servizio Web API o altri strumenti di gestione. Stabilire se si desidera eseguire le istanze in locazioni multiple (IP statico endpoints, o l attach persistent block storage). Pagare solo le risorse che si consumano effettivamente, come ad esempio, il tempo o il trasferimento di dati Servizi highlights Elasticità - Amazon EC2 consente di aumentare o diminuire la capacità di calcolo nel giro di pochi minuti, non in ore o in giorni. È possibile utilizzare centinaia o addirittura migliaia di server contemporaneamente. Questo perché tutto è sotto controllo mediante le API del servizio Web. Le applicazione degli utenti si possono scalare in maniera del tutto automatica, sia verso l alto che verso il basso, a seconda delle esigenze. Completamente controllata L utente ha il completo controllo delle sue istanze. Ha accesso come root per ciascuna di esse, e può interagire con loro come si farebbe con qualsiasi macchina. Le istanze possono essere riavviate in remoto usando le API del servizio web. Si può anche ottenere un accesso alla console di uscita delle proprie istanze. Flessibilità L utente può scegliere tra varie tipologie di istanze, ha a disposizione vari sistemi operativi e pacchetti software. Amazon EC2 consente di selezionare una configurazione di memoria, di CPU, e della migliore istanza di archiviazione possibile, in funzione della scelta del sistema operativo e delle applicazioni. Ad esempio, la scelta di sistemi operativi comprende numerose distribuzioni di Linux, di Microsoft Windows Server e di OpenSolaris. Integrazione - Amazon EC2 è progettato anche per l utilizzo con altri Amazon Web Services. Esso, infatti, lavora in collaborazione con Amazon Simple Storage Service (Amazon S3), Amazon SimpleDB e Amazon Simple Queue Service (Amazon SQS) per fornire una soluzione completa per il calcolo, l'elaborazione e l'archiviazione di ricerca in una vasta gamma di applicazioni. Studio ed analisi del Cloud Computing Stumpo Elvio

21 Capitolo 2 Analisi sulle offerte cloud Affidabilità - Amazon EC2 è altamente affidabile ed offre un ambiente in cui le istanze possono essere comodamente previste, quindi, facilmente commissionate, ma anche rapidamente sostituite (database di istanze pre-configurate). I vari servizi vengono eseguiti all'interno dell infrastruttura di rete e dei data center di Amazon. Personalizzazione - Amazon EC2 fornisce agli utenti particolari strumenti per creare applicazioni tra le quali sono presenti: Amazon Elastic Block Store - Amazon Elastic Block Store (EBS), è il servizio offerto per lo stoccaggio persistente delle istanze di Amazon EC2. Amazon EBS fornisce volumi, ad esempio, di memorizzazione off-instance che persistono indipendentemente dalla vita di un istanza. Gli Amazon EBS sono volumi di stoccaggio facilmente reperibili, altamente affidabili che possono essere facilmente connessi ad istanze di Amazon EC2 e sono rilevati come dispositivi standard a blocchi. I volumi EBS offrono notevoli miglioramenti in termini di durevolezza, indipendentemente da dove le istanze di Amazon EC2 siano memorizzate; infatti, i volumi di Amazon EBS sono automaticamente replicati tramite backend (in una unica availability zone). Per quelli che vogliono ancora più affidabilità nello stoccaggio, Amazon EBS prevede la possibilità di creare point-in-time, istantanee dei volumi selezionati che vengono poi immagazzinate in Amazon S3, e automaticamente replicate su più zone disponibili (multi availability zone). Queste istantanee possono essere utilizzate come backup o come punto di partenza per i nuovi volumi Amazon EBS. Multiple Locations - Amazon EC2 prevede la possibilità di collocare le varie istanze in più sedi. Le locazioni di Amazon EC2 sono composte da regioni e da availability zone. Queste ultime sono luoghi ben distinti progettati per essere potenzialmente immuni da possibili guasti, sono poco costose, hanno basso tempo di latenza di connettività di rete e sono sempre collegate con le rimanenti availability zone presenti nella stessa Regione. Con il lancio di istanze in availability zone distinte, si possono proteggere le applicazioni dai potenziali guasti avvenuti in una singola locazione. Le regioni consistono in una o più availability zone (per esempio la regione che si occupa dell Europa è formata solo da due availability zone); sono distribuite sul territorio, e sono in zone geografiche distinte o in veri e propri stati. L Amazon EC2 Service Level Agreement è impiegato al 99,95% della sua disponibilità per ogni Amazon EC2 Region. Amazon EC2 è attualmente disponibile in due sole regioni: uno negli Stati Uniti e uno in Europa. Elastic IP Addresses - Indirizzi IP elastici statici sono progettati per fornire indirizzi IP dinamici della nube di calcolo. Ogni indirizzo IP elastico è associato con l account dell utente e non alla singola istanza, e l utente continua a controllare tale indirizzo fino a quando non si scelga esplicitamente di rilasciarlo. A differenza dei tradizionali indirizzi IP statici, gli indirizzi IP elastici consentono di proteggere le istanze dai guasti delle availability zone attraverso una rimappatura sistematica degli indirizzi IP dell utente e di tutte le istanze del suo account. Piuttosto che attendere un supporto tecnico (dati programmi etc) che riconfiguri o sostituisca l host, o in attesa della trasmissione del DNS a tutti i suoi client, Amazon EC2 consente di risolvere rapidamente i problemi con le proprie istanze o con particolari software mediante l invocazione della rimappatura dei propri indirizzi IP elastici in modo da ottenerne dei nuovi da sostituire a quelli temporaneamente non funzionanti. Sicurezza - Amazon EC2 fornisce delle interfacce web service per configurare le impostazioni del firewall che controllano l'accesso alla rete e tra gruppi di istanze. Studio ed analisi del Cloud Computing Stumpo Elvio

22 Capitolo 2 Analisi sulle offerte cloud Economicità - Amazon EC2 fornisce a tutti i suoi utenti i vantaggi finanziari derivanti dalla scalabilità di Amazon. Le spese sostenute da ogni utente per il pay-for-use risultano essere molto più convenienti a confronto del tradizionale e significativo investimento iniziale per l'acquisto e la manutenzione dell hardware. L impiego dell EC2 libera da molte delle complessità della pianificazione delle capacità, trasformando quello che comunemente rappresentano i grandi costi fissi in costi variabili molto più piccoli, ed eliminando la necessità di acquistare più di una "rete di sicurezza" da utilizzare ogni qualvolta si devono gestire i saltuari picchi di carico Tipologie di istanze EC2 utilizza la virtualizzazione Xen. Ogni macchina virtuale, è chiamata istanza e funziona come un server virtuale privato, disponibili in tre possibili dimensioni, piccolo, grande o extra large. Amazon.com dimensiona caso per caso sulla base delle " EC2 4 Compute Units" l'equivalente della capacità della CPU in un hardware fisico. Il sistema offre le seguenti tipologie di istanze Istanze standard Istanze di questa famiglia sono particolarmente adatte per la maggior parte delle applicazioni. Piccola istanza La piccola istanza (di default), equivale a: 1 sistema con 1,7 GB di memoria, 1 EC2 Compute Unit (1 core virtuale con 1 EC2 Compute Unit) 160 GB di istanza di archiviazione Piattaforma a 32-bit. Grande istanza La grande istanza rappresenta: 1 sistema con 7,5 GB di memoria 4 EC2 Compute Unit (2 core virtuali con 2 unità EC2 Compute Unit ciascuno) 850 GB di istanza di archiviazione Piattaforma a 64-bit. Istanza extra large L'extra large offre l'equivalente di: 1 sistema con 15 GB di memoria 8 EC2 Compute Unit (4 core virtuali con 2 unità EC2 Compute Unit ciascuno) 1690 GB di istanza di archiviazione Piattaforma a 64-bit. 4 Una EC2 Compute Unit 2007, ad esempio, è pari a un Opteron o Xeon 2007 con un clock pari a 1,0-1,2 GHz Studio ed analisi del Cloud Computing Stumpo Elvio

23 Capitolo 2 Analisi sulle offerte cloud Istanze High-CPU Istanze di questa famiglia sono impiegate in tutte le applicazioni che utilizzerebbero le CPU sia in termini di memoria (RAM) che in termini di alta intensità di calcolo. High-CPU istanza media Istanze di questa famiglia hanno la seguente configurazione: 1,7 GB di memoria 5 EC2 Compute Unit (2 core virtuali con 2,5 EC2 Compute Unit ciascuno) 350 GB di istanza di archiviazione Piattaforma a 32-bit I / O Performance: Moderata High-CPU istanza extra large Istanze di questa famiglia hanno la seguente configurazione: 7 GB di memoria 20 EC2 Compute Unit (8 core virtuali con 2,5 EC2 Compute Unit ciascuno) 1690 GB di istanza di archiviazione Piattaforma a 64-bit I / O Performance: Alta Sistemi operativi e software Sistemi operativi Le Amazon Machine Images (AMIS) sono preconfigurate con un sempre crescente elenco di sistemi operativi. Quando è stato lanciato nell agosto 2006, il servizio offerto da EC2 era compatibile con Linux e con Sun Microsystems, più tardi con OpenSolaris e con Solaris Express Community Edition. Nell ottobre 2008, EC2 ha aggiunto il sistema operativo Windows Server 2003 alla lista dei sistemi operativi utilizzabili. Attualmente disponibili all'uso con Amazon EC2 sono: Red Hat Enterprise Linux OpenSolaris Fedora Windows Server 2003 OpenSUSE Linux Gentoo Linux Oracle Enterprise Linux Ubuntu Linux Debian Il prossimo passo che Amazon intende intraprendere è quello di creare un interfaccia API adatta ad essere inserita direttamente nella distribuzione standard di Ubuntu Software Amazon EC2 consente ai suoi collaboratori e ai suoi clienti di creare e personalizzare le Amazon Machine Immagini (AMIS) con software in base alle esigenze. Esistono ampie Studio ed analisi del Cloud Computing Stumpo Elvio

24 Capitolo 2 Analisi sulle offerte cloud disponibilità di macchine virtuali (AMIS) e di spazio ( a pagamento e/o gratuito). Alcuni dei software oggi disponibile per l'uso all'interno di Amazon EC2 sono: Databases Batch Processing Web Hosting Oracle 11g Hadoop Apache HTTP Microsoft SQL Server Standard 2005 MySQL Enterprise Microsoft SQL Server Express Condor Open MPI IIS/Asp.Net Application Development Environments Java Application Server JBoss Enterprise Application Platform Ruby on Rails Video Encoding & Streaming Wowza Media Server Pro Windows Media Server Fig.2-6 Elenco dei programmi (divisi per categorie ) già compatibili con EC Costi Istanze Stati Uniti Instanza Standard Linux/UNIX Windows Instanza Standard Linux/UNIX Small $0.10 all'ora $0.125 all'ora Small $0.11 all'ora (Default) (Default) Large $0.40 all'ora $0.50 all'ora Large $0.44 all'ora Extra Large $0.80 all'ora $1.00 all'ora Extra Large $0.88 all'ora Instanza High CPU Linux/UNIX Windows Instanza High CPU Linux/UNIX Medium $0.20 all'ora $0.30 all'ora Medium $0.22 all'ora Extra Large $0.80 all'ora $1.20 all'ora Extra Large $0.88 all'ora Fig.2-7. Elenco dei costi delle varie istanze disponibili in EC2 viene avviata fino a quando essa termina 5. Europa Si paga solo per quello che si usa. Non esiste alcuna tariffa minima. Come si vede, la tariffazione è basata sulle ore effettivamente consumate per ogni tipo di istanza, a partire dal momento in cui 5 Consumi effettivi inferiori all ora sono fatturati come un ora piena. Studio ed analisi del Cloud Computing Stumpo Elvio

25 Capitolo 2 Analisi sulle offerte cloud Trasferimento dei dati Internet Trasferimento dati IN I prezzi si basano su trasferimenti dei dati "in" e "out" da Amazon EC2. Trasferimento $0.10 per GB dati completo Trasferimento dati OUT Per 10 TB $0.17 per GB mensili Per ulteriori 40 $0.13 per GB TB mensili Per ulteriori $0.11 per GB 100TB mensili Oltre i 150 TB $0.10 per GB mensili Fig.2-8. Elenco costi dei trasferimenti tramite EC2 Il trasferimento dei dati nella stessa Amazon Web Services è gratuito. Il trasferimento dei dati tra AWS diverse o tra regioni diverse, è sottoposto a tariffazione ed il costo dell operazione viene addebitato, come in Internet, su entrambi i lati del trasferimento (mittente e destinatario). L impiego di Amazon Web Services per altri scopi è fatturato separatamente da Amazon EC Availability zone e trasferimento dati Trasferimenti inter-zona $ 0.00 per GB - tutti i dati trasferiti dentro la stessa availability zone utilizzando indirizzi IP privati. Trasferimenti regionali $ 0,01 per GB in / out - tutti i dati trasferiti tra diverse availability zone ma appartenenti alla stessa regione. IP elastici pubblici e trasferimento dati $ 0,01 per GB in / out - Se si sceglie di comunicare utilizzando il proprio indirizzo IP elastico all'interno della rete Amazon EC2, si accetta automaticamente di pagare le tariffe di trasferimento dati di tipo regionale, anche se le istanze sono disponibili nella stessa availability zone. Per il trasferimento dei dati all'interno della stessa availability zone, si può facilmente evitare questa tariffazione (e ottenere migliori prestazioni di rete) utilizzando il proprio IP privato, ove possibile. Studio ed analisi del Cloud Computing Stumpo Elvio

26 Capitolo 2 Analisi sulle offerte cloud Amazon Elastic Block Storage Amazon.com offre la possibilità di salvare dati anche sul lungo periodo grazie ad Elastik Block Storage (EBS). Gli utenti possono creare e gestire volumi di dimensioni da 1 GB a 1 TB. Si possono allegare istanze di EBS ad un particolare tipo di server in modo da mantenere l'archiviazione dei dati in strutture sicure e sempre raggiungibili da EC2. United States Amazon EBS Volumes $0.10 per GB mensili per lo stoccaggio dati $0.10 per 1 millione di richieste I/O Snapshots delle EBS in Amazon S3 $0.15 per GB mensili per dati salvati $0.01 per 1,000 richieste di PUT (salvataggio di una snapshot) $0.01 per 10,000 richieste di GET (caricamento di una snapshot) Europa Amazon EBS Volumes $0.11 per GB mensili per lo stoccaggio dati $0.11 per 1 millione di richieste I/O Snapshots delle EBS in Amazon S3 $0.18 per GB mensili per dati salvati $0.012 per 1,000 richieste di PUT (salvataggio di una snapshot) $0.012 per 10,000 richieste di GET (caricamento di una snapshot) Da luglio 2008 Outblaze Spamhaus.org ha iniziato a bloccare Amazon EC2 a causa di problemi con la distribuzione di spam e malware Indirizzi IP elastici Nessun costo per gli indirizzi IP elastici mentre sono in uso. $ 0,01 per gli indirizzi IP elastici non-attached per ogni ora $ 0,00 per le prime 100 rimappature degli indirizzi IP elastici per ogni mese $ 0,10 per ogni rimappatura degli indirizzi IP elastici supplementare a quelli mensili. Fig.2-9. Elenco costi dello storage in EC Pay-for-use Il pagamento è effettuato alla fine di ogni mese per il proprio EC2 in base alle risorse effettivamente consumate. A titolo di esempio, si consideri che avviare 100 istanze del tipo small ha un costo orario pari a 0,10 $. Le istanze saranno immediatamente pronte all'avvio, ma non saranno avviate necessariamente tutte nello stesso momento. Ogni istanza è in grado di memorizzare il suo tempo di lancio effettivo. Successivamente, per ogni istanza verrà addebitato l utilizzo delle risorse in base al tempo (a $ 0.10/ora) di esecuzione, ovvero, dal momento che l istanza è effettivamente partita fino alla sua conclusione. Ogni istanza verrà eseguita fino a quando non si verifichi uno dei seguenti casi: Chiusura dell istanza corretta, si invoca API TerminateInstances (o uno strumento equivalente), l'istanza termina Chiusura dell istanza a causa di guasti di tipo software o di tipo hardware Descrizione dettagliata per l esecuzione delle istanze Amazon EC2 consente di impostare e configurare tutto delle proprie istanze, dal sistema operativo impiegato fino alle singole applicazioni. Un Amazon Machine Image (AMI) è semplicemente un ambiente di lavoro preconfezionato che comprende tutti gli strumenti necessari per impostare e avviare le istanze. Si può impiegare solamente una singola AMI, ma è possibile Fig Elementi fondamentali che compongono il cloud di Amazon e loro rispettive competenze impiegare anche interi gruppi di diverse AMI (ad esempio, web, applicazioni server, banche dati, etc). Amazon EC2, tramite linee di comando, Studio ed analisi del Cloud Computing Stumpo Elvio

27 Capitolo 2 Analisi sulle offerte cloud fornisce una serie di strumenti per facilitare la creazione della propria AMI. Una volta creata e personalizzata, bisogna caricarla su Amazon S3. EC2 utilizza Amazon S3 per fornire affidabilità, scalabilità nello stoccaggio delle varie AMI in modo che siano sempre pronte per essere utilizzate dagli utenti. È anche possibile scegliere le AMI da una libreria disponibile a livello mondiale che possono fungere anche da utili esempi di istanze. Ad esempio, se si desidera solo un semplice server Linux, è possibile scegliere tra una delle tante AMI server standard create per Linux. Dopo aver impostato il proprio account e caricata la propria AMI, si è pronti per avviare le istanze. È possibile avviare l AMI in qualsiasi momento e/o qualsiasi altro tipo di istanza utilizzando il RunInstances API. Se si desidera eseguire più di 20 istanze, creare più di 20 volumi EBS o se sono necessari più di 5 indirizzi IP elastici, si devono compilare i vari moduli di richiesta (instance request form, EBS volume request form, Elastic IP request form) da inviare ad Amazon EC2, che li esaminerà. Attualmente il servizio fornito da Amazon risulta essere il più completo sotto ogni punto di vista ed il vero avversario da battere se si vuole diventare l azienda leader nel settore del cloud computing. L unica pecca che attualmente possiede è la non disponibilità di virtualizzazioni di macchine Windows nella regione Europa. 2.5-Microsoft Azure Microsoft Azure Services Platform è una piattaforma cloud che "offre una vasta serie di servizi Internet che possono essere impiegati indifferentemente sia con applicazioni onpremises e sia con codice cloud. La sua prima apparizione risale alla PDC 2008 dove è stata presentata alla comunità informatica in versione per sviluppatori. L uscita della versione ufficiale è prevista entro il La piattaforma dei servizi Azure sfrutta un sistema operativo specializzato, indicato con il termine Windows Azure, che viene eseguito nei cluster dei datacenters di Microsoft. Le sue mansioni fondamentali sono: l assegnazione delle risorse (o un loro sottoinsieme) ad applicativi presenti al suo interno e la gestione della potenza di calcolo e di quella d immagazzinamento dei dati. Azure di Windows, in fase di progettazione noto come "Red dog", è stato descritto come uno "strato di nube" da collocarsi al di sopra dei vari sistemi di server di Microsoft che impiegano Windows Server 2008 ed Hyper-V 6 per la virtualizzazione dei servizi. 6 Microsoft Hyper-V è la tecnologia di virtualizzazione verticale (dal datacenter al desktop) integrata in Windows Server 2008 che consente il consolidamento di un ampia gamma di servizi, da quelli che utilizzano intensamente le risorse, alle applicazioni di terze parti. Il vantaggio più rilevante della virtualizzazione è il consolidamento dei server, che consente di concentrare in un solo server il carico di lavoro di più server. Le aziende in questo modo consolidano il server di stampa, il server di fax, il server di Exchange e il server Web in un solo computer Windows Server. Ma Hyper-V non si limita al Studio ed analisi del Cloud Computing Stumpo Elvio

28 Capitolo 2 Analisi sulle offerte cloud La piattaforma include al suo interno cinque diversi servizi: Live Services, SQL Services,.NET Services, SharePoint Services e Dynamics CRM Services che possono essere impiegati dagli sviluppatori per progettare gli applicativi cloud. Sono disponibili, inoltre, per gli utenti di Visual Studio le librerie, esempi di codice, ed alcuni tools finalizzati alla creazione di applicativi destinati alla nube. La piattaforma dei servizi può gestire attualmente applicazioni di.net Framework scritte in C# che devono supportare ASP.NET e tutti i metodi ed i servizi necessari alla pubblicazione dell applicazione stessa nella nube. Sono stati realizzati anche due particolari SDK per garantire l interoperabilità con Azure: il Java SDK ed il Ruby SDK entrambi disponibili per.net Services. In questo modo si abilitano gli sviluppatori Java e quelli di Ruby ad impiegare le funzionalità di.net Services. In futuro Microsoft si impegna a realizzare e a rendere disponibili anche SDK per Python, php, OpenID, Eclipse. Nel capitolo successivo sono presenti maggiori dettagli su questa architettura di cloud computing. consolidamento dei server: migliora anche l affidabilità, la scalabilità, la protezione e la flessibilità della rete. Hyper-V virtualizza i seguenti sistemi operativi: Windows Server 2008 x86 e x64 (VM configurate con 1, 2 or 4-way SMP), Windows Server 2003 x86 e x64 (VMs configurate con 1 or 2-way SMP), Windows Vista x86 e x64 con Service Pack 1 (VMs configurate con 1 or 2-way SMP), Windows XP x64 con Service Pack 2 (VMs configurate con 1 or 2-way SMP), Windows XP x86 con Service Pack 3 (VMs configurate con 1 or 2-way SMP), Windows XP x86 con Service Pack 2 (VMs configurate con 1-way only), Windows Server 2000 con Service Pack 4 (VMs configurate con 1-way only) e SUSE Linux Enterprise Server 10 con Service Pack 1 e Pack 2 ( x86 e x64 Edition). Studio ed analisi del Cloud Computing Stumpo Elvio

29 Capitolo 3 Microsoft Azure Services Platform 3.1-Introduzione alla piattaforma di servizi Azure Microsoft Azure Service Platform è la nuova piattaforma di servizi che Microsoft offre per il cloud computing. Si definisce piattaforma di servizi una particolare raccolta di programmi di diversa natura che godono di un alto grado di reciproca integrazione e tale caratteristica può essere sfruttata in maniera automatica e/o su richiesta degli sviluppatori. L Azure Services Platform (o semplicemente Azure) è stato ideato e progettato per poter essere impiegato nel calcolo a nube e sfrutta i datacenters della Microsoft per fornire alla propria piattaforma di servizi caratteristiche di scalabilità basate su Internet. Questa tipologia di prodotti offre un sistema operativo ed un set di servizi per gli sviluppatori, che possono essere impiegati in maniera del tutto indipendente. Godendo di flessibilità e di interoperabilità, la piattaforma Azure può essere usata per progettare nuove applicazioni cloud o migliorare quelle vecchie equipaggiandole con capacità tipiche della rete a nube. La sua è un architettura aperta (possibilità di personalizzazione della rete) che fornisce agli sviluppatori la capacità di scegliere il tipo di sistema su cui far girare le proprie applicazioni web, come ad esempio, sulla propria macchina, su più PC, su server o su soluzioni ibride realizzate per sfruttare il meglio delle varie realtà. Azure, come ogni architettura di questo tipo, evita la forte dipendenza dai vincoli hardware consentendo agli sviluppatori di creare rapidamente e facilmente nuove applicazioni di tipo cloud usando le loro abilità con i prodotti Microsoft, impiegando gli ambienti di sviluppo di Visual Studio o.net Framework. Oltre al codice di tipo.net, Azure, nel prossimo futuro, supporterà diversi linguaggi di programmazione e di ambienti di sviluppo. La gestione dell infrastruttura è automatizzata mediante una piattaforma progettata per gestire un gran numero di richieste, scalabili dinamicamente, per soddisfare le necessità d impiego mediante il modello di pagamento pay-as-you-go (del tutto simile al pay-for-use). Il provider Azure è impostato su uno standard aperto (predisposizione all implementazione di vari standard applicativi web-oriented) basato su ambienti d interoperabilità, i quali sfruttano protocolli Internet multipli, incluso l HTTP, il PHP il Representational State Transfer (REST 7 ), il Simple Object Access Protocol (SOAP 8 ) e il Extensible Markup Language (XML 9 ). 7 Representational state transfer (REST) è un tipo di architettura software per sistemi di ipertesto distribuiti come il World Wide Web. REST, in particolare, indica un insieme di principi costruttivi per le architetture di rete, i quali delineano come le risorse sono definite ed indirizzate. 8 Simple Object Access Protocol (Soap) è un protocollo prevalentemente d abilitazione dei servizi web progettato secondo il paradigma della programmazione orientata agli oggetti e come obiettivo finale ha quello di realizzare lo scambio di messaggi tra componenti software. 9 Extensible Markup Language (XML) consente di definire in modo semplice nuovi linguaggi di markup (un classico esempio di linguaggio markup è il SGML Standard Generalized Markup Language che consiste, appunto, in uno standard per la descrizione logica dei documenti) da usare in ambito web. Studio ed analisi del Cloud Computing Stumpo Elvio

30 Microsoft, inoltre, offre anche applicazioni di tipo cloud già pronte per i clienti, come Windows Live, Microsoft Dynamics e molti servizi on-line di tipo business come Exchange Online e Office SharePoint Online. L Azure Services Platform lascia ai suoi sviluppatori la più completa libertà nella creazione delle applicazioni, limitandosi ad offrire solamente i componenti fondamentali, come potenza di calcolo, di memorizzazione e l assistenza tecnica con personale competente nelle applicazioni a nube. 3.2-Rapida analisi della piattaforma di servizi Azure Il mondo cloud fornisce ai propri utilizzatori soluzioni software differenti. Esiste, infatti, la possibilità di affidarsi completamente alla nube reperendo nella stessa sia i dati da elaborare che gli applicativi in grado di manipolarli. In alternativa, si può impiegare la soluzione denominata on-premises 10. Per far fronte a tale pluralità di servizi Azure supporta un gran numero di tecnologie di nube, ognuna delle quali adatta ad uno specifico set di servizi destinati agli sviluppatori degli applicativi. Microsoft garantisce che Azure è completamente compatibile con le Fig.3-1. Schema riassuntivo delle funzionalità di Azure versioni di Windows più diffuse (Server, Vista, XP, Mobile) ed alcuni suoi componenti possono essere impiegati anche in altri sistemi operativi. Azure Services Platform è caratterizzato da una pluralità di applicativi e di servizi realizzati per eseguire specifici processi. Prevalentemente Azure è costituita dai seguenti componenti: Windows Azure: Fornisce un ambiente di sviluppo basato su Windows per l esecuzione delle applicazioni e la memorizzazione dei dati sui server di Microsoft datacenter. Microsoft.NET Services: Offre infrastrutture distribuite sia per i servizi di tipo cloudbased e sia per le applicazioni locali. Microsoft SQL Services: Fornisce servizi di memorizzazione dati nella nube basati su SQL Server. 10 On-premises, in ambito Microsoft, sta ad indicare un gruppo di programmi che hanno una natura duale e più precisamente impiegano la nube per salvare i propri dati e si affidano a terze parti, diverse dalla nube, per reperire gli applicativi. Le terze parti migliori si trovano di solito sul proprio elaboratore (o in ambito aziendale su lan di PC o su server proprietari), ed è quindi pratica diffusa quella di reperire gli eseguibili in locale. Va, inoltre, precisato che in ambito on-premises si possono impiegare diversi protocolli; uno per la connessione alla nube ed un altro per le comunicazioni con le terze parti. Studio ed analisi del Cloud Computing Stumpo Elvio

31 Live Services: Attraverso il Live Framework, fornisce l'accesso ai dati e a varie applicazioni, tra cui quelle di Microsoft. Il Live Framework, permette anche la sincronizzazione dei dati tra computer desktop e dispositivi, la ricerca e il download di applicazioni e molto altro ancora. Anche se non presenti nello schema di Azure, bisogna citare anche due applicazioni di tipo aziendale che in ambito business sono molto utilizzate e che impiegano attivamente l architettura cloud: Microsoft SharePoint Online 11 e Microsoft Dynamics CRM Online Services 12. Questi due prodotti sono stati progettati in origine per fornire supporto alle aziende. La possibilità che tali soluzioni software possano interfacciarsi con la piattaforma Azure le renderà ancora più performanti. Questo incremento dell efficienza è dovuta alla indipendenza hardware ed all elasticità proprie di Azure, unite con i servizi forniti da Dynamics CRM per la gestione dei rapporti cliente-azienda e da SharePoint per la coordinazione e la condivisione dei flussi di lavoro tra i vari dipendenti della medesima impresa. 11 Microsoft SharePoint Online è un software che permette la gestione centralizzata delle risorse e del flusso di lavoro. Esso, infatti, offre la possibilità di fornire ai propri utilizzatori un metodo sicuro ed efficiente per creare collaborazioni fra dipendenti, trovare le risorse organizzative, gestire i contenuti ed il flusso di lavoro e ricavare i dati necessari per prendere decisioni basate su informazioni aggiornate. I dipendenti possono creare e gestire siti intranet personalizzati appositamente per un team o un progetto, allo scopo di favorire la collaborazione e la condivisione dei documenti. 12 Microsoft Dynamics CRM Online Services è un software dedicato alle aziende che ha come caratteristica principale la drastica riduzione dei tempi di messa in esercizio (instant-on deployment over the Internet) e l'assenza di una struttura HW dedicata. Il CRM si occupa prevalentemente delle relazioni fra l azienda che lo impiega ed i suoi clienti. Esso è caratterizzato principalmente da tre moduli: acquisizione (marketing), vendita (sales), postvendita (customer service). Studio ed analisi del Cloud Computing Stumpo Elvio

32 3.3-Windows Azure Ogni applicazione per poter funzionare correttamente ha bisogno di una piattaforma operativa (o base) per poter essere eseguita. Per gli applicativi on-premises tale base, di solito, risulta essere il sistema operativo presente in locale. Le applicazione cloud, vale a dire applicativi eseguiti su macchine appartenenti ad un centro di calcolo accessibile via Internet, necessitano, analogamente a quelle di tipo on-premises, di una piattaforma operativa adatta alle loro caratteristiche. L obiettivo di Microsoft Windows Azure è quello di provvedere a questa base. Come mostrato in figura 3-2, Azure viene eseguita presso i Data Center di Fig.3-2. Possibili applicazioni dell architettura cloud di Microsoft Microsoft. Piuttosto che offrire ai propri clienti (utenti Windows) software su supporti fisici (CD, DVD, BLU Ray Disk, etc.) che richiedano manutenzione da parte dell utente, Microsoft, con Azure, fornisce loro un servizio. Tale servizio è utilizzato dai clienti per gestire le applicazioni e per la memorizzazione dei dati sulle macchine dei data centers Cenni preliminari Fondamentalmente Azure è formato da tre servizi fondamentali: Compute, Storage e Fabric. I primi due servizi ricoprono mansioni facilmente desumibili, mentre il terzo servizio, leggermente più criptico nella definizione, necessita di maggiori specificazioni. L elemento di Azure che Microsoft indica con il termine di Fabric è, in realtà, il luogo dove viene concentrato un grande quantitativo di risorse d ogni genere. Lo scopo principale delle fabric è quello di fornire a Windows Azure tutte le risorse di cui ha bisogno. Per Fig.3-3. Elementi fondamentali che caratterizzano Windows Azure (Compute, Storage, Fabric) Studio ed analisi del Cloud Computing Stumpo Elvio

33 l anteprima CTP 13 di Azure, presentata nell autunno 08, Microsoft stabilì che la piattaforma di servizi sarebbe stata disponibile solamente per le applicazioni basate su ambiente di sviluppo.net Framework. Nello stesso momento la compagnia di Redmond ha garantito, nel 2009, il suo impegno a fornire l accesso ai servizi di Azure anche ad applicazioni basate su altre tipologie d ambiente di sviluppo. Azure, nella versione CTP, permette la creazione di software basati su codice di tipo.net come applicazioni di tipo ASP.NET 14 e servizi di tipo WCF 15. Per la realizzazione di tali codici, gli sviluppatori possono impiegare C#, ma anche tutti gli altri linguaggi di tipo.net disponendo dei classici strumenti del Visual Studio Già nella prima versione, mentre gli sviluppatori la impiegavano per creare applicativi weboriented, Azure era già in grado di eseguire in background ed in maniera del tutto indipendente diversi processi. Inoltre, sia le applicazioni cloud che gli applicativi on-premises possono accedere ai servizi di memorizzazione offerti da Azure, questo perché entrambe le tipologie di applicativi usano un approccio di tipo REST per operare con la nube. La memorizzazione delle informazioni da parte di Azure non impiega Microsoft SQL Server per gestire i propri dati, questo perché il magazzino dati Azure non è un sistema relazionale ed il suo linguaggio di interrogazione non è SQL. Questa scelta di progettazione è imputabile al fatto che deve offrire servizi di memorizzazione il più possibile semplici e scalabili. Per perseguire gli obiettivi di semplicità e scalabilità in Azure di Windows, ogni applicazione ha un file di configurazione che può essere modificato sia manualmente che da programma. Avendo previsto anche la possibilità della modifica manuale, l utente è in grado di accedere alle informazioni contenute in questo file, controllare i vari aspetti del comportamento del suo codice o, in alternativa, di impostare il numero di istanze che Azure dovrà gestire. Tutti questi aspetti delle applicazioni sono gestite dalle Azure fabric. Esse, infatti, esaminano le applicazioni per garantirne il loro corretto funzionamento. 13 CTP: Community Technology Preview distribuzione del programma (non definitiva, ancora in fase di lavorazione) destinata solamente ad utenti altamente specializzati ed esperti. 14 ASP.NET: ASP.NET è un insieme di tecnologie di sviluppo di software per il web, commercializzate da Microsoft. Utilizzando queste tecnologie gli sviluppatori possono realizzare applicazioni web e servizi web (Web Service). 15 WCF: Windows Communication Foundation, conosciuto in fase di sviluppo con il nome in codice Indigo, è un "sottosistema applicativo" della Microsoft che offre la struttura API per la creazione di applicazioni distribuite in ambienti Windows. Se da un lato ogni protocollo di rete (e.g. HTTP, FTP, SMTP, ecc.) ha un suo modello di programmazione e necessita, quindi, di una conoscenza specifica da parte degli sviluppatori per poter essere utilizzata, WCF è stato realizzato con l'intento di ricondurre ad un unico modello diverse tecnologie, rendendo più semplice ed uniforme la programmazione in ambiente Windows. È stato sviluppato per Windows Vista, ma è disponibile anche per i sistemi Windows XP SP2 e Windows Server Studio ed analisi del Cloud Computing Stumpo Elvio

34 Azure ha implementato la procedura d accesso mediante browser, rendendo i propri clienti liberi di creare, configurare, ed esaminare le proprie applicazioni su praticamente ogni tipo di macchina. Il potenziale cliente deve solo fornire un Live ID che lo identifica e poi scegliere se creare un conto di hosting per la gestione delle applicazioni, un account di memorizzazione per conservare i dati o entrambi. L'Azure di Windows è una piattaforma generale che può essere usata in vari scenari: Un possibile start-up potrebbe essere l impiego di Windows Azure per la creazione di nuove applicazioni web. La piattaforma supporta tutti i possibili servizi Web richiesti come la gestione di processi in background, la disponibilità di interfaccia utente interattiva, nonché l'esecuzione di lavori anche lato utente in modo asincrono. Lo start-up di Azure risulta essere, ancora una volta, indipendente dai vincoli di hardware in modo da permettere ai propri utilizzatori di concentrarsi esclusivamente sulla creazione del codice da fornire, eventualmente, ai propri utenti ed agli investitori. La natura elastica di Azure è in grado di seguire anche la crescita di un azienda che fornisce i propri prodotti nell ambito dell IT. Un ISV 16, ad esempio, che ha intenzione di progettare un software che offra un servizio aggiuntivo (SaaS 17 ) ad applicazioni.net già esistenti e di tipo on-premises, può anche scegliere di idearlo impiegando Windows Azure. Sfruttando la piattaforma dei servizi cloud di Windows per lo sviluppo di applicazione.net si evitano numerosi problemi di compatibilità. In Azure, infatti, questo genere di applicazioni sono già presenti ed eseguite e, inoltre nella stessa rete sono reperibili tutti gli strumenti necessari per la progettazione, anche per quelle di tipo avanzato come, ad esempio, i processi business. Questo tipo di ambiente di sviluppo elimina ulteriormente la forte dipendenza dalle infrastrutture di tipo aziendale, consentendo di convogliare tutte le risorse della ISV nella fase di progettazione logica. Sempre più imprese scelgono Windows Azure per la creazione di applicazioni destinate ai propri dipendenti. Eseguendo le applicazioni presso i data center della 16 Independent software vendor (ISV): Fornitore di software indipendenti. Imprese specializzate nella progettazione e/o vendita di software, creato per la commercializzazione di massa o per mercati di nicchia. Questi mercati possono essere diversi, compresi quello del software di gestione, di attività immobiliari, di pianificazione del personale sanitario, di scansione codici a barre, scorte di manutenzione e cura dei bambini. La maggior parte delle grandi società di software, tra cui Microsoft, Google e IBM, hanno programmi speciali per gli ISV. In generale, maggiore è numero di applicazioni che girano su una determinata piattaforma, più valore si offre ai clienti. 17 Software as a service (SaaS) è un modello di distribuzione di un codice applicativo in cui un produttore di software sviluppa, opera (direttamente o tramite terze parti) e gestisce un'applicazione web che mette a disposizione dei propri clienti via internet. I clienti non pagano per il possesso del software, bensì per l'utilizzo dello stesso. Essi utilizzano il software tramite API accessibili via web, spesso implementate con Web Services o REST. SaaS è diventato il termine di riferimento, rimpiazzando i precedenti termini Application Service Provider (ASP) e On-Demand. Studio ed analisi del Cloud Computing Stumpo Elvio

35 Microsoft si libera l'impresa dalla responsabilità e dalle spese di gestione dei propri server, ottenendo una riduzione dei costi aziendali. Microsoft, soprattutto, è in grado di fornire in qualsiasi momento risorse per gestire picchi di carico. Questo significa un ulteriore risparmio per l azienda che non avrà più l onere dei costi dovuti all acquisizione di una o più reti di sicurezza. Per meglio comprendere che cosa si indichi per picchi di carico, si pensi, ad esempio, ad un negozio di vendita di fiori online. In prossimità di alcune ricorrenze tipo San Valentino, festa della mamma, festa della donna, etc. tali attività economiche possono essere subissate di richieste, tanto da non essere in grado di gestire la mole d informazioni con le loro risorse standard, ma necessitano di un qualche genere di strutture ausiliarie. Un ulteriore esempio può essere fornito dalle procedure bancarie. La diffusione di carte di credito e tutte le varie forme di pagamento impiegate, sia dentro che fuori Internet, forniscono a vari enti che le emanano, una considerevole mole di dati solamente per il trasferimento di valuta. Periodicamente, inoltre, per ogni possessore di carte, l ente deve fornire la lista di tutti i movimenti effettuati nell ultimo periodo. Questo tipo di procedure, di notevole impatto sulle risorse, devono essere eseguite parallelamente alla normale gestione dei conti. Solo in questo caso e per pochi giorni, e non in maniera sistematica, l ente necessita della cosiddetta rete di sicurezza. Ogni tipo di azienda e/o attività che necessita di risorse informatiche, dal negozio dei fiori fino ad arrivare alla più grande banca on-line, può impiegare Windows Azure per recuperare le risorse necessarie per gestire i propri picchi di carico Definizioni generali Fig.3-4. Schema analogo al precedente. Nel caso specifico il Compute è stato suddiviso nei suoi elementi di base, web role e worker role fase di testing del codice da parte degli sviluppatori di applicazioni cloud. Prima di conoscere in dettaglio gli elementi che formano Azure, bisogna precisare che Microsoft segue la politica di mercato delle architetture a nube (pay-as-you-go) e non fornisce i propri servizi gratuitamente neanche durante la Per gli sviluppatori progettare un applicazione per Azure, nella sua versione CTP, risulta essere molto simile alla programmazione tradizionale di un applicativo di tipo.net. Microsoft, nel suo Visual Studio 2008, offre diversi prototipi di progetto (templates) adatti alla creazione di singole istanze e di loro eventuali combinazioni. Gli sviluppatori, infatti, sono liberi di impiegare qualsiasi linguaggio di tipo.net (anche se, come è facile desumere, Studio ed analisi del Cloud Computing Stumpo Elvio

36 Microsoft in questo progetto ha scelto come linguaggio principale il C#). Per ridurre al minimo le spese d impiego, è stato progettato e poi reso disponibile a chiunque ne faccia richiesta, il kit di sviluppo software per Windows Azure che include una versione dell ambiente di sviluppo cloud che funziona in locale sulla macchina del progettista. Questa soluzione operativa, nota come Azure-in-a-box, è formata dai simulatori di Compute service, Storage service, Development Fabric, e da tutti i possibili componenti cloud necessari per poter eseguire un applicativo cloud in remoto. Uno sviluppatore, sfruttando tale soluzione, può creare e testare il suo applicativo verificandolo nel simulatore locale (presente in Azure-in-a-box) a costo zero e, quando lo sviluppatore lo ritenga opportuno, si procede alla sua implementazione all interno della nube. Azure offre anche altri servizi per gli sviluppatori. Ad esempio, un applicazione di Azure può spedire una stringa d allarme (alert string) dentro la nube, ed il cloud di Windows propagherà l allarme via , via messaggio istantaneo, o utilizzando altri metodi di comunicazione per consentire alla stringa di giungere al suo specifico destinatario. Se richiesto, la fabric, analizzando le istanze di una data applicazione, può spedire un allarme quando si verifica un fallimento applicativo. Lo sviluppo della Fabric può essere eseguito su una singola macchina, ma tale dispositivo deve essere obbligatoriamente equipaggiato con sistemi operativi Windows Server 2008 o Windows Vista. L emulazione delle funzionalità cloud di Windows Azure è completa. Sono disponibili, infatti, le web role istance, worker role istance, e tutte e tre le possibili opzioni d archiviazione di Windows Azure. Mediante questi strumenti, uno sviluppatore può creare un applicazione per Windows Azure, implementarne lo sviluppo della fabric e del suo corrispondente controller ed eseguire ogni singola operazione con modalità pressoché identiche alla rete cloud di Microsoft, anche se praticamente tutto si svolge solo all interno della macchina del programmatore. Lo sviluppatore, inoltre, è anche in grado di determinare il tipo ed il numero di istanze totali da eseguire, scegliere di convogliare le comunicazioni tra le varie istanze nelle code, e compiere tutte le possibili operazioni eseguibili in Windows Azure (in realtà, è del tutto possibile creare da zero un intera applicazione cloud per Windows, senza mai impiegare attivamente la nube di Azure). Nella trasposizione dell applicazione da locale al cloud, lo sviluppatore carica il codice e il suo corrispondente file di configurazione tramite il portale di Windows Azure e, automaticamente, il software viene eseguito. Azure, infine, offre anche informazioni particolareggiate sul consumo delle risorse impiegate dalle istanze, incluso il tempo di utilizzo del processore, la larghezza di banda entrante e uscente e l immagazzinamento dei dati. Chiariti questi concetti fondamentali, si procede analizzando un po più nello specifico i servizi offerti da Azure. Studio ed analisi del Cloud Computing Stumpo Elvio

37 3.3.3-Compute services (esecuzione delle applicazioni) Il compute services di Azure può gestire molti generi diversi di software. L obiettivo primario di questo servizio è supportare applicazioni che hanno un numero molto grande di utenti simultanei (infatti, Microsoft ha dichiarato che costruirà le proprie domande SaaS su Azure). Azure è progettato per supportare la scalabilità delle applicazioni, gestendo copie multiple dello stesso codice (istanza) Fig.3-5. Classificazione di Compute con un maggior grado di dettaglio. Tramite questa figura si possono notare anche gli schemi di connessione tra i vari elementi appartenenti al medesimo servizio attraverso l impiego di diversi server dedicati. Ogni istanza può eseguire una copia completa o solamente una singola parte di codice dell applicazione. Un applicazione Azure può, quindi, avere istanze multiple, ognuna delle quali viene eseguita su una macchina virtuale (VM) ad essa assegnata. Queste VM sono in grado di eseguire applicativi di Windows Server 2008 con architettura 64bit e sono forniti di un supervisore specificamente progettato per essere impiegato nella nube. Un applicazione di Windows Azure non è in grado di conoscere su quale VM è in esecuzione. Questo permette agli sviluppatori di non fornire, obbligatoriamente, dati riguardanti l immagine della propria VM per l'esecuzione dell applicazione e, di conseguenza, tale condizione permette ad Azure di non preoccuparsi di mantenere copia del VM degli utenti. Nella prima versione CTP di Azure era consentito ad ogni singolo sviluppatore la creazione di applicazioni basate su.net 3.5,ed esclusivamente di due tipi: web role instances 18 e worker role instances Web role istances è simile ad una applicazione web, ed è munita di pagine aspx e del loro corrispettivo codice, ma possiede caratteristiche server che le permettono di accettare qualsiasi operazione che sfrutti il protocollo di http. Il web role è completamente gestito tramite UI (user interacts) che, con una pagina web o con un servizio, è in grado di programmare il lavoro da eseguire. Una caratteristica fondamentale è che il web role è in grado di stabilire uno scambio di informazioni bidirezionali con il worker role. 19 Worker role instance è simile ad un servizio di windows. Si inizializza e si esegue nello stesso tempo. Invece di un timer, usa un semplice ciclo iterativo while (impostato a vero) ed una istruzione di sleep. Quando l istanza viene lanciata, essa compie, di solito, lavoro di manutenzione. È ideale per l elaborazione in background. Come ogni applicazione, anche il worker ha bisogno di dati per eseguire le sue mansioni. Tali informazioni o dati possono provenire da diverse sorgenti. Un classico esempio, presente nell AzureServicesKit, è lo scambio di dati tra worker e web tramite opportune code. L idea di fondo di questa applicazione è che non importa da dove provengono i dati, una volta ottenuta una coda valida, l applicazione inizia a lavorare. I suoi risultati possono essere letti impiegando una web role, ma comunque non è sempre corretto pensare che per ogni worker role si debba associare una web role. Studio ed analisi del Cloud Computing Stumpo Elvio

38 Le istanze di tipo web, come è facile desumere, sono applicazioni orientate prevalentemente alla trasmissione dei dati e raggiungibili direttamente dall utente, mentre le worker sono istanze di tipo operativo (lanciano, eseguono e gestiscono i job necessari al corretto funzionamento dell applicazione cloud) e non sono raggiungili direttamente dall utente. Le web role instances accettano le request (richieste d informazioni) di tipo HTTP (o HTTPS) attraverso Internet Information Services 7.0 (IIS) 20. Un web role instances è implementato usando ASP.NET, WCF, o un'altra tecnologia del.net Framework in grado di operare con IIS. Azure è in grado di fornire il bilanciamento del carico propagando le request, che fanno parte della stessa applicazione, attraverso le medesime web role instances. Questa particolarità è derivata dal fatto che un istanza di web role non si lega ad una singola richiesta d informazioni. Una worker role instance, al contrario, non può accettare direttamente request dal mondo esterno, quindi, non è impostata per aver alcun tipo di collegamento di reti entranti, e l IIS non viene lanciata sulla corrispondente VM. Worker role instance fornisce, invece, il suo contributo tipicamente nelle code del magazzino di Windows Azure. Diversamente dagli input, i risultati del suo lavoro possono essere inseriti nel sistema di memorizzazione Azure o essere direttamente spediti verso il mondo esterno, poiché sono abilitati i collegamenti di rete uscenti. Diversamente da web role instances, che è creato per occuparsi delle request entranti mediante protocollo HTTP e di terminare quando l applicazione richiedente è stata eseguita, worker role instance può funzionare indefinitamente perché è un lavoro di tipo batch. Indipendentemente se venga eseguita una worker role instance o un web role instance, ogni VM contiene anche un Agente che permette alle applicazioni di interagire con le Fabric. L'agente definisce le API con cui l applicazione deve comunicare con Windows Azure, memorizza i file log e invia allarmi al proprietario dell applicativo attraverso la fabric. Nella distribuzione iniziale di Azure viene mantenuta una relazione di tipo uno-a-uno tra la VM ed il core fisico del processo. Per questo, l'esecuzione di ogni applicazione può essere garantita: infatti, ogni web role instance e worker role instance ha il proprio core dedicato. Per aumentare le prestazioni di un applicazione, il proprietario può aumentare il numero di istanze da eseguire specificandolo nel file di configurazione dell applicazione stessa. La fabbric corrispondente a 20 Microsoft Internet Information Services spesso abbreviato in IIS, è un complesso di servizi server Internet per sistemi operativi Microsoft Windows. La versione corrente, integrata in Windows Server 2008, è la 7.0 ed include i servizi server per i protocolli FTP, SMTP, NNTP e HTTP/HTTPS. L integrazione dei servizi è dovuta al fatto che l applicazione server non è in grado, di per sé, di eseguire elaborazioni server-side, ma ne delega l'esecuzione ad applicazioni ISAPI (Internet Server Application Programming Interface, le interfacce per sviluppatori di applicazioni lato server). Studio ed analisi del Cloud Computing Stumpo Elvio

39 tale applicativo le assegnerà nuove VM ed i loro corrispondenti core, ed immediatamente cominceranno ad essere eseguire nuove istanze dell applicazione. La fabric, inoltre, determina se la web role istance o la worker role istance è andata a buon fine; in caso contrario ne lancia una nuova. A volte, potrebbe essere necessario conoscere la precisa collocazione geografica dei datacenter di Microsoft ed essere in grado di scegliere un particolare cluster di server in cui far eseguire la propria applicazione e/o memorizzare i dati. Questa richiesta, di maggior potere decisionale, può derivare da innumerevoli necessità, tra le quali il desiderio dello sviluppatore di aver pieno controllo delle proprie applicazioni. Diversamente da tale casistica, vi sono situazioni in cui un maggiore controllo è strettamente necessario. Immaginiamo che alcuni dati e/o applicazioni, per motivi d ordine giuridico, devono rimanere all'interno dell'unione Europea, ma la maggior parte degli utilizzatori di tali servizi risiedono in Nord America. In questa situazione è strettamente necessario poter specificare i data center in cui le applicazioni gestiscono e memorizzano i dati. Per permettere questa operazione, Windows Azure consente allo sviluppatore, qualora lo ritenga necessario, di indicare i datacenter destinati alla gestione ed al mantenimento delle proprie applicazioni e dei propri dati. Si può anche specificare che un particolare gruppo di applicazioni e / o di dati siano eseguiti tutti nello stesso datacenter. Attualmente, Microsoft sta destinando a Windows Azure solamente datacenter presenti nel territorio degli Stati Uniti, ma tale lacuna verrà, in un prossimo futuro, colmata con l inserimento nel progetto Azure di datacenter europei adatti a tale scopo. Ovunque essa sia eseguita, un applicazione di Windows Azure è installata e messa a disposizione dei suoi utenti tramite un processo in due fasi. Uno sviluppatore, innanzitutto, effettua l upload dell applicazione in una piattaforma di gestione temporanea. L applicazione è rappresentata da un endpoint 21 di tipo HTTP / HTTPS e il suo DNS è definito mediante particolari procedure da Windows Azure. Tale DNS è associato ad un indirizzo IP virtuale (VIP) che identifica il particolare percorso da seguire in Windows Azure per potere raggiungere l applicazione ed essere letta (passo 1). Quando lo sviluppatore è pronto a rendere la sua applicazione disponibile nella rete (renderla Live), effettua una particolare richiesta detta di produzione al portale di Windows Azure. Quest ultimo, automaticamente, cambia il DNS del server destinato ad eseguire il codice con quello scelto dallo sviluppatore per associarvi il VIP dell'applicazione (passo 2). Vale la pena puntualizzare alcuni concetti relativi a questo processo. Dato che lo swap dei VIP è un operazione atomica, l upgrade di un applicazione in esecuzione viene effettuata 21 Nelle architetture di tipo service-oriented l endpoint è il punto di accesso ad un servizio, ad un processo, ad un modulo o ad una coda. Studio ed analisi del Cloud Computing Stumpo Elvio

40 senza downtime 22. Ciò è molto importante per molte tipologie di servizi cloud. Inoltre, durante tutto il processo, gli indirizzi IP reali non sono mai resi noti. Questo significa che gli indirizzi IP delle VM e gli IP fisici delle macchine ad esse strettamente legate non sono mai esposti. Una volta che l'applicazione è accessibile dal mondo esterno, i suoi potenziali utenti hanno bisogno di metodo per identificarsi. Per effettuare l identificazione, Windows Azure consente agli sviluppatori di utilizzare l'autenticazione che desiderino, l importante è che sia basata su protocollo HTTP. Analogamente agli applicativi ASP.NET, un software potrebbe utilizzare un membership provider nel quale sono memorizzati tutti gli ID e le password degli utenti abilitati o, in alternativa, si potrebbe usare un altro metodo, come ad esempio Microsoft LiveID. La scelta spetta solo al creatore dell'applicazione. Infine, anche gli accessi alle strutture di memorizzazione dati di Azure sono molto particolari. Entrambe le role istance usano servizi web basati su ADO.NET 23, una tecnologia relativamente nuova, più sensibile alle problematiche attuali di sicurezza ed affidabilità, ma che non è ancora disponibile per gli applicativi di tipo on-premise Storage services (accesso alla memoria) Per essere impiegato Windows Azure Storage necessita di un account di storage. Per controllare l accesso a tale account, Windows Azure fornisce al suo titolare una chiave segreta a 256-bit. Ogni tipo di richiesta di storage blobs, tables queues, è riconducibile al corrispondente account tramite la firma con chiave segreta contenuta al suo interno. Questo significa che l'autorizzazione è a livello di account. Le diverse applicazioni disponibili funzionano con dati molti diversi Fig.3-6. Elementi fondamentali che caratterizzano il servizio Storage di Azure (blobs, tables, queues) tra loro e con richieste di memorizzazione di varia natura, spaziando da semplici strutture 22 Downtime (tempo di fermo): Periodo di momentanea indisponibilità, dovuto a guasti o manutenzione, di un apparecchio informatico e/o dei servizi da esso erogati. 23 ADO.NET è un insieme di componenti software che può essere utilizzato dai programmatori per accedere ai dati e ai servizi. Si tratta di una parte della libreria di classi di base incluse in Microsoft. NET Framework. È comunemente utilizzato dai programmatori per accedere e modificare dati memorizzati in sistemi di database di tipo relazionale, ma può anche essere utilizzato per accedere ai sorgenti dei dati non-relazionali. ADO.NET è talvolta considerata una evoluzione di ActiveX Data Objects (ADO), ma con tale tecnologia ha in comune solo il nome visto che è stato ampiamente modificato tanto da essere considerato un prodotto integralmente nuovo. Studio ed analisi del Cloud Computing Stumpo Elvio

41 come gli oggetti binari (blobs) fino ad arrivare a quelle più complesse per la conservazione delle informazioni. Superata la problematica della differenziazione del tipo di memorizzazione delle informazioni, è stata affrontata quella di individuare un metodo affidabile di condivisione dei dati tra parti diverse di una medesima applicazione. Windows Azure dispone di tre diverse possibili soluzioni per la memorizzazione efficiente e funzionale dei dati Blobs I Binary Large ObjectS, o più semplicemente blobs, sono le strutture più semplici abilitate a conservare dati in Windows Azure. Ogni richiesta d accesso a tali strutture (lettura e scrittura) è caratterizzata dalla firma mediante chiave segreta. Sono organizzate in modo gerarchico, infatti, ogni account d immagazzinamento dati può avere uno o più contenitori (containers) che possono essere contrassegnati come privati o pubblici. Per i contenitori privati il sistema della apposizione della firma vale per entrambe le operazioni (lettura e scrittura), mentre per quelli pubblici la firma deve essere apposta solo in caso di scrittura, così da permettere a tutti gli utenti di potervi accedervi solamente per esaminare i vari file in essi contenuti. Il container è una struttura di tipo non atomico, infatti, ognuno di essi può contenere uno o più blob. I blob, inoltre, hanno una capacità di circa 50 gigabyte ciascuno e, per trasferire queste quantità di dati in maniera efficiente, si applica la frammentazione della struttura di memoria in sottosezioni chiamate blocchi. Il blocco è l elemento atomico di questo tipo di struttura ed in caso di errore di trasmissione la procedura di ripristino consiste nella ritrasmissione del blocco danneggiato seguito dalla normale trasmissione dei blocchi rimanenti. Con questo metodo trasmissivo si evitano, in caso d errore, le ritrasmissioni dei blocchi integri. I blob sono strutture dati a cui si può associare qualsiasi tipo di metadato, come, ad esempio, inserire le informazioni riguardanti la località dove è stata scattata una fotografia JPEG o altrimenti inserire l artista per un determinato file MP3. Fig.3-7. Schematizzazione delle caratteristiche di memorizzazione gerarchiche tipiche di un blob. Tutti gli accessi ai blob di Windows Azure devono essere effettuati tramite gli standard HTTP REST PUT/GET/DELETE. I comandi HTTP/REST supportati dai blob includono: Studio ed analisi del Cloud Computing Stumpo Elvio

42 dove: PUT Blob Inserimento di un nuovo blob GET Blob Inserimento dati nel blob DELETE Blob Cancellazione di un blob. Tutti gli elementi, infatti, sono identificabili tramite un URI 24. Gli utenti.net possono anche utilizzare ADO.NET Data Services 25 e LINQ 26, ma per l'accesso alla memorizzazione di Azure da parte di applicazioni non-.net, ad esempio di tipo Java, devono essere impiegati obbligatoriamente gli standard REST. Un blob può essere letto con una procedura di tipo HTTP GET con i campi degli URI organizzati in questo modo: <StorageAccount> è un identificatore assegnato nel momento in cui un nuovo account di storage è creato, ed identifica unicamente blob, tabelle, e code generate mediante questo account. <Container> identifica univocamente un determinato contenitore a cui è stato associato un nominativo d identificazione. <BlobName> identifica il nominativo del blob a cui la request di GET vuole accedere. In base alla gerarchia proposta nella figura 3-7, per ottenere, ad esempio, l IMG001.JPG la formulazione corretta della richiesta di HTTP GET risulterà essere: pictures /IMG001.JPG 24 Un Uniform Resource Identifier (URI, acronimo più generico rispetto ad "URL") è una stringa che identifica univocamente una risorsa generica che può essere un indirizzo web, un documento, un'immagine, un file, un servizio, un indirizzo di posta elettronica, un path, etc. 25 L ADO.NET Data Services framework consiste in una combinazione di configurazioni e di librerie che abilitano la creazione ed il consumo di servizi di dati di tipo web. Le risorse disponibili vengono organizzate in collezioni di risorse, che seguendo lo stile REST, vengono indicizzate mediante URIs e gli agenti preposti possono interagire con loro usando i soliti comandi di tipo Http come GET, POST o DELETE. 26 Language Integrated Query (LINQ): LINQ è un insieme di funzionalità tipiche del Visual Studio 2008 che estende le potenzialità d esecuzione delle query tramite la sintassi dei linguaggi C# and Visual Basic. In LINQ sono presenti modelli standard di facile utilizzo per l'esecuzione delle query e dell'aggiornamento dei dati, che consentono praticamente di gestire qualsiasi tipo di archivio dati (XML, array, e database relazionali). Studio ed analisi del Cloud Computing Stumpo Elvio

43 Tables I blob sono adatti solo a particolari generi di dati, per molti altri dati tali strutture sono inadeguate. In questo caso Azure offre una struttura di memorizzazione denominata tabelle (tables). Come mostra la figura 3-8, ogni tabella contiene un certo numero di oggetti. L'entità (entity) o soggetto contiene zero o più proprietà Fig.3-8. Rappresentazione dettagliata degli elementi costituenti una table (property) 27 ciascuna formata da tre campi: nome, tipo, e valore. Diverse tipologie di dati sono supportati, tra i quali sono compresi i Binary, Bool, DateTime, Double, GUID (identificatore univoco globale a 128-bit), Int, Int64, e String, ed una proprietà può assumere diverse forme, variabili nel tempo, a seconda del valore in esso memorizzato. Inoltre, non vi è alcun requisito che impone che tutte le strutture di un soggetto debbano aver gli stessi tipi; uno sviluppatore, infatti, è libero comportarsi come ritiene più opportuno per la sua applicazione. L operazione di lettura di un entità comporta l acquisizione di tutte le sue proprietà, mentre la scrittura è il processo operativo che permette atomicamente la modifica delle proprietà (Microsoft ha anche dichiarato che nella versione ufficiale sarà possibile anche effettuare una scrittura multi-entità su singole tabelle). Le tabelle di Windows Azure Storage sono completamente diverse dalle tabelle relazionali sotto vari aspetti. La maggior parte di loro non sono tabelle nel senso classico del termine. Esse, infatti, non possono essere raggiunte utilizzando un ADO.NET standard, né il supporto SQL. Dato che questo tipo di struttura dati non può essere correttamente interpretata da SQL, un applicazione che vuole accedere alle informazioni contenute nelle suddette tabelle, deve essere progettata seguendo le regole imposte dalla sintassi di LINQ. Una singola tabella è di notevoli dimensioni, poiché è in grado di contenere miliardi d entità, le quali, a loro volta, contengono terabyte di dati. Azure, se necessario, può migliorare il rendimento della struttura smistando i dati su più server. Le tabelle sono state create soprattutto per fornire supporti di memorizzazione adeguati ad Azure SQL Service. Quest ultimo (come tutti i servizi offerti dalla piattaforma di servizi Microsoft) ha come principale obiettivo quello di sostenere massicciamente le applicazioni scalabili. Un tradizionale database relazionale può assumere a tratti caratteristiche di scalabilità, infatti è possibile la sua manipolazione da parte di più utenti, ma il DBMS per 27 Anche se di natura diversa le tables di Azure possono trovare dei punti di contatto con le tabelle in uso in SQL. Infatti, le entità sono l analogo delle righe, mentre le proprietà sono l analogo alle colonne di una classica tabella relazionale. Studio ed analisi del Cloud Computing Stumpo Elvio

44 compiere tale operazione necessita di macchine sempre più potenti. I servizi Azure richiedono a tutti i suoi componenti, oltre a caratteristiche di scalabilità molto spinte, anche la capacità di gestire un gran numero di utenti simultanei, ed un adeguato sistema di stoccaggio dei dati. Per consentire questo, il meccanismo di memorizzazione deve essere semplificato: in queste condizioni le tabelle relazionali create con SQL standard diventano inutili e sono sostituite dalle tables dello Storage service. La nuova struttura dati libera gli sviluppatori dalla preoccupazione della scalabilità dovendo solo creare nuove tabelle, aggiungere nuove entità; il resto è completamente gestito da Windows Azure. Esso, inoltre, elimina la maggior parte del lavoro necessario al mantenimento di un DBMS. L'obiettivo finale è quello di lasciare che gli sviluppatori si concentrino unicamente sulle loro applicazioni, disinteressandosi completamente della meccanica della memorizzazione e gestione delle grandi quantità di dati. Come ogni elemento di Windows Azure Storage, le tabelle sono accessibili tramite protocollo REST. Qualsiasi applicazione,.net o di altra natura, è anche libera di effettuare direttamente richieste di tipo HTTP. L aggiornamento dei dati condivisi crea un annoso problema: come agire nel caso si presenti l eventualità che due o più applicazioni tentino di aggiornare la stessa entità contemporaneamente. Supponiamo che due applicazioni tentino nel medesimo istante di leggere, modificare, e scrivere sulla medesima entità. Se non si dispone di un metodo d individuazione di collisioni, la procedura di default (è quella più auspicabile) è che l'applicazione più veloce abbia un completo esito positivo. L'altra applicazione in fase di scrittura avrà esito negativo. In alternativa, l'applicazione è in grado di aggiornare incondizionatamente l'entità, garantendo che le sue modifiche saranno attuate (in questo caso si parla di trattamento concomitante degli aggiornamenti). Similmente, alla procedura di HTTP/REST GET impiegata per le interrogazioni dei blob, la consultazione di una tabella è espressa sempre mediante un GET di tipo HTTP con i campi degli URI organizzati, anche questa volta, secondo uno schema gerarchico seguendo tale criterio: dove: <StorageAccount> ha significato analogo al caso dei blobs <TableName > identifica univocamente, tramite un nominativo, una determinata tabella che deve essere consultata <Query> contiene la query che deve essere eseguita sulla tavola. Studio ed analisi del Cloud Computing Stumpo Elvio

45 Analogamente ai blocchi contenuti nei blob, nelle tabelle è previsto un metodo per poter suddividerle in vari sotto insiemi, chiamati partizioni, come si vede in figura 3-9. <PartitionKey> è una chiave principale posseduta da ogni tabella. Fig.3-9. Schema esemplificativo sulla modalità di memorizzazione delle informazioni nelle table. Il sistema impiega questa chiave per distribuire automaticamente le entità tabellari su più nodi di memorizzazione. <RowKey> è una chiave secondaria che caratterizza le entry. Tale chiave consiste in un ID univoco che permette l individuazione dell entry nella sua corrispondente partizione. La PartitionKey combinata con la RowKey consente di stabilire l esatta collocazione di un entry nell intera tabella. <Partition> è un cluster di entities di una tabella che hanno lo stesso valore di <PartitionKey>. <Entity (Row)> sono i contenitori in cui vengono memorizzati i dati di base della tabella. Una singola entry contiene un set di proprietà o (campi) fino ad un massimo di 255 campi. <Property (Column)> rappresenta un singolo valore di una entità. Diversi tipi di classi di valori sono supportati dalle proprietà. Le due chiavi (Partition, Row) sono di tipo stringa, quindi, possono essere tranquillamente inserite direttamente nelle varie partizioni e, dunque, nell intera tabella. Come i blobs, anche le tabelle hanno i propri limiti d utilizzo. Le tabelle di Windows Azure, infatti, non sono sempre la scelta ottimale per ogni tipo di situazione di memorizzazione, ed inoltre il loro utilizzo richiede agli sviluppatori di ampliare le proprie conoscenze per assimilare un nuovo metodo per interagire con le query e con le tabelle. Tuttavia, per tutte le applicazioni che necessitano di una spiccata scalabilità, le tabelle possono essere la scelta migliore Queues Sia i blob che le tabelle si concentrano sull effettiva conservazione dei dati. La terza scelta di Azure, le code (queues) hanno una finalità piuttosto diversa. Il ruolo primario delle code è quello di fornire un metodo per lo scambio di informazioni tra le istanze di tipo web role e le istanze di tipo worker. Ad esempio, un utente invia una richiesta per eseguire un task di calcolo intensivo via pagina web, implementando una web role istance. L istanza di web role ricevente può scrivere una comunicazione in una coda che descrive il task che deve essere eseguito. Tale coda è l input di un worker che è in grado di leggerla ed estrapolarne le specifiche del task. Il worker eseguirà l istanza del calcolo intensivo ed i risultati potranno essere inoltrati tramite un'altra coda o essere trattati in maniera diversa. Studio ed analisi del Cloud Computing Stumpo Elvio

46 Alle code (queues) possono accedere sia le applicazioni di Azure che le applicazioni no-cloud di Microsoft utilizzando ancora una volta una semplice procedura di tipo HTTP GET con i campi degli URI organizzati in questo modo: Fig Formalizzazione di una possibile sequenza operativa, in cui si può comprendere la funzione della queue. Qualsiasi forma d esecuzione parallela di più istanze riconducibili al medesimo utente (figura 3-10) è la classica situazione d impiego delle code in Azure (fase 1). La conversione di un filmato in diversi formati (avi, mpeg, wmv, mkv, rm etc ) appartiene a tali processi. Per propagare i vari task da eseguire verso le worker role corrispondenti, i web role scrivono un messaggio in una coda (fase 2). Questa comunicazione, che ha una dimensione massima di 8 kilobyte, contiene degli URI che possono puntare ad un blob, ad un entità contenuta in una tabella, o a qualsiasi altro elemento necessario all applicazione. Le worker role leggono i messaggi provenienti dalle code, vale a dire le informazioni si propagano fino alle worker (passo 3) e successivamente il lavoro commissionato inizialmente alle web role inizia ad essere eseguito (passo 4). La lettura del messaggio presente nella coda non è distruttiva, anche se tale comunicazione, una volta acquisita, viene resa invisibile alle altre worker role per un periodo limitato di tempo (di default è 30 secondi). Quando la worker role, incaricata di eseguire i vari task, termina con esito positivo, il messaggio richiedente deve essere eliminato dalla coda (passo 5). La separazione delle istanze web da quelle worker ha delle comprovate motivazioni: rendendo le due istanze indipendenti tra loro, permette all utente di non aspettare inattivamente la conclusione dei task, e facilita il processo di scalabilità aumentando il numero di istanze in esecuzione, senza nessuna conseguenza per quelle già attive. Il processo della propagazione delle comunicazioni operative potrebbe risultare inutilmente complesso. Ad esempio, si potrebbe immaginare di ottimizzare tale processo rendendo automatica l operazione di cancellazione del messaggio nella coda. Questa operazione, per quanto corretta in termini di ottimizzazione dei processi, non consentirebbe di manipolare i fallimenti. Si ha un fallimento del worker role quando l istanza acquisisce un task, ma non lo esegue completamente con successo. In questo caso, il mancato termine del task non abilita la cancellazione del suo corrispondente messaggio, e trascorso il tempo d invisibilità prefissato, la comunicazione ritorna ad essere visibile e pronta per essere eseguita Studio ed analisi del Cloud Computing Stumpo Elvio

47 nuovamente dal primo worker role disponibile. In questo modo si garantisce che ogni singolo messaggio venga elaborato almeno una volta. Diversamente, in caso di buon esito, la comunicazione viene cancellata prima dello scadere del timeout dell invisibilità. Le particolari caratteristiche delle code di Azure fanno sì che esse non utilizzino la stessa semantica tipica delle code modellate in Microsoft Message Queuing (MSMQ 28 ) o di altre tecnologie simili. Gli sviluppatori che intendano avvalersi delle code in ambito cloud dovranno tenere ben presenti tali caratteristiche. Indipendentemente dalla tipologia di struttura di memorizzazione impiegata (blob, tabelle, code) tutti i dati memorizzati in Azure vengono replicati almeno tre volte. Questo consente una buona tolleranza d errore di replica, in quanto la perdita di una copia non risulta fatale. Il sistema, inoltre, garantisce la coerenza. Lo storage di Windows Azure può essere letto da una qualsiasi applicazione di Windows Azure o da una generica applicazione che è eseguita al suo interno. In entrambi i casi, tutti e tre gli stili di storage di Azure utilizzano le convenzioni REST per identificare ed esporre i dati. Diversamente da quanto detto per gli applicativi cloud, una classica applicazione di tipo onpremises necessita solamente della componente di Azure che si occupa della memorizzazione dei dati. Lo scambio di dati tra le applicazioni e lo storage cloud è effettuato tramite procedura REST. La piattaforma di Windows pone la massima attenzione nella memorizzazione dei dati utilizzati dalle applicazioni eseguite al suo interno. La permanenza dei dati nel cloud, anche quando l applicazione che li ha generati è terminata, è motivata dal fatto che tali informazioni devono essere accessibili anche ad applicazioni Azure di tipo non- Windows. L obiettivo finale della piattaforma è quello di fornire un valido supporto di memorizzazione sia per le applicazioni on-premises e sia per quelle di tipo cloud. 28 Microsoft Message Queuing o MSMQ è una realizzazione di code di comunicazione sviluppata da Microsoft e utilizzata nei suoi sistemi operativi sin dal Windows 95 e Windows NT. MSMQ essenzialmente è un protocollo di messaggistica che permette di lanciare applicazioni su diversi sistemi per comunicare in maniera sicura. Una coda è un'ubicazione di memorizzazione provvisoria dalla quale possono essere spedite le comunicazioni in caso di condizioni ideali. Questo abilita comunicazioni attraverso reti eterogenee e tra computer che non possono essere sempre connessi. MSMQ è anche responsabile della distribuzione affidabile di comunicazioni tra applicazioni dentro e fuori l impresa. Queste genere di code, al contrario di quelle presenti in Azure, garantiscono che ogni singolo elemento contenuto in esse sia distribuito una volta sola. Studio ed analisi del Cloud Computing Stumpo Elvio

48 3.3.5-Fabric Tutte le applicazioni di Windows Azure e tutti i dati di Windows Azure Storage sono reperibili in alcuni dei data center di Microsoft. All interno di tale data center, un set di macchine dedicate a Windows Azure è organizzato con una serie di connessioni ad alta densità, tanto da far apparire la rete come una trama, da cui il nome fabric. Come mostra la figura 3-11, Windows Azure fabric è costituito da un gruppo molto vasto di macchine, tutte gestite da un software chiamato fabric controller. Esso viene replicato in ogni sottogruppo formato da cinque a sette macchine, e possiede tutte le risorse della fabric: computer, switch, bilanciamento carico, etc. ed è in grado di comunicare con gli altri fabric controllers presenti su ogni altro PC, ed inoltre, è informato su tutte le applicazioni di Windows Azure contenute nella fabric. Fig In questo esempio sono definite le varie funzioni ricoperte dalle fabric. Questa vasta conoscenza della fabric permette la creazione di molti controller di varia utilità. Si possono impiegare i controller per monitorare tutte le applicazioni in esecuzione, per gestire i sistemi operativi, vale a dire, controllo di versione di Windows Server 2008 eseguita nelle VM di Windows Azure. Si può anche decidere dove debbano essere eseguite le nuove applicazioni: la scelta riguarda l individuazione di particolari (o semplicemente preferiti 29 ) server fisici per ottimizzare l'utilizzo del hardware. Il potere gestionale di un fabric controller si estende anche sulle risorse di memorizzazione. Esso è anche responsabile dell assegnazione effettiva delle locazioni di memoria. Il controller, infatti, si preoccupa anche di individuare le macchine fisiche su cui memorizzare le applicazioni di cui è responsabile. L unica cosa che non gestisce autonomamente è la memorizzazione dei dati. Fabric controller, infatti, considera Windows Azure Storage come un'altra applicazione, e così 29 I server appartenenti ai data center di Windows sono praticamente simili fra loro, quindi la loro discriminazione sarebbe del tutto immotivata. Nella realtà, invece, ci sono due fattori che permettono di individuare il miglior server per una data applicazione: il carico di lavoro e la distanza dal server. Mediante il carico di lavoro si individua, a parità di merito, il server con il carico minore che garantisce una diminuzione dei tempi di latenza (d attesa). Il fattore distanza dal server è rilevante, ai fini operativi, soprattutto per le applicazioni che dialogano costantemente con il server. Se la distanza fisica è più breve, anche a parità di hardware, il server più vicino sarà più efficiente perché i dati impiegheranno meno tempo a giungere a destinazione e, quindi, si diminuiscono ulteriormente i tempi di latenza, anche se i tempi di computazione rimangono immutati. Studio ed analisi del Cloud Computing Stumpo Elvio

49 la gestione dei dati e le repliche non sono gestite da questo, ma direttamente dal servizio preposto a tali operazioni. Tutte le operazioni prima descritte sono possibili grazie ad un file di configurazione dal quale dipende il fabric controller e che viene caricato con ogni applicazione di Azure. Questo file contiene una descrizione, basata su XML, delle necessità applicative che un dato software richiede: quante istanze di tipo web role, quante istanze di tipo worker role, etc. Dopo aver stabilito il numero esatto di istanze di entrambe le tipologie, il fabric controller usa il file di configurazione per determinare le VM necessarie all applicazione. Create queste ultime, il fabric controller esamina ognuna di esse per verificarne il corretto funzionamento. Analizzando il comportamento del fabric controller quando vengono eseguite le applicazioni cloud destinate alla nube, si deduce che un generico sviluppatore, per la sua particolare applicazione, richiede, ad esempio, cinque istanze di tipo web role e quattro di tipo worker role. Una gestione alquanto azzardata collocherebbe tutte le nove istanze in macchine appartenenti alla stessa sottorete (rack) e gestite dallo stesso network switch. Se il rack o lo switch subissero un crash di Fig Esempio di suddivisione della rete in due sottoreti distinte sistema, l intera applicazione non sarebbe più disponibile. Una gestione fortemente dipendente dal malfunzionamento hardware non può essere ritenuta soddisfacente. Per evitare questa non rara possibilità, il fabric controller raggruppa le macchine che possiede in un numero di sottogruppi denominati fault domains (domini critici). Ogni dominio critico è una parte del datacenter dove un singolo fallimento è in grado di isolare tutto l intero dominio. Nell esempio riportato in figura 3-12, l applicazione in esame è formata solo da due istanze di tipo web role ed, inoltre, l intero datacenter è diviso solamente in due domini critici. Quando il controller implementa l applicazione nella rete cloud smista le due istanze web in domini critici diversi. Con questa configurazione, in caso di malfunzionamento hardware di un singolo fault domain, non si perde l intera applicazione, ma solo un'unica istanza. Oltre alla gestione dei crash hardware, se il file di configurazione è redatto in maniera corretta, si possono bypassare alcuni malfunzionamenti software. Si prenda a titolo Studio ed analisi del Cloud Computing Stumpo Elvio

50 d esempio un applicazione formata da cinque web role istances. In fase d esecuzione nel datacenter un istanza, improvvisamente, termina in maniera imprevista. In quel momento interviene il controller che, rilevato l errore, ne lancerà automaticamente una nuova. Similmente, se la VM termina in maniera anomala, il fabric controller avvierà nuovamente le istanza di web role e/o di worker role interrotte in una nuova VM eseguita su un elaboratore diverso dal precedente. Inoltre, ripristinerà il bilanciamento del carico che consentirà la sostituzione della macchina fallita con quella nuova. Data la relazione che sussiste fra VM e il suo corrispondente core fisico (uno-a-uno) si può desumere che ogni applicativo ha il suo microprocessore dedicato. Questo vuol dire anche che non c'è nessun limite temporale inerente all esecuzione di una determinata istanza. In altri termini, la mancanza di timeout permette, ad esempio, ad un web role di dedicarsi esclusivamente all istanza assegnata o, in alternativa, consente ad un worker role di calcolare, se necessario, il π fino alla milionesima cifra significativa. In definitiva, gli sviluppatori sono completamente liberi di progettare il proprio software come meglio credono Impieghi d uso d Azure Capire teoricamente i vari elementi che costituiscono Azure è indubbiamente utile, ma non è abbastanza per poter comprendere a pieno le sue funzionalità. Il miglior modo per capire le varie caratteristiche della piattaforma di Azure è quello di analizzare i suoi possibili impieghi mediante l utilizzo di esempi tipici. Essi analizzano i processi di sviluppo più frequenti e affrontano le problematiche con cui qualsiasi sviluppatore, anche alle prime armi, deve confrontarsi Applicazioni web scalabili Supponiamo che un organizzazione decida di creare un software di tipo web accessibile tramite Internet. Prima dello sviluppo dell architettura cloud, la scelta più ovvia da compiersi era quella di gestire l applicazione in un centro di calcolo all'interno dell'organizzazione o tramite un servizio di hosting. Attualmente la scelta migliore è quella d impiegare una piattaforma di nube come Azure di Windows. Se per necessità applicative il software si occupa di un gran numero di utenti simultanei, progettarlo unicamente per Fig Schematizzazione di un tipico applicativo scalabile di tipo web. supportare un unica piattaforma operativa è controproducente. Grazie alla forte scalabilità di Azure le applicazioni web di tipo cloud possono occuparsi di carichi maggiori rispetto alla Studio ed analisi del Cloud Computing Stumpo Elvio

51 tecnologie web convenzionali. Ad esempio, un servizio di ticketing on-line che offre ai suoi clienti la visione di materiale multimediale di diversa natura (informazioni, prenotazioni, video, link a siti esterni etc.) di solito viene consultato prevalentemente durante le ore diurne. Se tale sito è supportato con soluzioni tradizionali (un server privato o un servizio di hosting) le risorse sono prevalentemente sotto impiegate in certi periodi (bassa stagione e/o nelle ore notturne) ma non possono essere ridotte perché devono far fronte ad eventuali picchi di carico. Se, invece, la medesima applicazione è costruita mediante la piattaforma Azure l organizzazione può contare sulla scalabilità delle risorse che varia in funzione delle esigenze. Fin quando Windows Azure si baserà sul criterio pay-for-use, è probabile che la soluzione cloud sia più conveniente che mantenere molte macchine prevalentemente inutilizzate. Uno sviluppatore cloud può creare un applicativo adatto all organizzazione impiegando solamente un istanza web role ed una tabella connesse tra loro. Come mostrato anche in figura 3-13, i vari clienti sono rappresentati da istanze diverse di browser, condizione ideale per impiegare ASP.NET o un'altra tecnologia avanzata come il REST e/o web service basato sulle SOAP. In ogni caso, lo sviluppatore dovrà specificare quante istanze dell applicativo devono essere simultaneamente eseguite ed il fabric controller, di conseguenza, inizializzerà lo stesso numero di VM. A questo punto, l applicazione ha a disposizione tutto il necessario per funzionare correttamente. In termini di memorizzazione, la tabella impiegata per l immagazzinamento di dati ha elevate capacità contenitive, un buon grado di robustezza (repliche) e d efficienza. In ambito operativo, le VM, dove sono eseguite le istanze dell applicazione, sono costantemente monitorate dal fabric controller che ne garantisce il corretto funzionamento Istanze d esecuzione parallela L applicazione web scalabile è molto utile, ma non è l'unica situazione in cui Azure può essere impiegato. Si consideri un organizzazione che saltuariamente ha bisogno di molta potenza di calcolo per eseguire un applicazione di tipo parallelo. Esistono molti esempi inerenti a questo fenomeno: il rendering di un film per gli effetti speciali, lo sviluppo di nuovi farmaci per le società farmaceutiche, creazione di modelli finanziari per le banche, etc. Al solito, mantenere numerosi Fig Schematizzazione di una esecuzione parallela munita di una interfaccia web (parallel processing application with web role istance) cluster di macchine per far fronte ad esigenze occasionali è molto costoso. Windows Studio ed analisi del Cloud Computing Stumpo Elvio

52 Azure può invece fornire queste risorse, a seconda delle necessità, offrendo qualcosa di simile al servizio on-demand finalizzato ai supercomputer. Uno sviluppatore può utilizzare i worker role per la creazione di questo tipo d applicazione. Solitamente le applicazioni per il calcolo parallelo impiegano un dataset contenente una grande quantità di dati binari. In Azure, questo tipo di dati sono ideali per essere inseriti nei blob. Fig Schematizzazione di una esecuzione parallela priva di una interfaccia web (parallel processing application without web role istance) I task in parallelo, in Azure, vengono affrontati come un unico processo formato da un determinato numero di worker role eseguiti simultaneamente, ognuno dei quali accede direttamente ai blob per reperire i dati. Non essendoci limiti di alcun tipo sul tempo d impiego della piattaforma e di tutti i suoi servizi, ogni singola istanza può essere eseguita per tutto il tempo che si ritenga necessario (non esistono limiti massimi ma si ricordi che vale ancora il principio pay-for-use). Per interagire con l'applicazione, l'utente utilizza un unico web role presente nel processo; tramite questa interfaccia, l'utente è in grado di gestire completamente l intero processo. Essa, infatti, è in grado di impostare il numero di istanze di tipo worker che devono essere eseguite, quali di queste avviare e quali arrestare, ottenere risultati, etc. La comunicazione tra le istanze di tipo worker e quelle di tipo web sono possibili grazie all impiego delle code (queues) fornite dal servizio di storage di Azure. Queste code, oltre ad essere consultate dalle istanze web e da quelle worker, sono accessibili anche attraverso applicazioni on-premises. Grazie a questa possibile configurazione, un applicazione, che risiede stabilmente nella macchina dell utente, può bypassare l istanza web e comunicare con le worker direttamente tramite le code. Come si può vedere anche dalla figura 3-15, lo schema di principio del processo parallelo è esattamente identico al precedente, eccezion fatta per l eliminazione dell istanza web. La sua mancanza, però, può creare piccoli disagi per l utente: questi, infatti, non usando esplicitamente un istanza web, può non essere a conoscenza del fatto che l applicativo utilizzato per il calcolo in parallelo e che viene eseguito sulla sua macchina, sfrutti anche le potenzialità del cloud computing di Microsoft Applicazioni web eseguite in background Si può dire che ormai tutte le applicazioni realizzate dispongano di un'interfaccia browser. Questo significa che il software che non interagisce attivamente con Internet risulta essere sempre meno diffuso, anche se ancora utile. Inoltre, ci sono diverse situazioni in cui è Studio ed analisi del Cloud Computing Stumpo Elvio

53 richiesto al software web di lavorare in background, in altri termini, di essere completamente indipendentemente dall operato dell utente e di gestirsi autonomamente. Si pensi ad esempio ad un applicazione realizzata per lo sharing dei video. Tale software, deve accettare richieste di tipo browser, e probabilmente servire simultaneamente un gran numero di utenti. Alcune di quelle richieste sono di tipo upload (sequenza di operazioni che Fig Schema esemplificativo di un applicazione web eseguita in background. Come mostrato in figura, solo i worker role lavorano in background mentre i web role sono facilmente raggiungibili dagli utenti. permette caricare i nuovi video nella nube). Un nuovo video deve essere caricato e salvato per essere disponibile già dall accesso successivo. L applicazione web in background deve essere in grado, in fase d esecuzione, di evadere tutte le richieste di tipo browser evitando, per quanto possibile, di sovraccaricare il sistema operativo che lo ospita e, di conseguenza, di ridurre la fase d attesa imposta all'utente. In Azure applicazioni di questo tipo sono realizzate mediante l utilizzo congiunto di istanze di tipo web e di tipo worker. Analogamente alle web scalabili le applicazioni web in background associano ad ogni utente un determinato web role. Supportando, inoltre, un gran numero di utenti simultanei, l applicativo impiega anche delle tabelle per conservare le informazioni. Il numero delle istanze worker dipende essenzialmente dal tipo di processo che l applicazione è chiamata ad eseguire. Nell esempio proposto i worker role necessitano anche di un ulteriore supporto di memorizzazione, i blobs, ma questa non è una regola fissa. di Studio ed analisi del Cloud Computing Stumpo Elvio

54 Utilizzo del cloud storage per applicazioni on-premises o hosting A non tutti gli applicativi occorrono tutte le potenzialità offerte da Azure Windows; vi sono, infatti, alcuni software che necessitano solamente di un unico servizio. Un esempio classico di questa tipologia di applicativi possono essere i software on-premises o quelli di hosting che necessitano principalmente di conservare un quantitativo notevole di dati. Si pensi ad una grande impresa che voglia archiviare tutte le vecchie di tutti i suoi dipendenti, e che, per contenere le spese, memorizzi i messaggi direttamente nello storage del cloud 30. Similmente, un sito web di news, che viene eseguito su un hosting, Fig Applicativo di tipo On-permises o di hosting. Le suddette applicazioni vengono memorizzate, in funzione delle loro caratteristiche, nelle strutture di memorizzazione più idonee. per garantire un accesso globale necessita di elementi scalabili ed in grado di conservare grandi quantità di testo, grafica, video, e di informazioni sui profili dei suoi utenti 31. Come mostrato in figura 3-17, un applicazione on-premises (o di hosting) è in grado di accedere direttamente allo storage service di Azure. Molto probabilmente questo tipo d accesso risulta essere più lento rispetto a quello in locale, ma compensa tale lacuna con 30 Questa situazione è potenzialmente un classico esempio d impiego di software on-premises. Analizzandolo nel dettaglio, si può facilmente dedurre che ogni impiegato abbia almeno due indirizzi (uno aziendale e uno privato). L azienda in esame fornisce insieme alle varie risorse informatiche anche un programma per la lettura delle (windows mail, thunderbird, etc ) che istallato in locale, su ogni postazione dei dipendenti, permette ai diretti interessati di controllare le varie caselle di posta con un unico gesto. Questi programmi per rendere la corrispondenza online sempre disponibile ne eseguono il download dal server di posta ai server aziendali locali (o sui PC dei dipendenti), e molto spesso alla fine di tale operazione si procede con la cancellazione degli originali presenti nel web. In questo modo si ottiene che le proprie siano accessibili solamente dai computer aziendali. Lo spazio di memoria, impiegato dall azienda per memorizzare tutte le di tutti i suoi dipendenti, soprattutto per imprese di vasta dimensione, risulta essere considerevole senza contare che tale operazione sottrae risorse al normale processo di lavoro. In questo caso impiegare applicativi on-premises (e quindi il cloud) porta due grandi benefici: 1) non si è più obbligati ad accedere alle salvate solo dal proprio terminale aziendale, ma, tramite procedure d accesso supplementari, anche da casa o dal proprio smartphone; 2) si libera l azienda dall obbligo d impiegare proprie risorse per la conservazione delle Grazie ad Azure uno sviluppatore di pagine web può agire nel seguente modo: memorizza nel servizio di hosting solamente il codice delle proprie pagine e sfrutta lo storage services del cloud di Microsoft per salvare tutti i file associati alla pagine web. Questo metodo va ad aggiungersi alle configurazioni già esistenti. Quello più diffuso consiste nella memorizzazione della pagine e di tutti i suoi contenuti nel servizio di hosting, che non avendo caratteristiche di scalabilità, impone agli sviluppatori web dei limiti di spazio. Studio ed analisi del Cloud Computing Stumpo Elvio

55 caratteristiche di economicità, scalabilità, ed affidabilità. Per molte applicazioni, queste qualità superano di gran lunga la probabile diminuzione della velocità d accesso ai dati. Lo studio di queste quattro tipologie d applicazione fornisce i presupposti per l utilizzo di Azure. Queste basi, oltre a fornire soluzioni a problemi comuni, con il tempo e lo sviluppo del software e dell hardware, ne genereranno altri che, a loro volta, verranno risolti da altre tipologie di software. Quindi, con l impiego sistematico di tutti i servizi Azure si assisterà sicuramente alla nascita di nuove classi di applicazioni, sempre più idonee a impiegare pienamente le numerose risorse di Azure. 3.4-Microsoft.NET Services Cenni preliminari L impiego della nube come luogo dove eseguire le applicazioni è uno degli aspetti più importanti del cloud computing. Per le architetture cloud le applicazioni si dividono in due grandi categorie: quelle locali e quelle di tipo cloud. Attualmente i servizi basati sulla nube sono disponibili per entrambe le categorie di software. L obiettivo principale di questo genere di tecnologie è di eliminare il divario fra le tipologie di codice, tanto da rendere ininfluente la loro differenziazione. Se tale obiettivo sarà raggiunto, gli utenti, preso atto delle potenzialità offerte dalla rete a nube, potrebbero iniziare a prediligere il cloud per le loro applicazioni. Il.NET Services è stato realizzato per perseguire tale scopo. Originariamente conosciuto come BizTalk Services, NET Services si occupa di gestire e risolvere varie esigenze come quella di creare infrastrutture applicative distribuite adattate alla tipologie delle richiesta. Le componenti del.net Services sono: Fig Rappresentazione dettagliata degli elementi appartenenti ai servizi.net. Access Control (controllo degli accessi): Un approccio sempre più comune per stabilire l'identità di ogni utente consiste in un applicazione, che mediante token, ne verifichi l identità. Grazie ad essi un applicazione è in grado di stabilire i permessi specifici per ogni utente. Soprattutto in ambito aziendale l utilizzo dei token è diventato uno standard di sicurezza e la procedura ad essi legati è indicata con il termine identity federation 32. Un ulteriore metodo identificativo molto utilizzato è 32 Identity Federation: è la condivisione di un unica identità digitale fra organizzazioni differenti. Studio ed analisi del Cloud Computing Stumpo Elvio

56 quello detto claims transformation 33. In entrambi i casi l access control, disponibile nella nuvola, è in grado di supportarli. Service Bus (bus di servizio): progettare un applicazione che utilizzi servizi basati su Internet è più difficile di quanto si possa immaginare. L'obiettivo di service bus è di semplificare questa operazione. Esso, infatti, permette alle varie applicazioni, indipendentemente dalla tipologia d appartenenza, un facile accesso ai servizi su Internet. Ad ogni singolo servizio è assegnato un URI, che i client possono utilizzare per individuarlo ed accedervi. Service Bus, inoltre, gestisce anche le problematiche della modifica degli indirizzi di rete per superare i vari firewall senza modificarli (non vi è l apertura di nuove porte). Workflow (flusso di lavoro): Creazione di applicazioni composite, come Enterprise Application Integration 34, dove deve essere garantita la completa coordinazione tra le varie parti. Questa complessa logica viene modellata utilizzando un workflow, che è in grado di definire le modalità di attivazione dei processi. Esso è progettato mediante Windows Workflow Foundation (WF 35 ), ed è completamente compatibile con la nube. Ecco alcuni esempi di come i servizi.net Services possono essere utilizzati: Access Control: Un ISV fornisce la medesima applicazione ai propri clienti, i quali, a loro volta, sono impiegati in organizzazioni distinte. In tali condizioni l ISV può impiegare access control per semplificare lo sviluppo e il funzionamento dell'applicazione. Ad esempio, una ipotetica ISV crea un applicativo (è del tutto indifferente se di tipo on-permises o di tipo cloud) che fornisce ai propri clienti il 33 I claims sono dei particolari moduli contenenti una serie di elementi specifici tra cui le proprie limitazioni a particolari servizi e/o applicazioni. 34 L'obiettivo dell'eai (Enterprise Application Integration, letteralmente integrazione delle applicazioni aziendali) è l'interoperatività e l'organizzazione della diffusione dell'informazione tra applicazioni eterogenee; questo permette la più completa connettività tra le differenti applicazioni che costituiscono il sistema d'informazione aziendale, a volte esteso fino ad inglobare anche quelle dei clienti, dei partner o dei fornitori. EAI, in una prima fase, consiste nella creazione di un'architettura in cui le diverse applicazioni comunicano fra loro. Si tratta, quindi, di sviluppare dei connettori (middleware) che permettano di interfacciare le applicazioni usando dei protocolli di comunicazione diversi. Tuttavia, il progetto dell EAI va al di là dell'interoperatività tra le applicazioni: permette di definire un workflow tra le stesse. Inoltre, l'eai conserva dei limiti legati alla rigidità dell'esistente (detto legacy, tradotto eredità), così da rendere necessaria una modifica dei connettori se sopraggiungano delle variazioni importanti alle applicazioni. 35 Windows Workflow Foundation è una tecnologia inclusa nel.net Framework 3.0/3.5 e il suo scopo è quello di fornire un modello unificato di programmazione per la rappresentazione informatica di processi aziendali reali. Come il nome lascia chiaramente intuire, i processi aziendali sono rappresentati sotto forma di flussi di lavoro (workflow), che hanno una struttura logica simile ai diagrammi di flusso. Studio ed analisi del Cloud Computing Stumpo Elvio

57 codice che potrebbe monitorare le azioni degli utenti in real-time. Poniamo il caso che questo applicativo sia fornito ad X clienti, i quali appartengano a Y aziende differenti. Il programma, teoricamente, dovrebbe superare Y differenti procedure di richiesta d accesso per raggiungere gli X clienti corrispondenti. Per rendere insensibile l applicazione a questo problema la ISV delega alla nube l onere dell intera procedura di identificazione. Access control si occuperà di eseguire le Y procedure di identificazione idonee per ogni organizzazione, fornendo libero accesso all applicativo della ISV. Service Bus: Ipotizziamo che la medesima ISV voglia permettere ad un particolare software, utilizzato da alcuni suoi partner commerciali, l'accesso ad una delle sue applicazioni. Si può rendere accessibile l'applicazione tramite la tecnologia SOAP o REST, che con l impiego di Azure si riduce solamente al processo di registrazione (configurazione) dell accesso tramite service bus. I relativi partner commerciali potrebbero quindi utilizzare service bus per ottenere l accesso ai servizi richiesti. Poiché questo non richiede l'apertura di nuove porte nel firewall delle varie organizzazioni, si riduce il rischio di violazione (accessi non autorizzati) dell'applicazione. La procedura di accesso ai servizi risulta essere più robusta se unitamente a service bus viene impiegato Access Control che riduce ulteriormente le intrusioni a danno delle applicazioni direttamente coinvolte nel processo di condivisione dei servizi. Workflow: La solita ISV ha, inoltre, la necessità di eseguire costantemente un processo di tipo business che coinvolge i suoi partner commerciali. Per questo genere di operazione, è possibile utilizzare Workflow per implementare un applicazione di tipo WF che esegua il processo continuativamente. Questo genere di applicativo è in grado di impiegare altri tipi di servizi. Esso, infatti, è capace di comunicare con i partner utilizzando il service bus e di impiegare Access Control per effettuare correttamente le varie procedure di identificazione. Come con Windows Azure, basta un browser ed un Windows Live ID per accedere ai servizi.net Services. L'obiettivo di Microsoft con. NET Services è chiaro: fornire utili infrastrutture alla nube per le applicazioni distribuite Definizioni generali Dopo una breve definizione dei componenti fondamentali di.net Services si passa ora ad un analisi più dettagliata degli elementi prima citati Access Control Service Lavorare con le identità è una caratteristica fondamentale delle applicazioni distribuite. In base alle informazioni sulle identità degli utenti, un applicazione è in grado di stabilire il tipo di profilo utente con tutti i suoi permessi e tutte le sue limitazioni operative. Per stabilire il corrispondente profilo per ogni singolo utente, le applicazioni possono contare su speciali token denominati Security Assertion Markup Language (SAML). Un token di tipo SAML contiene le varie claims (nel caso specifico sono richieste d utilizzo delle risorse della rete Studio ed analisi del Cloud Computing Stumpo Elvio

58 cloud) ognuna delle quali fornisce alcune informazioni sull utente. Di norma, ogni claim contiene al suo interno informazioni, riferite all utente, che permettono di individuare il suo nome, il suo ruolo (utilizzatore, proprietario, sviluppatore, etc.), e il suo indirizzo . I token sono creati tramite un programma denominato STS (security token service) che apponendo la sua firma digitale ne garantisce la fonte. Precedentemente, un utente poteva trasferire i suoi permessi ad una applicazione solamente prestandole il proprio token. Grazie a questo elemento, l applicazione era in grado di richiedere l impiego di tutte le risorse che l utente aveva a disposizione nella rete cloud. Con questo sistema si presentano alcune problematiche come: Il caso della gestione delle applicazioni che non posseggono un token adatto alle loro necessità (claims transformation). Con l identificazione basata sui claims, ogni applicazione è libera di definire un set di claims che l utente deve essere in grado di fornirle per essere correttamente ammesso. Anche il STS crea qualche disagio all atto della creazione dei token; infatti, non è in grado di stabilire con certezza quale task ha fatto una esplicita richiesta di un determinato token. Il caso della gestione dell applicativo che non accetta l STS e dei suoi relativi token (identity federation). Può verificarsi che un determinato applicativo non accetti i token generati da particolari STS. Solitamente un applicazione deve permettere l accesso ad un elenco di STS certificati che verifichino e convalidino le specifiche d identificazione nel token che essi stessi hanno generato. Le applicazioni, per garantire un alto grado di sicurezza, accettano solamente i token provenienti da questi STS sicuri. L inserimento di un ulteriore STS (sicuro e accettato dall applicazione) nel processo può risolvere entrambi i problemi. Una volta che è stato verificato che i token contengano delle claims corrette, la nuova STS procede nell operazione di adattamento delle claims (claims transformation). La nuova STS può contenere regole che definiscono il metodo per formulare le richieste di input ed output corrette. Applicando tali norme si crea un ulteriore token contenente le claims di cui l applicazione ha bisogno. Nel caso della identity federation è necessario l inserimento di una nuova STS che l applicazione valuti come sicura. Il medesimo processo richiede, inoltre, la generazione di una relazione fidata tra il nuovo STS ed i vecchi STS che hanno generato i token rifiutati. Aggiungendo un altro STS si può effettuare sia la claims Fig Rappresentazione di una possibile sequenza operativa di autenticazione. Studio ed analisi del Cloud Computing Stumpo Elvio

59 transformation che l identity federation, entrambe molto utili. Un tema rilevante è la collocazione degli STS che devono essere eseguiti. Attualmente la soluzione maggiormente utilizzata è quella di far eseguire lo STS all interno dell organizzazione stessa. Lo STS locale ha molti vantaggi, ma anche molti svantaggi rispetto ad un security token service (sicuro) direttamente eseguito all interno della nube. Con tale accorgimento gli STS sarebbero accessibili dagli utenti e da tutte le applicazioni di qualsiasi organizzazione autorizzata. Questo è precisamente quello che offre Access Control Service: un STS nella nube. Se nella rete cloud è presente un security token service è probabile che questo STS sia usato, ad esempio, dalle varie ISV che, offrendo applicativi accessibili tramite Internet, possono essere utilizzati da diversi utenti anche impiegati in organizzazioni differenti. Non impiegando lo STS cloud, fornito da Azure, e più precisamente dal.net Access Control Service, gli utenti forniranno alle loro applicazioni gli SAML token in loro possesso che probabilmente saranno inadeguati alle richieste operative. Nella figura 3-19 viene illustrato come Access Control Service affronta il problema. Per iniziare una determinata applicazione (nel caso specifico si fa riferimento ad un browser web, ma potrebbe essere qualsiasi altro tipo di programma della WCF o altro ancora) acquisisce il token SAML dell'utente e lo presenta all Access Control Service (passo 1). Questo servizio convalida le specifiche di identificazione del token, verificandone che la sua creazione sia stata eseguita da un differente STS sicuro e fidato, diverso da quello presente nella nube. Il servizio, successivamente, genera e firma un nuovo token SAML che contiene esattamente le richieste di cui l applicazione necessita (passo 2). Per eseguire tale processo lo STS dell Access Control Service si basa su regole definite dal proprietario dell applicazione a cui l utente sta cercando di accedere. A titolo d esempio, si consideri una generica applicazione che supporti un protocollo di sicurezza basato sulle claims. Il proprietario dell applicazione ( in ambito aziendale, solitamente è un manager della società ) godrà di particolari diritti d accesso, tutti ricavabili dal token in suo possesso. Tale token può essere condiviso tra più utenti simultaneamente, i quali possono impiegare l applicazione per scopi diversi da quelli perseguiti dal proprietario del codice. Risulta, invece, più efficiente l inserimento di altre figure del personale. Oltre al ruolo di manager, infatti, se ne aggiunge un altro supervisor ed infine un terzo elemento recante un codice numerico interno. In queste condizioni il proprietario potrebbe ridefinire le regole per Access Control convertendo le tre stringhe della claim (manager, supervisor number) in un'unica stringa comune a tutti, definita come "Decision Maker" per permettere all applicazione di interagire con tutti i tipi di claims. Con questi accorgimenti l impiego dell applicativo risulta essere più semplice, anche l operazione di claims transformation è più efficiente. Una volta creato il nuovo SAML, lo STS-cloud rispedisce questo nuovo token all utente, (passo 3) il quale, a sua volta, lo invia all applicazione (passo 4) che lo richiede. L applicazione procede nella convalida delle specifiche d identificazione del token, assicurandosi che lo Studio ed analisi del Cloud Computing Stumpo Elvio

60 SAML ricevuto sia stato effettivamente generato dallo STS dell Access Control Service. Bisogna precisare che lo STS-cloud deve mantenere relazioni fidate e sicure con ogni STS di ogni organizzazione, in questo modo l applicazione, per garantire gli accessi, ha solo bisogno di relazionarsi con un unico STS, quello offerto dall Access Control Service. Una volta accertata la provenienza sicura del token, l applicativo può usare le claims ivi contenute per decidere se l utente richiedente sia autorizzato ad eseguire il task o meno (passo 5). Un applicativo può effettivamente delegare completamente l Access Control Service per la gestione dei permessi d accesso per ogni utente. Per esempio, l accesso ad una particolare funzionalità di uno specifico applicativo costringe l'utente a presentare claims adatte. La regola utilizzata dall Access Control Service inerente alla data applicazione potrebbe essere quella di autorizzare solo gli utenti che posseggono altre particolari claims, come ad esempio una manager claim. Normalmente quando l applicativo riceve il token di un utente, può accordargli o meno (negargli) l accesso, basandosi solamente sull analisi delle claims. Questa decisione può essere efficacemente presa dall Access Control Service. In questa condizione, un amministratore deve solo definire le regole d accesso di controllo, aiutare la condivisione dei controlli degli accessi ed, infine, controllare le regole per le applicazioni multiple. Ogni comunicazione con l Access Control Service si basa su protocolli standard come WS- Trust 36 e WS-Federation 37. Questo consente al servizio di essere accessibile da ogni genere di applicativi eseguiti su ogni tipo di piattaforma. Per la definizione delle regole, il servizio offre una GUI di tipo browser ed un API client per un accesso da programma. L'identificazione basata sulle claims è il metodo giusto per la creazione di un approccio standard per gli ambienti distribuiti. Offrendo uno STS nella nube, con annesse le regole per la claims transformation, l Access Control Service crea un moderno approccio alla verifica dell'identità molto interessante. 36 WS-Trust è uno standard che si occupa del rilascio, del rinnovo e della convalida di token di protezione, così come dei metodi per crearli, valuta l eventuale presenza di broker trust tra i partecipanti in una data operazione di condivisione delle informazioni al fine di garantire uno scambio di messaggi sicuro. 37 WS-Federation (WS sta per web service) è lo standard di riferimento utilizzato nei principali prodotti commerciali con l obiettivo di scambiare informazioni di autenticazione ed autorizzazione. Studio ed analisi del Cloud Computing Stumpo Elvio

61 Service Bus Supponiamo di lanciare una particolare applicazione all interno di una data organizzazione e che sia utile esportare il suddetto software anche in altre aziende attraverso Internet. Si ipotizzi, inoltre, che il software in questione sia provvisto anche di servizi web (REST o SOAP); in questo caso si possono impiegare solo questo genere di servizi web per rendere visibile l applicazione al mondo esterno all organizzazione. In ogni caso, questo genere di operazioni presenta alcune difficoltà. Il primo problema consiste nel modo in cui rendere rintracciabile un applicazione alle altre organizzazioni. Sarebbe auspicabile avere un qualche Fig Rappresentazione di una tipica applicazione del service bus genere di catalogo in cui gli interessati siano in grado di localizzare una determinata applicazione. Superato questo problema, se ne riscontra immediatamente un altro: conoscere gli endpoints dove reperire le applicazioni. Tali endpoints, inoltre, devono essere accessibili solo alle organizzazioni interessate ed autorizzate. Per renderli sicuri, e limitarne l acceso solo al personale abilitato, solitamente gli amministratori delle reti aziendali impiegano i NAT. I Network address translation (NAT) 38 sono di uso comune; sovente capita che le applicazioni non abbiano un indirizzo IP fisso esterno (l IP esterno è un indirizzo raggiungibile tramite internet). Nel caso di cui i NAT non vengano utilizzati, si potrebbero verificare dei problemi con il firewall che protegge l applicazione. Tale contrattempo è risolubile con l apertura delle porte nel firewall che permetterebbe l accesso al software, ma aumenterebbe la probabilità 38 Nel campo delle reti telematiche, il network address translation o NAT (letteralmente Traduzione degli Indirizzi di Rete) conosciuto anche come network masquerading, o native address translation, è una tecnica che consiste essenzialmente nella modifica degli indirizzi IP dei pacchetti in transito su un sistema, svolgendo mansioni tipiche del router. Il NAT interagisce con due elementi particolari presenti in rete: i router e i firewall. Storicamente il NAT si è affermato come mezzo per ovviare alla scarsità di indirizzi IP pubblici disponibili, soprattutto in quei paesi come l Italia che, a differenza degli USA, hanno meno spazio di indirizzamento IP allocato pro-capite (IPv4). Considerato che spesso gli indirizzi IP pubblici hanno un prezzo, per molti utenti Internet il costo di un indirizzo IP extra non è compensato dai benefici derivanti dal suo utilizzo. Le tecniche utilizzate per risparmiare indirizzi IP pubblici rendono i calcolatori non direttamente raggiungibili da internet, per cui spesso questa configurazione viene scelta anche per ragioni di sicurezza. Studio ed analisi del Cloud Computing Stumpo Elvio

62 del sistema di essere vulnerabile a qualsiasi attacco, rischio che gli amministratori di rete evitano categoricamente. In sintesi: nella condivisione aziendale di una o più applicazioni vi sono due grosse problematiche: Individuazione dell applicativo desiderato: viene risolto con la generazione di uno speciale elenco contente tutti gli applicativi condivisibili Individuazione dell endpoint corrispondente: ad ogni applicativo deve corrispondere un endpoint, che mediante l uso dei NAT, deve essere sicuro e limitare l accesso solo al personale autorizzato. Il Service Bus affronta entrambi questi aspetti. Seguendo lo schema mostrato in figura 3-20 si può notare che il software dell organizzazione Y registra uno o più endpoints 39 con il Service Bus (passo 1) che, immediatamente, saranno rintracciabili anche all esterno dell organizzazione Y. Il Service Bus assegna ad ogni organizzazione un URI radice in cui i file sono organizzati in maniera del tutto autonoma dalla società Y. Questo permette all endpoint di ottenere un assegnamento specifico, rintracciabile tramite gli URI. L applicazione deve, comunque, aprire un collegamento con il Service Bus per ciascun endpoint finalizzato alle connessioni esterne. Il Service Bus mantiene attivi questi tipi di collegamenti per risolvere i due problemi prima enunciati. Con l impiego dei tools.net le connessioni tramite NAT non sono più un problema, dato che tutto il traffico è indirizzato alla connessione aperta del Service Bus, che a sua volta lo reindirizzerà all applicazione desiderata. Inoltre, visto che il collegamento è stato creato all interno del firewall Y, non vi sono problemi nel passaggio delle informazioni verso l applicazione. Il firewall Y non bloccherà questo traffico, dato che il tipo di collegamento, rispetto all organizzazione Y, è uscente e non entrante. Spostando il punto di osservazione (lato azienda X ), per accedere ad un applicazione 40 posseduta dalle altre organizzazioni bisogna contattare il registro del Service Bus (passo 2). La richiesta dell applicativo impiega Atom Publishing Protocol, che riceve come risposta un documento di servizio AtomPub con i riferimenti all'endpoint inerente al software richiesto. Una volta ricevute tali informazioni, si possono richiedere i servizi offerti tramite l endpoint (passo 3). Ogni singola richiesta ricevuta dal Service Bus, viene inoltrata all applicativo, il quale risponde seguendo il percorso inverso. Come risultato finale, il Service Bus stabilisce sempre un collegamento diretto tra un applicazione ed il suo possibile utilizzatore, rendendo la loro comunicazione molto più efficiente. 39 Nelle architetture di tipo service-oriented l endpoint è il punto di accesso ad un servizio, ad un processo, o ad una coda. 40 Nel caso specifico le altre organizzazioni risultano essere solo l azienda Y ma tale scenario non è l unico; infatti il singolo software potrebbe essere posseduto da più aziende, le quali singolarmente detengono una sola parte dell applicativo. Studio ed analisi del Cloud Computing Stumpo Elvio

63 Oltre a rendere più facile la comunicazione, il Service Bus migliora anche la sicurezza. Questo perché gli utenti conoscono solamente un indirizzo IP interno al Service Bus, ignorando completamente gli indirizzi IP privati dell organizzazione proprietaria dell applicativo richiesto. In questa condizione l applicativo risulta essere anonimo perché non è riconducibile a nessun indirizzo IP valido. Il Service Bus funge anche da DMZ 41 esterna, introducendo un livello di disaccoppiamento aggiuntivo che contribuisce a debellare i potenziali attacchi. Chiaramente il Service Bus è stato progettato per funzionare unitamente con l Access Control Service, quando si eseguono le claims transformation. Il Service Bus, infatti, accetta solo i token provenienti dal STS dell Access Control Service. Un applicazione che viene resa accessibile attraverso il Service Bus, solitamente, è implementata tipicamente tramite WCF. I client, invece, possono essere progettati con WCF o con altre tecnologie, tipo Java, che effettuano le loro richieste via SOAP o HTTP. Le applicazioni ed i loro client sono anche liberi di usare le proprie procedure di sicurezza, come cifratura con chiavi asimmetriche, per preservare le loro comunicazioni da possibili attacchi anche dal Service Bus stesso. Rendere accessibile un applicazione dall esterno, come già detto prima, non è un operazione semplice come sembra, ma il service bus ha come obiettivo quello di fornire un valido aiuto semplificando il più possibile tale processo e rendendolo il più efficiente possibile Workflow Service Windows Workflow Foundation è una tecnologia impiegata per la creazione di applicazioni basate sui flussi di lavoro. Un caso classico per il flusso di lavoro (Workflow) è il controllo di un processo con tempi di esecuzione molto lunghi, come avviene spesso nelle applicazioni di tipo Enterprise Integration. Più in generale, le applicazioni basate su WF possono essere una scelta valida per il coordinamento di vari tipi di lavoro, soprattutto se risulta dislocato in diverse organizzazioni. 41 Una DMZ (De Militarized Zone) è un segmento isolato di LAN (una "sottorete") raggiungibile sia da reti interne che esterne che permette, però, connessioni esclusivamente verso l'esterno: gli host posizionati nella DMZ non possono connettersi alla rete aziendale interna. Tale configurazione viene normalmente utilizzata per permettere ai server posizionati sulla DMZ di fornire servizi all'esterno, senza compromettere la sicurezza della rete aziendale interna. Per chi si connette dall'esterno dell'organizzazione, la DMZ è, infatti, una sorta di "strada senza uscita" o "vicolo cieco". Solitamente sulla DMZ sono collegati i server pubblici (ovvero quei server che necessitano di essere raggiungibili dall'esterno della rete aziendale ed anche tramite internet) che rimangono in tal modo separati dalla LAN interna, evitando di comprometterne l'integrità della stessa. Una DMZ può essere creata attraverso la definizione di politiche distinte su uno o più firewall. Studio ed analisi del Cloud Computing Stumpo Elvio

64 Il servizio Workflow consente l esecuzione di un processo di host per applicazioni basate su WF 3.5, che consente agli sviluppatori di creare flussi di lavoro che funzionino nella nube. Ogni flusso di lavoro WF è attuato mediante un certo numero di attività, indicate nella figura 3-21 con gli elementi rossi. Ogni attività Fig Schematizzazione dettagliata degli elementi costituenti il workflow svolge una determinata operazione, come: l'invio o la ricezione di un messaggio, l'attuazione di una decisione IF, il controllo di un loop di tipo WHILE etc. Workflow Foundation fornisce alle sue applicazioni una serie di attività conosciute come Base Activity Library (BAL). Workflow Service permette di eseguire le applicazioni utilizzando parte delle istruzioni presente nella BAL. Il servizio prevede inoltre diverse attività. Ad esempio, le applicazioni host sono in grado di comunicare con gli altri software utilizzando HTTP o il Service Bus (come mostrato in figura 3-21) dato che Workflow Service supporta entrambe le tecnologie. Il Workflow Service prevede, inoltre, attività dedicate all utilizzo di messaggi XML, un requisito comune alle applicazioni di tipo integrativo. L esecuzione dentro la nube porta alcune limitazioni: infatti, le applicazioni di tipo WF-based eseguite da Workflow Service possono utilizzare, ad esempio, solo i modelli di sequenze di lavoro presenti in WF. L'esecuzione di codice arbitrario non è consentita. Questo significa che le attività personalizzate ed addirittura lo stesso sorgente del BAL, non possono essere utilizzati. Per creare applicazioni per il Workflow Service, gli sviluppatori possono impiegare lo standard WF Workflow Designer utilizzabile tramite Visual Studio. Una volta progettate, le applicazioni WF-based possono essere impiegate nella nube usando un portale Workflow browser-based o utilizzando le API espressamente configurate per essere utilizzate come Workflow-provided. Entrambe le soluzioni possono essere utilizzate per gestire i flussi di lavoro. Come con il Service Bus, le applicazioni che interagiscono con il Workflow Service devono prima ottenere un token proveniente dall Access Control Service, l'unico STS presente nella nube e il più attendibile. Le applicazioni WF-based non sono l'approccio giusto per ogni situazione. Quando questo tipo di soluzione è attuabile, tuttavia, l impiego della tecnologia del flusso di lavoro semplifica il compito dello sviluppatore. Studio ed analisi del Cloud Computing Stumpo Elvio

65 3.5-SQL Services Cenni preliminari Una modalità di utilizzo di Internet è la possibilità di accedere ai server per la gestione dei dati. L'obiettivo di SQL Services è quello di fornire una serie di servizi cloud-base per la memorizzazione e per la gestione di molti tipi di dati, dai non strutturati fino a quelli relazionali. SQL Services comprenderà, in un futuro, una serie di Fig Servizi fondamentali offerti da SQL Services facilitazioni per il trattamento dei dati impiegando strutture di tipo data-oriented come, ad esempio, reporting, analisi dei dati, etc. Il componente di SQL Services attualmente disponibile, invece, è SQL Data Services. Questo, precedentemente noto come SQL Server Data Services, fornisce il servizio che gestisce i database nella nube. Detta tecnologia consente alle applicazioni sia di tipo on-premises che di tipo clouding la memorizzazione e la possibilità di accedere ai dati presenti sui datacenters Microsoft. Anche con questo genere di servizi vale la regola del pay-for-use e, quindi, ne consegue che i costi di alcune risorse hardware possono essere impiegate per altri scopi. L obiettivo primario di SQL Data Services è quello di essere ampiamente accessibile. A tale fine, esso dispone di interfacce di tipo SOAP e di tipo REST, consentendo ai suoi dati la possibilità di essere acquisiti in vari modi. E poiché questi dati sono esposti attraverso protocolli standard (resi disponibili tramite internet), SQL Data Services può essere utilizzato da applicazioni su qualsiasi tipo di sistema operativo, non essendo una tecnologia esclusiva per Windows. A differenza del servizio di memorizzazione di Azure, SQL Data Services si basa su Microsoft SQL Server con alcune sostanziali differenze. Esso, infatti, fornisce un modello di dati di tipo gerarchico che non necessita di uno schema predefinito. La memorizzazione di ogni elemento è compiuta classificando ogni dato con alcune sue caratteristiche fondamentali come: nome, tipo e valore. Per formulare le query, le applicazioni possono utilizzare l'accesso diretto di tipo REST o un linguaggio basato sulla sintassi del C # definita da Microsoft come Language Integrated Query (LINQ). La motivazione che ha spinto Microsoft ad inserire un nuovo linguaggio in SQL Data Services diverso dal precedente, ad un analisi superficiale, sembrerebbe controproducente. In questo modo, infatti, si è inserito un ostacolo in più per l impiego della tecnologia cloud dato che, ogni singolo utilizzatore deve far proprio un nuovo linguaggio. A tale handicap sono soggetti tutti, dal neofita fino ad arrivare all esperto che ha utilizzato il metodo relazionale sistematicamente acquisendo una notevole esperienza in questo ambito, e con i prodotti software ad esso dedicati. Questo svantaggio è giustificato dal fatto che il nuovo software, Studio ed analisi del Cloud Computing Stumpo Elvio

66 leggermente diverso dal suo predecessore, offre alcuni benefici tra cui, maggiore scalabilità, disponibilità ed affidabilità. Il modo in cui si organizzano e si richiamano i dati rende la replica e il bilanciamento del carico più facile e più veloce rispetto ad un tradizionale approccio relazionale. Un altro vantaggio è che SQL Data Services non richiede ai clienti di gestire direttamente i propri DBMS. Gli utenti di SQL Data Services sono svincolati da alcune delle procedure tipiche di un database, come il controllo del disco, la manutenzione dei file di log e la determinazione del numero dei casi. Questo permette di concentrarsi esclusivamente su ciò che è importante: i dati. SQL Data Services può essere utilizzato in una varietà di modi. Ecco alcuni esempi: La riconversione dei vecchi database, oltre a portare migliorie in termini di efficienza e funzionalità, fornisce servizi mai associati prima ai DBMS di tipo relazionale. Un esempio fra tutti è la possibilità di associare ad alcuni dati intere procedure di aggiornamento dinamico tramite gli RSS feed. Questo genere di accorgimenti sono stati ideati per fornire servizi alternativi a basso costo e affidabili. Poiché i dati possono essere accessibili attraverso interfacce SOAP e REST, le applicazioni che le utilizzano possono essere scritte con qualsiasi tecnologia ed essere eseguite su qualsiasi piattaforma. Questo tipo di architettura del DBMS rende più agevole la gestione dell accesso ai dati anche ad utenti a cui il database non era originariamente destinato. Un classico esempio è fornitore-rivenditore-cliente. Con l impiego del SQL Data Services il fornitore di un prodotto, qualora lo ritenga opportuno, con una semplice procedura può fornire al cliente l accesso al database del magazzino del rivenditore più vicino. In questo modo si fornisce al cliente la completa tracciabilità del prodotto che comporta una procedura di acquisto più pratica, più efficiente e più sicura. Come per gli altri componenti dell Azure Services Platform, SQL Data Services deve rende semplice l utilizzo dei suoi servizi: basta impiegare un qualunque browser e fornire tutte le informazioni necessarie. Questi vincoli sono i medesimi per ogni tipo di operazione da eseguire sul database, dall'archiviazione dei dati, fino ad arrivare alle procedure di accesso ai dati ad applicazioni dislocate in diverse sedi. Studio ed analisi del Cloud Computing Stumpo Elvio

67 3.5.2-Definizioni generali Con il termine SQL Services viene indicato un gruppo di tecnologie cloud-based. Tutti i suoi componenti sono incentrati sulla gestione dei dati come la memorizzazione, l'analisi, la creazione di reports, etc. Dato che le funzioni base di un DBMS sono l elemento fondamentale, il primo membro di questa famiglia che si contraddistingue per tali Fig Rappresentazione dettagliata degli elementi impiegati nel SQL Data Services caratteristiche è SQL Data Services. Una banca dati residente nella nube è interessante sotto molti aspetti. Per molte organizzazioni, è importante impiegare servizi specializzati per garantirne l'affidabilità (impiegare tecnologie di backup ed eseguire altre funzioni di gestione). I dati nella nube possono essere resi disponibili per le applicazioni in esecuzione ovunque esse siano collocate, anche su dispositivi mobili. Oltretutto, per i server provider risulta essere economicamente più conveniente impiegare la nube per gestire database che farlo in maniera individuale. L'obiettivo di SQL Data Services è quello di fornire tutti questi vantaggi. Tuttavia, l'attuazione di una banca dati affidabile e ad alte prestazioni impiegando la scalabilità di Internet non è affatto semplice; dei compromessi (tradeoffs) sono obbligatori. Come descritto in precedenza, SQL Data Services non fornisce uno standard di database relazionale, né il supporto SQL. I dati, infatti, sono organizzati utilizzando la struttura mostrata in figura Le informazioni in SQL Data Services sono conservate in centri di calcolo multipli. Ogni centro di calcolo contiene un certo numero di authorities (autorità). Un'autorità è l unico elemento che ha esplicita collocazione geografica. Essa viene effettivamente posizionata in specifiche banche dati di Microsoft caratterizzate da un unico DNS. Un'authority possiede degli elementi denominati containers (contenitori), ognuno dei quali viene replicato all'interno del suo data center. I containers sono usati per il bilanciamento del carico e della disponibilità. In caso di crash di un container, SQL Data Services comincerà ad usare automaticamente una replica del contenitore. Ogni query è pubblicata all interno di una specifico container. Ogni contenitore racchiude un numero arbitrario di entities che a loro Studio ed analisi del Cloud Computing Stumpo Elvio

68 volta includono le proprietà (property). Ogni property è caratterizzata da un nome, un tipo, ed un valore (concorde con il campo type). I possibili tipi di dati che SQL Data Services supporta includono String, DateTime, Base64Binary, Boolean, e Decimal. Per consultare questi dati, il software ha diverse opzioni. Il primo metodo consiste nell impiegare il linguaggio LINQ (basato sulla sintassi del C#) con query trasmesse tramite SOAP o approccio REST. Un altra possibilità potrebbe essere utilizzare ADO.NET Data Services, valida alternativa all approccio REST per l accesso ai dati. In entrambi i casi, gli applicativi continuano ad impiegare le query per le loro interrogazioni del database. Dette query sfruttano ancora operatori come ==,!=, <, >, AND, OR, e NOT e possono includere anche alcuni operatori simili ad ORDER BY e JOIN presenti in SQL. Le query sono gli unici elementi che possono essere impiegati sia per la ricerca che per l aggiornamento dei dati. Una volta eseguita una qualsiasi query si ottengono, ad esempio, le informazioni sul numero delle entità, incluso anche tutte le proprietà che le compongono. Non è possibile, invece, aggiornare solo una singola proprietà in una entità: l intera entry deve essere sostituita. Dato che l entità non ha uno schema predefinito, le proprietà in una unica entry possono essere di vari tipi. Le entità immagazzinate nel medesimo contenitore possono anche essere tutte diverse fra loro, ognuna costituita da diverse tipologie di proprietà. I dati in SQL Data Services sono individuabili tramite gli URI, lo stesso genere di classificazione impiegato nello storage di Azure. I campi degli URI sono organizzati in modo da identificare una particolare entità come ad esempio: Un errore comune è quello di ritenere che SQL Data Services necessiti di un client.netbased eseguito su Windows; invece, i dati sono accessibili, tramite il protocollo REST o SOAP, da qualsiasi applicativo eseguito su una qualsivoglia piattaforma. Indipendentemente dal sistema operativo impiegato, il software in esecuzione per accedere ai dati deve effettuare la procedura di identificazione dell utente mediante username e password ammissibili e/o token creati dalla STS presente in Access Control Service. Per gli sviluppi futuri, Microsoft ha annunciato piani per evolvere SQL Data Services in una tecnologia più vicina al relazionale. Diversamente dallo storage di Azure, SQL Data Services è stato implementato sulle basi di SQL Server di cui risulta essere la sua naturale evoluzione. Ancora una volta l obiettivo che la suddetta tecnologia persegue rimane immutato: offrire un servizio, nel caso specifico un database basato sulla nube scalabile, affidabile, ed a buon mercato per qualsiasi genere di applicativo. Studio ed analisi del Cloud Computing Stumpo Elvio

69 3.6-Live Services I Live Services potrebbero sembrare l unico servizio indipendente dalla rete cloud di Microsoft. Questa sensazione è imputabile essenzialmente alla loro particolare natura. Basti pensare che gli applicativi Live impiegano la rete cloud sistematicamente (nella sincronizzazione dei file e nella istallazione del software tramite web 42 ) ma in maniera completamente trasparente, tanto che l utente non ne percepisce la presenza Cenni preliminari Mentre l'idea della nube è relativamente recente, Internet non lo è di certo. Centinaia di milioni di persone in tutto il mondo lo utilizzano ogni giorno. Per supportarli in tale attività, Microsoft offre un gruppo di servizi cloud progettati per Internet, in continua espansione: i servizi Windows Live. Con alcune applicazioni Fig In questa figura viene dimostrato la natura duale del Live Framework (Cloud, Desktop/Device ) ed i loro possibili collegamenti. basate su tali servizi, gli utenti possono inviare messaggi istantanei, memorizzare i propri contatti, effettuare ricerche, ottenere indicazioni stradali e fare altre operazioni di pubblica utilità. Tutte queste applicazioni, comunque, sono in grado di memorizzare dati. Alcuni di questi, come i contatti, variano in base all utente. Altri, come la mappatura e la ricerca di informazioni di ordine generale, possono essere di dominio pubblico. In entrambi i casi, Microsoft è certa che la condivisione di queste informazioni con altre applicazioni possa portare numerosi vantaggi. La condivisione dei dati non deve essere interpretata come la possibilità di rendere accessibile a chiunque i dati 42 L applicativo più diffuso della famiglia Live è: Live Messenger (MSN), il servizio che ai suoi albori veniva impiegato per scambiare messaggi istantanei. Nelle ultime versione di MSN il software ha acquisito nuove funzionalità, come il controllo automatico di una sua nuova versione. Se si utilizzava, ad esempio, una versione beta del programma, una volta pubblicata la versione ufficiale, il software si bloccava autonomamente fin quando l utente non accettasse di installare la nuova versione. Il file di istallazione è anch esso mutato completamente. Al posto del classico eseguibile (.exe) viene fornito un file di diversa natura che ha come unico compito quello di collegarsi ad internet, dove avverrà la vera istallazione. Per comprendere al meglio tali caratteristiche si leggano i successivi paragrafi. Studio ed analisi del Cloud Computing Stumpo Elvio

70 privati dell utente, cosa che senza una espressa autorizzazione sarebbe anche illegale (Privacy), ma come la volontà di condividere le informazioni tra applicazioni simili. Al fine di rendere questo possibile, Microsoft ha creato un gruppo di risorse, denominato Live Services, adatto a tali operazioni. Applicazioni di Microsoft già esistenti, come quelle appartenenti alla famiglia di Windows Live, già si basano sul Live Services per conservare e gestire le informazioni. L accesso a tali dati da parte delle nuove tipologie di applicazioni è gestito da Microsoft tramite Live Framework. Il componente fondamentale del Live Framework è il Live Operating Environment (LOE) 43. Il suddetto componente viene eseguito nella nube e le applicazioni ad esso connesse lo adoperano per accedere a Live Services Data, presente anch esso nella nube. La procedura di accesso ai dati attraverso LOE è basata su protocollo di tipo HTTP, il che significa che le applicazioni scritte utilizzando il.net Framework, Java Script, Java, o qualsiasi altro linguaggio, sono in grado di accedere ai dati contenuti in Live Services. Oltre all HTTP sono disponibili altri protocolli di accesso ai dati, ad esempio i feed RSS 44 e Atom 45, in cui le applicazioni riescono a tenere traccia dei dati e, di conseguenza, sono in grado di applicare loro le eventuali modifiche e/o aggiornamenti. Per rendere più facile l uso della tecnologia Live, l utente utilizza un browser, basato su Live Services Developer Portal, per configurare e gestire il Live Services e le applicazioni da esso dipendenti. Il LOE può anche essere lanciato in sistemi operativi diversi. Per utilizzare questa opzione, i vari dispositivi di un utente devono applicare un particolare 46 elemento, noto come mesh, ai propri sistemi. Ad esempio, si può creare una rete che 43 Live Operating Environment (LOE) è un software di sincronizzazione tipico di casa Microsoft che permette ai file e alle cartelle di essere condivise e di sincronizzarsi attraverso vari dispositivi. Se, ad esempio, una cartella sarà impostata per la sincronizzazione sarà disponibile presso ogni dispositivo e qualsiasi cambiamento del suo contenuto verrà rilevato e notificato a tutte le macchine. 44 Feed RSS: letteralmente RDF Site Summary RSS, in precedenza noto come Rich Site Summary o Really Simple Syndication, è un metodo per descrivere contenuti che possono essere forniti a chi pubblica informazioni su Internet. È parte del progetto XML e aderisce alle specifiche del W3C. Un documento RSS o RSS feed, come viene generalmente chiamato, non è altro che un elenco di elementi, ciascuno identificato da un link e caratterizzato da una breve descrizione ed eventuali altre informazioni. 45 Atom: è un modello di documento basato su XML per la sottoscrizione di contenuti web, come blog o testate giornalistiche e che supporta una moltitudine di strumenti per la sottoscrizione, sia per chi riceve la sottoscrizione, sia per chi la pubblica. Anche alcuni servizi di Google, come Blogger o Gmail, usano questo formato. 46 Mesh: In questo ambito il termine Mesh sta ad indicare una particolare tipologia di reti nota anche con il termine Live Mesh. Nelle suddette reti vengono impiegati diversi applicativi dedicati come Live Mesh Operating Environment per la sincronizzazione e la condivisione di file e cartelle tra i vari dispositivi connessi alla rete. Live Mesh include anche una componente di cloud storage chiamata Live Desktop. Studio ed analisi del Cloud Computing Stumpo Elvio

71 contenga simultaneamente il desktop, il laptop, il netbook, e il telefono cellulare. Su ciascuna macchina, equipaggiata con sistemi operativi differenti, viene eseguita un'istanza di Live Operating Environment. Una caratteristica fondamentale dell'ambiente operativo Live è la possibilità di sincronizzare i dati su tutti i sistemi apparenti alla mesh. Gli utenti, e anche le applicazioni, possono indicare quali tipi di dati devono essere conservati in sincronia; LOE, di conseguenza, aggiorna automaticamente tutti i desktop, laptop e dispositivi connessi in rete con le modifiche apportate a tali dati. Anche la nube è vista come un sistema connesso alla mesh, ma agisce come un dispositivo speciale quando si opera sui dati del Live Services. Ad esempio, se un utente ha mantenuto tutte le voci dell'elenco dei contatti in un database utilizzando Windows Live Hotmail, Windows Live Messenger, Windows Live Contacts, o altre applicazioni simili, i dati verranno automaticamente conservati in maniera sincrona su ogni dispositivo presente nella sua Mesh. Il Live Operating Environment consente anche ad un utente di rendere pubblici i dati della sua mesh ad altri utenti, permettendogli di scegliere selettivamente quali informazioni condividere. Un applicazione può accedere, attraverso una rete mesh, ai dati semplicemente lanciando un istanza di LOE, sia essa eseguita in locale o tramite la rete cloud. In entrambi i casi, l'accesso è realizzato nello stesso modo: attraverso le richieste HTTP. Questa simmetria consente all applicazione di lavorare indipendentemente dal suo stato (connessa o disconnessa dalla rete cloud); infatti, in entrambi i casi i dati sono disponibili e sono gestiti in maniera analoga. Qualsiasi applicativo, se è in esecuzione su Windows o su qualsiasi altro sistema operativo, può accedere ai dati di Live Services conservati nella nube attraverso il Live Operating Environment. Se l'applicazione è in esecuzione su un sistema che fa parte di una mesh, può anche accedere, direttamente, alla copia locale dei dati di Live Services. Tuttavia, c'è anche una terza possibilità: uno sviluppatore può creare un applicazione denominata mesh-enable web. Questo stile di applicazione è progettato per essere eseguito su una multi-piattaforma 47, come ad esempio la tecnologia Microsoft Silver light, ed accede ai dati (sincronizzati) attraverso il LOE. Per aiutare gli utenti a trovare questo genere di applicazioni, Live Framework prevede un catalogo di tipo cloud-based di applicativi mesh-enable web. Un utente, infatti, può sfogliare il catalogo, scegliere una data applicazione e procedere con la sua installazione. Il Live offre un gran numero di funzioni che possono essere utilizzate in molti modi diversi. Ecco alcuni esempi: Un applicazione Java in esecuzione su Linux potrebbe contare su Live Framework per l'accesso alle informazioni dei contatti dell utente. Il suddetto applicativo ignora la tecnologia utilizzata per rendere accessibili i dati, di tali informazioni è responsabile il 47 Un applicazione multi-piattaforma indica quel genere di applicativi che possono essere eseguiti, con le medesime caratteristiche, su sistemi operativi diversi fra loro (da qui l appellativo di multipiattaforma). Studio ed analisi del Cloud Computing Stumpo Elvio

72 Live Framework.Tutto ciò di cui il programma ha bisogno è una interfaccia HTTP coerente con Live Framework e con i dati dell'utente. Un applicazione di tipo.net Framework potrebbe richiedere all'utente di creare una rete mesh, quindi utilizzare il Live Framework per effettuare la copia in cache dei dati e la sincronizzazione dei servizi. Quando la macchina su cui viene eseguita l applicazione è collegata a Internet, l'applicativo accede ad una copia dei suoi dati tramite la nube. Quando la macchina è disconnessa (si pensi a tutti i dispositivi portabili che lanciano il suddetto applicativo su un aereo o in qualunque altro luogo dove non è disponibile un accesso ad Internet) l'applicazione accede a una copia in locale dei dati stessi. Le modifiche apportate a qualsiasi copia dei dati sono propagate dal LOE appena la macchina ritorna nuovamente online. Un ISV è in grado di creare, ad esempio, un applicazione di tipo mesh-enable web che consente di tenere traccia di cosa stiano facendo i propri amici. Questa applicazione, che può essere eseguita invariabilmente su tutti i sistemi dell utente, sfrutta alcuni aspetti del Live Framework che supporta questo genere di applicazione di tipo sociale. Il Live Framework in una rete di tipo mesh trasmette le informazioni tramite feed. L'applicazione è in grado di tenere traccia di tutti gli aggiornamenti effettuati da propri amici. Gli applicativi di tipo mesh-enable web assumono diffusioni di tipo virale se ogni utente invita i propri amici ad utilizzare i suoi medesimi programmi. Il suddetto invito può essere effettuato anche in maniera automatica, previa autorizzazione del fruitore del servizio, dalla rete mesh, visto che è in grado di accedere all elenco dei contatti dell utente. Live Framework offre un modo diretto per accedere a Live Services Data. Le sue funzioni di sincronizzazione dei dati e di supporto possono essere impiegate su una varietà di applicazioni Definizioni generali La maggior parte dei software subisce un continuo aggiornamento. Questo fenomeno è imputabile alla condizione che tutto è in continuo cambiamento: cambia l hardware, cambia il software, e cambiano anche i modi con cui gli utenti si rapportano alle applicazione e ai dati. Gli attuali telefoni mobili tendono a trasformarsi Fig Descrizione delle relazioni esistenti fra le Applicazioni Live, Live Services, Live Framework, e la rete Live Mesh Studio ed analisi del Cloud Computing Stumpo Elvio

73 sempre più in piccoli computer, tanto che molti dei servizi offerti dalla nube sono divenuti di uso comune e quotidiano (si pensi a Windows Live Messenger versione mobile phone). Le applicazioni sono diventate sempre più personali, come i dati che vengono in esse conservati. La necessità di questo continuo cambiamento ha aperto le porte allo sviluppo di nuovi generi di piattaforme applicative. Live Services e Live Framework sono una possibile soluzione a tale necessità. Le applicazioni che sono in grado di usare Live Framework per accedere a Live Services Data sono in grado di sincronizzare i propri dati attraverso desktop, laptop, ed altri dispositivi simili. Live Services si può frammentare in molte categorie diverse, come è mostrato in figura Ogni servizio permette l accesso ad un particolare set di risorse che possono essere adibite ad uso esclusivo dell utente o condivise. Ad esempio, l'elenco di contatti di un utente è una risorsa offerta da Directory service, mentre il profilo dell utente è una risorsa fornita dallo Storage service. Entrambi i servizi sono ad uso esclusivo dell utente, poiché lavorano con dati personali associati ad un particolare individuo. Il servizio Geospatial, invece, offre risorse che contengono dati condivisi, come la ricerca di mappe e di altre informazioni di tipo geografico. I dati in Live Services sono usati in vari modi, dato che Microsoft dispone di software differenti. Il primo obiettivo di Live Framework è quello di semplificare la creazione dei nuovi applicativi che impiegano i dati contenuti in Live Services. Microsoft Live Mesh può essere visto come un classico esempio di semplificazione di software di tipo Live ed, inoltre, sia le ISV che gli utenti finali sono liberi di creare software per conto terzi. Tutte queste applicazioni accedono ai dati attraverso il componente primario di Live Framework: il Live Operating Environment Accessing Data Il modo più semplice di accedere ai dati di Live Services è quello di accedere direttamente a Live Operating Environment. A tutte le risorse disponibili in Live Services, siano esse esclusive che di condivisione, sono associati degli URI che vengono impiegati per richiamarle. Per accedere alle informazioni, un applicativo può eseguire una richiesta di tipo REST o di tipo HTTP. Si può accedere anche alle risorse tramite AtomPub o con altri metodi basati sul protocollo HTTP. Fig Esempi di servizi disponibile nel Live Services Per garantire un approccio costante, e per meglio comprendere i propri componenti, Live Studio ed analisi del Cloud Computing Stumpo Elvio

74 Framework definisce un modello di risorsa. Questo modello specifica i tipi di dati e le relazioni permesse fra le istanze, insieme ad uno schema basato sugli URI. Le applicazioni possono creare anche tipi di dati personalizzati che memorizzano particolari generi di informazioni. Lo scopo fondamentale è quello di permettere alle applicazioni, comunemente eseguite, di navigare tra i dati di Live Services mentre per gli applicativi di sviluppo vengono fornite caratteristiche di flessibilità e strutture idonee alla memorizzazione dei dati. Per creare un applicazione che acceda ai servizi Live, uno sviluppatore è libero di progettare il suo codice utilizzando una interfaccia di tipo HTTP. Per queste evenienze, Live Framework include nella sua offerta di servizi Live Framework Toolkits. Queste librerie offrono un approccio più semplice alla progettazione degli applicativi che accedono ai servizi Live attraverso i Live Framework. Microsoft offre attualmente dei toolkit di.net Framework, Silver light, e Java Script, e presto altri software verranno inseriti nella famiglia Microsoft Live. Come tutti i componenti della piattaforma di servizi Azure, anche il Live Framework è stato progettato per integrarsi con varie tecnologie, in altri termini con qualsiasi linguaggio e/o piattaforma Utilizzo delle Mesh Fin quando un applicazione possiede i giusti permessi, l accesso ai dati di Live Services è garantito con l unica condizione che si impieghi il Live Framework. Se una determinata applicazione viene eseguita su sistema che fa parte della mesh, il software potrà usufruire di opzioni aggiuntive. Ogni utente può avere la propria mesh contenente i sistemi operativi da questi di solito impiegati. Per esempio, un possibile fruitore può utilizzare Windows XP nel desktop del lavoro, MacOSX sul PC di casa, Windows Vista in un laptop, e Windows Mobile sul proprio telefono. Tutti questi sistemi operativi differenti possono essere raggruppati in una mesh. Per creare una mesh, un utente deve identificarsi grazie al suo Live ID, al termine di tale operazione può accedere al Live Desktop tramite il suo browser. Una volta dentro Live Desktop utilizza un applicativo di tipo cloudbased per aggiungere il nuovo sistema alla sua rete mesh. Come viene mostrato anche in figura 3-27, l'utente specifica un sistema Fig Esempio di dispositivi che possono interagire con la rete Live Mesh operativo (e quindi un particolare dispositivo) da aggiungere, ad esempio il suo laptop (passo 1), ed il Live Desktop lo aggiungerà alla mesh. Per essere inserito a tutti gli effetti nella rete mesh, il sistema in questione deve compiere due operazioni fondamentali: scaricare Live Environment dalla nube ed istallarlo (passo 2). Studio ed analisi del Cloud Computing Stumpo Elvio

75 Live Operating Environment permette alle applicazioni di accedere a Live Services tramite HTTP. Quando si utilizza una mesh, questo componente esegue anche Fig Grafico esemplificatico inerente alle relazioni esistenti fra la Mesh ed i servizi altre mansioni: Live sincronizza, attraverso la nube, tutti i dati, presenti nel Live Services dell utente, in ogni sistema presente nella mesh. Sia gli utenti che le applicazioni possono indicare quali dati devono essere inclusi nella mesh, e Live Operating Environment si preoccupa di tenere le informazioni selezionate sincronizzate. Un applicazione di Live Mesh, ad esempio, permette agli utenti di creare specifiche cartelle che dovranno essere presenti nella rete mesh. Una volta conclusa tale operazione Live Operating Environment propagherà in background i cambiamenti dei dati delle cartelle verso tutti i sistemi presenti nella mesh. Analogamente a quanto detto prima, i dati di ogni utente, presenti in Live Services, come i contatti e le informazioni del profilo, possono essere sincronizzati mediante la mesh. La sincronizzazione di una mesh è multi - master, vale a dire, che non esiste un solo master in grado di aggiornare i dati. In questo modo ogni utente può cambiare le proprie informazioni su un qualsivoglia dispositivo. La tecnologia che compie tale operazione è FeedSync 48, un protocollo formalizzato da Microsoft disponibile per operazioni di tipo HTTP. Ogni qualvolta sia possibile, i dati sono sincronizzati tra i sistemi collegati alla rete. Il metodo, non il contenuto, utilizzato per la sincronizzazione dei dati cloud da Live Operating Environment non è modificabile. Le istanze di tipo cloud-based possono connettersi direttamente a tutti i sistemi della rete mesh; così si ottiene la sincronizzazione tra le parti interessate (applicazione - gruppo di sistemi mesh). Lanciando un applicativo su un sistema di tipo mesh-enable si può accedere ai dati cloud facendo richieste HTTP a Live Operating Environment. Si può accedere anche alla copia locale (anche la copia locale fa parte della rete mesh) che contiene tutti i dati di Live Services. Se 48 FeedSync è stato creato dopo che i feed RSS e Atom sono esplosi sul web, e sfruttando la loro innata semplicità si potrebbe consentire la creazione di un "bus dati decentrato" tra i siti web del mondo. Proprio come RSS e Atom, FeedSync può essere utilizzato per la sincronizzazione con qualsiasi dispositivo o piattaforma. Studio ed analisi del Cloud Computing Stumpo Elvio

76 per qualche motivo l interazione con l'istanza remota di Live Operating Environment non è possibile (ad esempio la macchina su cui si sta lavorando è momentaneamente off-line), l applicazione può inviare le proprie richieste di tipo HTTP direttamente all istanza locale. Ad eccezione degli URI (che naturalmente cambiano se si lavora on-line o off-line), le richieste sono esattamente identiche sia in modalità locale che in modalità cloud. Questa simmetria permette all applicativo di lavorare nello stesso modo con dati locali e con dati conservati nella nube. Se un applicativo è eseguito su un desktop o su dispositivi che sono momentaneamente disconnessi, la copia locale si comporta come una cache dell'ultimo stato conosciuto dei dati della nube. Nel momento in cui il dispositivo ritorna on-line, l applicazione si riconnette direttamente ai dati della nube (cambia gli URI usando quelli adeguati alla connessione cloud) ed attende che la copia locale aggiorni i dati della nube tramite la sincronizzazione di Live Operating Environment. I sistemi che non interagiscono con Live Operating Environment possono far parte anch essi della rete mesh, ma con molte limitazioni. Dato che il Live Desktop è accessibile utilizzando un semplice browser, un utente che utilizza, ad esempio Linux, può creare una rete mesh vuota (nessun dispositivo connesso) utilizzando solamente componenti cloud anche con un sistema basato su UNIX. Gli applicativi di origine Linux possono gestire i dati della mesh nel momento in cui utilizzano un protocollo di connessione valido anche per i Live Services. Tale protocollo è ancora una volta HTTP. Un applicativo, inoltre, può implementare anche il protocollo FeedSync per sincronizzare i dati della nube con la copia locale Applicativi web mesh-enable Qualsiasi applicativo, basato su Windows o più semplicemente capace di accedere ai dati di Live Services non ha bisogno necessariamente di essere parte di una mesh. Uno sviluppatore, però, può anche liberamente scegliere di progettare un applicativo che funzioni Fig Rappresentazione di una possibile sequenze operativa di un applicazione web mesh-enable espressamente sistemi mesh. Un classico esempio di questo tipo di software sono le applicazioni web mesh-enable che possono essere distribuite ed utilizzate dallo stesso Live Framework. Un applicazione web mesh-enable può essere disponibile attraverso il catalogo delle applicazioni di Microsoft presente nella nube. Un utente può accedere a questo catalogo per su Studio ed analisi del Cloud Computing Stumpo Elvio

77 scoprire le applicazioni mesh-enable disponibili (passo 1). Una volta scelta l applicazione, l'utente la può installare (passo 2). Inizialmente la copia dell applicativo viene memorizzata nel corrispondente Live Services. Finita tale operazione, si effettuerà la sincronizzazione software con i desktop e i dispositivi dell'utente, operazione analoga a quando si sincronizzano i dati della mesh (passo 3). L applicazione ora è disponibile anche in copia locale e può essere gestita in remoto su qualsiasi sistema apparente alla mesh dell utente (passo 4). Un applicazione web mesh-enable deve essere progettata usando tecnologia multipiattaforma; ne sono un esempio Microsoft Silver light, DHTML, o Adobe Flash. Queste tecnologie sono supportate su tutti i sistemi operativi che possono eseguire una Live Framework: Windows Vista/XP, Macintosh OS X, e Windows Mobile 6. Di conseguenza, qualsiasi applicativo web mesh-enable può funzionare su qualsiasi sistema nella mesh. Considerato che il Live Operating Environment mantiene tutti i dati della mesh sincronizzati, una sua applicazione web (mesh-enable) può funzionare indipendentemente su qualsiasi sistema all'interno di una mesh, e può disporre degli stessi dati, reperibili in rete, a prescindere da dove venga eseguita. Questo sistema dà un nuovo ed interessante significato alla nozione di write once, run anywhere (scrivi una volta, esegui dovunque). L utente può scegliere, seguendo la filosofia Live, a quali dati possono accedere i software cloud. Questo vale anche per le applicazioni web mesh-enable. Inoltre, come per Silver light, DHTML, le applicazioni Flash, una web mesh-enable viene eseguita in una sandbox 49 sicura. A meno di specifici permessi dell utente, queste applicazioni non possono accedere direttamente al disco locale o ai dati di altri applicativi web mesh-enable. Un utente, comunque, è libero di condividere questo genere di applicativi con una mesh di un amico. Per esempio, un utente potrebbe autorizzare un applicazione web mesh-enable a spedire inviti a tutti i propri contatti. Una volta che l utente autorizzi l accesso ai suoi contatti, l applicativo automaticamente integra i nuovi dati nella mesh dell utente. Microsoft offre templates di progetto per il Visual Studio 2008 per aiutare gli sviluppatori a creare applicazioni web mesh-enable. Per facilitare l aggiornamento di questo genere di applicazioni, uno sviluppatore può caricare una versione nuova dal catalogo applicativo, poi il Live Framework automaticamente si preoccuperà di aggiornare l applicazione nella mesh di ogni utente che dispone della versione precedente. 49 Sandbox: in ambito informatico identifica un ambiente di test, di prova, di staging, spesso slegato dal normale flusso di ambienti predisposti per lo sviluppo ed il test delle applicazioni. In ambito informatico una nuova applicazione o una modifica ad una applicazione esistente viene da prima implementata nell'ambiente di sviluppo (development environment), poi testata in un ambiente apposito (test environment), infine verificato il corretto funzionamento in un ambiente di qualità (quality environment) in cui siano presenti dati copiati recentemente da un ambiente produttivo (live environment o productive environment), per poi essere trasferita definitivamente nell'ambiente produttivo. Studio ed analisi del Cloud Computing Stumpo Elvio

78 La Live Framework è un genere completamente nuovo di piattaforma applicativa. Molti aspetti dell'ambiente, come l accesso ai dati Live Services e la particolare attenzione per i desktop e per i dispositivi, chiarisce indiscutibilmente che l obiettivo principale di questa tecnologia è di fornire un valido supporto per i consumatori. 3.7 Costi I costi 50 si basano sul consumo, come nella tradizione delle architetture cloud. Windows Azure Computing: 0,12 $ all'ora Storage: 0,13 $ a Gigabyte Storage transaction: 0,10 $ per 10K Banda: 0,10 $ in entrata e 0,15 $ in uscita per ogni Gb SQL Azure Web Edition Database, compreso fino a 1 Giga di database relazionale: 9,99 $ Business Edition Database, con 10 Gb di database relazionale: 99,99 $ Banda: 0,10 $ in entrata e 0,15 $ in uscita per ogni Gb.NET Services Messaggi: 0,15 $ per messaggi fino a 100 K Banda: 0,10 $ in entrata e 0,15 $ in uscita per ogni Gb Oltre alle offerte promozionali destinate ai partners Microsoft è stata già creata un ulteriore offerta finalizzata ad accelerare lo sviluppo su cloud: Core. Questa soluzione comprende Windows Azure computing e storage, oltre ai servizi di.net Services. Estende invece è l'offerta che comprende Windows Azure computing e storage, il database di SQL Azure ed i servizi di.net Services. 50 I Costi si riferiscono ai prodotti che verranno resi disponibili dopo la prossima Professional Developers Conference (PDC2009). Studio ed analisi del Cloud Computing Stumpo Elvio

79 Capitolo 4 Analisi a confronto Capitolo 4 Analisi a confronto In questo capitolo si effettueranno dei paragoni fra le varie soluzioni cloud precedentemente analizzate. Cloud GoGrid Blue GEA EC2 Azure Sistemi Operativi Virtualizzati (SOV) Linux e Windows Linux no Linux e Windows no Programmi aggiuntivi presenti sulle vitual machine Java, PHP, Python, Perl, Ruby, C#, bash prevalentemente solo programmi IBM rigidi, solo GQL e Python Oracle 11g, Apache HTTP, Java, Microsoft SQL Server,ecc.NET Services, SQL Services, Live Services, ecc Scalabilità rete limitata ma multi-core variabile e multi-core rigida e mono-core dinamica e multi-core dinamica e multi-core Open Source sofware Hardware configurabile Fig.4-1. Tabella riassuntiva delle principali caratteristiche delle realtà cloud analizzate no no si no no Uno dei termini di paragone sarà Windows Azure di Microsoft per poterne dedurre i punti di forza e i difetti rispetto alle altre tecnologie. La tabella riportata riassume brevemente le caratteristiche fondamentali di ogni realtà cloud. Gli elementi che caratterizzano la tabella e che fungono da indicatori sono: SOV (sistemi operativi virtualizzati): Sistema di simulazione di sistemi operativi, precaricati nelle VM. Programmi aggiuntivi: sono i programmi che sono compatibili e/o reperibili nelle rete cloud in esame. Scalabilità rete: valuta la capacità della rete di mutare la propria grandezza in base alle esigenze di computazione e alla possibilità di utilizzare piattaforme come, ad esempio, la virtualizzazione di sistemi di multiprocessore. Open source software: indica la possibilità che il codice sorgente degli applicativi cloud possa essere modificato da parte degli utilizzatori della rete a nube selezionata. Hardware configurabile: indicatore pressoché identico al precedente che monitorizza l elasticità della rete. Tale concetto indica la possibilità offerta all utilizzatore della rete di modificare la stessa in base a criteri del tutto personali. si si no si si 4.1-GoGrid vs Azure Consultando le informazioni contenute nella tabella raffrontiamo GoGrid con Azure. GoGrid fornisce indicazioni ben precise sulla tipologia delle proprie VM impiegate: a partire dalle loro caratteristiche tecniche fino ad arrivare agli ambienti di sviluppo supportati (Linux Windows etc.). Azure, invece, non fornisce alcuna informazione tecnica sulle VM impiegate. Studio ed analisi del Cloud Computing Stumpo Elvio

80 Capitolo 4 Analisi a confronto GoGrid, attualmente, fornisce la compatibilità solo con un numero limitato di programmi, mentre Azure con i servizi Live Service e.net può disporre di un maggior numero di applicativi con essa compatibili. La rete Go ha un elasticità di rete molto limitata, ma supporta l architettura multi core fino ad un massimo di 6 processori, mentre, in questo ambito, Azure non ha nessun limite sul numero massimo di cpu da impiegare per il multi core ed è stata implementata con forti caratteristiche di elasticità. Limitatamente alle sue possibilità GoGrid permette all utente la gestione della propria rete. Tale caratteristica è del tutto analoga ad Azure, ed in entrambe le realtà cloud il codice del software non è modificabile dall utente ordinario. GoGrid fornisce un servizio d assistenza del tutto invidiabile: ad ogni suo cliente viene associato un determinato team di tecnici e specialisti del cloud che si occuperà sempre del medesimo cliente. Questo sodalizio porta benefici ad entrambi i partecipanti. Per il cliente vi è il vantaggio di relazionarsi sempre con le medesime persone che, conoscendo bene il cliente, potranno fornire indicazioni più specifiche. Per il servizio d assistenza, invece, vi è il vantaggio che colloquiando sempre con il medesimo cliente sono in grado di estrapolare informazioni importanti sia sul cliente che sulla sua rete. L architettura di servizi Azure, al momento della stesura di questa tesi, non è ancora in commercio, e conseguentemente il servizio d assistenza è formato da una classica FAQ in cui gli utenti Azure sono aiutati da altri utenti o da personale tecnico. Un supporto alla clientela stile GoGrid non è attuabile da Microsoft poiché il suo bacino d utenza previsto risulterà molto maggiore e diffuso a livello mondiale. In questa analisi a confronto la soluzione di casa Microsoft risulta essere la migliore scelta nel campo dei servizi forniti alla clientela, anche se la qualità dei servizi stessi a volte risulta inferiore a quella di GoGrid, che essendo una piccola realtà nel panorama cloud tenta di essere competitiva fornendo maggiore qualità a fronte di un numero inferiore di servizi forniti. 4.2-Blue vs Azure Raffrontiamo ora Azure con un altra realtà cloud: Blue dell IBM. Blue virtualizza sola una tipologia di ambiente di sviluppo, LINUX, mentre Azure, come già accennato, non supporta nessun sistema operativo virtuale. Blue ammette al suo interno solo un numero limitato di programmi estremamente specifici: impiega, infatti, prevalentemente solo quelli forniti dalla medesima azienda (IBM). Azure, sotto questo aspetto, risulta essere meno rigida. Studio ed analisi del Cloud Computing Stumpo Elvio

81 Capitolo 4 Analisi a confronto IBM garantisce che Blue Cloud supporta un architettura variabile e multi-core, ma come nel caso di Azure, non fornisce caratteristiche tecniche ben precise. Inoltre anche utilizzando hardware specifico (tutto di produzione IBM) potrebbe avere dei problemi ad integrarsi con reti di tipo non-ibm; ecco perché nella tabella alla voce scalabilità di rete è presente il termine variabile e non dinamica. Entrambe le realtà cloud non impiegano software open source e, come ogni vera architettura a nube impone, la gestione della rete (in ambito hardware, anche se sarebbe più opportuno parlare di virtuale, visto che si lavora con le VM) è completamente gestibile dall utente. La grande limitazione di Blue è la sua fortissima dipendenza, in ogni suo aspetto, dai prodotti IBM. Questo grande deficit non ha impedito la creazione di una stretta collaborazione a livello mondiale tra IBM e varie istituzioni. Se Azure raggiungerà tutti i suoi obiettivi potrà essere una valida alternativa a Blue disponendo di più servizi e, in generale, di una minore rigidità sotto ogni aspetto. 4.3-GEA vs Azure Passiamo ora a confrontare la soluzione cloud di Google con quella di casa Microsoft. Entrambe non supportano nessuna Virtualizzazione di sistema operativo. GEA accetta solo programmi creati in codice Python mentre Azure risulta essere più flessibile diversificando la sua offerta. Un grossa limitazione di GEA è una incredibile rigidità della rete; attualmente non è implementata neanche l architettura multi-core. Al contrario, Azure, anche in questo ambito, risulta fornire servizi migliori. Il grande punto di forza di GEA è nell open source. Solo questa realtà cloud, tra quelle analizzate, fornisce la possibilità di avere accesso al codice sorgente per poterlo modificare. Azure dà la possibilità di creare un nuovo software cloud tramite il Visual Studio, ma non permette ai suoi utenti l accesso diretto ai programmi in esecuzione. GEA ha basato tutta le sue risorse per creare un servizio stabile e completamente monitorizzabile, a discapito della scalabilità della rete stessa. Google, comunque, è fermamente decisa a potenziare il suo prodotto (ad esempio aggiungere il multi core) per poter competere con le altre architetture cloud attualmente disponibili. Studio ed analisi del Cloud Computing Stumpo Elvio

82 Capitolo 4 Analisi a confronto 4.4-EC2-vs Azure EC2 attualmente è la soluzione cloud migliore che si possa trovare in commercio sia per l offerta, che per la qualità dei servizi. EC2 virtualizza ben due ambienti di sviluppo, al contrario di Azure. EC2 fornisce un ampia scelta di software di terze parti e, non essendo proprietario di tali programmi, non è in possesso del codice sorgente; quindi è impossibilitato ad attuare la politica dell open source. Analogamente il cloud di casa Microsoft risente dei medesimi effetti anche se generati da diverse cause. Per quanto riguarda la struttura della rete cloud, EC2 dispone di varie opzioni operative che possono essere modificate in qualsiasi istante. I tempi tecnici necessari alla realizzazione di tali modifiche sono molto limitati, tanto da poter parlare di sistema cloud elastico, da cui deriva il nome della rete cloud di Amazon. L elasticità è anche nella possibilità di utilizzare sistemi multi-core e/o architetture sia a 32 che a 64 bit. Azure, nonostante non fornisca esplicitamente nessuna informazione sulla tipologia delle sue macchine virtuali, ha lavorato per consentire alla sua rete di essere il più possibile adattabile a continui cambiamenti. Se si considera che attualmente Amazon, per sua stessa ammissione, dichiara di impiegare EC2 per monitorare e/o gestire tutte le sue transizioni di e-commerce su scala mondiale, si può facilmente dedurne il suo reale valore. Inoltre, nonostante la mole di lavoro che EC2 è costretta a monitorare quasi in real-time, è ancora in grado di gestire e generare risorse da offrire ai suoi clienti che richiedano una rete cloud. Si può, quindi, dedurre che qualsiasi società presente e futura che intenda inserirsi nel settore del cloud computing deve vedere nel cloud di Amazon un grosso ostacolo alla diffusione del proprio prodotto. Microsoft Azure, essendo a conoscenza di tale realtà, ha deciso di creare la sua soluzione cloud investendo molto sia in termini economici che in risorse umane per poter essere in grado di tenere il passo di EC2. Studio ed analisi del Cloud Computing Stumpo Elvio

83 Capitolo 5 Azure Sharing File Capitolo 5 Azure Sharing File Per ottenere una completa analisi delle potenzialità di Microsoft Azure è necessario testare la piattaforma dei servizi cloud mediante un esempio applicativo. Lo scopo di tale applicativo non è quello di fornire un eventuale nuovo servizio, ma di verificare il corretto funzionamento del software di sviluppo mediante l applicazione dell iter operativo che permette di creare applicazione cloud. Microsoft, infatti, ha dichiarato che i suoi clienti cloud non dovranno necessariamente essere dei programmatori e/o sviluppatori ma soprattutto semplici utenti che saranno in grado di ottenere il proprio programma mediante l accesso ad un database di esempi già precompilati. Tali programmi potranno essere personalizzati mediante l uso di semplici form che ridurranno l intero processo di configurazione ad un numero limitato di click. Visto che Azure fornisce differenti servizi (Compute Services, Storage Services, etc), un generico sviluppatore deve innanzitutto eseguire una scelta settoriale teorica. Nel caso specifico si è voluto focalizzare l attenzione sul servizio di storage perché con la sua particolare organizzazione interna ha destato maggior interesse. 5.1-Installazione software di sviluppo Come già accennato in precedenza un qualsiasi sviluppatore di applicativi Azure deve impiegare necessariamente alcuni programmi specifici. Tali software sono: Microsoft Visual Studio 2008 (con service pack 1) o superiori: permette la gestione dei progetti e di tutti i file ad essi connessi. VSCloudService: la sua funzione principale è quella di integrarsi completamente con il Visual Studio 2008 consentendogli la generazione e/o la gestione di progetti di tipo cloud. IIS 51 :è un server virtuale integrato nei sistemi Windows. La sua funzione è quella di permettere una corretta visualizzazione degli output durante l operazione di Build per testare, in locale, la correttezza del codice. Altri plug-in: sono dei programmi specifici che devono essere installati per fornire al proprio software specifiche caratteristiche (ad esempio sono necessari diversi plug-in per poter utilizzare le potenzialità di Silver light nel proprio programma). 51 Nel caso specifico il sistema operativo impiegato è Microsoft Windows Vista Ultimate a 32 bit che supporta la versione 7 di IIS indicata anche con la dicitura IIS7. L IIS7, inoltre, diversamente dagli altri plug-in è un servizio già integrato in Windows Vista ma normalmente non è attivo. Se l attivazione è eseguita con successo eseguendo un qualsiasi browser e digitando localhost o comparirà la homepage (in locale) dell IIS compatibile con il sistema operativo in uso. Studio ed analisi del Cloud Computing Stumpo Elvio

84 Capitolo 5 Azure Sharing File Oltre al software, per poter utilizzare completamente i servizi cloud di Microsoft è necessario anche disporre di un account valido sul portale Azure 52. Durante la realizzazione del sorgente alcuni software aggiuntivi (plug-in) sono stati sostituiti con le loro versioni aggiornate che, spesso, non garantivano la retrocompatibilità con le versione precedenti. Questa caratteristica è una delle tante motivazioni che ha spinto, attualmente, Microsoft a destinare questo genere di software ai soli sviluppatori. 5.2-Ricerca e sviluppo Come già indicato nel Capitolo 3, nello storage cloud di Microsoft è stato introdotto un nuovo concetto di memorizzazione di tipo gerarchico denominato blob. Con la realizzazione dell applicativo si sono volute testare le reali funzionalità di questo particolare servizio offerto dallo Storage Services di Azure. Come ogni architettura cloud impone, anche Microsoft mette a disposizione degli esempi di applicativi cloud su cui basare le proprie applicazioni. Questa libera circolazione di codice ha un duplice vantaggio: fornisce un punto di riferimento per i neo sviluppatori ed inoltre la libera fruizione di tale software tra gli addetti ai lavori risulta essere un solidissimo test sull efficienza del codice stesso. L applicativo creato in questa tesi sarà indicato con la sigla ASF (Azure Sharing File). La sua caratteristica fondamentale è quella di fornire gli strumenti per un corretto impiego di un blob. Oltre ad ASF, si è allocato uno spazio di memorizzazione sui server Microsoft dove effettivamente sono salvati i file nel web. Per ottenere questo servizio e per utilizzarne altri è stato necessario l impiego dell account su Azure. La registrazione consiste essenzialmente nel fornire a Microsoft il proprio LIVE ID 53 e, dopo un breve lasso di tempo, si ottiene un token per lo sviluppo cloud. Tramite questo token l utente è in grado di attivare un numero ben preciso di servizi e/o di progetti. Nel caso specifico il token è quello classico per gli sviluppatori: numero esiguo di progetti, ma di utilizzo illimitato e senza nessun costo (2 Storage Account, 1 Hosted Services). 52 L account su Azure è fondamentale per compiere qualsiasi operazione in remoto (pubblicazione sorgente, creazione strutture dati, configurazione service bus e/o access control etc.). 53 Di solito il Live ID è riconducibile a un qualsiasi utente che abbia richiesto un qualsiasi servizio di Microsoft o di un dei suoi patners, di solito si tratta di account di posta elettronica. Con questo particolare numero identificativo Microsoft è in grado di gestire i propri utenti e i servizi ad essi associati. Studio ed analisi del Cloud Computing Stumpo Elvio

85 Capitolo 5 Azure Sharing File 5.3-Creazione di ASF Utilizzando come guida gli esempi di codice messi a disposizione dalla comunità cloud di Microsoft si è verificato che la gestione di una blob non richiede un elevata potenza di calcolo quindi non sono necessari i servizi forniti dal Compute Service. In termini pratici questa particolare condizione sta ad indicare che non sono fondamentali i worker role ma solo i web role. Il passo successivo è stato quello di suddividere ASF in due componenti distinti essenzialmente caratterizzati da diversi settori di competenza: L amministratore o Admin Gli utenti o User. Questa differenziazione comporta che ogni settore abbia almeno una pagina web 54 (.aspx) a cui deve essere associato un endpoint, sia se l applicativo venga eseguito in locale che in remoto. In tutti gli applicativi cloud basati su C# e quindi anche per ASF, ad ogni pagina.aspx sono associati due differenti file omonimi ma con differenti funzionalità ed estensioni:.cs e.designer.cs. Il file. CS racchiude in sè tutte le funzioni e/o procedure su cui l.aspx si basa, mentre nel file.designer.cs. sono contenute le definizioni degli elementi in comune tra.aspx e il.cs. Nella pagina dell Admin oltre all implementazione delle necessarie operazioni per consentire un corretto accesso al blob, sono state implementate anche le procedure per: la creazione e/o la cancellazione di un containers, l inserimento e/o l eliminazione di un determinato blob in uno specifico contenitore 55. Nelle pagine riservate agli utenti, invece, sono state implementate solo le funzioni che permettono una corretta visione del contenuto del blob. Al termine di tale processo di sviluppo il progetto ASF eseguito in locale permette effettivamente di interagire con la struttura blob allocata sui data center di Microsoft. 54 I progetti del cloud computing di Microsoft sono formati sempre da pagine web dinamiche basate su ASP.NET indipendentemente dal tipo di compilatore impiegato (Visual Basic o C#). 55 Microsoft ha deciso di memorizzare nel web le proprie informazioni in maniera molto simile a quella impiegata in Windows. Per chiarire il precedente concetto basti pensare ai containers come a delle speciali cartelle disponibili solo in rete in cui vengono inseriti dei blob vale a dire degli speciali contenitori progettati appositamente per il web che racchiudono al loro interno un normalissimo file. Studio ed analisi del Cloud Computing Stumpo Elvio

86 Capitolo 5 Azure Sharing File 5.4-Pubblicazione ASF Con il termine pubblicazione si indica una serie di operazioni che permettono al codice di essere importato in rete dove sarà raggiungibile da chiunque conosca il suo corrispondente endpoint. Per rendere possibile tale operazione, un progetto cloud che ha superato le verifiche locali deve subire un ulteriore compilazione che genererà dei particolari file aggiuntivi che dovranno essere inseriti su richiesta nel form di pubblicazione di Azure. Fig L immagine sopra riportata mostra una fase essenziale inerente al processo di pubblicazione. Sulla destra (Staging) è implementato uno speciale processo di prova, una specie di debug in rete che una volta terminato fornisce un endpoint temporaneo e di tipo alfanumerico da impiegare per verificare il corretto funzionamento del codice. Superata tale fase, si passa nella sottosezione di sinistra (Production) che ha un comportamento del tutto analogo allo Staging, ma come risultato finale si otterrà un endpoint reale e definitivo. L endpoint generato da tale procedura sarà l effettivo URL dell applicazione che permetterà l accesso al codice anche tramite il web. Questo form, in base al token posseduto dall account, consente un numero ben preciso di progetti; alcuni di questi vengono impiegati per generare strutture dati (Storage Account), altri invece sono stati realizzati per fornire un endpoint globale alle applicazioni del proprietario dell account (Hosted Services). Prima della realizzazione del progetto ASF si è voluta testare l effettiva funzionalità del processo di pubblicazione. Il test consisteva essenzialmente nella creazione di una semplice pagina web accessibile tramite web che conteneva al suo interno una semplice stringa di testo. Dopo aver compreso il corretto funzionamento della procedura di pubblicazione, si è ottenuto il risultato sperato. La situazione, però, è completamente cambiata quando si è provato a pubblicare ASF. Nonostante si sia seguito il medesimo iter operativo, il risultato è Studio ed analisi del Cloud Computing Stumpo Elvio

87 Capitolo 5 Azure Sharing File stato molto deludente 56. L impiego di metodi di pubblicazione alternativi hanno ottenuto il medesimo risultato. Fin quando l operato del compilatore CSPack 57 non sarà perfettamente compatibile con le specifiche imposte dal compilatore presente in rete, il processo di pubblicazione risulta essere improponibile. È auspicabile che Microsoft, in qualche modo, rimedi al più presto a tale mancanza in modo da fornire ai suoi utenti i mezzi per rendere pubbliche le proprie applicazioni. 5.5-Resoconto operativo Si sono verificati non pochi problemi durante la realizzazione del programma a causa della non completa efficienza sia del software di sviluppo che di alcuni servizi web, entrambi progettati da Microsoft Rendimento software (sviluppo applicativo in ambito locale) Dopo aver installato tutti i software necessari alla realizzazione dell applicazione, operazione complessa e laboriosa, sono emerse alcune grosse limitazioni. Gli esempi di codice forniti dalla comunità cloud di Microsoft sono spesso pieni di errori, mancanze e varie altre piccole imperfezioni che costringono lo sviluppatore che vuole compilarli ad una scrupolosa analisi sulla correttezza del codice operazione non sempre semplice, ma sistematicamente dispendiosa in termini di tempo. Quando si passa alla realizzazione del proprio codice si riscontrano altre imperfezioni. La prima, in ordine cronologico è la limitazione imposta sulla grandezza dei file caricabili in un determinato blob. Tale limitazione, pari attualmente a 4MB, consente il caricamento solo di un numero limitato di file, come documenti di testo immagini e alcuni file multimediali di breve durata. Oltre ai limiti dimensionali, vi sono anche dei limiti sulla metodologia di visualizzazione dei file. Non è possibile, attualmente, per lo sviluppatore, apportare modifiche nella parte terminale dell endpoint. In altre parole, la visualizzazione dei file dentro il browser è completamente automatica e non modificabile. 56 Per verificare se il problema provenisse dal codice di ASF si è tentata la pubblicazione a passi successivi. Tale criterio consiste nella pubblicazione iterativa di una versione ad ogni passo sempre più limitata di ASF per individuare la parte di codice che viene compilata erroneamente da CSPack. Tale approccio (eseguito sia in modalità top-down che in modalità bottom-up) non ha ottenuto i risultati sperati. Successivamente si è riprovato a ripubblicare il codice che precedentemente era stato pubblicato correttamente, ma stranamente si è ottenuto il medesimo fallimento riscontrato con ASF. Questo n-esimo fallimento ha però messo in chiaro un aspetto importante : il problema della mancata pubblicazione non è imputabile al codice, ma ad una incongruenza tra il compilatore locale (CSPack) e quello presente in rete. 57 CSPack: Compilatore locale nel software VSCloudService responsabile della generazione dei file di configurazione necessari alla pubblicazione di qualsiasi applicativo. Studio ed analisi del Cloud Computing Stumpo Elvio

88 Capitolo 5 Azure Sharing File Rendimento dei servizi (sviluppo applicativo in ambito remoto) Un applicativo cloud, per essere definito tale, deve poter sfruttare uno o più servizi disponibili sul web. Attualmente vi sono però solo alcuni servizi che si integrano con ASF. Ad esempio, il servizio che permette all ASF di poter modificare il contenuto del blob memorizzato nei server di Microsoft risulta essere sempre funzionante ed efficiente anche se un po lento, ma tale caratteristica è imputabile alla grande distanza che intercorre tra la macchina in cui viene eseguita ASF ed i server Microsoft. Nel codice di ASF è stato implementata anche la possibilità di creare dei container ad accesso limitato. Questi elementi, basandosi sul servizio Access Control Service (ACS), permettono la visione dei file solo ad utenti autorizzati. Gli utenti autorizzati devono essere ritenuti tali dopo essersi identificati tramite un server di autenticazione sempre gestito da ACS. L unico inconveniente è che tale servizio non è attualmente disponibile per le applicazioni cloud a causa di upgrade e/o aggiornamenti del software lato server. Allo stato attuale, senza poter configurare un grammatica degli accessi, funzione cardine di ACS, ogni procedura di sicurezza risulta essere praticamente inutile. Tale momentanea mancanza ha delle conseguenze notevoli sul codice ASF : Senza ACS i container privati sono off-limits per chiunque, paradossalmente anche per l Admin che ha le competenze e la possibilità di crearli e/o cancellarli. Tale condizione anche se paradossale dimostra il corretto funzionamento di questa tipologia di oggetti: senza una valida autenticazione i container bloccano l accesso a chiunque. Non essendo disponibile ACS e la sua grammatica, è pressoché inutile ogni tipo di accesso limitato tramite procedura di log-in. Non potendo associare procedure di identificazione a determinate pagine, come ad esempio alla pagina dell Admin, anche gli utenti non autorizzati sono in grado di accedere a pagine che normalmente sarebbero loro inaccessibili. Il temporaneo mancato funzionamento di ACS risulta essere un vero spreco di risorse: basti pensare che gli applicativi Azure possono impiegare Geneva Framework 58 per la propria sicurezza. 58 Geneva Framework appartiene a.net Framework. Il suo scopo principale è essenzialmente l implementazione delle procedure di sicurezza, come l identificazione tramite claims nelle applicazioni degli utenti. Geneva può essere impiegato sia in applicazione di tipo web che in applicativi web service, l unica condizione è che entrambi supportino la versione 3.5 di.net Framework. Geneva Framework è solo un dei tanti servizi offerti da Geneva di Microsoft Esso, unitamente a Geneva Server, Windows CardSpace Geneva costituisce il cuore della nuova piattaforma di servizi di autenticazione tramite claims utilizzata da Microsoft in tutti i suoi applicativi. Studio ed analisi del Cloud Computing Stumpo Elvio

89 Capitolo 5 Azure Sharing File Il mancato impiego di ACS e della procedura di pubblicazione risultano essere due enormi problemi che Microsoft nel più breve tempo possibile deve risolvere per poter dimostrare le reali qualità di Azure. Studio ed analisi del Cloud Computing Stumpo Elvio

90 Conclusione Conclusione Il word wide web è proiettato verso un ulteriore sviluppo tecnologico. I grandi colossi del IT ne sono consapevoli e per poter competere in questa imminente rivoluzione informatica hanno investito milioni di dollari in mezzi e risorse per essere preparati a tale evento. Tale rivoluzione si può riassumere con un unico concetto base: Il Cloud Computing (o calcolo a nube). Il calcolo a nube consiste essenzialmente in un metodo innovativo, diverso dagli attuali, per recuperare, assegnare e gestire le innumerevoli risorse presenti nell intero web. I primi esempi di reti cloud sono imputabili a IBM e ad Amazon; entrambe spinte a cercare nuove soluzioni da un incessante bisogno di risorse da impiegare. Nel caso di IBM la nascita della propria rete cloud è imputabile alla necessità del suo personale tecnico di avere a disposizione risorse adeguate per testare le applicazioni in fase di istallazione. Le installazioni, specie se ancora in allestimento, non sono sempre in grado di fornire le risorse adatte a tutte le esigenze per le quali sono state progettate e realizzate. In tali condizioni, il personale tecnico di IBM ha creato e poi utilizzato una complessa rete di calcolatori per colmare l inadeguatezza delle risorse limitate. Il processo di perfezionamento di tale rete è coinciso con la creazione delle rete cloud di IBM. Per quanto riguarda Amazon la motivazione che ha spinto questa azienda a perfezionare ed utilizzare una propria rete cloud è stata la necessità di creare un'unica struttura in grado di gestire tutte le transizioni mondiali del proprio e-commerce in real-time. In entrambi i casi, le energie spese per la realizzazione di tale progetto hanno reso possibile la realizzazione di un servizio che fornisce enormi benefici sia all azienda promotrice del cloud che ai propri clienti, i quali vengono proiettati verso il futuro dello sviluppo applicativo. La necessità di far propri tali benefici è stato l elemento scatenante che ha convinto Microsoft a competere attivamente nel software cloud confrontandosi con realtà come Blue di IBM, GAE di Google e di EC2 di Amazon. L impiego sistematico di reti cloud può limitare drasticamente il processo di istallazione di software che non deve essere necessariamente gestito sul computer dell'utente, ma può essere tranquillamente reperito ed impiegato in rete. Lo scopo di questa tesi è stato quello di studiare Azure, l emergente realtà cloud di Microsoft, per testarne il suo effettivo rendimento. Per rendere l analisi completa si è, inoltre, tentato di creare un applicativo adatto ad Azure. Tale applicativo è stato realizzato per poter acquisire dimestichezza nella pratica della creazione di codice cloud specifico per Azure, permettendo anche un analisi tecnica di tipo operativo, oltre a quella teorica. Studio ed analisi del Cloud Computing Stumpo Elvio

91 Conclusione In questo modo si è ottenuta una visione completa ed esaustiva delle caratteristiche del prodotto Microsoft e, ultimata anche la realizzazione dell applicativo di prova, si è passati alla formulazione di un parere sull intera esperienza. Attualmente la soluzione cloud proposta in teoria da Microsoft è molto interessante, ma non risulta essere la migliore disponibile sul mercato mondiale. Esistono, infatti, realtà cloud, come ad esempio EC2, che ad oggi sono molto più efficienti di Azure. Questo perché EC2 ha già superato brillantemente la fase di testing ed è già presente con una versione ufficiale stabile ed in continuo sviluppo. Durante la stesura di questa tesi, inoltre, si è riscontrata un'altra grossa lacuna di Azure: la carenza di fonti di informazioni competenti, che ha reso difficile l operazione di documentazione sia di tipo teorico che di carattere pratico. Questa situazione, oltre a rendere complessa la ricerca di indicazioni teoriche e/o di esempi di codice da analizzare, ha creato una barriera verso chiunque fosse interessato a documentarsi su questo genere di servizio. Va anche segnalato che, nonostante gli enormi sforzi sia economici, che di personale sostenuti per realizzare Azure, i servizi offerti da quest ultima non sono stati sempre efficienti o per lo meno non adeguati ad un azienda come Microsoft. Ci sono stati innumerevoli sospensioni dei vari servizi on-line che bloccavano ed a volte rendevano inservibili i progetti creati dagli utenti. Tali disagi non hanno consentito, ad esempio, all applicativo ASF di usufruire del servizio denominato Access Control Services che, rendendo inutile ogni tipo di procedura di autentificazione, oltre a causare una completa mancanza di sicurezza, ha reso inutilizzabili dei particolari container ad accesso limitato (container privato). Un altro disagio evidente è la non molto soddisfacente diffusione del software di sviluppo. Esso, infatti, è molto frammentario e non sempre si è nella condizione ottimale per individuare quale elemento installare sulla propria macchina. A volte si sono riscontrate delle evidenti incompatibilità tra versioni differenti del medesimo software creando non pochi disagi di tipo operativo. Nonostante la distribuzione del software sia frammentaria e poco documentata, Microsoft ha fornito una piccola raccolta di esempi applicativi che ogni sviluppatore di Azure prende sia come riferimento che come codice base su cui sviluppare la sua applicazione. In alcuni di questi esempi sono presenti dei software che sono in grado di analizzare gli elementi cloud istallati sulla macchina in uso e, nel caso in cui siano insufficienti per la determinata applicazione, creano dei link per l installazione diretta del software mancante. L unico grosso problema è che tali file sono pochi e disponibili solo per un numero limitato di esempi. Questi esempi pubblicati da Microsoft (come se fossero una specie di plug-in aggiuntivo) sono spesso anche ready-to-run, vale a dire che il codice è completo e funzionante e che per vederli in funzione basta compilarli senza errori. Questa mini raccolta di codici è una rappresentazione in scala di quello che Microsoft vorrebbe realizzare in un prossimo futuro: un database funzionale contenente sorgenti già pronti per essere utilizzati, che gli utenti devono solo scaricare e compilare. Studio ed analisi del Cloud Computing Stumpo Elvio

92 Conclusione Concretamente, però, la situazione è diversa: a parte il numero esiguo di applicativi funzionanti sopra citati, la comunità cloud di Microsoft si basa ancora sulla condivisione di codici spesso incompleti e poco efficienti. Va anche detto che per alcuni codici sono presenti anche dei file video di supporto che spiegano chiaramente il loro utilizzo, ma spesso sono inservibili in caso di ricerca della/e cause di un errore in compilazione. Per poter rendere efficiente tale software lo sviluppatore deve essere in grado di immaginare il corretto funzionamento del codice e di apportare le dovute correzioni. Questa operazione, specie se non si è pratici della programmazione.net, richiede molto più tempo di quello impiegato a programmare un codice ex novo. Per migliorare Azure e renderlo sempre più competitivo Microsoft deve essere in grado di fornire a chiunque ne faccia richiesta il codice di tipo ready-to-run. Così facendo lo sviluppatore potrà concentrarsi esclusivamente sul proprio codice, mentre l utente standard dovrà solo preoccuparsi di effettuare una compilazione corretta. Un altro piccolo accorgimento che invoglierebbe gli sviluppatori indecisi a optare per la soluzione cloud di Microsoft sarebbe quella di fare un po d ordine nel caos del plug-in aggiuntivi e creare una specie di cloud service pack dove, per quanto possibile, in maniera automatica, vengano istallati sequenzialmente tutti i software aggiuntivi necessari per ogni tipo di applicativo Azure. I disagi provenienti da un software inadeguato non sono stati riscontrati solo in fase di istallazione o di ricerca di esempi validi; nella fase di pubblicazione del codice, infatti, il compilatore ad esso dedicato non assolve correttamente al suo compito, tanto da rendere inservibile il software pubblicato in rete. Le varie alternative proposte per ovviare a tale deficit sono giunte al medesimo risultato. Allo stato attuale il codice prodotto per questa tesi risulta essere completamente funzionante in locale, eccezion fatta per i servizi che si basano in qualche modo su Access Control Services (log in, containers privati etc..). Gli attuali difetti ed imperfezioni riscontrati in Azure sono in parte giustificati dalla natura stessa del prodotto Microsoft: esso, infatti, è attualmente disponibile solo nella sua versione di prova che è stata diffusa per permettere agli sviluppatori di perfezionarla. Il codice ASF è stato realizzato solo per poter apprendere meglio il prodotto Microsoft. Questo però non significa che non può essere migliorato. Partendo dalle condizioni attuali di ASF, i possibili sviluppi futuri potrebbero essere, innanzitutto, l integrazione del servizio ACS con annessa la possibilità di gestione delle grammatiche di sicurezza. Sempre in ambito di sicurezza si potrebbero inserire procedure di log in tramite LIVE ID o tramite claims in modo da mettere in sicurezza le informazioni contenute nei container privati. Un altro eventuale sviluppo, quando le librerie lo permetteranno, potrebbe essere la possibilità di memorizzare nella nube file di grandezza maggiore degli attuali 4MB, permettendo così l aumento della condivisione e della diversificazione dei file. Studio ed analisi del Cloud Computing Stumpo Elvio

93 Conclusione Se Microsoft sarà in grado di migliorare notevolmente i servizi attualmente offerti e contemporaneamente realizzare tutti gli obiettivi che si è prefissata, preferibilmente prima dell uscita ufficiale del prodotto, potrà essere un valido rivale di EC2, l attuale leader nel campo del Cloud Computing. Studio ed analisi del Cloud Computing Stumpo Elvio

94 Bibliografia Bibliografia [1]. Delic K. A., Walker M.A., Emergence of the academic computing cloud ACM Ubiquity, Volume 9, Issue 31 August 2008 [2]. Chappell D., A short introduction to cloud platform an enterprise-oriented view (sponsored by Microsoft Corporation) Chappell & associates August 2008 [3]. Chappell D., Cloud platforms an enterprise-oriented overview (sponsored by Microsoft Corporation) Chappell & associates July 2008 [4]. Chappell D., Introducing the Azure services platform an early look at Windows Azure,.Net Services, SQL Services, and Live Services (sponsored by Microsoft Corporation) Chappell & associates October 2008 [5]. Chappell D., Introducing Windows Azure (sponsored by Microsoft Corporation) Chappell & associates March 2009 [6]. Da sito [7]. Dal sito Seeding the Clouds: Key Infrastructure Elements for Cloud Computing February 2009 IBM: da oggi è possibile utilizzare i data center come si usa Internet [8]. Dal sito: What is the Azure Services Platform? Windows Azure Blob December, 2008 Windows Azure Queue December, 2008 Studio ed analisi del Cloud Computing Stumpo Elvio

95 Bibliografia Windows Azure Table December, 2008 [9]. Dal sito: Google App Engine: cloud computing visto da Mountain View di Bellasio S. Google App Engine, scopriamo la cloud di Google per le nostre applicazioni di Bellasio S. [10]. Brown K, Mani S. Microsoft Code Name "Geneva" Framework Whitepaper for Developers Microsoft Corporation [11]. [12]. [13]. Per informazioni di carattere generale si è consultato anche il sito Studio ed analisi del Cloud Computing Stumpo Elvio

96 Sommario Sommario Introduzione: Il calcolo distribuito 1 Capitolo 1 Architetture di calcolo distribuito Grid computing Cloud computing Problematiche d impiego Componenti Architettura 11 Capitolo 2 Analisi sulle offerte cloud GoGrid IBM Blue Cloud Cenni sull organizzazione della nube Carnegie Mellon University, Qatar University, Texas A&M University (Qatar) University of Pretoria (Sud Africa) The Higher Education Alliance for Leadership Through Health (Africa Orientale) Google App Engine Le risorse I componenti fondamentali Costi per l impiego della rete GEA Ulteriori dettagli EC Funzionalità Amazon EC Servizi highlights Tipologie di istanze Istanze standard Istanze High-CPU Sistemi operativi e software Sistemi operativi Software Costi Istanze Trasferimento dei dati Internet Availability zone e trasferimento dati Amazon Elastic Block Storage Indirizzi IP elastici Pay-for-use Descrizione dettagliata per l esecuzione delle istanze Microsoft Azure 26 Studio ed analisi del Cloud Computing Stumpo Elvio

97 Sommario Capitolo 3 Microsoft Azure Services Platform Introduzione alla piattaforma di servizi Azure Rapida analisi della piattaforma di servizi Azure Windows Azure Cenni preliminari Definizioni generali Compute services (esecuzione delle applicazioni) Storage services (accesso alla memoria) Blobs Tables Queues Fabric Impieghi d uso d Azure Applicazioni web scalabili Istanze d esecuzione parallela Applicazioni web eseguite in background Utilizzo del cloud storage per applicazioni on-premises o hosting Microsoft.NET Services Cenni preliminari Definizioni generali Access Control Service Service Bus Workflow Service SQL Services Cenni preliminari Definizioni generali Live Services Cenni preliminari Definizioni generali Accessing Data Utilizzo delle Mesh Applicativi web mesh-enable Costi 77 Capitolo 4 Analisi a confronto GoGrid vs Azure Blue vs Azure GEA vs Azure EC2-vs Azure 81 Studio ed analisi del Cloud Computing Stumpo Elvio

98 Sommario Capitolo 5 Azure Sharing File Installazione software di sviluppo Ricerca e sviluppo Creazione di ASF Pubblicazione ASF Resoconto operativo Rendimento software (sviluppo applicativo in ambito locale) Rendimento dei servizi (sviluppo applicativo in ambito remoto) 87 Conclusione 89 Bibliografia 93 Sommario 95 Studio ed analisi del Cloud Computing Stumpo Elvio