I COOKIE CI PERMETTONO DI MIGLIORARE LA TUA ESPERIENZA UTENTE CONTINUANDO A NAVIGARE SU QUESTO SITO ACCETTI IL LORO IMPIEGO 

Guide

Guide (20)

Martedì, 22 Novembre 2011 18:42

Il controller di infrastruttura in dettaglio

Scritto da

Per gli sviluppatori di applicazioni, i servizi di elaborazione e archiviazione sono i componenti più importanti di Windows Azure. Il funzionamento di entrambi, tuttavia, dipende dal controller di infrastruttura, il quale, trasformando un data center pieno di computer in un insieme coerente, fornisce le basi per tutto il resto.

Come abbiamo già visto, il controller di infrastruttura è il proprietario di tutte le risorse in un determinato data center di Windows Azure ed è anche responsabile dell'assegnazione delle applicazioni ai computer fisici. Eseguire tutto questo in modo intelligente è importante. Supponiamo ad esempio che per la propria applicazione uno sviluppatore abbia bisogno di cinque istanze di ruolo Web e quattro istanze di ruolo di lavoro. Si potrebbe ingenuamente collocare tutte queste istanze in computer dello stesso rack, gestiti dallo stesso switch di rete. In caso di errore del rack o dello switch, però, l'intera applicazione non sarà più disponibile. Dati gli obiettivi di disponibilità elevata che si impone Windows Azure, far dipendere in questo modo un'applicazione da singoli punti di errore sarebbe sbagliato.

Per evitare questa situazione, il controller di infrastruttura raggruppa i computer sotto il suo controllo in un certo numero di domini di errore. Ciascun dominio di errore fa parte del data center nel quale un singolo errore può impedire l'accesso a tutti gli elementi in quel dominio, come illustrato nella figura 16.

Figura 16: il controller di infrastruttura colloca diverse istanze di un'applicazione in diversi domini di errore.

 

In questo semplice esempio, l'applicazione sta eseguendo solo due istanze di ruolo Web e il data center è diviso in due domini di errore. Quando il controller di infrastruttura distribuisce l'applicazione, colloca un'istanza di ruolo Web in ciascuno dei domini di errore. Con una configurazione di questo tipo, un solo problema hardware nel data center non è sufficiente a bloccare l'intera applicazione. Non dimentichiamo inoltre che il controller di infrastruttura vede l'archiviazione di Windows Azure come una semplice applicazione: il controller non gestisce la replica dei dati. Questa operazione è gestita dal servizio di archiviazione stesso, che garantisce che le repliche dei blob, le tabelle e le code utilizzati dall'applicazione siano collocate in domini di errore diversi.

Mantenere un'applicazione in esecuzione anche in caso di problemi hardware è utile, ma non basta. Un'applicazione davvero affidabile, del tipo che Windows Azure mira a supportare, non deve necessariamente essere arrestata per essere aggiornata. Un modo per eseguire l'aggiornamento consiste nell'utilizzare l'approccio descritto in precedenza per passare dalla versione esistente di un'applicazione a una nuova versione, ma è anche possibile affidarsi ai domini di aggiornamento di Windows Azure. In base a questo secondo approccio, il controller di infrastruttura assegna istanze diverse dei ruoli di un'applicazione a diversi domini di aggiornamento. Per eseguire il deployment di una nuova versione dell'applicazione, il controller di infrastruttura distribuisce il nuovo codice a un dominio di aggiornamento alla volta, interrompendone le istanze di ruolo, aggiornando il codice per tale ruolo e quindi avviando nuove istanze. L'obiettivo è mantenere l'applicazione in esecuzione anche quando viene aggiornata. Gli utenti potrebbero accorgersi dell'aggiornamento in corso, ad esempio a causa del superiore tempo di risposta dell'applicazione quando alcune istanze vengono arrestate, e utenti diversi potrebbero avere accesso a versioni diverse dell'applicazione nel corso dell'aggiornamento. Dal punto di vista dell'utente, comunque, l'applicazione nel suo insieme rimane sempre disponibile.

