21

Feb

Windows Azure – Compute pt.1 – Architettura di alto livello e SDK

Abbiamo percorso una panoramica attorno all’ambiente Windows Azure per capire quali fossero i tasselli compositori base di questa piattaforma. Ora entriamo di più nel dettaglio.

Concordemente allo scenario comune di una soluzione Cloud, anche Azure dovrà presentare tratti somatici tipici del caso:

  • Computazione
  • Storage
  • Gestione dell’infrastruttura
  • SDK e/o ambiente di sviluppo per il deployment delle soluzioni

In tutto questo ricordiamoci che, requisito numero UNO per le soluzioni Cloud è garantire Scalabilità, Disponibilità ed essere tariffabile a consumo come una public utility. Un grafico riassuntivo della architettura di alto livello di Azure è presentato sotto.

image

Tutto parte dalla sottoscrizione: una sottoscrizione è un abbonamento che può fare un singolo individuo (policy già nota e rodata per i servizi online) dando come garanzia la propria carta di credito. Nota: molti pensano che esistano fee occulte quando l’utente lascia il proprio numero di carta e, sebbene questo sia spesso possibile con altri servizi online, in Azure paghi quello che consumi. Prima di partire quindi basterà ricordarsi che se abbiamo istanze attive all’interno della nostra sottoscrizione, stiamo pagando; altrimenti no.

Una volta creata la propria sottoscrizione, un utente può creare fino a 6 servizi al suo interno, detti anche deployment slots (proprio per indicare che sono a tutti gli effetti dei deployment distinti); tali slots non condividono alcuno spazio e sono isolati by-design: per farli comunicare tra di loro sarà necessario aprire il giusto canale tramite indirizzo pubblico.

Un servizio, all’interno di una subscription, può essere un package composto da vari “ruoli”, ovvero porzioni applicative. Un esempio tipico è la classica applicazione ASP.NET con processo batch coadiuvante: in tal caso si parlerà di due ruoli (Web+Worker) all’interno dello stesso servizio. Un servizio può avere fino a 5 ruoli diversi, ognuno dei quali però può avere un numero potenzialmente infinito di istanze associate (ad oggi questo numero è fissato a 20 istanze per subcription). Quando lo sviluppatore effettua il deployment del ruolo, decide quale sarà la dimensione della macchina virtuale che conterrà l’applicazione, deciderà quali endpoints aprire e le eventuali altre risorse da dichiarare: queste informazioni viaggiano con il deploy e non possono essere cambiate a runtime.

Se pensiamo in grande, con un grande numero di istanze per ruolo, significa che abbiamo una soluzione che dovrà necessariamente scalare; e come sarà organizzata l’architettura per permetterlo? Queste due figure riassumono bene tutti i concetti del caso.

image

Le grandi applicazioni seguono quasi tutte un certo pattern architetturale:

  • Le connessioni in ingresso arrivano tramite un load balancer che distribuisce il carico in base allo stato dei web server di cui esso stesso è al corrente
  • Ci sono alcuni web server (un pool) che non mantengono lo stato tra due diverse richieste client (questa è l’ipotesi semplificatrice)
  • Nota: nel caso di sticky sessions bisogna capire cosa utilizzare per persistere i dati della sessione tra diverse richieste client.
  • La rimozione/aggiunta di un web server non comporta nessun effort amministrativo
  • Ci sono i servizi di backend stateful, utilizzabili as-a-service, senza adoperare specifiche competenze IT.

image

Qui notiamo come:

  • Tutte le connessioni esterne vanno verso un load balancer (storage incluso)
  • Esistano inoltre alcune connessioni intra-servizio tra un ruolo ed un altro, senza passare dal load balancer e senza esporre nulla al di fuori della sottorete privata del servizio stesso.
by Roberto Freato on 2/21/2011
Post archive