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 17:15

Panoramica di Windows Azure

Scritto da

Il cloud computing si sta diffondendo rapidamente. Sono ormai innumerevoli i vantaggi offerti dall'esecuzione di applicazioni e dall'archiviazione dei dati nei computer di un data center accessibile via Internet. Le applicazioni, ovunque siano eseguite, devono tuttavia essere basate su una piattaforma. Nel caso delle applicazioni on-premises, come quelle eseguite nel data center di un'organizzazione, questa piattaforma è solitamente composta almeno da un sistema operativo e da una soluzione per l'archiviazione dei dati. Le applicazioni eseguite nella cloud necessitano delle medesime basi.

L'obiettivo di Windows Azure è quello di fornire queste basi. Parte di una piattaforma più vasta, Windows Azure fornisce le fondamenta per l'esecuzione di applicazioni e l'archiviazione di dati nella cloud, come illustrato nella figura 1.
fig 1

Figura1: le applicazioni Windows Azure vengono eseguite nei data center di Microsoft e sono accessibili via Internet.

Windows Azure non è un software che i clienti Microsoft possono installare ed eseguire nei propri computer, ma un servizio che consente di eseguire applicazioni e archiviare dati in computer di proprietà di Microsoft, accedendovi tramite Internet. Queste applicazioni possono essere rivolte ad aziende, utenti consumer o entrambe le tipologie di destinatari. Di seguito sono riportati alcuni esempi di applicazioni che possono essere basate su Windows Azure: Un fornitore di software indipendente, o ISV (Independent Software Vendor), potrebbe creare un'applicazione rivolta a utenti aziendali con un approccio spesso denominato Software as a Service (SaaS). Windows Azure è stato in parte progettato per supportare le applicazioni SaaS Microsoft, in modo da poter essere utilizzato dagli ISV come piattaforma per una varietà di applicazioni software cloud aziendali.

Un ISV potrebbe creare un'applicazione SaaS destinata agli utenti consumer anziché alle aziende. Progettato per supportare software altamente scalabile, Windows Azure è adatto per essere utilizzato come piattaforma da un'azienda che abbia tra i suoi piani di mercato un target di consumatori molto ampio. Le aziende potrebbero utilizzare Windows Azure per realizzare ed eseguire applicazioni utilizzate internamente dai propri dipendenti. Anche se in una situazione di questo tipo non è necessaria l'enorme scalabilità richiesta per supportare un vasto pubblico, l'affidabilità e la gestibilità di Windows Azure rendono la piattaforma una scelta molto appetibile.

Per il supporto di applicazioni e dati nella cloud, Windows Azure si avvale di cinque componenti, illustrati nella figura 2.
fig2

Figura2: Windows Azure è costituito da cinque componenti principali: servizio di elaborazione (Compute), servizio di archiviazione (Storage), controller di infrastruttura (Fabric Controller), rete CDN e servizio di connessione (Connect).

Tali componenti sono:

Servizio di elaborazione (Compute): esegue le applicazioni nella cloud. Queste applicazioni sono per lo più in grado di percepire un ambiente Windows Server, benché il modello di programmazione di Windows Azure non corrisponda esattamente al modello Windows Server on-premises.

 Servizio di archiviazione (Storage): archivia i dati binari e strutturati nella cloud.

Controller di infrastruttura (Fabric Controller): esegue il deployment, la gestione e il monitoraggio delle applicazioni. Gestisce inoltre gli aggiornamenti al software del sistema nell'intera piattaforma.

Rete per la distribuzione di contenuti (CDN, Content Delivery Network): rende più rapido l'accesso globale ai dati binari nell'archivio Windows Azure mantenendo nella cache copie di tali dati in tutto il mondo. Servizio di connessione: consente la creazione di connessioni a livello di IP tra i computer on-premises e le applicazioni Windows Azure.

Torna all'articolo principale 
 Articolo successivo

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.

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

Martedì, 22 Novembre 2011 17:25

Servizio di archiviazione (Storage)

Scritto da

Poiché le applicazioni gestiscono i dati in modi molto diversi tra loro, il servizio di archiviazione di Windows Azure fornisce varie opzioni, illustrate nella figura 4.

 Figura4: il servizio di archiviazione di Windows Azure offre blob, tabelle e code.