È importante non confondere i domini di aggiornamento, che sono una proprietà di un'applicazione, con i domini di errore, che sono una proprietà dei data center. Entrambi, tuttavia, hanno uno scopo in comune: consentire al controller di infrastruttura di mantenere continuamente in esecuzione le applicazioni Windows Azure.

Microsoft ha annunciato l'intenzione di aggiungere ulteriori funzionalità a Windows Azure nel 2011, tra cui:

Windows Azure Platform Appliance, una combinazione di hardware e software che consentirà a provider di servizi di hosting e aziende di eseguire Windows Azure nei propri data center.

Memorizzazione di contenuti dinamici nella cache della rete CDN: attualmente la rete CDN di Windows Azure supporta solamente i dati di blob. Grazie a questa funzionalità di prossima implementazione, la rete CDN sarà in grado di memorizzare nella cache contenuti creati dinamicamente da un'applicazione Windows Azure.

Creazione di snapshot dei ruoli VM: nella prima versione di Windows Azure, il ruolo VM non consente di salvare le modifiche apportate al volume del sistema operativo durante l'esecuzione. La funzionalità di creazione di snapshot offrirà un modo per salvare periodicamente lo stato di questo volume nell'archivio permanente.

Migliore supporto Java: Microsoft intende aggiungere ulteriore supporto all'attuale capacità di Windows Azure di eseguire applicazioni Java. I miglioramenti previsti includono un aumento delle prestazioni Java, un maggiore supporto degli strumenti basati su Eclipse e un set più completo di librerie Java per Windows Azure.

Come sempre, l'obiettivo di queste aggiunte è rendere questa piattaforma cloud utile in una più ampia varietà di situazioni.

Martedì, 22 Novembre 2011 18:40

Code

Scritto da

Mentre tabelle e blob hanno essenzialmente la funzione di consentire l'archiviazione e l'accesso ai dati, l'obiettivo principale delle code è consentire alle diverse parti di un'applicazione Windows Azure di comunicare. Come tutto il resto nell'archiviazione di Windows Azure, l'accesso alle code avviene in modalità REST. Sia le applicazioni Windows Azure che quelle esterne fanno riferimento alle code utilizzando un URI nel seguente formato:

http://<AccountArchiviazione>.queue.core.windows.net/<NomeCoda>

Come già accennato, le code vengono utilizzate anche per consentire l'interazione tra istanze di ruolo Web e istanze di ruolo di lavoro, come illustrato nella figura 15.

Figura 15: i messaggi vengono accodati, rimossi dalla coda, elaborati e quindi eliminati esplicitamente dalla coda.

 

In un tipico scenario, più istanze di ruolo Web sono in esecuzione in un dato momento, ciascuna delle quali accetta lavori dagli utenti (passaggio 1). Per passare un lavoro alle istanze di ruolo di lavoro, l'istanza di ruolo Web scrive un messaggio in una coda (passaggio 2). Questo messaggio, delle dimensioni massime di 8 KB, potrebbe contenere un URI che fa riferimento a un blob, a un'entità in una tabella o ad altro ancora. Le istanze di ruolo di lavoro leggono i messaggi nella coda (passaggio 3), quindi eseguono il lavoro richiesto (passaggio 4). È importante sottolineare che la lettura di un messaggio da una coda non ne comporta l'eliminazione, bensì rende il messaggio invisibile ad altre letture per un determinato periodo di tempo (30 secondi per impostazione predefinita). Una volta completata l'attività richiesta dal messaggio, l'istanza di ruolo di lavoro dovrà esplicitamente eliminare il messaggio dalla coda (passaggio 5).

