Considerazioni sulla continuità aziendale per i carichi di lavoro di Desktop virtuale Di Azure

Questo articolo illustra l'area di progettazione della continuità aziendale di un carico di lavoro di Desktop virtuale Di Azure. Per rafforzare la distribuzione di Desktop virtuale Azure dell'organizzazione e per proteggere i dati, è necessario implementare una strategia di continuità aziendale e ripristino di emergenza. Una buona strategia consente di mantenere le app e i carichi di lavoro in esecuzione durante le interruzioni pianificate e non pianificate o di Azure.

Per assicurarsi che gli utenti possano connettersi durante un'interruzione dell'area di Azure, potrebbe essere necessario replicare macchine virtuali personali in un'area di Azure diversa, ovvero la posizione secondaria. Durante le interruzioni, l'area primaria 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 delle macchine virtuali, è anche necessario assicurarsi che le identità utente siano accessibili nella posizione secondaria. È possibile usare i contenitori del profilo per rendere accessibili le identità. In alternativa alla replica di macchine virtuali, è possibile usare più pool di host in pool con provisioning automatizzato tra aree.

Servizio Desktop virtuale di Azure

Impatto: affidabilità

Nel servizio Desktop virtuale Azure, Microsoft gestisce alcune aree di responsabilità e il cliente gestisce altri.

• Microsoft controlla i metadati, ad esempio i pool host, i gruppi di applicazioni e le aree di lavoro. I metadati sono sempre disponibili. Non è necessario che il cliente faccia una configurazione aggiuntiva per replicare i dati o le configurazioni del pool host. L'infrastruttura gateway che connette gli utenti agli host di sessione è progettata per essere un servizio globale e altamente resiliente gestito da Microsoft.
• Le aree gestite dal cliente coinvolgono le macchine virtuali usate da Desktop virtuale di Azure e le impostazioni e le configurazioni univoche per la distribuzione del cliente.

La tabella seguente fornisce informazioni dettagliate sulle aree gestite da ogni parte:

Consigli

• Tenere presente le proprie responsabilità nel modello di responsabilità condivisa.
• Assicurarsi che l'organizzazione gestisca attivamente le aree che rientrano nella responsabilità del cliente. Gli esempi includono le macchine virtuali usate da Desktop virtuale Di Azure, i dati del profilo utente e le impostazioni univoche per l'ambiente.

Pool di host

Impatto: affidabilità, ottimizzazione dei costi

Se set distinti di utenti hanno requisiti di continuità aziendale e ripristino di emergenza diversi, è consigliabile usare più pool di host con configurazioni diverse. Ad esempio, gli utenti con un'applicazione business-critical possono usare un pool host completamente ridondante con funzionalità di ripristino di emergenza geografico. Tuttavia, gli utenti di sviluppo e test possono usare un pool host separato senza ripristino di emergenza.

Per ogni pool di host di Desktop virtuale Azure, è possibile basare la strategia di continuità aziendale e ripristino di emergenza in un modello attivo o attivo-passivo.

Scenari attivi

La configurazione consigliata per uno scenario attivo usa due pool host, un pool di host per area. Non è necessario alcun intervento dell'amministratore per il failover. Come durante le normali operazioni, il pool di host secondario fornisce agli utenti risorse di Desktop virtuale Di Azure. Gli utenti devono avere una buona comprensione delle funzionalità offerte da Desktop virtuale Azure e come usarle.

Ogni pool di host ha un proprio account di archiviazione per profili utente persistenti. Se i piani di ripristino di emergenza richiedono che i profili siano persistenti, è necessario usare la funzionalità cache cloud di FSLogix per sincronizzare i profili tra aree. Per evitare conflitti di profilo, non consentire agli utenti di accedere a entrambi i pool di host contemporaneamente.

Per altre informazioni, vedere Continuità aziendale multiregion e ripristino di emergenza (BCDR) per Desktop virtuale di Azure.

Scenari attivi-passivi

In uno scenario attivo-passivo, la distribuzione host è simile alla configurazione in uno scenario attivo-attivo. Per ogni pool di host nell'area primaria, un altro pool di host viene distribuito nell'area secondaria. In uno scenario attivo passivo, tuttavia, meno risorse di calcolo sono attive nell'area secondaria rispetto all'area primaria. È possibile che nessuna risorsa di calcolo sia attiva nell'area secondaria. Il numero di risorse attive in genere dipende dal budget disponibile. Tenere presente che la capacità di Azure non è garantita durante le interruzioni a livello di area quando le risorse inattive devono essere attivate. La capacità è garantita solo se le macchine virtuali sono attive. Prendere in considerazione l'uso delle prenotazioni di capacità su richiesta per riservare la capacità di Azure per gli scenari di ripristino di emergenza. Per altre informazioni, vedere Prenotazione della capacità su richiesta.

