Nel post precedente abbiamo visto quali sono i tool necessari per poter iniziare a sviluppare una soluzione per Windows Azure, quali sono gli elementi che la compongono e le funzionalità che i role possono utilizzare. In questo post realizzeremo una semplice soluzione utilizzante un web role e vedremo inseme quali sono le configurazioni ed i meccanismi in gioco.
Iniziamo con il lanciare Visual Studio e cliccare sul link nuovo progetto della pagina iniziale:
Selezionando le template Cloud viene proposto il modello del progetto Windows Azure. Specificando il nome e premendo OK, viene mostrata una finestra che permette di scegliere quali role utilizzare all’interno della soluzione:
La scelta possibile è tra:
- Web Role ASP.NET
- Web Role ASP.NET MVC2
- Web Role Servizio WCF
- Web Role CGI
- Worker Role
I primi due permettono di pubblicare un servizio con front end web (nel secondo caso sviluppata usando MVC 2). Il Web Role Servizio WCF, come intuibile dal nome, permette di creare un Web Role preconfigurato per la pubblicazione di un servizio WCF. Il Web Role CGI permette di inserire un progetto per una web application FastCGI che utilizza codice nativo all’interno del Cloud Service. Il Worker Role, come visto nel post precedente, permette di creare un componente eseguito all’esterno del contesto IIS come, ad esempio, un processo per l’esecuzione di task in background. Nel nostro caso ci limiteremo ad inserire solo un web role. Premendo OK il progetto viene creato:
Osservando la soluzione è possibile notare che è composta da due progetti: il WindowsAzureProject1, con lo stesso nome della soluzione, contenente i file di configurazione del servizio e una cartella contenente i role e il progetto web WebRole1, avente la stessa struttura di una comune web application eccettuata la presenza del file WebRole.cs.
Apriamo questo file:
vediamo che si tratta di una classe derivata dalla classe RoleEntryPoint. Questa classe, utilizzata da Windows Azure per comunicare con le istanze, possiede tre metodi di sicuro interesse:
- public virtual bool OnStart()
- public virtual void OnStop()
- public virtual void Run()
Durante l’esecuzione del metodo OnStart l’istanza viene posta allo stato Busy ed è indisponibile alle richieste ricevute dal load balancer. Questo metodo è utile per effettuare tutte le inizializzazioni necessarie prima dell’avvio del servizio.
Se il metodo OnStart ritorna falso l’istanza viene immediatamente arrestata, in caso contrario viene avviata chiamando il metodo Run. Questo consiste essenzialmente in un thread in esecuzione continua. Nell’implementazione di default il thread va in sleep per un tempo infinito, bloccando il ritorno del metodo.
Il metodo OnStop, chiamato da Windows Azure allo shutdown dell’istanza, viene utilizzato per implementare il codice necessario per gestire l’arresto regolare. Il metodo OnStop deve ritornare entro un certo tempo, in caso contrario Windows Azure interromperà forzatamente l’esecuzione dell’istanza del role.
Come detto in precedenza nel progetto del cloud service è presente una cartella contenente i riferimenti ai role e i due XML file di configurazione ServiceConfiguration.cscfg e ServiceDefinition.csdef. Questi file contengono tutte le impostazioni del servizio e dei role in esso contenuti. Sebbene molte impostazioni siano configurabili solo attraverso la loro modifica (vedi MSDN), quelle principali possono essere effettuate usando l’interfaccia grafica. Basta fare click con il tasto destro su uno dei role e selezionare Proprietà.
I permessi disponibili per un role dipendono dal livello di trust con cui il role è stato pubblicato. Sono disponibili due livelli di trust: partial trust e full trust. L’impostazione di default prevede l’esecuzione in full trust. Maggiori informazioni sul livello di trust sono disponibili sugli articoli dell’MSDN Hosting Web and Worker Roles Under Full Trust e Windows Azure Partial Trust Policy Reference.
Nella sezione Instances è possibile impostare il numero di istanze utilizzate dal role e la tipologia di virtual machine su cui devono essere eseguite. Al fine di rientrare nello SLA di Windows Azure, che prevede una disponibilità del compute service del 99.95%, è necessario attivare almeno due istanze per role.
Le dimensioni disponibili per le macchine virtuali sono:
| Virtual Machine | CPU Cores | RAM | Local Storage |
| ExtraSmall | Shared | 768 MB | 20 GB |
| Small | 1 | 1.75 GB | 225 GB |
| Large | 4 | 7 GB | 1000 GB |
| ExtraLarge | 8 | 14 GB | 2040 GB |
Per controllare il funzionamento dei role eseguiti in full trust (e valutare l’opportunità di scalare in alto o in basso) è possibile utilizzare Windows Azure Diagnostics che permette di campionare informazioni dai performance counters e memorizzarle sul cloud storage.
La voce di configurazione Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString contiene la stringa di connessione al cloud storage utilizzato a questo scopo o la stringa “UseDevelopmentStorage=true”, indicante l’utilizzo del Development Storage del kit di sviluppo.
Per configurare la raccolta dei dati andiamo sul metodo OnStart() della classe vista in precedenza e inseriamo il codice seguente:
In seguito all’avvio del progetto avremo modo di vedere che ci permetterà di monitorare il livello di occupazione di CPU per le istanze del web role campionando i valori ogni 10 secondi e memorizzando i valori sulla tabella WADPerformanceCountersTable del Development Storage ogni minuto. Maggiori dettagli sull’utilizzo di Windows Azure Diagnostics è disponibile sull’MSDN.
Come visto in precedenza, ogni istanza del web role può utilizzare uno spazio di storage locale la cui dimensione varia a secondo del tipo di virtual machine selezionata. Questo spazio può essere configurato, definendo delle risorse cui viene attribuito un nome e una dimensione, attraverso le impostazioni relative.
E’ bene ricordare che il local storage è da considerarsi volatile anche se non viene impostato per la cancellazione in caso di riciclo del role e pertanto va utilizzato solo per la memorizzazione di file temporanei.
E’ giunto il momento di avviare il nostro primo progetto ma, prima di lanciare il debug, vi consiglio di cliccare col tasto destro sul logo di Windows Azure sull’area di notifica (il Windows Azure Simulation Monitor) e selezionare Show Compute Emulator UI. In questo modo avrete modo di vedere l’effetto del deployment e, cliccando sulle singole istanze del web role, il susseguirsi degli eventi che portano all’avvio.
Ad avvio completato, viene lanciato il browser e caricata la pagina Default.aspx del web role. Il primo passo verso le nuvole è fatto, adesso non vi resta che dare un’occhiata ai dati diagnostici sul Development Storage utilizzando il Server Explorer di Visual Studio. Alla prossima!
Vittorio Polizzi 