Separando le istanze di ruolo Web dalle istanze di ruolo di lavoro, si evita all'utente di dover attendere il completamento delle attività in elaborazione e si semplifica la scalabilità, poiché è sufficiente aggiungere più istanze di entrambi. L'eliminazione esplicita dei messaggi da parte delle istanze è invece vantaggiosa perché permette di gestire gli errori. Se l'istanza di ruolo di lavoro che recupera il messaggio lo gestisce senza errori, eliminerà il messaggio quando questo sarà ancora invisibile, ovvero entro una finestra temporale di 30 secondi. Se invece un'istanza di ruolo di lavoro rimuove dalla coda un messaggio e quindi si arresta in modo anomalo prima di completare l'attività richiesta dal messaggio stesso, non eliminerà permanentemente il messaggio dalla coda. Allo scadere del tempo di invisibilità, il messaggio riapparirà nella coda e verrà letto da un'altra istanza di ruolo di lavoro. Lo scopo è garantire che ciascun messaggio venga elaborato almeno una volta.

Come possiamo vedere, le code di archiviazione di Windows Azure non seguono la stessa semantica delle code in Accodamento messaggi Microsoft (MSMQ) o altre tecnologie tradizionali. Un sistema di accodamento convenzionale può offrire ad esempio una semantica di tipo “First In, First Out” inviando esattamente una volta sola ciascun messaggio. Le code di archiviazione di Windows Azure non forniscono funzionalità di questo genere. Come abbiamo visto, un messaggio può essere recapitato più volte e non esiste un particolare ordine di recapito. Nella cloud l'approccio è differente e gli sviluppatori devono adattarsi a queste differenze.

Martedì, 22 Novembre 2011 18:38

Tabelle

Scritto da

È facile capire come è fatto un blob: si tratta semplicemente di un blocco di byte. Ma le tabelle sono più complesse. Nella figura 14 sono illustrate le parti di una tabella.

 

Figura 14: le tabelle forniscono archiviazione basata su entità.

 

Come mostrato nella figura, ogni tabella contiene un certo numero di entità. Un'entità contiene zero o più proprietà, ciascuna con un nome, un tipo e un valore. I numerosi tipi supportati includono Binary, Bool, DateTime, Double, GUID, Int, Int64 e String. Il tipo può cambiare in base ai valori archiviati nell'unità e non è necessario che tutte le proprietà presenti in un'unità siano dello stesso tipo. Gli sviluppatori rimangono liberi di usare tutto quello che può essere utile per la loro applicazione.

Qualunque sia il suo contenuto, un'entità può arrivare a dimensioni di 1 MB e vi si accede sempre come un'unità. La lettura di un'entità restituisce tutte le sue proprietà e la scrittura di un'entità può sostituirne tutte le proprietà. Vi è inoltre la possibilità di aggiornare in modo atomico un gruppo di entità all'interno di una sola tabella, vincolando così la riuscita, o la mancata riuscita, di tutti gli aggiornamenti insieme.

Le tabelle di archiviazione di Windows Azure si differenziano dalle tabelle relazionali in numerosi aspetti. Innanzitutto, non sono tabelle in senso classico. Inoltre non sono accessibili tramite ADO.NET, né sono in grado di supportare query SQL. Per finire, non applicano alcuno schema: le proprietà in una singola entità possono essere di diversi tipi, che possono anche variare nel tempo. La domanda è naturalmente: perché? Perché non supportare semplicemente normali tabelle relazionali con query SQL standard?

La risposta è insita in uno degli obiettivi principali di Windows Azure: supportare applicazioni altamente scalabili. I tradizionali database relazionali consentono la scalabilità verticale, per gestire sempre più utenti eseguendo il sistema DBMS in computer sempre più potenti. Tuttavia, per supportare numeri

veramente elevati di utenti simultanei, è necessario assicurare la scalabilità orizzontale dell'archiviazione, non quella verticale. A tale scopo, il meccanismo di archiviazione deve diventare più semplice, e le tradizionali tabelle relazionali SQL non sono adeguate allo scopo. Ciò che serve è il tipo di struttura fornito dalle tabelle di Windows Azure.

