Microsoft AZ-140: Operazioni, scalabilità e ottimizzazione degli host di sessione — Guida allo studio

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Virtual Desktop Specialty AZ-140 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le operazioni sugli host di sessione in Azure Virtual Desktop (AVD) si concentrano su tre discipline principali: dimensionamento corretto (right-sizing) e ingegneria delle prestazioni, scalabilità intelligente e gestione dell’alimentazione, e operazioni day-2 affidabili. L’obiettivo è fornire un’esperienza utente coerente durante i picchi di domanda, minimizzando al contempo la spesa nelle ore non di punta, il tutto senza compromettere la manutenibilità o la recuperabilità. Questa sezione spiega come progettare e gestire la scalabilità automatica (autoscale) di AVD con i piani di scalabilità, la configurazione di pianificazioni e capacità, gli stati operativi come la modalità di drenaggio (drain mode), e la risoluzione dei problemi di integrità e registrazione. Infine, collega le linee guida sul dimensionamento (inclusi i carichi di lavoro con GPU) e l’automazione con le leve di ottimizzazione dei costi come le prenotazioni (reservations), i piani di risparmio (savings plans) e il Vantaggio Azure Hybrid (Azure Hybrid Benefit).

Progettazione della Scalabilità Automatica: Piani di Scalabilità, Pianificazioni e Targeting dei Pool di Host

• Piani di scalabilità e targeting

  • Un piano di scalabilità definisce quando e come un pool di host condiviso (pooled) avvia, drena, arresta e dealloca gli host di sessione. Un singolo piano di scalabilità può essere applicato a più pool di host, anche in diverse aree geografiche (region).
  • Ogni pool di host target esegue il piano di scalabilità in modo indipendente nel contesto del proprio fuso orario. Utilizzare l’impostazione del fuso orario del piano di scalabilità per ogni pianificazione per allinearsi con l’orario di lavoro locale.
  • Tag di esclusione: definire una coppia chiave/valore di tag in modo che la scalabilità automatica ignori VM specifiche (ad es. canarini operativi o piloti di manutenzione).
  • La modalità di bilanciamento del carico è importante: la modalità breadth-first distribuisce le sessioni su più host (migliora le prestazioni istantanee, rallenta lo scale-in); la modalità depth-first concentra le sessioni su un numero inferiore di host (massimizza il consolidamento e il risparmio sui costi). Per una scalabilità automatica orientata ai costi, utilizzare la modalità depth-first con soglie di capacità appropriate.

• Pianificazioni: ramp-up, picco, ramp-down, non di punta

  • Ramp-up: avvia e prepara la flotta minima in anticipo rispetto alla domanda, quindi esegue lo scale-out quando le soglie di capacità vengono superate.
  • Picco (Peak): mantiene più capacità online per minimizzare la latenza e le code; lo scale-out continua se le soglie vengono superate.
  • Ramp-down: imposta gli host selezionati in modalità di drenaggio, consolida le sessioni e, dopo un periodo di tolleranza, spegne gli host inattivi.
  • Non di punta (Off-peak): mantiene una piccola baseline per l’accesso fuori orario; gli host inattivi rimanenti vengono deallocati per minimizzare la spesa.

• Soglie di capacità, disponibilità minima degli host e comportamento della scalabilità automatica

  • La soglia di capacità (%) è misurata rispetto alla capacità di sessione totale degli host online. Quando l’utilizzo medio supera la soglia, la scalabilità automatica avvia VM aggiuntive. L’utilizzo è determinato dal numero massimo di sessioni per host e dal conteggio delle sessioni correnti. Va regolata per ogni carico di lavoro; iniziare con il 60–70% per la modalità depth-first, 70–80% per la modalità breadth-first.
  • La disponibilità minima degli host può essere definita come un numero o una percentuale di host da mantenere in esecuzione in ogni fase della pianificazione. Mantenere sempre almeno un host di “riserva” per assorbire picchi improvvisi.
  • Sicurezza dello scale-in: la scalabilità automatica utilizza la modalità di drenaggio e controlli di “assenza di sessioni attive” per evitare di disconnettere gli utenti. Solo gli host inattivi vengono arrestati/deallocati.

