Aggiornamenti, backup e disaster recovery

Il ciclo di vita della golden image

Un ambiente Azure Virtual Desktop non si configura una volta sola: vive attraverso versioni di immagine. La golden image è l’artefatto centrale della manutenzione, e va trattata come codice — costruita in modo riproducibile con Azure VM Image Builder o con i custom image template, versionata e conservata in una Azure Compute Gallery. La gallery non è solo un archivio: è il meccanismo con cui una versione viene replicata nelle regioni dove servirà. Se una regione secondaria deve poter creare session host, la versione dell’immagine deve essere replicata lì, altrimenti al momento del bisogno non hai da cosa partire. Il criterio da portare all’esame è questo: la disponibilità regionale dell’immagine è una proprietà della versione nella gallery, non una copia manuale di un disco.

Aggiornare: pooled si sostituisce, personal si patcha

Su un host pool pooled i session host sono intercambiabili e non contengono stato utente: il profilo sta in un FSLogix profile container su share SMB. La strategia corretta è quindi ricostruire l’immagine e sostituire gli host: si aggiungono session host dalla nuova versione, si mettono i vecchi in drain mode (bloccano le nuove connessioni ma lasciano lavorare le sessioni già aperte), si attende lo svuotamento naturale o si pianifica il logoff in finestra, e infine si rimuovono. Il beneficio non è cosmetico: ogni host riparte da uno stato noto e il configuration drift sparisce.

Su un host pool personal la logica si ribalta. La macchina è assegnata a un utente e contiene il suo stato — applicazioni installate, personalizzazioni, dati locali. Ricostruirla significherebbe distruggerlo. Qui si applicano le patch in place, con gli strumenti di gestione degli aggiornamenti già in uso, accettando che nel tempo gli host divergano tra loro.

Disaster recovery: cosa si ricostruisce, cosa si replica

Un piano di DR parte dal requisito di ripristino, non dalla tecnologia, e poi separa i componenti in tre categorie con destini diversi.

I session host sono ricostruibili: derivano da un’immagine e da un’automazione di deployment. Replicarli è quasi sempre spesa inutile — meglio garantire che immagine e automazione siano pronte nella regione secondaria e ricrearli lì.

I profili FSLogix e i dati utente sono lo stato vero, l’unica cosa che non puoi rigenerare. Vanno replicati o resi comunque raggiungibili dalla regione secondaria, ed è esattamente lo scenario in cui la Cloud Cache si giustifica: scrivendo su più provider di storage rende il profilo disponibile anche se una destinazione cade. È una scelta di resilienza, con un costo in complessità, non un acceleratore di prestazioni.

I metadati di servizio — host pool, application group, workspace, assegnazioni, scaling plan — vanno ricreati con Infrastructure as Code o mantenuti già esistenti in parallelo. Ricordati anche delle dipendenze fuori da Azure Virtual Desktop: identità, file share, back-end applicativi. Un desktop che riparte in una seconda regione mentre l’applicazione resta nella prima è tecnicamente vivo e praticamente inutilizzabile.

Multi-region e backup

L’implementazione multi-region ha due forme. Nella prima, host pool attivi in più regioni servono gruppi di utenti diversi: il failover diventa una riassegnazione, il tempo di ripristino è basso, il costo è continuo. Nella seconda, la regione secondaria è pre-configurata ma dormiente e viene avviata solo all’evento: costo ridotto, ripristino più lento, e un rischio maggiore che qualcosa non sia allineato quando serve davvero.

Sul backup, la domanda utile è “cosa non posso rigenerare”: le share con i profili, i desktop personali (che contengono stato irripetibile) e le definizioni e versioni delle immagini. Fare il backup dei session host pooled è quasi sempre sprecato, perché sono derivati di un artefatto che hai già. E vale la regola finale: un piano di ripristino mai provato non è un piano, è un’ipotesi — il test periodico del failover fa parte del design, non dell’ottimismo.

Trappole tipiche d’esame

• Nuova versione di un’applicazione da distribuire su host pool pooled → nuova immagine e sostituzione dei session host con drain mode: patchare gli host uno per uno è l’opzione plausibile e sbagliata, perché reintroduce drift e non è ripetibile.
• Host pool personal da aggiornare senza perdere i dati utente → patch in place: riproporre qui il ciclo “ricostruisci da immagine” distrugge lo stato che appartiene all’utente.
• Svuotare gli host prima della manutenzione senza disconnettere chi sta lavorando → drain mode: non è uno spegnimento, blocca le nuove sessioni e lascia terminare quelle attive.
• Profili raggiungibili e resilienti in una seconda regione → Cloud Cache: se invece lo scenario chiede più prestazioni o meno latenza sul profilo, la Cloud Cache non è la risposta.
• Disaster recovery a costo contenuto con session host “da salvare” → replica i profili e ricrea gli host: replicare macchine ricostruibili è la distrazione classica della domanda.
• Deployment nella regione secondaria che fallisce al failover → versione di immagine non replicata nella Azure Compute Gallery: l’automazione c’è, l’artefatto da cui partire no.