Il modo più semplice per archiviare dati in Windows Azure consiste nell'utilizzo dei blob. Un blob contiene dati binari e, come indica la figura 4, presenta una gerarchia semplice: ogni contenitore può contenere uno o più blob. I blob possono essere di grandi dimensioni, fino a un terabyte, e possono includere metadati, ad esempio informazioni sul luogo in cui è stata scattata una foto in formato JPEG o il nome del cantante di un brano MP3. Forniscono inoltre l'archiviazione sottostante per le unità Windows Azure, un meccanismo che consente a un'istanza di ruolo di Windows Azure di interagire con l'archivio permanente come se fosse un file system NTFS locale.

I blob sono molto adatti in certe situazioni, ma sono troppo poco strutturati per altre. Per poter elaborare i dati in modo più dettagliato, Windows Azure fornisce tabelle per l'archiviazione. Il nome "tabella" non deve fuorviare: non si tratta infatti di tabelle relazionali. I dati contenuti in ogni tabella sono in realtà archiviati in un gruppo di entità che contengono a loro volta proprietà. Inoltre, anziché utilizzare SQL, un'applicazione può eseguire query sui dati di una tabella utilizzando le convenzioni definite da OData. Questo approccio consente la scalabilità orizzontale dell'archiviazione, ovvero la capacità di sfruttare la distribuzione dei dati su più computer, in modo più efficiente rispetto a un normale database relazionale. Di fatto, una singola tabella di Windows Azure può contenere miliardi di entità con terabyte di dati.

Sia i blob che le tabelle sono utilizzati per l'archiviazione e l'accesso ai dati. La terza opzione di archiviazione in Windows Azure, ovvero le code, ha uno scopo totalmente diverso. Tra i compiti principali delle code vi è quello di garantire alle istanze di ruolo Web la possibilità di comunicazione asincrona con le istanze di ruolo di lavoro. Ad esempio, un utente potrebbe inviare una richiesta per una determinata attività di elaborazione intensiva tramite un'interfaccia Web implementata da un ruolo Web di Windows Azure. L'istanza di ruolo Web che riceve la richiesta può scrivere un messaggio in una coda con la descrizione del lavoro da svolgere. Un'istanza di ruolo di lavoro in attesa nella coda può quindi leggere il messaggio ed eseguire l'attività specificata. Il risultato può infine essere restituito tramite un'altra coda o essere gestito in altri modi.

A prescindere dalla modalità di archiviazione dei dati (in blob, tabelle o code), tutte le informazioni contenute nell'archivio di Windows Azure vengono replicate tre volte. Questo garantisce la tolleranza di errore, dal momento che la perdita di una copia dei dati non risulta fatale. Il sistema assicura allo stesso tempo grande coerenza, pertanto un'applicazione che legge immediatamente i dati che ha appena scritto ottiene esattamente gli stessi dati. Windows Azure mantiene inoltre una copia di backup di tutti i dati in un altro data center ubicato nella stessa area del pianeta. Se il data center che ospita la copia principale non è disponibile o addirittura viene distrutto, la copia di backup rimarrà accessibile.

L'archivio di Windows Azure è accessibile da applicazioni Windows Azure, on-premises o eseguite presso un provider di servizi di hosting o su un'altra piattaforma cloud. In ogni caso, tutti e tre gli stili di archiviazione di Windows Azure utilizzano le convenzioni REST per identificare ed esporre i dati, come illustrato nella figura 4. Blob, tabelle e code vengono tutti denominati utilizzando URI e sono accessibili tramite normali operazioni HTTP. A tale scopo, un client .NET può utilizzare una libreria fornita da Windows Azure, sebbene ciò non sia necessario, dal momento che un'applicazione può anche effettuare chiamate HTTP non elaborate.

Creare applicazioni Windows Azure che utilizzano blob, tabelle e code è certamente utile. Le applicazioni che si avvalgono dell'archiviazione relazionale possono invece utilizzare SQL Azure, un altro componente della piattaforma Windows Azure. Le applicazioni eseguite in Windows Azure (o su altre piattaforme) possono utilizzare questa tecnologia per ottenere un familiare accesso basato su SQL all'archiviazione relazionale nella cloud.

Torna all'articolo principale

Articolo succassivo

Martedì, 22 Novembre 2011 17:29

Controller di infrastruttura (Fabric Controller)

Scritto da

Tutte le applicazioni Windows Azure e tutti i dati nell'archivio di Windows Azure risiedono in data center di Microsoft. All'interno del data center, i computer dedicati a Windows Azure e il software eseguito in ciascuno di essi sono gestiti dal controller di infrastruttura, come illustrato nella figura 5.

 

