VM Windows Server in Azure: capacita, disponibilita e accesso

Una VM Windows Server in Azure vive su due piani che l’esame tiene separati: il piano Azure (disco, size, set di disponibilità, NIC, regole di rete) e il piano guest (volume NTFS, configurazione IP nel sistema operativo, sessione RDP). Quasi tutte le domande di questo dominio nascono da un amministratore che ha agito su un piano aspettandosi l’effetto sull’altro.

Storage: il disco cresce in Azure, il volume no

I tipi sono cinque (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) e dall’8 settembre 2028 gli Standard HDD non saranno più usabili come disco OS.

Il punto che l’esame chiede davvero è il seguito dell’espansione. Quando allarghi un managed disk dal portale — un disco OS da 128 a 256 GiB — l’operazione Azure riesce, ma dentro Windows il volume resta com’era: va esteso nel guest. E l’estensione può fallire per cause precise:

• una partizione di recovery frapposta fra volume OS e spazio libero: si estende solo in spazio non allocato adiacente. Nelle VM Azure WinRE non viene usato, quindi la partizione si rimuove con diskpart (select partition, poi delete partition override) dopo uno snapshot del disco OS;
• l’unità di allocazione NTFS: con i 4 KB di default il volume si ferma a 16 TB, con 64 KB arriva a 256 TB. Si legge con fsutil fsinfo ntfsinfo C: (Bytes Per Cluster) e non si cambia senza riformattare: serve un disco nuovo e robocopy;
• partizionamento MBR quando bisogna superare i 2 TB: sul disco OS si converte con MBR2GPT /convert /allowFullOS, non disponibile su Windows Server 2016 ed è consigliato estendere il volume prima della conversione;
• Azure Disk Encryption su immagine custom, che può piazzare una System Reserved dopo il volume OS; e i permessi RBAC, quando a essere grigio è il pulsante Save del portale (serve Microsoft.Compute/disks/write).

Due note: sulle VM SQL Server da Marketplace lo storage pool blocca l’estensione classica e si passa dal menu SQL Server configuration; e un managed disk non si rimpicciolisce.

Capacità: resize della VM e scale set

Cambiare la size è la leva verticale: se la size di destinazione non è disponibile sul cluster hardware dove la VM gira, la VM va deallocata e riavviata altrove, con perdita del disco temporaneo e cambio dell’IP pubblico dinamico.

La leva orizzontale è il Virtual Machine Scale Set, che si scala in quattro modi: manualmente (sku.capacity, az vmss scale, Update-AzVmss -SkuCapacity), a schedule, su metriche, o con l’autoscale predittivo. La distinzione che l’esame sfrutta è fra le prime due: le regole su metrica reagiscono dopo il superamento della soglia, e fra il picco e le istanze pronte c’è un buco di prestazioni; le regole a schedule aggiungono istanze a un orario fisso e sono quindi la risposta corretta quando il carico è prevedibile (uffici che aprono alle 08:00 e chiudono alle 18:00, picco di fine mese).

Le metriche host — Percentage CPU, Network In/Out, Disk Read/Write Bytes e Operations/Sec, CPU Credits — non richiedono agenti. I contatori dentro il guest (la memoria disponibile) richiedono l’Azure diagnostics extension con uno storage account, o Application Insights per le metriche applicative. Limiti: 20 regole di autoscale per scale set e massimo 1.000 istanze con le automatic instance repairs attive.

Disponibilità: availability set, fault domain e zone

Un availability set distribuisce le VM su fino a 3 fault domain (alimentazione e switch di rete distinti) e fino a 20 update domain (riavvii di manutenzione uno alla volta, con 30 minuti di recupero); i due valori non si cambiano dopo la creazione. Due o più VM nel set danno l’SLA del 99,95% e il set non costa nulla. Una VM entra in un availability set solo al momento della creazione.

I dischi seguono le VM: tutti i managed disk di una VM stanno negli stessi fault domain, e i fault domain dei managed disk sono due o tre a seconda della region (az vm list-skus --resource-type availabilitySets). Da qui il caso che l’esame ama: se crei la prima VM, la fermi (deallocate) e poi crei la seconda, il disco OS della seconda può nascere nel fault domain della prima e le due VM finiscono condividendolo — lo si vede nella colonna Fault Domain del set. Regola: non fermare né deallocare VM fra un deployment e l’altro.

Per una resilienza superiore ci sono le availability zone (almeno tre per region, indipendenti per alimentazione, rete e raffreddamento): il set protegge dal guasto hardware, non dall’interruzione di un datacenter, in cambio di una latenza VM-a-VM più bassa. Microsoft raccomanda oggi lo scale set in modalità Flexible come opzione di HA più completa.

Accesso: JIT VM access e Azure Bastion

Due risposte diverse allo stesso problema — non esporre RDP a internet — che non vanno scambiate.

Sui permessi JIT: Reader + Security Reader per vedere; jitNetworkAccessPolicies/write più Microsoft.Compute/virtualMachines/write per configurare; jitNetworkAccessPolicies/initiate/action per richiedere accesso. Sugli SKU Bastion: client nativo, shareable link, connessione per indirizzo IP, porte custom e trasferimento file dallo Standard; session recording e deployment private-only, cioè senza IP pubblico, dal Premium; il Developer è gratuito, condiviso, una VM alla volta.

Rete della VM

Il numero di NIC dipende dalla size (tutte ne reggono almeno due) e aggiungere o rimuovere una NIC richiede la VM in stato Stopped (deallocated). Le NIC di una VM possono stare su subnet diverse ma devono appartenere alla stessa VNet, non possono essere già collegate ad altre VM, e almeno una deve restare. La prima è la primaria: per default il traffico in uscita esce dall’IP della sua configurazione primaria.

Vale ancora la regola del doppio piano: l’IP privato statico si imposta sulla ipconfig della NIC in Azure, non nel guest; cambiarlo fa riavviare la VM, e il valore eventualmente scritto nel sistema operativo deve coincidere, altrimenti si perde la connettività.

Trappole tipiche d’esame

• Disco OS portato da 128 a 256 GiB, ma in Windows C: è ancora 128 → soluzione: l’operazione nel portale è metà del lavoro; rientra nella VM, fai il rescan ed estendi il volume. Se Extend Volume è grigio cerca una partizione di recovery non adiacente, non un altro resize nel portale.
• Non si riesce a estendere oltre i 2 TB → soluzione: è il partizionamento MBR, non il tipo di disco; MBR2GPT /convert /allowFullOS, che su Windows Server 2016 non esiste. Il tetto dei 16 TB è invece un limite NTFS legato ai cluster da 4 KB e si risolve solo riformattando su un disco nuovo.
• Carico prevedibile alle 08:00 di ogni giorno feriale → soluzione: profilo di autoscale a schedule; abbassare la soglia CPU di una regola su metrica fa comunque scalare in ritardo e rende il sistema instabile.
• Due VM dello stesso availability set nello stesso fault domain → soluzione: è l’effetto di aver deallocato la prima VM prima di creare la seconda. E ricorda che una VM entra nel set solo alla creazione: dopo, va ricreata.
• JIT «non supportato» su una VM → soluzione: verifica Defender for Servers Piano 2 e la presenza di una NSG o di Azure Firewall; le VM classiche non sono ammesse. JIT apre e chiude porte: se l’obiettivo è non esporre 3389 per niente, la risposta è Bastion.
• Serve registrare le sessioni o un Bastion senza IP pubblico → soluzione: SKU Premium; lo Standard dà client nativo, shareable link e connessione via IP, ma non la session recording.