Ripristino di emergenza di Desktop virtuale Azure

  • Articolo

Per garantire la sicurezza dei dati dell'organizzazione, è necessario adottare e gestire una strategia di continuità aziendale e ripristino di emergenza (BCDR). Una strategia BCDR valida consente di mantenere le app e i carichi di lavoro operativi durante le interruzioni pianificate e non pianificate o di Azure. Questi piani devono coprire le macchine virtuali (VM) host di sessione gestite dai clienti, anziché il servizio Desktop virtuale Azure gestito da Microsoft. Per altre informazioni sulle aree di gestione, vedere Concetti relativi al ripristino di emergenza di Desktop virtuale Azure.

Il servizio Desktop virtuale Azure è progettato tenendo presente la disponibilità elevata. Desktop virtuale Azure è un servizio globale gestito da Microsoft, con più istanze dei relativi componenti indipendenti distribuiti in più aree di Azure. Se si verifica un'interruzione imprevista in uno dei componenti, il traffico verrà deviato a una delle istanze rimanenti o Microsoft avvierà un failover completo per l'infrastruttura ridondante in un'altra area di Azure.

Per assicurarsi che gli utenti possano comunque connettersi durante un'interruzione dell'area nelle macchine virtuali host di sessione, è necessario progettare l'infrastruttura tenendo presente la disponibilità elevata e il ripristino di emergenza. Un piano di ripristino di emergenza tipico include la replica di macchine virtuali (VM) in una posizione diversa. Durante le interruzioni, il sito primario esegue il failover nelle macchine virtuali replicate nella posizione secondaria. Gli utenti possono continuare ad accedere alle app dalla posizione secondaria senza interruzioni. Oltre alla replica di macchine virtuali, è necessario mantenere accessibili le identità utente nella posizione secondaria. Se si usano contenitori di profilo, sarà necessario replicarli anche. Infine, assicurarsi che le app aziendali che si basano sui dati nella posizione primaria possano eseguire il failover con il resto dei dati.

Per riepilogare, per mantenere gli utenti connessi durante un'interruzione, è necessario eseguire le operazioni seguenti:

  • Replicare le macchine virtuali in una posizione secondaria.
  • Se si usano contenitori di profili, configurare la replica dei dati nella posizione secondaria.
  • Assicurarsi che le identità utente configurate nel percorso primario siano disponibili nella posizione secondaria. Per garantire la disponibilità, assicurarsi che i controller di Dominio di Active Directory siano disponibili in o dalla posizione secondaria.
  • Assicurarsi che anche qualsiasi applicazione line-of-business e dati nella posizione primaria venga eseguito il failover nella posizione secondaria.

Piani di ripristino di emergenza attivi e passivi e attivi

Esistono due tipi diversi di infrastruttura di ripristino di emergenza: attivo-passivo e attivo-attivo. Ogni tipo di infrastruttura funziona in modo diverso, quindi esaminiamo le differenze.

I piani attivo-passivo sono quando si dispone di un'area con un set di risorse attivo e uno disattivato fino a quando non è necessario (passivo). Se l'area attiva viene portata offline da un'interruzione o da un'emergenza, l'organizzazione può passare all'area passiva attivandola e indirizzando tutti gli utenti.

Un'altra opzione è una distribuzione attiva-attiva, in cui si usano entrambi i set di infrastruttura contemporaneamente. Anche se alcuni utenti potrebbero essere interessati da interruzioni, l'impatto è limitato agli utenti dell'area che sono stati disattivati. Gli utenti dell'altra area ancora online non saranno interessati e il ripristino è limitato agli utenti dell'area interessata che si riconnettono all'area attiva funzionante. Le distribuzioni attive possono assumere molte forme, tra cui:

  • Infrastruttura di overprovisioning in ogni area per supportare gli utenti interessati in caso di arresto di una delle aree. Un potenziale svantaggio di questo metodo è che la gestione delle risorse aggiuntive costa di più.
  • Avere host di sessione aggiuntivi in entrambe le aree attive, ma deallocarli quando non sono necessari, riducendo così i costi.
  • Effettuare il provisioning di una nuova infrastruttura durante il ripristino di emergenza e consentire agli utenti interessati di connettersi agli host di sessione di cui è stato appena effettuato il provisioning. Questo metodo richiede test regolari con strumenti di infrastruttura come codice, in modo da poter distribuire la nuova infrastruttura il più rapidamente possibile durante un'emergenza.

Per altre informazioni sui tipi di piani di ripristino di emergenza che è possibile usare, vedere Concetti relativi al ripristino di emergenza di Desktop virtuale Azure.

L'identificazione del metodo più adatto per l'organizzazione è la prima operazione da eseguire prima di iniziare. Dopo aver creato il piano, è possibile iniziare a creare il piano di ripristino.

Replica VM

Prima di tutto, è necessario replicare le macchine virtuali nella posizione secondaria. Le opzioni per eseguire questa operazione dipendono dal modo in cui sono configurate le macchine virtuali:

  • È possibile configurare la replica per tutte le macchine virtuali in pool e nei pool di host personali con Azure Site Recovery. Per altre informazioni sul funzionamento di questo processo, vedere Replicare macchine virtuali di Azure in un'altra area di Azure. Tuttavia, se sono presenti pool di host in pool creati dalla stessa immagine e non sono presenti dati utente personali archiviati in locale, è possibile scegliere di non replicarli. È invece possibile creare le macchine virtuali in anticipo e mantenerle spente. È anche possibile scegliere di effettuare il provisioning di nuove macchine virtuali solo nell'area secondaria mentre si verifica un'emergenza. Se si sceglie questi metodi, sarà necessario configurare un solo pool di host e i relativi gruppi di applicazioni e aree di lavoro correlati.
  • È possibile creare un nuovo pool di host nell'area di failover mantenendo tutte le risorse disattivate nella propria posizione di failover. Per questo metodo, è necessario configurare nuovi gruppi di applicazioni e aree di lavoro nell'area di failover. È quindi possibile usare un piano di Azure Site Recovery per attivare i pool di host.
  • È possibile creare un pool di host popolato da macchine virtuali sia nell'area primaria che in quella di failover mantenendo disattivate le macchine virtuali nell'area di failover. In questo caso, è sufficiente configurare un pool di host e i relativi gruppi di applicazioni e aree di lavoro correlati. È possibile usare un piano di Azure Site Recovery per attivare i pool di host con questo metodo.

