Il disaster recovery plan, o piano di ripristino da disastro, è un documento strategico che definisce le procedure e le azioni da intraprendere per garantire il ripristino delle operazioni aziendali in seguito a un evento eccezionale di crash o a un’interruzione significativa dei servizi. Questo piano prevede una serie di misure preventive, come la creazione di backup regolari dei dati critici e la messa in sicurezza delle infrastrutture, nonché azioni di mitigazione e di recupero, come la riparazione o la sostituzione di hardware danneggiato e la ripristino dei dati. L’obiettivo principale di un disaster recovery plan è quello di minimizzare l’impatto negativo di un disastro sulla continuità operativa dell’azienda, garantendo la ripresa delle attività nel minor tempo possibile.
Il Disaster Recovery è quindi una componente essenziale per qualsiasi infrastruttura IT e, soprattutto quando si utilizza Azure Virtual Desktop (AVD), l’implementazione di un piano di disaster recovery ben progettato è fondamentale per garantire la continuità operativa.
Per fare questo, è necessario rivedere il design e gli attuali processi per garantire che questi soddisfino tutti i requisiti aziendali e di business:
- Assessment dell’impatto per la perdita del servizio
- Obiettivi in termini di tempi di recupero (RTO/RPO)
La posizione dei dati del piano di Disaster Recovery è un altro aspetto principale da considerare: solitamente si desidera che la region sia il più vicino possibile all’entry point dell’utente. Se l’ambiente AVD principale è eseguito nell’Europa occidentale, probabilmente sceglieremo “North Europe”.
Preparare un piano di Disaster Ricovery: l’esempio di Azure Virtual Desktop
Di per sé Azure Virtual Desktop è 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:
- Identity Provider (se si fa uso di Active Directory e non Azure AD)
- Networking
- Virtual Machine template (Golden image)
- Session hosts
- Storage e profili utente
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 domain 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 Disaster Recovery scelta. La vNet deve disporre di funzionalità di peering o VPN per accedere a tutte le reti richieste per la normale operatività aziendale.
Golden Image
Può essere che il piano di Disaster Recovery 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 Disaster Recovery. 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.
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 Disaster Recovery
- Questa strategia non è adatta per VDI di tipo personal in quanto i dati degli utenti del Disaster Recovery 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 DISASTER RECOVERY al momento
- Non comporta costi di replica o storage/computing
Singolo pool di host o multiplo
Una considerazione da fare quando si fa la progettazione del piano di Disaster Recovery è se si dispone di un unico pool di host che conterrà tutti gli host di sessione o se si distribuiscono gli host di sessione Disaster Recovery in una configurazione di pool separata.
Nella maggior parte dei casi si estende il pool di host esistente all’ambiente Disaster Recovery, 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 Disaster Recovery separato richiederebbe la creazione di tutti i gruppi di applicazioni e la configurazione con il sito Disaster Recovery. Uno use case potrebbe essere quello di limitare l’accesso al Disaster Recovery a un sottoinsieme specifico di utenti.