L'utilizzo delle tabelle impone agli sviluppatori un certo cambio di atteggiamento mentale, poiché i familiari concetti relazionali non possono essere applicati senza variazioni. Nonostante questo, per quanto riguarda la creazione di applicazioni estremamente scalabili, questo approccio è il più valido. In primo luogo, libera gli sviluppatori da ogni preoccupazione relativa alla scalabilità. Gli sviluppatori non devono fare altro che creare nuove tabelle, aggiungere entità e lasciare che Windows Azure faccia il resto. Inoltre, elimina molto del lavoro necessario per mantenere un sistema DBMS, dal momento che se ne fa carico Windows Azure. L'obiettivo è lasciare che gli sviluppatori si concentrino sulla loro applicazione anziché sulle meccaniche di archiviazione e amministrazione di grandi quantità di dati.

Come tutto il resto nell'archiviazione di Windows Azure, l'accesso alle tabelle avviene in modalità REST. A tale scopo un'applicazione .NET può utilizzare WCF Data Services, nascondendo le richieste HTTP sottostanti. Qualsiasi applicazione, .NET o meno, è libera di effettuare direttamente queste richieste. Ad esempio, una query eseguita su una determinata tabella viene espressa come un HTTP GET su un URI nel seguente formato:

http://<AccountArchiviazione>.table.core.windows.net/<NomeTabella>?$filter=<Query>

<NomeTabella> specifica la tabella oggetto della query, mentre <Query> contiene la query da eseguire. Se la query restituisce numerosi risultati, lo sviluppatore può ottenere un token di continuità da passare alla query successiva. Questo metodo eseguito ripetutamente consente di recuperare l'intero set di risultati in più blocchi.

Le tabelle di Windows Azure non sono sempre la scelta giusta per ogni scenario di archiviazione e utilizzarle comporta una curva di apprendimento. La scalabilità che offrono è però perfetta per molti tipi di applicazioni.

Martedì, 22 Novembre 2011 18:36

Blob

Scritto da

I blob (Binary Large Object) sono spesso la soluzione ideale per le esigenze di un'applicazione. Il loro scopo è consentire alle applicazioni di archiviare dati e di accedervi in modo generico, indipendentemente dal tipo di dati (video, audio, messaggi di posta elettronica archiviati o altro ancora). Per utilizzare i blob, uno sviluppatore deve prima creare uno o più contenitori in un account di archiviazione. Ciascun contenitore potrà quindi contenere uno o più blob.

Per identificare un determinato blob, un'applicazione può fornire un URI nel seguente formato:

http://<AccountArchiviazione>.blob.core.windows.net/<Contenitore>/<NomeBlob>

<AccountArchiviazione> è un identificatore univoco assegnato al momento della creazione di un nuovo account di archiviazione, mentre <Contenitore> e <NomeBlob> sono i nomi rispettivamente di un contenitore e di un blob all'interno di tale contenitore.

I blob possono avere due forme:

A blocchi. Ogni blob può contenere fino a 200 gigabyte di dati. Per poter garantire trasferimenti efficienti, questi blob sono suddivisi in blocchi. In caso di errore, una ritrasmissione può ripartire dal blocco più recente anziché da zero. Dopo che sono stati caricati tutti i blocchi, viene eseguito il commit dell'intero blob.

A pagine. Ogni blob può contenere fino a un terabyte di dati. Un blob a pagine è diviso in pagine da 512 byte, e un'applicazione è libera di leggere e scrivere in ordine casuale le singole pagine del blob.

 

