\ /
cloud  Cloud Native  DR  BestPractices  Azure  Hybrid Work  Azure Virtual Desktop 

Azure Virtual Desktop - Disaster Recovery Considerations

Il disaster recovery (DR) è un componente essenziale per qualsiasi infrastruttura IT poiché consente alle organizzazioni di proteggere i propri dati e le applicazioni critiche in caso di incidenti imprevisti.

Quando si tratta di Azure Virtual Desktop (AVD) l'implementazione di un piano di disaster recovery ben progettato è fondamentale per garantire la continuità operativa.

azure-avd-dr-concept-scenario-example-01b.png

Per implementare un piano di DR efficace è necessario rivedere l'attuale design e gli attuali processi per garantire che questo soddisfi tutti i requisiti aziendali e di business:

  1. Assessment dell'impatto per la perdita del servizio
  2. Obiettivi in termini di tempi di recupero (RTO/RPO)

rto-rpo-meaning01b.png

La posizione dei dati del DR è un'altro aspetto principale da considerare, idealmente si desidera che la region sia il più vicino possibile all'entry point dell'utente. Se l'ambiente AVD principale è eseguito in West Europe probabilmente sceglieremo North Europe.

azure-regions-europe01.png

Di per sè AVD è un servizio ad alta disponibilità distribuito globalmente da Microsoft, nel caso quindi di un outage i componenti saranno resi disponibili in un'altra region con un impatto minimo sul cliente. Dovremo però assicurarci che le risorse gestite dal cliente siano coperte e protette ovvero:

  1. Identity Provider (se si fa uso di Active Directory e non Azure AD)
  2. Networking
  3. Virtual Machine template (Golden image)
  4. Session hosts
  5. Storage e profili utente

azure-avd-components-01b.png

Identity Provider

La maggior parte delle organizzazioni adotta ancora un approccio ibrido all'identità avvalendosi quindi di un Active Directory tradizionale, l'ideale sarebbe avere un comain controller replicato in ogni region in cui è stata implementata l'infrastruttura.

Networking

Essendo per definizione una vNet isolata e spannata tra le AZ di una region per forza di cose sarà necessario configurarne una nella region di DR scelta. La vNet deve disporre di funzionalità di peering o VPN per accedere a tutte le rete richieste per la normale operatività aziendale.

azure-avd-dr-network-peering-vpn-01b.png

Golden Image

Può essere che il piano di DR preveda una ricostruzione piuttosto che una replica quindi sarà necessario garantire che l'immagine della VM da cui viene creato l'ambiente AVD sia disponibile nella region di DR. Con Azure Compute Gallery possiamo creare una VM Image Definition che conterrà le versioni di immagini che possono a loro volta essere replicate in altre region.

Storage & User profiles

Solitamente si fa uso di FSLogix per l'archiviazione come container dei profili utente su Azure Storage Account File Share. Questo software permette di configurare la funzionalità di Cloud Cache e replicare il dato del profilo in tempo reale su un'altra file share.

azure-avd-fslogix-cloudcache-storage-01.png

Session Hosts VM

Per quanto riguarda le macchine di sessione dell'ambiente ci sono varie opzioni:

  • Replica delle VM con Azure Site Recovery (consigliata da Microsoft)
    • Questa strategia è particolarmente adatta per VDI di tipo personal dove i profili utente sono salvati in locale
    • In caso di guasto della regione primaria, verrebbe invocato il failover delle macchine virtuali e le macchine di replica diventerebbero attive per le connessioni degli utenti al server
  • Pre-creazione degli host nella region di DR
    • Questa strategia non è adatta per VDI di tipo personal in quanto i dati degli utenti andrebbero persi
    • Questi host saranno presenti nello stesso pool degli host di sessione primari e saranno spenti fino a quando non saranno necessari
  • Creazione degli host nella region di DR al momento
    • Non comporta costi di replica o storage/computing

azure-siterecovery-vm-iaas-concept-scenario-example-01b.png

Singolo pool di host o multiplo

Una considerazione da fare quando si fa la progettazione è se si dispone di un unico pool di host che conterrà tutti gli host di sessione o se si distribuiscono gli host di sessione DR in una configurazione di pool separata.

Nella maggior parte dei casi si estende il pool di host esistente all'ambiente DR, così facendo gli utenti finali non subiranno alcuna differenza lato experience, si collegheranno allo stesso pool di host e alla stessa sessione desktop del gruppo di applicazioni.

La creazione di un pool di host DR separato richiederebbe la creazione di tutti i gruppi di applicazioni e la configurazione con il sito DR. Uno use case potrebbe essere quello di limitare l'accesso al DR a un sottoinsieme specifico di utenti.

Reference

comments powered by Disqus