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

Servizio di connessione

Scritto da

L'esecuzione di applicazioni in ambiente cloud Microsoft offre molti vantaggi, tuttavia nel prossimo futuro si continuerà parallelamente ad utilizzare applicazioni e dati in locale all'interno delle organizzazioni. È quindi importante connettere in maniera efficace gli ambienti on-premises con Windows Azure.

Il servizio di connessione di Windows Azure è stato progettato proprio per soddisfare questa esigenza. Fornendo connettività a livello di IP tra un'applicazione Windows Azure e i computer in esecuzione all'esterno dell'ambiente cloud Microsoft, questa funzionalità semplifica l'utilizzo di questa combinazione, come illustrato nella figura 7.

Figura7: il servizio di connessione di Windows Azure consente la comunicazione a livello di IP tra un computer Windows on-premises e un'applicazione Windows Azure.

Come illustrato nella figura, per utilizzare il servizio di connessione di Windows Azure è necessario installare un agente di endpoint in ogni computer on-premises che si connette a un'applicazione Windows Azure. Poiché la tecnologia si basa su IPv6, l'agente di endpoint è attualmente disponibile solo per Windows Server 2008, Windows Server 2008 R2, Windows Vista e Windows 7. È inoltre necessario configurare l'applicazione Windows Azure per l'interazione con il servizio di connessione di Windows Azure. Una volta completate queste operazioni, l'agente potrà utilizzare IPsec per interagire con un determinato ruolo in quell'applicazione.

È importante sottolineare che il servizio di connessione di Windows Azure non è una rete privata virtuale (VPN) a tutti gli effetti, bensì una soluzione più semplice, sebbene Microsoft abbia annunciato l'intenzione di offrire questa funzionalità in futuro. Per configurarla, ad esempio, non è necessario richiedere l'assistenza dell'amministratore di rete, ma è sufficiente installare l'agente di endpoint nel computer locale. Questo approccio elimina inoltre la potenziale complessità insita nella configurazione di IPsec, operazione che viene eseguita automaticamente dal servizio di connessione di Windows Azure.

Una volta configurata la tecnologia, i ruoli di un'applicazione Windows Azure appariranno sulla stessa rete IP del computer on-premises. Ciò rende possibili gli scenari seguenti:

  • Un'applicazione Windows Azure può accedere a un database on-premises direttamente. Supponiamo ad esempio che un'organizzazione decida di migrare un'applicazione Windows Server basata su ASP.NET in un ruolo Web di Windows Azure. Se il database utilizzato da questa applicazione deve rimanere in una posizione on-premises, una connessione del servizio di connessione di Windows Azure può consentire all'applicazione, ora in esecuzione su Windows Azure, di accedere al database on-premises nel modo consueto, senza necessità di modificare nemmeno la stringa di connessione.
  • Un'applicazione Windows Azure può essere aggiunta allo stesso dominio dell'ambiente on-premises, per consentire l'accesso Single Sign-On all'applicazione cloud da parte degli utenti on-premises e per permettere all'applicazione di utilizzare gli account e i gruppi Active Directory esistenti per il controllo dell'accesso.

Trovare la giusta comunicazione tra la cloud e l'ambiente on-premises è importante. Consentendo la connettività diretta a livello di IP, il servizio di connessione di Windows Azure soddisfa questa esigenza in modo semplice per le applicazioni Windows Azure.

Torna all'articolo principale 

Articolo succassivo

   

Martedì, 22 Novembre 2011 17:36

Rete per la distribuzione di contenuti (CDN)

Scritto da

Una delle funzioni più comuni dei blob è l'archiviazione di informazioni che devono essere accessibili da numerose posizioni diverse. Pensiamo ad esempio a un'applicazione che distribuisce video a client Flash, Silverlight o HTML 5 in tutto il mondo. Per migliorare le prestazioni nelle situazioni di questo tipo, Windows Azure fornisce una rete per la distribuzione di contenuti, o CDN (Content Delivery Network). La rete CDN archivia le copie di un blob in ubicazioni geograficamente più vicine ai client che utilizzano il blob, come illustrato nella figura 6.

 

Figura6: la rete CDN di Windows Azure memorizza nella cache copie di blob di ogni parte del mondo, permettendo agli utenti di accedere alle relative informazioni più rapidamente.

La figura non deve essere presa alla lettera: la rete CDN di Windows Azure dispone in realtà di molti più percorsi di cache globali di quelli illustrati, tuttavia il concetto è corretto. Quando un utente accede a un determinato blob per la prima volta, la rete CDN archivia una copia del blob in una posizione geograficamente vicina all'utente. Al successivo accesso al blob, il relativo contenuto verrà reso disponibile dalla cache anziché dalla posizione originale, più lontana.

Supponiamo ad esempio che Windows Azure venga utilizzato per trasmettere i video degli eventi sportivi di una giornata a un pubblico remoto. Il primo utente che accede a un determinato video non trarrà alcun beneficio dalla rete CDN, poiché il blob corrispondente non è ancora stato memorizzato nella cache in una posizione più vicina. Tutti gli altri utenti che si trovano nella stessa area geografica, tuttavia, sperimenteranno un miglioramento delle prestazioni, poiché l'utilizzo della copia memorizzata nella cache consente di caricare il video più velocemente.


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

Servizio di elaborazione

Scritto da

Il servizio di elaborazione di Windows Azure può eseguire applicazioni molto diverse tra loro. Qualunque sia la sua funzione, tuttavia, un'applicazione deve essere implementata come uno o più ruoli. Windows Azure esegue quindi più istanze di ogni ruolo, utilizzando la funzionalità di bilanciamento del carico incorporata per distribuire le richieste tra le varie istanze. Questo sistema di base è illustrato nella figura 3.

 

