Pooled o personal: la forma dell’ambiente

L’host pool è l’unità di progettazione di Azure Virtual Desktop: definisce quali session host esistono, come vengono assegnati e con quale esperienza l’utente ci atterra. Il tipo si sceglie alla creazione e condiziona tutto il resto, quindi è la decisione da prendere per prima.

In un host pool pooled molti utenti condividono lo stesso insieme di session host: la sessione atterra sull’host scelto dall’algoritmo di bilanciamento, e a ogni accesso può essere un host diverso. Il costo per utente è basso, perché la densità è alta e il parco macchine si dimensiona sulla concorrenza reale, non sul numero di utenti nominali. È la scelta naturale per popolazioni omogenee di task worker che usano lo stesso set di applicazioni e non hanno bisogno che la macchina ricordi nulla di loro: la persistenza la garantisce il FSLogix profile container su una share SMB, non il disco locale.

In un host pool personal ogni utente riceve un session host dedicato, con assegnazione automatica (al primo accesso) o diretta (l’amministratore assegna l’host a un utente specifico). Serve quando l’utente installa software, quando un’applicazione richiede stato a livello di macchina, quando esistono vincoli di tracciabilità o driver particolari. Il costo per utente è nettamente più alto e la densità è per definizione uno a uno. Punto che l’esame ama: un host pool personal non ha bilanciamento di carico, perché non c’è nulla da bilanciare — la sessione va sempre e solo sull’host assegnato.

Breadth-first o depth-first: esperienza contro costo

Sui soli host pool pooled si sceglie l’algoritmo di bilanciamento. Breadth-first distribuisce le nuove sessioni sugli host disponibili, tenendo bassa la concorrenza su ciascuno: è l’impostazione che privilegia l’esperienza utente, perché riduce la contesa su CPU, memoria e I/O, ma mantiene acceso un numero maggiore di macchine. Depth-first riempie un host alla volta fino al limite di sessioni configurato prima di passare al successivo: consolida gli utenti, lascia host vuoti e quindi spegnibili, e privilegia il costo. Il trade-off è tutto qui, ed è amplificato dall’autoscaling: depth-first ha senso soprattutto quando uno scaling plan può effettivamente spegnere gli host liberati nelle fasi di ramp-down e off-peak.

Sistema operativo: multi-session, single-session, Windows Server

Windows multi-session è pensato per la densità: più utenti simultanei sullo stesso session host, ed è la combinazione tipica con un host pool pooled. Windows single-session ospita un solo utente per volta ed è la scelta per gli host pool personal, oppure per applicazioni certificate solo su Windows client desktop. È legittimo anche un pooled con OS single-session, ma la densità resta di un utente per host: si perde il vantaggio economico del pooled e si tiene solo la rotazione sugli host liberi.

Windows Server come session host resta valido quando servono ruoli, applicazioni o driver supportati solo su Server, o quando esiste già una farm Remote Desktop Services da portare in Azure. Cambia però il modello di licenza.

Capacity planning e licenze

Il dimensionamento si fa per profilo d’uso, non a occhio: carico leggero (browser, produttività base), medio (più applicazioni line-of-business), pesante (sviluppo, dataset ampi, molti processi) e carichi GPU (CAD, rendering, grafica 3D), che richiedono size con GPU e driver dedicati. Il metodo corretto è stimare la concorrenza massima, non gli utenti totali, misurare su un pilota rappresentativo e ricalibrare: le raccomandazioni puntuali di utenti per vCPU o di serie di VM cambiano nel tempo, quindi vanno lette sulla documentazione ufficiale al momento del progetto.

Sul fronte licenze, l’accesso ad Azure Virtual Desktop con session host Windows client è coperto dalle licenze idonee (le suite Microsoft 365 e Windows Enterprise per utente), mentre per gli utenti esterni esiste il modello per-user access pricing; compute, storage e networking si pagano comunque a consumo. Con session host Windows Server, invece, entra in gioco il requisito delle RDS CAL, che la licenza Microsoft 365 non sostituisce.

Trappole tipiche d’esame

  • Gli utenti devono installare applicazioni e ritrovarle al riavvio → host pool personal: il profile container FSLogix persiste il profilo, non le installazioni a livello di macchina; su pooled l’utente atterra su un altro host e l’applicazione non c’è più.
  • Ridurre la spesa compute fuori dalle ore di punta → depth-first più scaling plan: breadth-first spalma le sessioni e tiene accesi quasi tutti gli host, vanificando il ramp-down.
  • “Distribuire meglio il carico” su un host pool personal → nessuna delle opzioni di load balancing: su personal l’algoritmo non esiste; la leva è l’assegnazione, o il ridimensionamento del singolo host.
  • Session host Windows Server → RDS CAL obbligatorie: avere Microsoft 365 E3/E5 per gli utenti non basta quando l’OS del session host è Windows Server.
  • Applicazione non supportata su multi-session → OS single-session: accettando la perdita di densità, e valutando se convenga isolarla in un host pool dedicato con application group RemoteApp anziché convertire tutto l’ambiente.
  • Esperienza utente prioritaria con budget vincolato → breadth-first con limite di sessioni tarato: il limite di sessioni per host, non l’algoritmo, è la protezione contro la saturazione del singolo session host.