È consigliabile usare Azure Site Recovery per gestire la replica di macchine virtuali in altre posizioni di Azure, come descritto in Architettura di ripristino di emergenza da Azure ad Azure. È consigliabile usare Azure Site Recovery per i pool di host personali perché, true per il nome, i pool di host personali tendono ad avere qualcosa di personale per gli utenti. Azure Site Recovery supporta sku basati su server e basati su client.

Se si usa Azure Site Recovery, non sarà necessario registrare queste macchine virtuali manualmente. L'agente di Desktop virtuale Azure nella macchina virtuale secondaria userà automaticamente il token di sicurezza più recente per connettersi all'istanza del servizio più vicina. La macchina virtuale (host di sessione) nella posizione secondaria diventerà automaticamente parte del pool di host. L'utente finale dovrà riconnettersi durante il processo, ma a parte questo non ci sono altre operazioni manuali.

Se sono presenti connessioni utente durante l'interruzione, prima che l'amministratore possa iniziare a eseguire il failover nell'area secondaria, è necessario terminare le connessioni utente nell'area corrente.

Per disconnettere gli utenti in Desktop virtuale Azure (versione classica), eseguire questo cmdlet:

Invoke-RdsUserSessionLogoff

Per disconnettere gli utenti in Desktop virtuale Azure, eseguire questo cmdlet:

Remove-AzWvdUserSession

Dopo aver disconnesso tutti gli utenti nell'area primaria, è possibile eseguire il failover delle macchine virtuali nell'area primaria e consentire agli utenti di connettersi alle macchine virtuali nell'area secondaria.

Rete virtuale

Prendere quindi in considerazione la connettività di rete durante l'interruzione. È necessario assicurarsi di aver configurato una rete virtuale (VNET) nell'area secondaria. Se gli utenti devono accedere alle risorse locali, è necessario configurare questa rete virtuale per accedervi. È possibile stabilire connessioni locali con una rete VPN, ExpressRoute o una rete WAN virtuale.

È consigliabile usare Azure Site Recovery per configurare la rete virtuale nell'area di failover perché mantiene le impostazioni della rete primaria e non richiede il peering.

Identità utente

Assicurarsi quindi che il controller di dominio sia disponibile nel percorso secondario.

Esistono tre modi per mantenere disponibile il controller di dominio:

  • Disporre di uno o più controller Dominio di Active Directory nella posizione secondaria
  • Usare un controller di dominio Active Directory locale
  • Replicare Dominio di Active Directory Controller con Azure Site Recovery

Profili utente

È consigliabile usare FSLogix per la gestione dei profili utente. Per informazioni, vedere Opzioni di continuità aziendale e ripristino di emergenza per FSLogix.

Eseguire il backup dei dati

È anche possibile eseguire il backup dei dati. È possibile scegliere uno dei metodi seguenti per eseguire il backup dei dati di Desktop virtuale Azure:

  • Per i dati di calcolo, è consigliabile eseguire il backup solo dei pool di host personali con Backup di Azure.
  • Per Archiviazione dati, la soluzione di backup consigliata varia in base all'archiviazione back-end usata per archiviare i profili utente:

Dipendenze dell'app

Infine, assicurarsi che tutte le app aziendali che si basano sui dati che si trovano nell'area primaria possano eseguire il failover nella posizione secondaria. Assicurarsi anche di configurare le impostazioni necessarie per il funzionamento delle app nella nuova posizione. Ad esempio, se una delle app dipende dal back-end SQL, assicurarsi di replicare SQL nella posizione secondaria. È necessario configurare l'app in modo che usi la posizione secondaria come parte del processo di failover o come configurazione predefinita. È possibile modellare le dipendenze delle app nei piani di Azure Site Recovery. Per altre informazioni, vedere Informazioni sui piani di ripristino.

Test di ripristino di emergenza

Dopo aver completato la configurazione del ripristino di emergenza, è necessario testare il piano per assicurarsi che funzioni.

Ecco alcuni suggerimenti per testare il piano:

  • Se le macchine virtuali di test hanno accesso a Internet, assumeranno il controllo di qualsiasi host di sessione esistente per le nuove connessioni, ma tutte le connessioni esistenti all'host sessione originale rimarranno attive. Assicurarsi che l'amministratore che esegue il test disconnette tutti gli utenti attivi prima di testare il piano.
  • È consigliabile eseguire test di ripristino di emergenza completi solo durante una finestra di manutenzione per non interrompere gli utenti.
  • Assicurarsi che il test includa tutte le applicazioni e i dati critici per l'azienda.
  • È consigliabile eseguire il failover solo su 100 macchine virtuali alla volta. Se si dispone di più macchine virtuali, è consigliabile eseguirne il failover in batch a distanza di 10 minuti.

Passaggi successivi

Per domande su come proteggere i dati oltre a pianificare interruzioni, consultare la guida alla sicurezza.