• Gestione dell’alimentazione e deallocazione attenta ai costi

  • L’arresto (deallocazione) interrompe gli addebiti per la capacità di calcolo (compute); i dischi del sistema operativo e dei dati continuano a generare costi di archiviazione (storage). La scalabilità automatica dealloca gli host inattivi durante le fasi di ramp-down e non di punta.
  • L’opzione Start VM on connect può integrare la configurazione per le ore non di punta, avviando le VM deallocate quando un utente tenta di connettersi. Assicurarsi che l’identità gestita o il service principal del pool di host disponga delle autorizzazioni “VM Start” sul gruppo di risorse degli host di sessione.
  • Evitare l’arresto del sistema operativo guest senza deallocazione; lascia la VM allocata e fatturabile.

Stato Operativo, Manutenzione e Integrità: Modalità di Drenaggio, Notifiche e Registrazione

• Modalità di drenaggio e finestre di manutenzione

  • La modalità di drenaggio (AllowNewSession=false) impedisce nuovi accessi consentendo al contempo il completamento delle sessioni esistenti. Utilizzarla per applicare patch, aggiornare agent, sostituire immagini o per lo scale-in.
  • Approccio alla manutenzione: impostare l’host (o gli host) in modalità di drenaggio, attendere che diventi inattivo, disconnettere in modo controllato le sessioni persistenti dopo una notifica, quindi applicare gli aggiornamenti e riavviare. Verificare l’integrità/heartbeat e riabilitare le nuove sessioni.

• Strategia di notifica agli utenti

  • Notifiche del piano di scalabilità: configurare il messaggio di disconnessione e il periodo di tolleranza durante il ramp-down. Usare un linguaggio chiaro e con scadenze precise.
  • Notifiche supplementari: utilizzare Azure Automation (Send-AzVMRunCommand, notifiche toast tramite PowerShell) o Endpoint Manager per visualizzare messaggi all’interno della sessione prima della manutenzione.

• Stato dell’host di sessione, heartbeat e integrità dell’agent

  • Stati tipici: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Prerequisiti per l’heartbeat/agent: traffico in uscita sulla porta 443 verso gli endpoint del servizio AVD (usare il service tag AzureVirtualDesktop), risoluzione DNS stabile, sincronizzazione dell’ora e, se applicabile, join al dominio riuscito.
  • Servizi dell’agent: i servizi Remote Desktop Agent Loader e Remote Desktop Agent devono essere in esecuzione. L’agent AVD e lo stack side-by-side si aggiornano automaticamente se l’accesso in uscita è consentito.

• Registrazione e risoluzione dei problemi

  • Per aggiungere VM esistenti a un pool di host, creare un token di registrazione (valido per un tempo limitato) e installare/registrare l’agent AVD con tale token.
  • Passaggi comuni per l’isolamento dei guasti:
    • Verificare che l’host risulti come Registered e Available nel pool di host; in caso contrario, registrarlo nuovamente con un nuovo token.
    • Ispezionare il Visualizzatore Eventi (Event Viewer): controllare i log Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader e RDS/TerminalServices per errori di connettività o autenticazione.
    • Convalidare il DNS: la risoluzione del dominio e degli endpoint di servizio deve avere successo; se si utilizza Azure AD DS, assicurarsi che il DNS della VNet punti ai domain controller gestiti.
    • Confermare che Windows Firewall o le regole di sicurezza di rete consentano il traffico in uscita sulla porta 443 e che nessuna intercettazione TLS comprometta la fiducia nel servizio.

• Esempi utili di automazione

# Put a session host in drain mode (no new sessions)
Update-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-finance `
  -Name host1.contoso.com -AllowNewSession:$false

# Gracefully logoff idle users after notice (example)
Invoke-AzVMRunCommand -ResourceGroupName rg-avd -Name host1 `
  -CommandId RunPowerShellScript -ScriptPath .\Notify-And-Logoff.ps1

Dimensionamento, utilizzo e carichi di lavoro abilitati per GPU

• Selezione della dimensione della VM e dimensionamento basato sul carico di lavoro

  • Iniziare dalla caratterizzazione del carico di lavoro: produttività d’ufficio, knowledge worker con ottimizzazione per Microsoft 365 Apps e Teams, sviluppatore/ingegnere o grafica/3D.
  • CPU: mantenere la CPU sostenuta sotto il 70–75% con picchi brevi sotto l'85%. Monitorare Processor(_Total)% Processor Time e System\Processor Queue Length.
  • Memoria: puntare a un utilizzo inferiore all'80% (committed) con Memory\Available MBytes superiore a 500 MB per host; prestare attenzione al paging. La cache di FSLogix può aumentare il working set: dimensionare di conseguenza.
  • Storage: l’esperienza utente dipende dagli IOPS e dalla latenza del profilo FSLogix. Utilizzare Premium SSD v2, Ultra Disk per scenari ad alta intensità di temp/cache, e Azure Files Premium o Azure NetApp Files per profili ad alto numero di IOPS. Per ambienti molto grandi o profili a bassissima latenza, Azure NetApp Files offre la migliore consistenza.
  • Baseline iniziali (multi-sessione):
    • Produttività leggera: 4–8 vCPU, 16–32 GB RAM; breadth-first per la reattività.
    • Knowledge worker medio: 8–16 vCPU, 32–64 GB RAM; depth-first per l’efficienza dei costi.
    • Sviluppo/compilazione/dati pesanti: 16–32 vCPU, 64–128 GB RAM; considerare pool dedicati.

