19

May

Windows Azure – Deployment pt.1 – Modello di servizio

Vediamo come è organizzato il modello di servizio di Windows Azure e come è previsto ad oggi il sistema di deployment delle applicazioni. Abbiamo imparato che l’applicazione consta di:

  • un Service Definition (csdef) inserito nel pacchetto di deployment (il codice + il csdef vengono zippati e poi crittografati)
  • un Service Configuration (cscfg) che può essere uploadato e modificato a runtime

Questa coppia costituisce l’applicazione Azure.

Faults Domains e Upgrade Domains

Windows Azure è Cloud Computing e il cloud computing ha come primo comandamento l’essere scalabile e disponibile. Per cui se io decidessi di allocare 2 istanze su una applicazione, non mi aspetto che essere risiedano sullo stesso server fisico… nel caso di un incendio? Azure definisce quindi il concetto di dominio di fallimento (fault domain) come la minima unità hardware implicata nel processo di deployment (per semplicità si può pensare ad un rack). Il valore di default del fault domain è di 2, significando che alla seconda istanza allocata essa verrà creata sicuramente (ci pensa il fabric) su un secondo fault domain.

Il concetto di FD viene anche ripreso nella definizione di SLA di Microsoft, che richiede all’utenza di attivare almeno due istanza per ruolo, proprio per poter avere la distribuzione fisica e quindi garantire un up-time del 99,95%.

E che cos’è l’Upgrade Domain? Si tratta di gruppi logici (default 5) in cui vengono raggruppate le istanze per eseguire l’upgrade dell’applicazione. Così facendo si continua infatti a garantire continuità di servizio e l’utente finale non percepirà mai il down-time dovuto all’aggiornamento (questo è vero solo in alcune condizioni, ad esempio la presenza di almeno due istanze): il load balancer “staccherà” a turno gruppi di istanze per aggiornarle.

image

Staging e Production

Abbiamo due ambienti su Azure: Staging e Produzione. La differenza tra i due ambienti è esclusivamente di endpoint, poichè il comportamenti di entrambi è il medesimo. Quando si distribuisce l’applicazione in staging essa sarà disponibile su [deploymentID].cloudapp.net, quando si distribuisce in produzione sarà invece [name].cloudapp.net.

Ci sono fondamentalmente due modi di pubblicare l’applicazione. La prima, la più banale, è di andare nello slot interessato (Staging o Prod) e fare quel che si dice una In-Place upgrade: si pubblica direttamente l’app nell’ambiente desiderato e se c’è già una applicazione la si va a sostituire (cancellando e ri-pubblicando). La secondo è il VIP swap, ovvero si distribuisce l’app prima in staging e poi si clicca su “swap” per portare l’ambiente in produzione (la tecnica è comoda per verificare che sia tutto ok prima del rilascio).

Nota: quando si cancella un deployment, non è garantita la preservazione dell’IP associato, per cui in caso di DNS basato su Record A o whitelisting del proprio IP, questo genere di operazione può recare dei problemi (motivo per cui Microsoft consiglia l’utilizzo dei  CNAME).

by Roberto Freato on 5/19/2011
Post archive