Cosa risolvono i Virtual Machine Scale Sets

I Virtual Machine Scale Sets (VMSS) permettono di gestire un gruppo di VM identiche come singola risorsa logica, aggiungendo o rimuovendo istanze in base al carico. Rispetto a VM singole con availability set, offrono elasticità reale (scale-out orizzontale) e sono la base per architetture stateless ad alta disponibilità. Da amministratore devi saper scegliere fra i due modelli di orchestrazione e disegnare correttamente autoscale, bilanciamento e distribuzione zonale.

Uniform vs Flexible orchestration

  • Uniform orchestration: tutte le istanze derivano da un unico model identico; ottimizzata per grandi flotte omogenee (fino a 1000 istanze) di workload stateless. Le VM non sono oggetti Microsoft.Compute/virtualMachines standard.
  • Flexible orchestration: le istanze sono VM standard a tutti gli effetti, gestibili singolarmente, con possibilità di mischiare dimensioni, immagini e persino VM aggiunte manualmente. È oggi il modello raccomandato per la maggior parte degli scenari perché unifica la gestione di VM singole e scalate e supporta meglio le availability zone con distribuzione garantita.

Scegli Flexible quando ti serve controllo granulare per istanza, mix di configurazioni o forte garanzia di spread zonale; Uniform quando gestisci flotte molto grandi e perfettamente omogenee.

Scale-out, scale-in e regole di autoscale

Lo scale-out aggiunge istanze quando il carico cresce; lo scale-in le rimuove quando cala. L’autoscale (basato su Azure Monitor) automatizza queste decisioni tramite un profilo con tre valori chiave:

  • minimum: istanze sempre attive (garantisce baseline e HA)
  • maximum: tetto di scala (protegge dai costi e dai limiti di quota)
  • default: valore usato se le metriche non sono disponibili

Regole metric-based vs schedule-based

  • Le regole basate su metriche reagiscono a segnali come Percentage CPU, memoria (via agente), lunghezza coda o metriche custom. Tipico: +1 istanza se CPU media > 70% per 10 minuti, -1 se CPU < 30%.
  • Le regole basate su schedule modificano min/max/default a orari o giorni prefissati (es. più capacità in orario lavorativo, meno di notte). Ideali quando il carico è prevedibile.

Puoi combinarle: uno schedule imposta la finestra di capacità e le regole metriche gestiscono le variazioni al suo interno. Quando più profili si sovrappongono, l’autoscale valuta prima gli schedule specifici.

Integrazione con bilanciatori e availability zone

Un VMSS raramente vive da solo: il traffico va distribuito sulle istanze che cambiano dinamicamente.

  • Azure Load Balancer (layer 4): per traffico TCP/UDP generico, backend interni, bassa latenza. Il backend pool si aggancia direttamente allo scale set e segue le istanze aggiunte/rimosse.
  • Application Gateway (layer 7): quando servono routing HTTP/HTTPS, terminazione TLS, path-based routing o WAF. È la scelta corretta per front-end web che necessitano ispezione applicativa.

Per l’alta disponibilità, distribuisci il VMSS su più availability zone: le istanze vengono ripartite tra zone fisicamente separate, sopravvivendo al guasto di un intero datacenter. Con Flexible orchestration puoi ottenere un spread zonale bilanciato esplicito. Ricorda che il bilanciatore deve essere Standard SKU (zone-redundant) per servire correttamente un backend multi-zona.

Ottimizzazione dei costi

  • Alza il minimum solo quanto basta per la baseline: ogni istanza minima è costo fisso 24/7.
  • Usa schedule-based scaling per abbassare la capacità nelle finestre a basso traffico.
  • Valuta Spot instances all’interno del set per workload interrompibili e tolleranti ai guasti.

Trappole tipiche d’esame

  • Scenario: le regole di autoscale continuano ad aggiungere e togliere istanze in modo oscillante (flapping). → Risposta: configura un cooldown adeguato e usa soglie asimmetriche (scale-out e scale-in distanti), così l’azione precedente si stabilizza prima della successiva.
  • Scenario: dopo uno scale-in gli utenti perdono la sessione. → Risposta: esternalizza lo stato (Azure Cache for Redis, database, storage condiviso); lo scale-in può terminare istanze con sessioni attive, quindi le VM devono restare stateless.
  • Scenario: serve routing HTTP con WAF davanti allo scale set. → Risposta: Application Gateway, non un Load Balancer layer 4.
  • Scenario: serve resilienza al guasto di un intero datacenter nella region. → Risposta: distribuisci il VMSS su più availability zone con Load Balancer Standard zone-redundant (un availability set protegge solo dai guasti a livello di rack, non zonali).
  • Scenario: occorre gestire ogni istanza come VM standard, con dimensioni miste. → Risposta: Flexible orchestration, non Uniform.