• Host di sessione abilitati per GPU

  • Per CAD/GIS/3D/video editing e visualizzazioni complesse, utilizzare NVads A10 v5 per profili vGPU granulari e un ottimo rapporto prezzo/prestazioni; considerare le famiglie NV v4/v5 dove appropriato.
  • Distribuire la NVIDIA GPU Driver Extension for Windows sulle VM della serie N. Convalidare la codifica hardware: abilitare AVC/H.264 e configurare “Use hardware encoding for Remote Desktop” tramite policy quando vantaggioso.
  • Monitorare la GPU con i Performance Counters (utilizzo del motore GPU, memoria GPU) e le metriche di Azure Monitor. Assicurarsi che ci sia un headroom di CPU sufficiente; le applicazioni ad alta intensità grafica sono comunque sensibili alla carenza di CPU (CPU starvation).

• Telemetria e ottimizzazione iterativa

  • Abilitare Azure Monitor per gli insight di AVD e Log Analytics. Tracciare CPU, memoria, latenza del profilo FSLogix, durata degli accessi, disconnessioni e tempi di brokering.
  • Regolare il MaxSessionLimit del pool di host e la modalità di bilanciamento del carico in base alla contesa osservata, quindi riadattare le soglie di autoscale di conseguenza.

Ottimizzazione dei costi: Alimentazione, scalabilità automatica, prenotazioni, piani di risparmio e AHB

• Allineare la scalabilità all’orario di lavoro

  • Usare la modalità depth-first con soglie di capacità conservative per consolidare le sessioni e accelerare lo scale-in. Combinare con la deallocazione nelle ore non di punta e la funzione Start VM on connect per accessi tardivi o rari.
  • Impostare un numero minimo di host ridotto ma non nullo per evitare picchi di avvio a freddo.

• Prenotazioni e piani di risparmio

  • Prenotazioni: le prenotazioni di VM a 1 o 3 anni bloccano SKU specifici in regioni specifiche per ottenere gli sconti maggiori; ideali per la capacità di base che è attiva per la maggior parte del tempo (ad es. la flotta nelle ore di punta diurne).
  • Compute Savings Plans: offrono sconti flessibili su famiglie di VM e regioni diverse; utili quando si utilizzano dimensioni miste o per ambienti dinamici in cui la prevedibilità esatta degli SKU è inferiore.
  • Prenotazioni di archiviazione: la capacità riservata di Azure Files può ridurre i costi di archiviazione di FSLogix su larga scala.

• Azure Hybrid Benefit (AHB) e gestione delle licenze

  • Applicare l’AHB a Windows Server e ai carichi di lavoro client Windows idonei per ridurre i costi di licenza del sistema operativo di calcolo. Assicurare l’idoneità e la conformità delle licenze.
  • Per le distribuzioni di Microsoft 365, verificare che le licenze coprano Windows Enterprise multi-sessione e Microsoft 365 Apps, ove applicabile.

• Script operativi e runbook

  • Usare Azure Automation o GitHub Actions per:
    • Sequenze di drain/abilitazione della flotta prima e dopo la manutenzione.
    • Script di warm-up pre-scalabilità il lunedì o dopo le festività pubbliche.
    • Risoluzione dei problemi di integrità (riavvio dei servizi dell’agente, nuova registrazione dell’host in caso di perdita dell’heartbeat).
  • L’orchestrazione basata su tag semplifica le operazioni selettive (ad es. taggare Environment=Pilot per escludere dallo scale-in).

# Start or stop idle hosts by tag (supplemental to native autoscale)
$hosts = Get-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-ops
foreach ($h in $hosts) {
  if ($h.Session -eq 0 -and $h.Tags["KeepOnline"] -ne "true") {
    Stop-AzVM -ResourceGroupName rg-avd -Name ($h.Name.Split("/")[1]) -Force -StayProvisioned:$false
  }
}

Scenario pratico

