Prima dei grafici: da dove arrivano i dati

Azure Virtual Desktop non tiene la propria telemetria pronta all’uso: va instradata. Il primo passo sono le diagnostic settings sugli oggetti del control plane — host pool, workspace, application group e lo stesso scaling plan — con destinazione un workspace Log Analytics. Da lì arrivano gli eventi di connessione, gli errori, i checkpoint della sessione, lo stato di registrazione e di salute degli agent sui session host.

È un piano diverso da quello del sistema operativo. Contatori di performance (CPU, memoria, disco, input delay) ed event log dei session host non passano dalle diagnostic settings: si raccolgono con l’agente di Azure Monitor e le relative data collection rule. Chi configura solo una delle due metà si ritrova metà dashboard vuota, ed è esattamente la situazione che l’esame descrive senza dirlo. Criterio pratico: un workspace Log Analytics condiviso per ambiente, così le query correlano eventi di connessione e metriche host senza cross-workspace, con la retention decisa in base a quanto indietro serve indagare.

Azure Virtual Desktop Insights e la diagnosi di un rallentamento

Azure Virtual Desktop Insights è la vista già confezionata sopra quei dati: connessioni e utenti attivi, prestazioni degli host, errori ricorrenti, tempi di accesso, disponibilità degli host. Ha una pagina di configurazione che segnala quali sorgenti mancano, ed è una workbook: se serve una vista su misura — per reparto, per host pool, per applicazione — si salva una copia e si estende con query proprie, senza inventare un’infrastruttura di monitoraggio parallela. Per il reattivo si affiancano alert di Azure Monitor con action group.

Quando un utente dice “è lento”, i dati da guardare sono pochi e sempre gli stessi. Il tempo di accesso scomposto nelle sue fasi dice se il collo di bottiglia è l’autenticazione, il caricamento del profilo o la shell. Il round-trip time dice se il problema è di rete: valori alti orientano verso la scelta della region, il percorso di connessione e l’eventuale abilitazione di RDP Shortpath. La saturazione di CPU o memoria dell’host indica che il numero di sessioni per host è troppo alto rispetto allo sizing, non che l’utente ha torto. Infine la disponibilità del profilo: gli errori del FSLogix profile container e la capacità residua della share spiegano da soli buona parte dei logon lenti o dei profili temporanei.

Scaling plan: l’autoscaling pianificato

Lo scaling plan è una risorsa a sé, assegnata a uno o più host pool, con un fuso orario e uno schedule articolato in ramp-up, peak, ramp-down e off-peak. In ogni fase si dichiara la soglia di capacità e la percentuale minima di host da tenere accesi; nelle fasi di riduzione si decide se e come far uscire le sessioni residue, con messaggio agli utenti e tempo di attesa prima del logoff forzato. Nelle fasi di crescita l’autoscaling accende host, non caccia nessuno.

Il trade-off importante è l’accoppiamento con l’algoritmo di bilanciamento: lo spegnimento produce risparmio solo se qualche host resta davvero vuoto, quindi depth-first è il compagno naturale dello scaling plan, mentre breadth-first privilegia l’esperienza utente e lascia sessioni sparse ovunque. Esistono scaling plan anche per host pool personal, ma lì la logica è diversa: si governa l’accensione e lo spegnimento del desktop assegnato, non la distribuzione del carico, che in personal non esiste.

Start VM on Connect, sessioni attive e drain mode

Start VM on Connect risponde a un problema diverso: accende un session host deallocato quando l’utente si connette. È la scelta per accessi sporadici o fuori orario, dove tenere host accesi “per sicurezza” è puro costo. Non spegne nulla da solo, quindi convive con uno scaling plan che si occupa della fase discendente.

La manutenzione quotidiana passa dalla gestione delle sessioni: disconnessione, logoff, invio di messaggi agli utenti e soprattutto drain mode, che impedisce l’arrivo di nuove sessioni su un host lasciando lavorare chi è già collegato. È il meccanismo con cui si svuota un host prima di sostituirlo con una nuova versione di immagine.

Trappole tipiche d’esame

  • Insights mostra le connessioni ma non CPU e memoria → mancano i dati dal sistema operativo: le diagnostic settings coprono il control plane; performance counter ed event log dei session host richiedono l’agente di Azure Monitor e le data collection rule.
  • Utenti che si collegano in orari imprevedibili e sporadici → Start VM on Connect: lo scaling plan segue una pianificazione e non sa che sta arrivando qualcuno fuori fascia.
  • Lo scaling plan non spegne quasi nulla in ramp-down → è l’algoritmo di bilanciamento: con breadth-first le sessioni restano sparse e nessun host si svuota; depth-first le concentra e libera host deallocabili.
  • Nuova immagine da distribuire senza buttare fuori chi lavora → drain mode: blocca le nuove sessioni e lascia svuotare l’host, poi lo si sostituisce; non disconnette le sessioni già attive.
  • “Gli utenti vanno avvisati prima dello spegnimento” → notifica e attesa nella fase di ramp-down: il logoff forzato appartiene alle fasi discendenti e solo se configurato, con messaggio e tempo di grazia; ramp-up e peak non interrompono nessuno.
  • Host accesi ma le sessioni non ci atterrano → guardare la salute dell’agent, non lo scaling: un host non registrato o con agent non sano esce dal bilanciamento pur restando acceso, quindi continua a costare senza servire utenti.