Figura5: il controller di infrastruttura interagisce con le applicazioni Windows Azure mediante un agente di infrastruttura.

Lo stesso controller di infrastruttura è un'applicazione distribuita che viene replicata in un gruppo di computer e controlla tutte le risorse dell'ambiente: computer, switch, servizi di bilanciamento del carico e così via. Poiché è in grado di comunicare con un agente di infrastruttura in ogni computer, è anche a conoscenza di ogni applicazione Windows Azure nell'infrastruttura. Il controller di infrastruttura vede l'archivio di Windows Azure come un'applicazione a se stante e per tale motivo non ha alcuna visibilità sui dettagli della gestione dei dati e sulla replica.

Questa ampia disponibilità di informazioni permette al controller di infrastruttura di svolgere numerose attività utili, ad esempio monitorare tutte le applicazioni in esecuzione, offrendo un quadro immediato di ciò che sta accadendo nell'infrastruttura, e decidere dove debbano essere eseguite le nuove applicazioni, scegliendo i server fisici per ottimizzare l'utilizzo dell'hardware. A tale scopo, il controller di infrastruttura dipende dalle informazioni di configurazione caricate in ogni applicazione Windows Azure. Il file corrispondente fornisce una descrizione basata su XML delle esigenze dell'applicazione, ad esempio il numero delle istanze di ruolo Web o di lavoro e altro ancora. Quando il controller di infrastruttura implementa una nuova applicazione, utilizza questo file di configurazione per determinare il numero di macchine virtuali da creare.

Una volta create le macchine virtuali, il controller di infrastruttura ne esegue il monitoraggio. Se ad esempio un'applicazione necessita di cinque istanze di ruolo Web e una di queste subisce un arresto anomalo, il controller di infrastruttura ne avvierà automaticamente una nuova. Se allo stesso modo smette di funzionare un computer in cui è in esecuzione una macchina virtuale, il controller di infrastruttura avvierà una nuova istanza del ruolo in un altro computer, reimpostando il servizio di bilanciamento del carico per indirizzare il carico verso la nuova macchina virtuale.

 La nuova versione Windows Azure offre agli sviluppatori cinque dimensioni per le macchine virtuali tra cui scegliere, ovvero:

  • Molto piccola, con CPU a core singolo da 1,0 GHz, 768 MB di memoria e 20 GB di spazio di archiviazione delle istanze
  • Piccola, con CPU a core singolo da 1,6 GHz, 1,75 GB di memoria e 225 GB di spazio di archiviazione delle istanze
  • Media, con CPU dual-core da 1,6 GHz, 3,5 GB di memoria e 490 GB di spazio di archiviazione delle istanze
  • Grande, con CPU a quattro core da 1,6 GHz, 7 GB di memoria e 1000 GB di spazio di archiviazione delle istanze
  • Molto grande, con CPU a otto core da 1,6 GHz, 14 GB di memoria e 2040 GB di spazio di archiviazione delle istanze

Un'istanza di dimensioni molto piccole condivide una core del processore con altre istanze delle stesse dimensioni, mentre per tutte le altre dimensioni ogni istanza dispone di una o più core dedicate. In questo modo, le prestazioni di un'applicazione risultano prevedibili e non vi è alcun vincolo di durata per l'esecuzione delle istanze. Ad esempio, un'istanza di ruolo Web può impiegare tutto il tempo necessario a gestire la richiesta di un utente, mentre un'istanza di ruolo di lavoro può elaborare il valore del pi greco fino a un milione di cifre dopo lo zero.

Per i ruoli Web e di lavoro (ma non per i ruoli VM), il controller di infrastruttura gestisce inoltre il sistema operativo di ogni istanza, eseguendo anche attività come l'applicazione di patch e l'aggiornamento di altre applicazioni software di sistema. In tal modo gli sviluppatori possono concentrarsi esclusivamente sulla creazione di applicazioni, senza preoccuparsi della gestione della piattaforma stessa. È importante comprendere, tuttavia, che il controller di infrastruttura presuppone sempre che siano in esecuzione almeno due istanze di ogni ruolo, per consentire l'arresto di una delle due istanze per aggiornare il relativo software senza interrompere l'esecuzione dell'intera applicazione. Per questo e per altri motivi, non è consigliabile eseguire una sola istanza di un ruolo di Windows Azure.

Torna all'articolo principale

Articolo succassivo

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.

Pagina 1 di 2