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

Creazione di un'applicazione Web scalabile

Scritto da

Immaginiamo che un'azienda desideri creare un'applicazione Web accessibile da Internet. La scelta standard oggi sarebbe quella di eseguire l'applicazione in un data center interno all'azienda o presso un apposito provider. In molti casi, però, la scelta migliore è affidarsi a una piattaforma cloud come Windows Azure. Se ad esempio un'applicazione ha la necessità di gestire un elevato numero di utenti simultanei, realizzarla su una piattaforma dedicata espressamente a questo scopo avrebbe più senso. Il supporto intrinseco per applicazioni e dati scalabili fornito da Windows Azure consente di gestire carichi decisamente superiori rispetto alle tradizionali tecnologie Web.

Supponiamo invece che il carico dell'applicazione subisca notevoli variazioni, con picchi di utilizzo alternati a periodi di calma. Questo comportamento è tipico ad esempio di sistemi di biglietteria online, siti di notizie con scoop occasionali, applicazioni utilizzate prevalentemente in particolari orari del giorno e così via. Eseguire simili applicazioni in un data center convenzionale comporterebbe la necessità di disporre in ogni momento di computer sufficienti ad affrontare i picchi, anche se tali computer rimarrebbero inutilizzati per lunghi periodi. Con le stesse applicazioni in Windows Azure, invece, l'azienda potrebbe espandere il numero di istanze ogni volta che si rendesse necessario e tornare a un numero ridotto di istanze nelle condizioni di normalità. Poiché il costo di Windows Azure si basa sull'utilizzo effettivo, ovvero sulle ore di utilizzo di ciascuna istanza, questa soluzione nella maggior parte dei casi potrebbe rivelarsi più conveniente rispetto alla manutenzione di computer che rimangono per lo più inutilizzati.

Per creare un'applicazione Web altamente scalabile in Windows Azure, gli sviluppatori possono utilizzare ruoli Web e tabelle, come illustrato nella figura 8..

 

Figura8: un'applicazione Web scalabile può utilizzare istanze di ruolo Web e tabelle.

Nell'esempio illustrato nella figura i client sono browser, pertanto la logica dell'applicazione può essere implementata utilizzando ASP.NET o un'altra tecnologia Web. È inoltre possibile, ad esempio, creare un'applicazione Web scalabile che espone servizi Web REST e/o basati su SOAP utilizzando WCF, quindi chiamare tali servizi da un client Silverlight. In ogni caso, lo sviluppatore specifica il numero di istanze del ruolo Web da eseguire e il controller di infrastruttura di Windows Azure crea il numero di macchine virtuali corrispondenti. Come accennato in precedenza, il controller di infrastruttura esegue anche il monitoraggio di queste istanze, assicurandone il giusto numero in ogni momento. Per l'archiviazione dei dati, l'applicazione utilizza le tabelle di archiviazione di Windows Azure, che forniscono capacità di scalabilità orizzontale dell'archiviazione, gestendo ingenti quantità di dati.

Torna all'articolo principale

Articolo succassivo

Martedì, 22 Novembre 2011 18:08

Windows Azure scenari di utilizzo

Scritto da

Capire il funzionamento dei componenti di Windows Azure è solo il primo passo. Per comprendere tutte le potenzialità di questa piattaforma, è importante esaminarne alcuni esempi di utilizzo. In questa sezione verranno illustrati diversi scenari di utilizzo di Windows Azure: la creazione di un'applicazione Web scalabile, la creazione di un'applicazione di elaborazione parallela, la creazione di un'applicazione Web con elaborazione in background, la creazione di un'applicazione con dati relazionali, la migrazione di un'applicazione Web on-premises con dati relazionali e l'utilizzo dell'archiviazione cloud da un'applicazione on-premises o ospitata.

Torna all'articolo principale

Articolo succassivo

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

Pagina 3 di 23