IKEA affronta picchi nei giorni feriali dovuti a progettisti 3D, ingegneri di prodotto e personale del call center che utilizzano app remote. La sera e nei fine settimana la domanda è bassa. Le sessioni supportate da GPU devono rimanere reattive, minimizzando al contempo il costo complessivo di calcolo.

1. Segmentare i pool di host per carico di lavoro

   • Creare tre pool di host condivisi: GPU-CAD (NVads A10 v5), KnowledgeWorker (serie D/E) e ContactCenter (serie D).
   • Perché: Allinea le dimensioni e la densità delle VM a profili di prestazioni distinti; consente finestre di manutenzione e scalabilità automatica indipendenti.

2. Associare un unico piano di scalabilità con pianificazioni basate sull’orario di lavoro

   • Definire una fase di avvio (ramp-up) alle 07:00, un picco dalle 09:00 alle 17:00, una fase di riduzione (ramp-down) dalle 17:00 alle 19:00, e ore non di punta per il resto del tempo; impostare il fuso orario sulla regione di ciascun pool.
   • Perché: Garantisce che la capacità sia pronta prima dell’arrivo degli utenti, consolida e spegne le risorse in modo controllato dopo l’orario di lavoro e rispetta gli orari regionali.

3. Ottimizzare le soglie di capacità e la disponibilità minima degli host per ogni pool

   • GPU-CAD: breadth-first, soglia di capacità 70%, minimo 30% di host online; KnowledgeWorker: depth-first, soglia 65%, minimo 10%; ContactCenter: depth-first, soglia 70%, minimo 15%.
   • Perché: I carichi di lavoro GPU preferiscono una distribuzione più ampia (breadth-first) per una maggiore reattività; i carichi di lavoro d’ufficio traggono vantaggio dal consolidamento (depth-first) per ridurre i costi; il call center richiede una riserva costante per i cambi di turno.

4. Abilitare Start VM on connect per i pool KnowledgeWorker e ContactCenter

   • Concedere all’identità gestita del pool di host le autorizzazioni di avvio della VM (VM Start); mantenere basso il minimo di host nelle ore non di punta.
   • Perché: Riduce i costi di esecuzione a vuoto preservando l’accesso just-in-time per accessi imprevisti fuori orario.

5. Implementare un flusso di lavoro per la manutenzione e le notifiche

   • Prima del Patch Tuesday: mettere il 20% di ogni pool in modalità di drain tramite tag; notificare gli utenti 30 minuti prima; dopo che le sessioni sono terminate, applicare le patch, riavviare, convalidare l’agente/heartbeat, quindi passare al gruppo successivo.
   • Perché: Il drain progressivo (rolling drain) evita disconnessioni di massa, preserva la continuità del servizio e riduce i picchi di richieste all’helpdesk.

6. Monitorare e iterare con Azure Monitor for AVD

   • Tracciare l’utilizzo di CPU, memoria, GPU, la durata degli accessi, la latenza di FSLogix; regolare mensilmente MaxSessionLimit e le soglie di scalabilità automatica.
   • Perché: L’ottimizzazione basata sui dati mantiene gli SLA e controlla la spesa man mano che i modelli di utilizzo evolvono.

7. Applicare le leve di costo

   • Prenotare capacità per 3 anni per il picco di base nei giorni feriali nei pool KnowledgeWorker e ContactCenter; usare un Compute Savings Plan per la domanda variabile di GPU; applicare l’Azure Hybrid Benefit dove idoneo.
   • Perché: Le prenotazioni garantiscono i maggiori risparmi per il carico di base prevedibile; i piani di risparmio si adattano ai picchi di GPU meno prevedibili; l’AHB riduce i costi di licenza del sistema operativo.

8. Rafforzare la registrazione e l’integrità

   • Mantenere un runbook permanente per registrare nuovamente qualsiasi host che mostri lo stato NoHeartbeat e convalidare DNS/ora. Mantenere tag di esclusione per gli host di diagnostica.
   • Perché: Una risoluzione rapida e automatizzata limita l’impatto sugli utenti e preserva la capacità durante problemi imprevisti dell’agente.

Con questo progetto, IKEA raggiunge gli obiettivi di prestazione diurni — inclusa la reattività delle GPU — deallocando in modo aggressivo la capacità al di fuori dell’orario di lavoro e automatizzando la manutenzione, ottenendo un’esperienza utente stabile e una riduzione misurabile dei costi.

← FSLogix · Tutti i domini · Applicazioni ed esperienza dell’utente finale →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →