Autoscale delle Virtual Machine con Microsoft Azure

Uno dei principali vantaggi che la piattaforma di Azure offre è la possibilità di scalare rapidamente le applicazioni in the cloud, in risposta alle fluttuazioni di carico.

Normalmente si scalano website o cloud services, ma se invece abbiamo le nostre applicazioni hostate su una Virtual Machine e le vogliamo scalare orizzontalmente? Anche questo è possibile.

Per farlo, vanno effettuati sostanzialmente 2 step: creare una Load Balanced Web Farm epoi configurare il servizio di AutoScale.

Ecco come:

Passaggi:

1. Creare una VM Standard ed assegnarla ad un availability set
2. Configurare la VM secondo le necessità (IIS, Application server, ftp, ecc...)
3. Clonare la VM
1. Sysprep 
2. Cattura
3. Ricreare la VM originale ed aggiungere tutti gli endpoint necessari
4. Creare la seconda  VM senza "endpoint extra"
5. Optional - ripetere il punto 3.4 per creare ulteriori VM
4. Bilanciare le VM
1. Cambiare gli endpoint sulla prima VM per creare un Load-Balanced set
2. Aggiungere gli endpoint alla seconda (terza, ecc...) VM sul Load-Balanced set
3. Ripetere i punti 4.1 e 4.2 per tutti gli endpoint che devono essere bilanciati
4. Fare attenzione al Session State (se necessario)
5. Configurare l'Autoscale

Dettagli:

3.1 - Sysprep

La prima cosa da fare quando si clona una VM Windows è il "sysprepping". Su Linux c'è un'opzione simile sull'Azure agent. Il Sysprep fa in modo che la macchina possa essere clonata in una nuova VM personalizzando le impostazioni come hostname ed indirizzo IP. 

