26

Feb

Windows Azure – Compute pt.3 – La configurazione e il monitoring

Partiamo dal considerare gli unici due file importanti coinvolti nel processo di configurazione:

  • CSDEF: il service definition
  • CSCFG: il service configuration

Il nostro codice e tutto il pacchetto è racchiuso nell’archvio CSPKG, nel quale ci sarà anche la definizione del servizio, utile al deployment dell’infrastruttura.

Ciò che non è incluso nel pacchetto, poichè può essere potenzialmente molto variabile durante il tempo, sono i parametri di configurazione attuali del progetto e una serie di impostazioni modificabili anche a runtime, contenuti nel service configuration. Ovviamente per poter procedere con un deploy corretto, è necessario pubblicare la configurazione iniziale o tramite il Web Portal, oppure direttamente da Visual Studio. Di seguito alcuni esempi di CSDEF e CSCFG:

image

image

Nella definizione del servizio dobbiamo decidere quale sarà la dimensione della macchina virtuale host dell’applicazione. Al momento Azure non supporta l’upgrade dinamico della dimensione della macchina virtuale: è perciò necessario il ri-deploy. Le dimensioni e le caratteristiche delle macchine sono le seguenti:

image

Dove la dimensione Extra Small è stata introdotta da pochissimo e oltretutto rompe lo schema delle proporzioni tra le pregresse dimensioni di instanza. Prima infatti della Extra Small ogni istanza era multiplo di una istanza small (esattamente come fa AWS, anche in termini quantitativi molto simili), cosa che si vede sia dalle risorse che dai prezzi. L’istanza Extra-Small ha dichiaratamente un core condiviso, anche se probabilmente il modello ricalca molto quello di AWS in cui la più piccola istanza ha in realtà fino a due core condivisi, in modalità da gestire burst di computazione di breve durata, limitando il throughput sul lungo periodo.

Networking

In Azure abbiamo la possibilità di comunicare con la nostra istanza in 3 modi:

  • Un public endpoint
  • Un endpoint interno intra-role
  • Windows Azure Connect

I primi due sono banali mentre il terzo è ancora in beta, ma già promette bene per venire incontro alle necessità di tutte le organizzazioni modestamente grandi. L’idea di Windows Azure Connect, anche se ne parleremo più in là, è quella di fare da ponte tra la rete Azure e la rete aziendale, tramite IPsec, per far comunicare i ruoli Azure con, per esempio, i database legacy o i sistemi intra-organizzazione.

Local Storage

Sempre in fase di configurazione, possiamo definire quello che viene chiamato LocalStorage. Partendo dal presupposto che in Azure tutto dovrebbe rimanere astratto (è un PaaS, dovremmo solo interessarci della applicazione) non dovremmo fare assunzioni riguardo a come viene gestito il sistema operativo, lo spazio su disco e via dicendo. Così, se per necessità di sviluppo dovesse servire uno storage temporaneo (la tipica cartella %TEMP%), Windows Azure mette a disposizione il LocalStorage, accessibile così:

image

Perchè questo codice non dia eccezione bisogna preventivamente dichiarare che utilizzeremo un LocalStorage nel file di configurazione, dare ad esso un nome e specificare gli eventuali parametri, così:

image

Un riflessioni sull’attributo “cleanOnRoleRecycle”. Siccome ripeto: NON dobbiamo interessarci del ciclo di vita dell’OS sottostante, non dovremmo fare supposizioni su quanto possa permanere un dato scritto in un local storage (è temporaneo, dobbiamo farcene una ragione). Tuttavia, al solito, una richiesta dalla CTP è stata quella di poter preservare questo spazio, cosa ora possibile impostando a false l’attributo sopra.

Settings e ciclo di vita di RoleEnviroment

Il RoleEnvironment è il tassello chiave di tutta l’applicazione Azure. Da esso possiamo accedere ai parametri di configurazione, alle informazioni sulla struttura e via dicendo. Per quello che abbiamo detto prima oltretutto, tutte le configurazioni dovrebbero essere poste nel CSCFG, anche quelle che normalmente porremmo nel Web.Config dell’applicazione: questo perchè il web.config è parte integrante del deploy e non può essere cambiato a runtime, se non con un ri-deploy. Possiamo perciò cambiare il cscfg di configurazione a runtime e intercettarne gli eventi:

  • RoleEnvironment.Changing: avviene prima che la configurazione nuova venga posta in atto e può essere cancellata
  • RoleEnvironment.Changed: avviene dopo che la nuova configurazione è stata applicata

In tutto questo le modifiche possono essere fondamentalemtne di due tipi: alle settings (RoleEnvironmentConfigurationSettingChange) e alla topologia (RoleEnvironmentTopologyChange), quando vengono per esempio aumentate le istanze di un ruolo.

RoleEnvironment è anche l’entrypoint per la gestione del monitoring e del logging della applicazione, vedremo più in là nel dettaglio di cosa si tratta.

by Roberto Freato on 2/26/2011
Post archive