Opções de continuidade de negócios e recuperação de desastre para o FSLogix

Um plano eficaz de continuidade de negócios e recuperação de desastres (BCDR) concentra-se nos processos e recursos necessários para que uma organização opere em caso de catástrofe ou outra interrupção significativa. Os perfis de usuário móvel não são comumente descritos como um componente comercial ou de missão crítica de uma estratégia de BCDR . Em um ambiente de área de trabalho virtual, um usuário não sabe que tem um perfil móvel. O perfil é movido para fornecer aos usuários uma experiência consistente, independentemente da máquina virtual. Os dados comerciais ou de missão crítica não devem ser armazenados no perfil de um usuário, se possível. O uso do OneDrive, do SharePoint ou de outras soluções é um meio eficaz de proteger os dados durante um evento BCDR , sem depender do roaming de dados com o usuário como parte de seu perfil. Esse processo é melhor descrito em um exercício de RTO (Recovery Time Objective, objetivo de tempo de recuperação) e RPO (Recovery Point Objective, objetivo de ponto de recuperação), em que a análise de custo-benefício e de risco pode ser ponderada com base nas metas organizacionais e de negócios.

Opção 1: sem recuperação de perfil

Embora essa opção não pareça um design de BCDR , ela se concentra em garantir que os dados de negócios e de missão crítica não estejam no perfil do usuário. Durante um desastre, os usuários criariam novos perfis em um novo local ou em um novo provedor de armazenamento (ambos podem ser verdadeiros). Esta opção é a mais econômica em termos de custo de infraestrutura, embora tenha uma penalidade devido ao efeito que pode ter na experiência do usuário.

^{Figura 1: Sem recuperação de perfil | Contêineres padrão FSLogix (VHDLocations)}

No diagrama, há um Pool de Host de várias regiões usando a Área de Trabalho Virtual do Azure. As regiões primária e de failover têm um compartilhamento dedicado de Arquivos do Azure usando ZRS (armazenamento com redundância de zona), que fornece alta disponibilidade na região. A região de failover tem hosts de sessão, que são interrompidos ou desalocados. Em um desastre, a região de failover se torna a região primária e os usuários entrarão nesses Hosts de Sessão e criarão novos perfis no compartilhamento de Arquivos do Azure nessa região.

Opção 2: Cache de Nuvem (primário/failover)

Um design de failover é uma estratégia comum para garantir a disponibilidade e a confiabilidade de sua infraestrutura em caso de desastre ou falha. O Cache de Nuvem permite que você use o FSLogix usando esse tipo de design de failover. Com o Cache de Nuvem, você pode configurar seus dispositivos para usar dois (2) provedores de armazenamento que armazenam seus dados de perfil em locais diferentes. O Cache de Nuvem sincroniza seus dados de perfil com cada um dos dois provedores de armazenamento de forma assíncrona, para que você sempre tenha a versão mais recente de seus dados. Alguns de seus dispositivos estão no local principal e os outros dispositivos estão no local de failover. O Cache de Nuvem prioriza o primeiro provedor de armazenamento (mais próximo do seu dispositivo) e usa o outro provedor de armazenamento como backup. Por exemplo, se o dispositivo principal estiver no Oeste dos EUA e o dispositivo de failover estiver no Leste dos EUA, você poderá configurar o Cache de Nuvem da seguinte maneira:

• O dispositivo primário usa um provedor de armazenamento no Oeste dos EUA como a primeira opção e um provedor de armazenamento no Leste dos EUA como a segunda opção.
• O dispositivo de failover usa um provedor de armazenamento no Leste dos EUA como a primeira opção e um provedor de armazenamento no Oeste dos EUA como a segunda opção.
• Se o dispositivo principal ou o provedor de armazenamento mais próximo falhar, você poderá alternar para o dispositivo de failover ou o provedor de armazenamento de backup e continuar seu trabalho sem perder os dados do perfil.

No entanto, há algumas desvantagens de usar um design de failover com o Cache de Nuvem. Primeiro, você deve pagar mais para armazenar os dados do seu perfil em dois (2) locais. Em segundo lugar, você precisa iniciar manualmente o processo de failover, o que pode exigir a aprovação das partes interessadas do negócio. Em terceiro lugar, você pode experimentar alguma latência ou inconsistência nos dados do perfil devido à sincronização assíncrona com os dois provedores de armazenamento.

^{Figura 2: Cache de nuvem (primário/failover) | Cache de nuvem FSLogix (CCDLocations)}

No diagrama, temos um Pool de Host de várias regiões utilizando a Área de Trabalho Virtual do Azure. As regiões primária e de failover fazem parte dessa configuração. Cada um deles tem um compartilhamento de Arquivos do Azure dedicado usando ZRS (armazenamento com redundância de zona), garantindo alta disponibilidade na região. A região de failover contém hosts de sessão, que são interrompidos ou desalocados. No caso de um desastre, a região de failover se torna a região primária. Os usuários entrarão nesses hosts de sessão e carregarão seu perfil replicado da região de failover.

No entanto, é essencial considerar o seguinte:

• Os eventos BCDR (Business Continuity and Disaster Recovery) raramente são graciosos. Dependendo das circunstâncias, os dados do perfil do usuário podem não ter garantia de estarem intactos.
• Os usuários que entram em hosts de sessão na região de failover podem sofrer perda de dados ou, em casos piores, corrupção de contêiner.

Dada essa situação, é crucial usar plataformas de armazenamento como OneDrive ou SharePoint para dados críticos. Essas plataformas fornecem redundância adicional e proteção contra perda de dados. Lembre-se de que o planejamento para recuperação de desastres é essencial, e ter a estratégia de armazenamento certa pode reduzir os riscos e garantir a continuidade dos negócios.

Opção 3: Cache de Nuvem (ativo/ativo)

Ao discutir infraestrutura, é comum usar designs ativos/ativos, que também podem ser aplicados a uma solução de perfil FSLogix. Com essa opção, o Cache de Nuvem é configurado com dois provedores de armazenamento que são atualizados de forma assíncrona para refletir todas as alterações feitas no cache local. O provedor de armazenamento mais próximo do local ativo é listado primeiro, enquanto o provedor mais distante é listado em segundo lugar. No outro local, a ordem é invertida. Essa opção incorre em custos adicionais para armazenar dados do provedor em dois locais e requer uma decisão manual das partes interessadas da empresa antes de iniciar um failover.

^{Figura 3: Cache de nuvem (ativo/ativo) | Cache de nuvem FSLogix (CCDLocations)}

No diagrama, há dois (2) Pools de Host AVD e Hosts de Sessão que residem em regiões específicas do Azure. Os usuários atribuídos à região Oeste dos EUA acessam essas máquinas virtuais. Os usuários na região Leste dos EUA acessam e são atribuídos a essas máquinas virtuais. Durante um desastre, a região sobrevivente deve ter capacidade suficiente para suportar todos os usuários. Além disso, os usuários da região com falha precisam de acesso concedido às máquinas virtuais na região sobrevivente.

Os eventos BCDR nunca são normais e, dependendo das circunstâncias do evento, não há garantia de que os dados do perfil do usuário estejam intactos. Os usuários que entrarem nos hosts da sessão na região sobrevivente podem sofrer perda de dados ou, na pior das hipóteses, corrupção de contêiner. Essa situação amplifica a necessidade de usar plataformas de armazenamento como OneDrive ou SharePoint para dados críticos do usuário.