Dopo il sysprep, la VM va spenta (se non si è selezionata l'apposita opzione che la spegne automaticamente). Può essere fatto in Remote Desktop, SSH oppure, semplicemente, dall'Azure portal.

3.2 - Cattura

A questo punto, nell'Azure portal bisogna andare sulla dashboard della VM e cliccare il bottone "Capture" per creare un immagine del disco della VM. Diamogli un nome e selezioniamo la checbox vicino a "Yes, I’ve sysprepped the machine" per poter continuare.

Dopo aver cliccato su "OK", Azure creerà l'immagine del nostro server "originale".

3.3 - Ricreare la VM originale ed aggiungere tutti gli endpoint necessari

Dopo che l'immagine è stata creata, si noterà che la VM che abbiamo appena "catturato"... non esiste più! È normale: la macchina è stata "smontata" per creare da essa un template. Ora quindi è possibile ricrearla semplicemente usando la nuova VM image appena create invece che uno dei template forniti da Microsoft.

Nella configurazione degli endpoint aggiungiamo di nuovo l'endpoint HTTP in ascolto sulla porta 80 o, comunque, tutti gli endpoint di cui abbiamo bisogno per poter utilizzare la nostra applicazione.

3.4 - Creare la seconda VM senza "endpoint extra"

Per creare la seconda VM nella webfarm basta creare una nuova macchina partendo sempre dall'immagine che è stata creata precedentemente.

Nello step 4 della creazione macchina assicuriamoci di selezionare lo stesso "Cloud Service" del primo server ed inserire la VM nello stesso availability set. 

NON aggiungere ancora alla macchinal'endpoint HTTP (o gli altri endpoint configurati al punto 3.3).

Ora abbiamo due macchine "uguali" in esecuzione, ma non sono ancora sotto bilanciamento. Noterete che entrambe le macchine sono già esposte con lo stesso nome host e che condividono lo stesso indirizzo IP pubblico virtuale. Ciò è dovuto al fatto che abbiamo precedentemente linkato le VM selezionando lo stesso Cloud Service. Se non lo fate, non sarete in grado di utilizzare il sistema di bilanciamento di carico che Azure fornisce out-of-the-box. Questo significa anche che l'endpoint per il desktop remoto pubblico dovrà essere diverso per entrambe le macchine: c'è un solo indirizzo IP esposto al mondo esterno quindi dovrete pensare  voi a differenziare l'endpoint.

4.1 - Cambiare gli endpoint sulla prima VM per creare un Load-Balanced set

L'ultima sezione per configurare la nostra webfarm è il load balancing.  Di fatto, configurarlo è molto semplice. 

Come prima cosa, andare sulla pagina "Endpoints" della prima VM, Selezionare un Endpoint che deve essere bilanciato ed andare in modifica.

Selezionare il checkbox "Create a Load-Balance set".

Nello step 2 della configurazione, dare un nome al Load-Balanced set e configurare i parametri di probe (nell'esempio, ho configurato un endpoint HTTPS, quindi voglio che sia monitorata ogni 15 secondi la risposta della porta 443. Dopo 2 tentativi falliti, il bilanciatore switcherà sull'altra macchina in via esclusiva)

4.2 - Aggiungere gli endpoint alla seconda (terza, ecc...) VM sul Load-Balanced set

Andare sulla dashboard della seconda VM, sull'Azure portal, e selezionare anche in questo caso la tab "Endpoints". Abbiamo gia aggiunto l'endpoint HTTPS alla prima macchina, quindi per la seconda basta "sottoscrivere" il load balanced set creato:

A questo punto abbiamo attivo il bilanciamento di carico con round-robin, che ogni n secondi verificherà che tutte le macchine e tutti gli endpoint configurati siano attivi e funzionanti. E visto che abbiamo linkato le VM attraverso un availability set, saranno in differenti fault domains nel datacenter riducendo il rischio di malfunzionamenti o errori dovuti a problemi hardware o manutenzione. È possibile anche spegnere tranquillamente una VM. Sostanzialmente, tutto quello che ci si può aspettare da un load balancer (ad eccezione delle sticky sessions).

4.4 - Fare attenzione al Session State (se necessario)

Ora che abbiamo le nostre VM bilanciate, dobbiamo stare attenti a come la nostra applicazione gestisce il session state.

Se, per esempio, stiamo deployando dei web server con sopra delle applicazioni Asp.Net dobbiamo configurare le machine key ed il sessione state nello stesso modo in cui lo faremmo se fossimo in un ambiente on-premise. Su Azure è possibile scegliere di usare la "solita" base dati delle sessioni (quindi Session state memorizzato su un Azure database), oppure usare l'Azure storage o ancora la "nuova" Azure cache.

Visitate questo link su msdn (http://blogs.msdn.com/b/cie/archive/2013/05/17/session-state-management-in-windows-azure-web-roles.aspx) per avere una panoramica della gestione del Session State su Azure.

5 - Configurare l'Autoscale

Ok, è giunto il momento di configurare l'autoscale!
Ora abbiamo le nostre VM attive e bilanciate. Ma abbiamo veramente sempre bisogno di averle tutte attive nello stesso momento? Probabilmente no. Magari abbiamo bisogno di averle tutte attive solo in una determinata fascia oraria oppure solo se il carico sull'applicazione supera una certa soglia...

Se vi ricordate, quando abbiamo creato le nostre VM abbiamo selezionato per tutte lo stesso Cloud Service. Ebbene, per configurare l'autoscale delle VM basta andare a configurare quello del relativo Cloud Service: andare quindi sulla dashboard del servizio e selezionare la pagina "Scale".

Da qui è possibile selezionare il tipo di scaling che vogliamo: None (scalign disattivato...), Cpu (in base a delle soglie di utilizzo del processore) o Queue. 

Nel mio caso, ho deciso di scalare usando la percentuale di utilizzo della CPU come parametro. Lo slider "Target CPU" riporta che io voglio scalare "in più" quando la media dell'utilizzo della CPU supera l'80% e scalare "in meno" quando riscende sotto il 60%. 

Nel mio esempio ho solo 2 VM, quindi posso configurare che in condizioni normali ce ne sia solo 1 attiva e che la seconda venga abilitata solo in caso di "scale up".

Dalla stessa schermata è anche possibile selezionare che il servizio scali automaticamente in base a delle fasce orarie configurabili.