Si notino anche i punti seguenti sui modelli passivi attivi:

• Ogni pool di host ha i propri account di archiviazione per profili utente persistenti.
• Se i profili devono essere persistenti tra aree, è possibile usare la funzionalità cache cloud per sincronizzare i profili.

Se si prevede di usare un pool di host personale, è possibile usare Azure Site Recovery per replicare gli host di sessione dall'area primaria all'area secondaria. Per adottare questo approccio, è necessario disporre dell'infrastruttura appropriata.

Consigli

• Usare più pool di host se si dispone di set distinti di utenti con requisiti di continuità aziendale diversi.
• Valutare la funzionalità cache cloud di FSLogix per sincronizzare i profili tra aree se i profili devono essere protetti.
• Informare gli utenti sull'uso appropriato delle risorse se si usa una configurazione attiva.
• Usare Site Recovery per replicare gli host di sessione dall'area primaria all'area secondaria quando si usa un pool host personale.

Pianificazione della capacità

Impatto: affidabilità, ottimizzazione dei costi

Desktop virtuale Di Azure opera entro i vincoli dei limiti di capacità di Azure.

Ad esempio, Azure impone limiti a livello di sottoscrizione per il numero di macchine virtuali che è possibile distribuire in Desktop virtuale di Azure. Ad esempio, una sottoscrizione potrebbe avere un limite di 25.000 macchine virtuali. Per garantire operazioni senza problemi, è necessario essere consapevoli di questo limite e pianificare di conseguenza le distribuzioni. Il ridimensionamento oltre questo limite potrebbe richiedere sottoscrizioni aggiuntive o strategie alternative, che possono avere implicazioni sui costi.

Un altro esempio è gli host di sessione in un pool host. All'interno di Desktop virtuale Azure, ogni pool di host ha i propri limiti sul numero di host di sessione che possono ospitare sessioni utente. La serie di macchine virtuali e le dimensioni selezionate per il pool host determinano il numero massimo di host di sessione che è possibile usare. Per ottimizzare le prestazioni e l'esperienza utente, è necessario considerare questi limiti quando si progetta la distribuzione.

Per altre informazioni sui vincoli della piattaforma, vedere Limitazioni di Desktop virtuale di Azure.

Consigli

• Monitorare e pianificare i limiti di sottoscrizione. Monitorare attentamente le distribuzioni di Desktop virtuale Azure e tenere traccia dell'utilizzo delle risorse all'interno della sottoscrizione. Monitorando in modo proattivo la capacità, è possibile identificare le potenziali sfide all'inizio e intraprendere azioni appropriate per evitare di raggiungere limiti.
• Valutare la possibilità di ridimensionare più sottoscrizioni se è necessario un ulteriore ridimensionamento o usare supporto tecnico di Azure per modificare i limiti in base ai requisiti aziendali.
• Ridimensionare orizzontalmente per una domanda elevata. Per gestire un numero elevato di utenti, è consigliabile ridimensionare orizzontalmente creando più pool di host.

Profili FSLogix e Collegamento app

Impatto: affidabilità, ottimizzazione dei costi

Per ridurre al minimo la quantità di dati nei profili utente, reindirizzare i dati utente a una soluzione di archiviazione. Quando si riducono al minimo i dati nei profili utente, è anche necessario ridurre al minimo la protezione necessaria per i profili. Una strategia di ripristino senza profilo riduce il sovraccarico, ma può influire sull'esperienza utente negli scenari di ripristino di emergenza.

In alcuni casi, il contenuto del contenitore del profilo necessita di una soluzione separata di continuità aziendale e ripristino di emergenza, perché i requisiti del contenitore del profilo differiscono dai requisiti dei contenitori di Office. In questo caso, è possibile separare i due e gestirli in modo indipendente.

Per i profili FSLogix e App Attach, è consigliabile considerare tre scenari:

• Danneggiamento locale di dati, metadati o risorse. In questo caso, è possibile usare Backup di Azure:

  • Se si usa File di Azure archiviazione, è possibile configurare Backup per File di Azure.
  • Se si usa Azure NetApp Files per l'archiviazione, è possibile configurare Il backup per gli snapshot di Azure NetApp Files.

  In alternativa, è possibile usare il servizio di backup per proteggere file e cartelle nelle macchine virtuali del server.

• Errore di un singolo data center di una zona di disponibilità all'interno di un'area di Azure. In questo scenario è possibile usare File di Azure con l'archiviazione con ridondanza della zona Premium per sfruttare il supporto per le zone di disponibilità. I profili FSLogix e i dischi rigidi virtuali (VHD) di App Attach rimangono disponibili durante le interruzioni del data center.

• Interruzione dell'area di Azure. Se si dispone di una distribuzione multiregione, è possibile usare la funzionalità cache cloud FSLogix per proteggere i profili utente replicando tra aree.

Consigli

• È consigliabile usare una strategia di ripristino senza profilo per ridurre al minimo la necessità di proteggere i profili.
• Usare Backup per eseguire il backup dei profili FSLogix archiviati in File di Azure o Azure NetAppFiles.
• Usare l'archiviazione con ridondanza della zona per replicare i dati in modo sincrono tra le zone di disponibilità di Azure.
• Usare la funzionalità cache cloud FSLogix per replicare i profili tra aree.

Reti virtuali

Impatto: affidabilità, ottimizzazione dei costi

Le reti virtuali sono servizi gestiti che non sono interessati da:

• Danneggiamento locale di dati, metadati o risorse.
• Errore di un singolo data center di una zona di disponibilità all'interno di un'area di Azure.

Azure Rete virtuale fornisce un blocco di indirizzi IP privato che è possibile usare per distribuire le risorse per la connettività privata. È quindi possibile proteggere tali risorse all'interno di un limite. Di conseguenza, una rete virtuale non si arresta o si verifica un'interruzione se si verifica un errore locale delle risorse in un singolo data center.

Quando si verifica un'interruzione di un'intera area di Azure, le reti virtuali sono interessate. Gli errori a livello di area influiscono anche sui servizi distribuiti all'interno delle reti virtuali. Per proteggere le risorse, è necessario pianificare una rete virtuale nell'area secondaria per consentire la replica di macchine virtuali del pool di host personali o spazio per la distribuzione di host sessione. È anche possibile usare Site Recovery per configurare la rete virtuale nell'area di failover e mantenere le impostazioni della rete primaria. In un ambiente Desktop virtuale Azure connesso alla rete locale, è necessario configurare la rete virtuale nell'area secondaria con connettività alla rete locale.

Consigli

• Configurare una rete virtuale nell'area secondaria per il failover.
• Usare Site Recovery per configurare una rete virtuale nell'area di failover.

Immagini Golden

Impatto: affidabilità, ottimizzazione dei costi

Per le immagini dorate, è consigliabile considerare tre scenari:

• Danneggiamento locale di dati, metadati o risorse. In questo caso, è possibile usare Azure Compute Gallery per archiviare e condividere immagini usate in Desktop virtuale Azure. Per impostazione predefinita, La raccolta di calcolo usa l'archiviazione con ridondanza locale.
• Errore di un singolo data center di una zona di disponibilità all'interno di un'area di Azure. In questo scenario è possibile usare l'archiviazione con ridondanza della zona per distribuire copie delle immagini tra zone di disponibilità. Quando l'archiviazione con ridondanza della zona è disponibile, usarla per la disponibilità elevata.
• Interruzione dell'area di Azure. La raccolta di calcolo è una risorsa a livello di area. Per proteggersi da errori a livello di area, è necessario creare una raccolta di calcolo secondaria all'interno di un'area secondaria. È anche necessario avere più repliche della stessa immagine nella raccolta di calcolo primaria.

Consigli

• Usare La raccolta di calcolo per archiviare le immagini.
• Usare l'archiviazione con ridondanza della zona per distribuire copie di immagini tra zone di disponibilità.
• Creare una raccolta di calcolo secondaria all'interno di un'area secondaria.

Passaggi successivi

Dopo aver esaminato le considerazioni sulla continuità aziendale, vedere come ottimizzare le prestazioni e i costi quando si selezionano soluzioni di archiviazione per il carico di lavoro.

Usare lo strumento di valutazione per valutare le scelte di progettazione.