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

Windows

Windows (135)

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.

Pagina 1 di 23