Indipendentemente dal tipo di blob, i contenitori che li ospitano possono essere privati o pubblici. Per i blob in un contenitore privato, sia le richieste di lettura che di scrittura devono essere firmate utilizzando la chiave per l'account di archiviazione del blob. Per i blob in un contenitore pubblico, solo le richieste di scrittura devono essere firmate; qualsiasi applicazione invece ha la possibilità di leggere il blob. Ciò è utile in situazioni che coinvolgono video, foto o altri dati non strutturati, molto diffusi in Internet. La rete CDN di Windows Azure supporta solo i dati archiviati in contenitori di blob pubblici.

Un altro importante aspetto dei blob è il loro ruolo nel supporto delle unità Windows Azure. Per capire in cosa consiste il loro ruolo, è importante ricordare che le istanze di ruolo sono libere di accedere ai rispettivi file system locali. Per impostazione predefinita, questo tipo di archiviazione non è tuttavia permanente: alla chiusura di un'istanza vanno perse anche la macchina virtuale e il relativo archivio locale. Montare un'unità Windows Azure per l'istanza, invece, può far apparire un blob a pagine come un'unità locale completa di file system NTFS. Le scritture nell'unità possono avvenire immediatamente nel blob sottostante. Quando l'istanza non è in esecuzione, questi dati sono archiviati in modo permanente nel blob a pagine, pronti per essere nuovamente montati. Di seguito sono illustrati alcuni dei possibili utilizzi delle unità:

Uno sviluppatore può caricare un disco rigido virtuale (VHD) contenente un file system NTFS, quindi montare il VHD come unità di Windows Azure. Questo sistema consente di spostare agevolmente i dati dei file system tra Windows Azure e un sistema Windows Server on-premises.

Uno sviluppatore Windows Azure può installare ed eseguire un database MySQL in un'istanza di ruolo Windows Azure utilizzando un'unità di Windows Azure come archivio sottostante.

 

Martedì, 22 Novembre 2011 18:33

Il servizio di archiviazione in dettaglio

Scritto da