Figura3: un'applicazione Windows Azure in esecuzione è costituita da una qualsiasi combinazione di istanze di ruoli Web, ruoli di lavoro e ruoli VM (macchina virtuale).

Nella versione corrente di Windows Azure gli sviluppatori possono scegliere fra tre tipi di ruoli:

  • Ruoli Web, il cui scopo principale è quello di semplificare la creazione di applicazioni basate sul Web. Ogni istanza di ruolo Web è pre-configurata con Internet Information Services (IIS) 7, per semplificare la creazione di applicazioni mediante ASP.NET, Windows Communication Foundation (WCF) o altre tecnologie Web. Gli sviluppatori hanno anche la possibilità di creare applicazioni in codice nativo: non è infatti necessario utilizzare .NET Framework. Ciò significa che è possibile installare ed eseguire anche tecnologie non Microsoft, ad esempio PHP e Java.
  • Ruoli di lavoro, progettati per l'esecuzione di una varietà di codice basato su Windows. La più importante differenza tra un ruolo Web e un ruolo di lavoro è che quest'ultimo non è configurato con IIS ed esegue pertanto codice non ospitato da IIS. Un ruolo di lavoro può ad esempio eseguire una simulazione, gestire un'elaborazione video e molto altro ancora. Numerose applicazioni interagiscono con gli utenti attraverso un ruolo Web, affidando l'elaborazione delle attività a un ruolo di lavoro. Anche in questo caso gli sviluppatori sono liberi di utilizzare .NET Framework o un altro software eseguito su Windows, incluse le tecnologie non Microsoft.
  •  
  • Ruoli VM, ognuno dei quali utilizza un'immagine di Windows Server 2008 R2 fornita dall'utente. Un ruolo VM può essere utile, ad esempio, per migrare un'applicazione Windows Server on-premises in Windows Azure.

 

A tale scopo, gli sviluppatori possono utilizzare il portale Windows Azure, trasferendo insieme all'applicazione anche le informazioni di configurazione che indicano alla piattaforma il numero di istanze di ogni ruolo da eseguire. Il controller di infrastruttura di Windows Azure crea quindi una macchina virtuale (VM) per ogni istanza, eseguendo il codice relativo al ruolo appropriato in tale macchina virtuale.

Come illustrato nella figura 3, l'utente dell'applicazione può inviare richieste utilizzando protocolli quali HTTP, HTTPS e TCP. Tutte le richieste ricevute vengono distribuite a tutte le istanze di un ruolo mediante il servizio di bilanciamento del carico. Poiché questo servizio non consente la creazione di un'affinità con una determinata istanza di ruolo, non viene offerto alcun supporto per le sessioni permanenti, pertanto non esiste alcuna garanzia che più richieste inviate dallo stesso utente verranno indirizzate alla stessa istanza di un ruolo. Ciò significa che le istanze di ruolo di Windows Azure non devono mantenere il proprio stato tra le richieste. Ogni stato specifico del client deve invece essere scritto nell'archivio di Windows Azure, archiviato in SQL Azure (un altro componente della piattaforma Windows Azure) o gestito esternamente in altro modo.

Per creare un'applicazione Windows Azure, gli sviluppatori possono utilizzare qualsiasi combinazione di istanze di ruoli Web, ruoli di lavoro e ruoli VM. Se il carico dell'applicazione aumenta, è possibile utilizzare il portale Windows Azure per richiedere altre istanze per qualsiasi ruolo dell'applicazione. Se invece diminuisce, è possibile ridurre il numero di istanze in esecuzione. Windows Azure inoltre espone un'API per eseguire tutte queste operazioni a livello di programmazione (cambiare il numero di istanze in esecuzione non richiede un intervento manuale), ma la piattaforma in sé non gestisce automaticamente la scalabilità delle applicazioni in base al carico.

Per creare applicazioni Windows Azure si utilizzano gli stessi linguaggi e strumenti utilizzati per qualsiasi

altra applicazione Windows. Per un ruolo Web è ad esempio possibile utilizzare ASP.NET e Visual Basic oppure WCF e C#. Allo stesso modo, un ruolo di lavoro può essere creato in un linguaggio .NET, direttamente in C++ senza .NET Framework oppure in Java. Inoltre, anche se Windows Azure fornisce componenti aggiuntivi per Visual Studio, non è necessario lavorare all'interno di questo ambiente di sviluppo. Uno sviluppatore che ha installato PHP, ad esempio, potrebbe scegliere di utilizzare uno strumento diverso per scrivere le proprie applicazioni.

Per garantire il monitoraggio e il debug delle applicazioni Windows Azure, ciascuna istanza può chiamare un'API di registrazione per scrivere informazioni in un registro a livello di applicazione. È anche possibile configurare il sistema per raccogliere contatori delle prestazioni di un'applicazione, misurare l'utilizzo della CPU, archiviare dump di arresto anomalo del sistema e altro ancora. Queste informazioni vengono conservate nell'archivio di Windows Azure e gli sviluppatori possono creare codice per esaminarle. Ad esempio, se un'istanza di ruolo Web si arresta in modo anomalo tre volte in un'ora, un codice personalizzato potrebbe inviare un messaggio di posta elettronica all'amministratore dell'applicazione..

La capacità di eseguire codice è un requisito fondamentale di una piattaforma cloud, ma non è sufficiente. Le applicazioni necessitano anche di un archivio permanente. Soddisfare questa esigenza è l'obiettivo del servizio di archiviazione di Windows Azure, descritto nella sezione seguente.

Torna all'articolo principale

Articolo succassivo


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

Pagina 2 di 2