Per utilizzare il servizio di archiviazione di Windows Azure, è innanzitutto necessario creare un account di archiviazione. Per controllare l'accesso alle informazioni relative all'account, all'autore viene assegnata una chiave privata. Ogni richiesta di informazioni contenute in questo account di archiviazione, in blob, tabelle e code, è contrassegnata da una firma creata con questa chiave privata. In altre parole, l'autorizzazione avviene a livello di account (sebbene i blob offrano anche un'altra opzione, descritta più avanti). Il servizio di archiviazione Windows Azure non fornisce elenchi di controllo di accesso, né altri modi più precisi per controllare gli accessi ai dati.

Martedì, 22 Novembre 2011 18:32

Il servizio di elaborazione in dettaglio

Scritto da

Come la maggior parte delle tecnologie, il servizio di elaborazione di Windows Azure ha fatto progressi dal suo primo rilascio. Originariamente, ad esempio, il codice nei ruoli Web e di lavoro poteva essere eseguito solo in modalità utente. Oggi, invece, entrambi i ruoli forniscono un'opzione di esecuzione con privilegi elevati, consentendo di eseguire le applicazioni in modalità di amministrazione. Questa opzione può essere utile, ad esempio, con le applicazioni per le quali è necessario installare un componente COM, operazione che presentava diversi problemi nella prima versione di Windows Azure.

Tuttavia, ogni istanza in esecuzione di un ruolo Web o di lavoro viene avviata da zero: il sistema operativo sottostante nella macchina virtuale è un'immagine standard definita da Windows Azure. Questo significa che qualsiasi installazione software eseguita dal ruolo deve essere ripetuta ogni volta che viene creata una nuova istanza. Ciò non costituisce un problema per le installazioni semplici, come l'aggiunta di un componente COM. Se invece è necessario installare una varietà di componenti software per supportare le funzioni dell'istanza, farlo ogni volta che viene creata una nuova istanza del ruolo è una perdita di tempo inaccettabile.

Evitare questa perdita di tempo è lo scopo principale dei ruoli VM. Invece di ripetere l'installazione ad ogni creazione di istanze, è possibile includere tutto il software necessario in un VHD, utilizzandolo quindi per creare un'istanza di ruolo VM. Questa procedura può essere notevolmente più rapida rispetto all'utilizzo di ruoli Web o di lavoro con privilegi elevati. Può rappresentare inoltre la soluzione ideale quando il processo di installazione richiede un intervento manuale, non consentito da Windows Azure.

Un altro progresso rispetto alla versione originale di Windows Azure è il supporto dell'accesso tramite Remote Desktop Protocol (RDP). Questo tipo di accesso è utile ad esempio per il debug, in quanto consente agli sviluppatori di accedere direttamente a un'istanza specifica. Non può essere tuttavia utilizzato per l'infrastruttura desktop virtuale (VDI), tecnologia attualmente non supportata da Windows Azure.

Altri importanti aspetti del servizio di elaborazione di Windows Azure sono disponibili fin dal primo rilascio della tecnologia. Ad esempio, Windows Azure permette agli sviluppatori di indicare in quale data center debba essere eseguita un'applicazione e dove debbano essere archiviati i dati, nonché di riunire in uno stesso data center un determinato gruppo di applicazioni e dati, compresi i dati di SQL Azure. Oggi, Microsoft fornisce data center Windows Azure negli Stati Uniti, in Europa e in Asia e altri data center si aggiungeranno prossimamente.

Per far comprendere il funzionamento di Windows Azure, nelle sezioni precedenti sono state illustrate le funzioni fondamentali della piattaforma insieme ad alcuni scenari di utilizzo. Questa tecnologia offre tuttavia molto di più. In questa sezione verranno esaminati in dettaglio alcuni degli aspetti più interessanti.

Creazione di applicazioni Windows Azure

Dal punto di vista dello sviluppatore, realizzare un'applicazione in Windows Azure non è molto diverso dal realizzare un'applicazione Windows tradizionale. Poiché la piattaforma supporta sia applicazioni .NET che applicazioni realizzate con codice non gestito, uno sviluppatore può scegliere in base alle esigenze. Per semplificare il lavoro degli sviluppatori, Visual Studio offre modelli di progetto per la creazione di applicazioni Windows Azure. È anche possibile caricare direttamente le applicazioni da Visual Studio a Windows Azure.

Un'evidente differenza tra la cloud e le soluzioni on-premises è che le applicazioni Windows Azure non vengono eseguite in locale. Questa differenza costituisce una potenziale fonte di problemi da affrontare in fase di sviluppo. Microsoft ha quindi creato allo scopo l'infrastruttura di sviluppo, una versione dell'ambiente Windows Azure eseguibile nel computer dello sviluppatore.

L'infrastruttura di sviluppo viene eseguita in un solo computer desktop o server ed emula le funzionalità che Windows Azure fornisce nella cloud, inclusi i ruoli Web, di lavoro e VM e tutte le tre opzioni di archiviazione di Windows Azure. Uno sviluppatore può realizzare un'applicazione Windows Azure, distribuirla nell'infrastruttura di sviluppo ed eseguirla come farebbe con una normale applicazione in locale. È possibile stabilire quante istanze di ciascun ruolo eseguire, utilizzare code per la comunicazione tra le istanze e svolgere pressoché qualsiasi operazione possibile con Windows Azure. Dopo che l'applicazione è stata sviluppata e testata in locale, lo sviluppatore può caricare il codice e le relative informazioni di configurazione e quindi eseguirla.

In qualunque modo sia stata creata, un'applicazione Windows Azure viene in genere resa disponibile nella cloud attraverso un processo in due fasi. Innanzitutto, lo sviluppatore carica l'applicazione nell'area di gestione temporanea della piattaforma. Quando è pronto a introdurre l'applicazione in ambiente di produzione, utilizza quindi il portale Windows Azure per farne richiesta. Questo passaggio dall'ambiente di gestione temporanea a quello di produzione può essere completato senza tempi di inattività, consentendo l'aggiornamento di un'applicazione in esecuzione a una nuova versione senza alcun disagio per gli utenti.

L'applicazione in fase di gestione temporanea è caratterizzata da un nome DNS in formato <GUID>cloudapp.net, dove <GUID> rappresenta un identificatore univoco globale assegnato da Windows Azure. Per l'ambiente di produzione, lo sviluppatore sceglie un nome DNS nello stesso dominio, ad esempio servizioazure.cloudapp.net. Per utilizzare un dominio personale anziché il dominio cloudapp.net di Microsoft, il proprietario dell'applicazione può creare un alias DNS utilizzando un CNAME standard.

Una volta che l'applicazione è pubblicata e accessibile, gli utenti avranno bisogno di un modo per identificare se stessi. A tale scopo, Windows Azure consente agli sviluppatori di utilizzare qualsiasi meccanismo di autenticazione basato su HTTP. Ad esempio, un'applicazione ASP.NET può avvalersi di un provider di appartenenze per memorizzare il proprio ID utente e la password oppure utilizzare altri metodi, come il servizio Microsoft Windows Live ID. Le applicazioni Windows Azure possono inoltre utilizzare liberamente Windows Identity Foundation (WIF) per implementare l'identità basata sulle attestazioni. La scelta spetta interamente al creatore dell'applicazione.




Anche se le funzionalità di Windows Azure sono molte, un'applicazione potrebbe richiederne solo una. Pensiamo ad esempio a un'applicazione on-premises oppure ospitata che necessiti di archiviare una grande quantità di dati. Un'azienda potrebbe ad esempio desiderare di archiviare i vecchi messaggi di posta elettronica e risparmiare sull'archiviazione senza rinunciare all'accessibilità dei dati archiviati. Un sito Web di news ospitato da un provider potrebbe avere bisogno di una soluzione scalabile e accessibile globalmente per archiviare grandi quantità di testo, immagini, video e profili degli utenti. Un sito dedicato alla condivisione di foto, infine, potrebbe desiderare di affidare a terzi l'archiviazione dei propri contenuti. Tutte queste situazioni sono risolvibili con il servizio di archiviazione di Windows Azure, come illustrato nella figura 13.

 

Figura13: un'applicazione on-premises o ospitata può utilizzare blob o tabelle di Windows Azure per archiviare i propri dati nella cloud.

 

Come accennato in precedenza, un'applicazione on-premises o ospitata può accedere direttamente all'archivio di Windows Azure. Sebbene questo tipo di accesso risulti in genere più lento rispetto all'archiviazione on-premises, è tuttavia più economico, scalabile e affidabile. Per alcune applicazioni si tratta di un compromesso del tutto vantaggioso. Inoltre, anche se non viene mostrato nella figura, le applicazioni possono utilizzare SQL Azure nello stesso modo.

Immaginiamo che, anziché creare una nuova applicazione Web per Windows Azure, un'organizzazione intenda migrare un'applicazione Windows Server esistente su questa piattaforma cloud. Un modo per raggiungere lo scopo è offerto dal ruolo VM di Windows Azure. Questo scenario presenta molte analogie con il caso precedente, come illustrato nella figura 12.

 

Figura12: è possibile eseguire la migrazione di alcune applicazioni on-premises a Windows Azure utilizzando il ruolo VM e SQL Azure.

Per utilizzare un ruolo VM, l'azienda dovrà innanzitutto creare un disco rigido virtuale (VHD) da un computer on-premises in cui viene eseguito Windows Server 2008 R2. L'immagine creata potrà quindi essere caricata in Windows Azure ed essere eseguita all'interno di un ruolo VM. Come illustrato nella figura, l'applicazione può accedere a dati relazionali in SQL Azure. Un'altra opzione consiste nel lasciare i dati on-premises, accedendovi direttamente tramite il servizio di connessione di Windows Azure, come descritto in precedenza.

Il ruolo VM può essere utile, tuttavia è importante comprendere che per eseguire la migrazione di un'applicazione Windows Server in Windows Azure non è sufficiente creare un pacchetto dell'applicazione in un VHD ed eseguirlo in un ruolo VM. Innanzitutto, è bene ricordare che il controller di infrastruttura di Windows Azure presuppone che siano sempre in esecuzione almeno due istanze di ogni ruolo, come previsto dal contratto di servizio (SLA) di Windows Azure, e che Windows Azure esegue il bilanciamento del carico delle richieste degli utenti tra le varie istanze di un ruolo. Se l'applicazione da migrare è stata sviluppata con questi requisiti e, ad esempio, viene già eseguita in una Web farm con bilanciamento del carico, potrà funzionare anche in Windows Azure senza richiedere modifiche significative. Se invece l'applicazione è progettata per eseguire una sola istanza, dovrà probabilmente essere riprogettata per poter funzionare correttamente in Windows Azure.

Martedì, 22 Novembre 2011 18:19

Creazione di un'applicazione Web con dati relazionali

Scritto da

I blob e le tabelle di Windows Azure rappresentano la scelta ideale per alcune situazioni. In molti altri casi sono invece più consigliati i dati relazionali. Supponiamo che un'azienda decida di sviluppare

ruoloWebIstanzadiSQL AzureUtentiNuova applicazione Web con dati relazionali

un'applicazione per i propri dipendenti da eseguire su Windows Azure. L'applicazione avrà probabilmente un ciclo di vita breve o imprevedibile, pertanto non vale la pena di allocare un server nel data center aziendale. Se invece l'applicazione deve essere disponibile nel più breve tempo possibile, attendere che il reparto IT interno effettui il provisioning di un server è una soluzione inaccettabile. O ancora, la scelta di Windows Azure può essere dettata dalla convenienza e dalla maggiore semplicità che, secondo l'organizzazione, questa piattaforma è in grado di offrire.

Qualunque sia il motivo, l'applicazione probabilmente non ha bisogno delle capacità di scalabilità fornite dalle tabelle di Windows Azure. I suoi sviluppatori potrebbero anzi preferire l'approccio relazionale che già conoscono, con strumenti di reporting già noti e utilizzati. In un caso come questo, Windows Azure può essere utilizzato in combinazione con SQL Azure, come illustrato nella figura 11.

 

Figura11: un'applicazione Windows Azure può utilizzare SQL Azure per elaborare i dati relazionali.

 SQL Azure fornisce gran parte delle funzionalità di SQL Server, inclusi gli strumenti di reporting, come servizio cloud gestito. Le applicazioni possono creare database, eseguire query SQL e altro ancora, ma senza alcun bisogno di amministrare il sistema di database, né l'hardware in cui vengono eseguite. Di questo se ne occupa Microsoft. Per accedere a un database SQL Azure è possibile utilizzare il protocollo TDS (Tabular Data Stream), proprio come nella versione on-premises di SQL Server. Ciò consente alle applicazioni Windows Azure di accedere ai dati relazionali tramite meccanismi familiari come Entity Framework e ADO.NET. Inoltre, poiché SQL Azure è un servizio cloud, il costo si basa sull'effettivo utilizzo.

Dal momento che Windows Azure e SQL Azure forniscono equivalenti cloud delle loro controparti on-premises, spostare le code e i dati per queste applicazioni tra i due ambienti può rivelarsi un'operazione semplice e immediata. L'ambiente cloud e l'ambiente on-premises non sono esattamente corrispondenti, in quanto, per fare un esempio, un'applicazione Windows Azure deve essere in grado di eseguire più istanze, ma sono tuttavia simili. Questa portabilità si rivela utile nelle situazioni in cui è necessario creare un'applicazione in cui il codice e i dati possono esistere sia on-premises che nella cloud.

Pagina 1 di 2