BCDR (Continuidade de Negócios Multirregional e Recuperação de Desastres) para Área de Trabalho Virtual do Azure

A Área de Trabalho Virtual do Azure é um serviço abrangente de virtualização de área de trabalho e aplicativo em execução no Microsoft Azure. A Área de Trabalho Virtual ajuda a habilitar uma experiência de área de trabalho remota segura que ajuda as organizações a fortalecer a resiliência dos negócios. Ele oferece gerenciamento simplificado, Windows 10 e 11 Enterprise multi-sessão e otimizações para aplicativos Microsoft 365 para empresas. Com a Área de Trabalho Virtual, você pode implantar e dimensionar suas áreas de trabalho do Windows e aplicativos no Azure em minutos, fornecendo recursos integrados de segurança e conformidade para ajudar a manter seus aplicativos e dados seguros.

À medida que você continua a habilitar o trabalho remoto para sua organização com a Área de Trabalho Virtual, é importante entender seus recursos de recuperação de desastres (DR) e as práticas recomendadas. Essas práticas fortalecem a confiabilidade em todas as regiões para ajudar a manter os dados seguros e a produtividade dos funcionários. Este artigo fornece considerações sobre os pré-requisitos de continuidade de negócios e recuperação de desastres (BCDR), etapas de implantação e práticas recomendadas. Você aprende sobre opções, estratégias e orientação de arquitetura. O conteúdo deste documento permite que você prepare um plano BCDR bem-sucedido e pode ajudá-lo a trazer mais resiliência ao seu negócio durante eventos de tempo de inatividade planejados e não planejados.

Existem vários tipos de desastres e interrupções, e cada um pode ter um impacto diferente. A resiliência e a recuperação são discutidas em profundidade para eventos locais e regionais, incluindo a recuperação do serviço em uma região remota diferente do Azure. Esse tipo de recuperação é chamado de recuperação de desastres geográficos. É fundamental criar sua arquitetura de Área de Trabalho Virtual para resiliência e disponibilidade. Você deve fornecer resiliência local máxima para reduzir o impacto de eventos de falha. Essa resiliência também reduz os requisitos para executar procedimentos de recuperação. Este artigo também fornece informações sobre alta disponibilidade e práticas recomendadas.

Objetivos e âmbito

Os objetivos deste guia são:

• Garanta a máxima disponibilidade, resiliência e capacidade de recuperação de desastres geográficos enquanto minimiza a perda de dados importantes de usuários selecionados.
• Minimize o tempo de recuperação.

Esses objetivos também são conhecidos como RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e RTO (Recovery Time Objetive, objetivo de tempo de recuperação).

A solução proposta fornece alta disponibilidade local, proteção contra uma falha de zona de disponibilidade única e proteção contra uma falha de toda a região do Azure. Ele depende de uma implantação redundante em uma região diferente ou secundária do Azure para recuperar o serviço. Embora ainda seja uma boa prática, a Área de Trabalho Virtual e a tecnologia usada para criar o BCDR não exigem que as regiões do Azure sejam emparelhadas. Os locais primários e secundários podem ser qualquer combinação de região do Azure, se a latência da rede permitir. Operar pools de hosts AVD em várias regiões geográficas pode oferecer mais benefícios não limitados ao BCDR.

Para reduzir o impacto de uma única falha na zona de disponibilidade, use a resiliência para melhorar a alta disponibilidade:

• Na camada de computação, espalhe os hosts de sessão da Área de Trabalho Virtual em diferentes zonas de disponibilidade.
• Na camada de armazenamento, use a resiliência da zona sempre que possível.
• Na camada de rede, implante gateways do Azure ExpressRoute e VPN (rede virtual privada) resilientes à zona.
• Para cada dependência, analise o impacto de uma única interrupção de zona e planeje mitigações. Por exemplo, implante Controladores de Domínio Ative Directory e outros recursos externos acessados por usuários da Área de Trabalho Virtual em várias zonas de disponibilidade.

Dependendo do número de zonas de disponibilidade usadas, avalie o provisionamento excessivo do número de hosts de sessão para compensar a perda de uma zona. Por exemplo, mesmo com zonas (n-1) disponíveis, você pode garantir a experiência e o desempenho do usuário.

Devido às possíveis combinações de tipos, opções de replicação, recursos de serviço e restrições de disponibilidade em algumas regiões, o componente Cloud Cache do FSLogix é recomendado para ser usado em vez de mecanismos de replicação específicos de armazenamento.

O OneDrive não é abordado neste artigo. Para obter mais informações sobre redundância e alta disponibilidade, consulte Resiliência de dados do SharePoint e do OneDrive no Microsoft 365.

No restante deste artigo, você aprenderá sobre soluções para os dois tipos diferentes de pool de hosts da Área de Trabalho Virtual. Há também observações fornecidas para que você possa comparar essa arquitetura com outras soluções:

• Pessoal: Neste tipo de pool de hosts, um usuário tem um host de sessão atribuído permanentemente, que nunca deve mudar. Como é pessoal, essa VM pode armazenar dados do usuário. A suposição é usar técnicas de replicação e backup para preservar e proteger o estado.
• Em pool: os usuários recebem temporariamente uma das VMs de host de sessão disponíveis do pool, diretamente por meio de um grupo de aplicativos da área de trabalho ou usando aplicativos remotos. As VMs são sem monitoração de estado e os dados e perfis do usuário são armazenados no armazenamento externo ou no OneDrive.

As implicações de custo são discutidas, mas o objetivo principal é fornecer uma implantação eficaz de recuperação de desastres geográficos com perda mínima de dados. Para obter mais detalhes do BCDR, consulte os seguintes recursos:

• Considerações do BCDR para a Área de Trabalho Virtual
• Recuperação de desastres da Área de Trabalho Virtual

Pré-requisitos

Implante a infraestrutura principal e verifique se ela está disponível na região primária e secundária do Azure. Para obter orientação sobre sua topologia de rede, você pode usar a topologia de rede e os modelos de conectividade do Azure Cloud Adoption Framework:

• Topologia de rede tradicional do Azure
• Topologia de rede WAN virtual (gerenciada pela Microsoft)

Em ambos os modelos, implante o pool de hosts da Área de Trabalho Virtual primária e o ambiente secundário de recuperação de desastres dentro de redes virtuais spoke diferentes e conecte-as a cada hub na mesma região. Coloque um hub no local principal, um hub no local secundário e, em seguida, estabeleça conectividade entre os dois.

O hub eventualmente fornece conectividade híbrida para recursos locais, serviços de firewall, recursos de identidade, como controladores de domínio do Ative Directory, e recursos de gerenciamento, como o Log Analytics.

Você deve considerar todos os aplicativos de linha de negócios e a disponibilidade de recursos dependentes quando houver failover para o local secundário.

Controle a continuidade de negócios do plano e a recuperação de desastres

O Virtual Desktop oferece continuidade de negócios e recuperação de desastres para seu plano de controle para preservar os metadados do cliente durante interrupções. A plataforma Azure gerencia esses dados e processos, e os usuários não precisam configurar ou executar nada.

A Área de Trabalho Virtual foi projetada para ser resiliente a falhas de componentes individuais e para ser capaz de se recuperar de falhas rapidamente. Quando ocorre uma interrupção em uma região, os componentes da infraestrutura de serviço fazem failover para o local secundário e continuam funcionando normalmente. Você ainda pode acessar metadados relacionados ao serviço e os usuários ainda podem se conectar aos hosts disponíveis. As conexões de usuário final permanecem online se o ambiente do locatário ou os hosts permanecerem acessíveis. Os locais de dados para a Área de Trabalho Virtual são diferentes do local da implantação de máquinas virtuais (VMs) de host de sessão do pool de hosts. É possível localizar metadados da Área de Trabalho Virtual em uma das regiões suportadas e, em seguida, implantar VMs em um local diferente. Mais detalhes são fornecidos no artigo Arquitetura e resiliência do serviço de Área de Trabalho Virtual.

Ativo-Ativo vs. Ativo-Passivo

Se conjuntos distintos de usuários tiverem requisitos BCDR diferentes, a Microsoft recomenda que você use vários pools de hosts com configurações diferentes. Por exemplo, os usuários com um aplicativo de missão crítica podem atribuir um pool de hosts totalmente redundante com recursos de recuperação de desastres geográficos. No entanto, os usuários de desenvolvimento e teste podem usar um pool de hosts separado sem recuperação de desastres.

Para cada pool de hosts da Área de Trabalho Virtual, você pode basear sua estratégia BCDR em um modelo ativo-ativo ou ativo-passivo. Esse cenário pressupõe que o mesmo conjunto de usuários em um local geográfico seja servido por um pool de hosts específico.

• Ativo-Ativo

  • Para cada pool de hosts na região primária, você implanta um segundo pool de hosts na região secundária.

  • Essa configuração fornece quase zero RTO, e o RPO tem um custo extra.

  • Você não precisa que um administrador intervenha ou faça failover. Durante as operações normais, o pool de hosts secundários fornece ao usuário recursos da Área de Trabalho Virtual.

  • Cada pool de hosts tem suas próprias contas de armazenamento (pelo menos uma) para perfis de usuário persistentes.

  • Você deve avaliar a latência com base na localização física do usuário e na conectividade disponível. Para algumas regiões do Azure, como a Europa Ocidental e a Europa do Norte, a diferença pode ser insignificante ao acessar as regiões primárias ou secundárias. Você pode validar esse cenário usando a ferramenta Azure Virtual Desktop Experience Estimator .

  • Os usuários são atribuídos a diferentes grupos de aplicativos, como Grupo de Aplicativos de Área de Trabalho (DAG) e Grupo de Aplicativos RemoteApp (RAG), nos pools de hosts primário e secundário. Nesse caso, eles veem entradas duplicadas em seu feed de cliente da Área de Trabalho Virtual. Para evitar confusão, use espaços de trabalho separados da Área de Trabalho Virtual com nomes e rótulos claros que reflitam a finalidade de cada recurso. Informe seus usuários sobre o uso desses recursos.

    

  • Se você precisar de armazenamento para gerenciar o Perfil FSLogix e os contêineres ODFC separadamente, use o Cloud Cache para garantir quase zero RPO.

    • Para evitar conflitos de perfil, não permita que os usuários acessem os dois pools de hosts ao mesmo tempo.
    • Devido à natureza ativa-ativa desse cenário, você deve educar seus usuários sobre como usar esses recursos da maneira adequada.

• Ativo-Passivo
  • Como ativo-ativo, para cada pool de hosts na região primária, você implanta um segundo pool de hosts na região secundária.
  • A quantidade de recursos de computação ativos na região secundária é reduzida em comparação com a região primária, dependendo do orçamento disponível. Você pode usar o dimensionamento automático para fornecer mais capacidade de computação, mas isso requer mais tempo e a capacidade do Azure não é garantida.
  • Essa configuração fornece RTO mais alto quando comparado à abordagem ativo-ativo, mas é menos dispendiosa.
  • Você precisa da intervenção do administrador para executar um procedimento de failover se houver uma interrupção do Azure. O pool de hosts secundário normalmente não fornece ao usuário acesso aos recursos da Área de Trabalho Virtual.
  • Cada pool de hosts tem suas próprias contas de armazenamento para perfis de usuário persistentes.
  • Os usuários que consomem serviços de Área de Trabalho Virtual com latência e desempenho ideais são afetados somente se houver uma interrupção do Azure. Você deve validar esse cenário usando a ferramenta Azure Virtual Desktop Experience Estimator . O desempenho deve ser aceitável, mesmo que degradado, para o ambiente secundário de recuperação de desastres.
  • Os usuários são atribuídos a apenas um conjunto de grupos de aplicativos, como aplicativos de área de trabalho e remotos. Durante as operações normais, esses aplicativos estão no pool de hosts primários. Durante uma interrupção e após um failover, os usuários são atribuídos a Grupos de Aplicativos no pool de hosts secundários. Nenhuma entrada duplicada é mostrada no feed do cliente da Área de Trabalho Virtual do usuário, eles podem usar o mesmo espaço de trabalho e tudo é transparente para eles.
  • Se você precisar de armazenamento para gerenciar o Perfil FSLogix e os contêineres do Office, use o Cloud Cache para garantir quase zero RPO.
    • Para evitar conflitos de perfil, não permita que os usuários acessem os dois pools de hosts ao mesmo tempo. Como esse cenário é ativo-passivo, os administradores podem impor esse comportamento no nível do grupo de aplicativos. Somente após um procedimento de failover é que o usuário pode acessar cada grupo de aplicativos no pool de hosts secundário. O acesso é revogado no grupo de aplicativos do pool de hosts primário e reatribuído a um grupo de aplicativos no pool de hosts secundário.
    • Execute um failover para todos os grupos de aplicativos, caso contrário, os usuários que usam grupos de aplicativos diferentes em pools de hosts diferentes podem causar conflitos de perfil se não forem gerenciados com eficiência.
  • É possível permitir que um subconjunto específico de usuários faça failover seletivamente para o pool de hosts secundário e forneça comportamento ativo-ativo limitado e capacidade de failover de teste. Também é possível fazer failover de grupos de aplicativos específicos, mas você deve educar seus usuários a não usar recursos de diferentes pools de hosts ao mesmo tempo.

Para circunstâncias específicas, você pode criar um único pool de hosts com uma combinação de hosts de sessão localizados em diferentes regiões. A vantagem dessa solução é que, se você tiver um único pool de hosts, não há necessidade de duplicar definições e atribuições para aplicativos remotos e de área de trabalho. Infelizmente, a recuperação de desastres para pools de hosts compartilhados tem várias desvantagens:

• Para pools de hosts em pool, não é possível forçar um usuário a um host de sessão na mesma região.
• Um usuário pode experimentar latência mais alta e desempenho abaixo do ideal ao se conectar a um host de sessão em uma região remota.
• Se você precisar de armazenamento para perfis de usuário, precisará de uma configuração complexa para gerenciar atribuições para hosts de sessão nas regiões primária e secundária.
• Você pode usar o modo de drenagem para desabilitar temporariamente o acesso a hosts de sessão localizados na região secundária. Mas este método introduz mais complexidade, despesas gerais de gestão e utilização ineficiente dos recursos.
• Você pode manter hosts de sessão em um estado offline nas regiões secundárias, mas isso introduz mais complexidade e sobrecarga de gerenciamento.

Considerações e recomendações

Geral

Para implantar uma configuração ativo-ativo ou ativo-passivo usando vários pools de hosts e um mecanismo de cache em nuvem FSLogix, você pode criar o pool de hosts dentro do mesmo espaço de trabalho ou de um diferente, dependendo do modelo. Essa abordagem exige que você mantenha o alinhamento e as atualizações, mantendo ambos os pools de hosts sincronizados e no mesmo nível de configuração. Além de um novo pool de hosts para a região secundária de recuperação de desastres, você precisa:

• Para criar novos grupos de aplicativos distintos e aplicativos relacionados para o novo pool de hosts.
• Para revogar atribuições de usuário para o pool de hosts primário e, em seguida, reatribuí-los manualmente ao novo pool de hosts durante o failover.

Analise as opções de continuidade de negócios e recuperação de desastres para FSLogix.

• Nenhuma recuperação de perfil não é abordada neste documento.
• O cache de nuvem (ativo/passivo) está incluído neste documento, mas é implementado usando o mesmo pool de hosts.
• O cache de nuvem (ativo/ativo) é abordado na parte restante deste documento.

Há limites para recursos de Área de Trabalho Virtual que devem ser considerados no design de uma arquitetura de Área de Trabalho Virtual. Valide seu design com base nos limites do serviço de Área de Trabalho Virtual.

Para diagnóstico e monitoramento, é uma boa prática usar o mesmo espaço de trabalho do Log Analytics para o pool de hosts primário e secundário. Usando essa configuração, o Azure Virtual Desktop Insights oferece uma exibição unificada da implantação em ambas as regiões.

No entanto, usar um único destino de log pode causar problemas se toda a região primária não estiver disponível. A região secundária não poderá usar o espaço de trabalho do Log Analytics na região indisponível. Se esta situação for inaceitável, poderão ser adotadas as seguintes soluções:

• Use um espaço de trabalho do Log Analytics separado para cada região e, em seguida, aponte os componentes da Área de Trabalho Virtual para fazer logon em direção ao espaço de trabalho local.
• Teste e analise os recursos de replicação e failover do espaço de trabalho do Logs Analytics.

Computação

• Para a implantação de ambos os pools de hosts nas regiões de recuperação de desastres primária e secundária, você deve distribuir sua frota de VMs de host de sessão em várias zonas de disponibilidade. Se as zonas de disponibilidade não estiverem disponíveis na região local, você poderá usar um conjunto de disponibilidade para tornar sua solução mais resiliente do que com uma implantação padrão.

• A imagem dourada que você usa para a implantação do pool de hosts na região secundária de recuperação de desastres deve ser a mesma usada para a principal. Você deve armazenar imagens na Galeria de Computação do Azure e configurar várias réplicas de imagens nos locais primário e secundário. Cada réplica de imagem pode sustentar uma implantação paralela de um número máximo de VMs, e você pode precisar de mais de uma com base no tamanho de lote de implantação desejado. Para obter mais informações, consulte Armazenar e compartilhar imagens em uma Galeria de Computação do Azure.

  

• A Galeria de Computação do Azure não é um recurso global. Recomenda-se ter pelo menos uma galeria secundária na região secundária. Na região principal, crie uma galeria, uma definição de imagem de VM e uma versão de imagem de VM. Em seguida, crie os mesmos objetos também na região secundária. Ao criar a versão da imagem da VM, há a possibilidade de copiar a versão da imagem da VM criada na região primária, especificando a galeria, a definição da imagem da VM e a versão da imagem da VM usada na região primária. O Azure copia a imagem e cria uma versão de imagem de VM local. É possível executar essa operação usando o portal do Azure ou o comando da CLI do Azure, conforme descrito abaixo:

  Criar uma definição de imagem e uma versão de imagem

  az sig image-version criar

• Nem todas as VMs do host de sessão nos locais secundários de recuperação de desastres devem estar ativas e em execução o tempo todo. Inicialmente, você deve criar um número suficiente de VMs e, depois disso, usar um mecanismo de dimensionamento automático como planos de dimensionamento. Com esses mecanismos, é possível manter a maioria dos recursos de computação em um estado offline ou desalocado para reduzir custos.

• Também é possível usar a automação para criar hosts de sessão na região secundária somente quando necessário. Esse método otimiza os custos, mas, dependendo do mecanismo usado, pode exigir um RTO mais longo. Essa abordagem não permite testes de failover sem uma nova implantação e não permite failover seletivo para grupos específicos de usuários.

• Ter hosts de sessão em um estado offline ou deslocalizado na região secundária não garante que a capacidade esteja disponível em caso de desastre em toda a região primária. Ele também se aplica se novos hosts de sessão forem implantados sob demanda quando necessário e com o uso da Recuperação de Site. A capacidade de computação só pode ser garantida se os recursos relacionados já estiverem alocados e ativos.

Para cenários de uso do Cloud Cache, recomendamos o uso da camada Premium para discos gerenciados.

Armazenamento

Neste guia, você usa pelo menos duas contas de armazenamento separadas para cada pool de hosts da Área de Trabalho Virtual. Um é para o contêiner FSLogix Profile e um é para os dados do contêiner do Office. Você também precisa de mais uma conta de armazenamento para pacotes MSIX . As seguintes considerações são aplicáveis:

• Você pode usar o compartilhamento de Arquivos do Azure e os Arquivos NetApp do Azure como alternativas de armazenamento. Para comparar as opções, consulte as opções de armazenamento de contêiner FSLogix.
• O compartilhamento de Arquivos do Azure pode fornecer resiliência de zona usando a opção de resiliência de armazenamento com redundância de zona (ZRS), se estiver disponível na região.
• Não é possível usar o recurso de armazenamento com redundância geográfica nas seguintes situações:
  • Você precisa de uma região que não tenha um par. Os pares de regiões para armazenamento com redundância geográfica são fixos e não podem ser alterados.
  • Você está usando o nível Premium.
• RPO e RTO são maiores em comparação com o mecanismo FSLogix Cloud Cache.
• Não é fácil testar failover e failback em um ambiente de produção.
• Os Arquivos NetApp do Azure exigem mais considerações:
  • A redundância de zona ainda não está disponível. Se o requisito de resiliência for mais importante do que o desempenho, use o compartilhamento de Arquivos do Azure.
  • Os Arquivos NetApp do Azure podem ser zonais, ou seja, os clientes podem decidir em qual zona de disponibilidade do Azure (única) alocar.
  • A replicação entre zonas pode ser estabelecida no nível do volume para fornecer resiliência de zona, mas a replicação acontece de forma assíncrona e requer failover manual. Esse processo requer um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) maiores que zero. Antes de usar esse recurso, revise os requisitos e as considerações para replicação entre zonas.
  • Você pode usar os Arquivos NetApp do Azure com gateways VPN e ExpressRoute com redundância de zona, se o recurso de rede padrão for usado, que você pode usar para resiliência de rede. Para obter mais informações, consulte Topologias de rede suportadas.
  • A WAN Virtual do Azure é suportada quando usada em conjunto com a rede padrão do Azure NetApp Files. Para obter mais informações, consulte Topologias de rede suportadas.
• Os Arquivos NetApp do Azure têm um mecanismo de replicação entre regiões. Aplicam-se as seguintes considerações:
  • Não está disponível em todas as regiões.
  • A replicação entre regiões dos pares de regiões de volumes do Azure NetApp Files pode ser diferente dos pares de regiões do Armazenamento do Azure.
  • Ele não pode ser usado ao mesmo tempo com a replicação entre zonas
  • O failover não é transparente e o failback requer a reconfiguração do armazenamento.
• Limites
  • Há limites no tamanho, operações de entrada/saída por segundo (IOPS), MBps de largura de banda para o compartilhamento de Arquivos do Azure e contas e volumes de armazenamento do Azure NetApp Files . Se necessário, é possível usar mais de um para o mesmo pool de hosts na Área de Trabalho Virtual usando configurações por grupo no FSLogix. No entanto, essa configuração requer mais planejamento e configuração.

A conta de armazenamento usada para pacotes de aplicativos MSIX deve ser distinta das outras contas para contêineres de Perfil e Office. As seguintes opções de recuperação de desastres geográficos estão disponíveis:

• Uma conta de armazenamento com armazenamento com redundância geográfica habilitado, na região principal
  • A região secundária é fixa. Essa opção não é adequada para acesso local se houver failover de conta de armazenamento.
• Duas contas de armazenamento separadas, uma na região primária e outra na região secundária (recomendado)
  • Use armazenamento com redundância de zona para pelo menos a região primária.
  • Cada pool de hosts em cada região tem acesso de armazenamento local a pacotes MSIX com baixa latência.
  • Copie pacotes MSIX duas vezes em ambos os locais e registre os pacotes duas vezes em ambos os pools de hosts. Atribua usuários aos grupos de aplicativos duas vezes.

FSLogix

A Microsoft recomenda que você use a seguinte configuração e recursos do FSLogix:

• Se o conteúdo do contêiner Perfil precisar ter gerenciamento BCDR separado e tiver requisitos diferentes em comparação com o contêiner do Office, você deverá dividi-los.

  • O Office Container só tem conteúdo armazenado em cache que pode ser reconstruído ou preenchido novamente a partir da origem se houver um desastre. Com o Office Container, talvez não seja necessário manter backups, o que pode reduzir custos.
  • Ao usar contas de armazenamento diferentes, você só pode habilitar backups no contêiner de perfil. Ou, você deve ter configurações diferentes, como período de retenção, armazenamento usado, frequência e RTO/RPO.

• O Cloud Cache é um componente FSLogix no qual você pode especificar vários locais de armazenamento de perfil e replicar dados de perfil de forma assíncrona, tudo sem depender de nenhum mecanismo de replicação de armazenamento subjacente. Se o primeiro local de armazenamento falhar ou não estiver acessível, o Cloud Cache fará failover automaticamente para usar o secundário e adicionará efetivamente uma camada de resiliência. Use o Cloud Cache para replicar contêineres de Perfil e Office entre diferentes contas de armazenamento nas regiões primária e secundária.

  

• Você deve habilitar o Cloud Cache duas vezes no registro da VM do host da sessão, uma vez para o Contêiner de Perfil e uma vez para o Contêiner do Office. É possível não habilitar o Cloud Cache for Office Container, mas não habilitá-lo pode causar um desalinhamento de dados entre a região de recuperação de desastres primária e secundária se houver failover e failback. Teste este cenário cuidadosamente antes de usá-lo na produção.

• O Cloud Cache é compatível com configurações de divisão de perfil e por grupo . Por grupo requer um design e planejamento cuidadosos de grupos e associação do Ative Directory. Você deve garantir que cada usuário faça parte exatamente de um grupo e que esse grupo seja usado para conceder acesso a pools de hosts.

• O parâmetro CCDLocations especificado no Registro para o pool de hosts na região secundária de recuperação de desastres é revertido em ordem, em comparação com as configurações na região primária. Para obter mais informações, consulte Tutorial: Configurar o Cloud Cache para redirecionar contêineres de perfil ou contêiner de escritório para vários provedores.

  Gorjeta

  Este artigo se concentra em um cenário específico. Cenários adicionais são descritos em Opções de alta disponibilidade para FSLogix e opções de continuidade de negócios e recuperação de desastres para FSLogix.

O exemplo a seguir mostra uma configuração do Cloud Cache e chaves do Registro relacionadas:

Região primária = Norte da Europa

• URI da conta de armazenamento de contêiner de perfil = \northeustg1\profiles

  • Caminho da chave do Registro = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Perfis
  • Valor CCDLocations = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  Nota

  Se você baixou anteriormente os Modelos FSLogix, poderá realizar as mesmas configurações por meio do Console de Gerenciamento de Diretiva de Grupo do Ative Directory. Para obter mais detalhes sobre como configurar o Objeto de Diretiva de Grupo para FSLogix, consulte o guia Usar Arquivos de Modelo de Diretiva de Grupo FSLogix.

  

• URI da conta de armazenamento de contêiner do Office = \northeustg2\odcf

  • Caminho da chave do Registro = HKEY_LOCAL_MACHINE > Política > de SOFTWARE >FSLogix > ODFC

  • Valor CCDLocations = type=smb,connectionString=\northeustg2\odfc; type=smb,connectionString=\westeustg2\odfc

    

Região secundária = Europa Ocidental

• URI da conta de armazenamento de contêiner de perfil = \westeustg1\profiles
  • Caminho da chave do Registro = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Perfis
  • CCDLocations value = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• URI da conta de armazenamento de contêiner do Office = \westeustg2\odcf
  • Caminho da chave do Registro = HKEY_LOCAL_MACHINE > Política > de SOFTWARE >FSLogix > ODFC
  • Valor CCDLocations = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

Replicação de cache na nuvem

Os mecanismos de configuração e replicação do Cloud Cache garantem a replicação de dados de perfil entre diferentes regiões com perda mínima de dados. Como o mesmo arquivo de perfil de usuário pode ser aberto no modo ReadWrite por apenas um processo, o acesso simultâneo deve ser evitado, portanto, os usuários não devem abrir uma conexão com ambos os pools de hosts ao mesmo tempo.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

1. Um usuário da Área de Trabalho Virtual inicia o cliente da Área de Trabalho Virtual e abre um aplicativo de Área de Trabalho ou Aplicativo Remoto publicado atribuído ao pool de hosts da região primária.

2. O FSLogix recupera o Perfil de Usuário e os contêineres do Office e, em seguida, monta o VHD/X de armazenamento subjacente a partir da conta de armazenamento localizada na região primária.

3. Ao mesmo tempo, o componente Cloud Cache inicializa a replicação entre os arquivos na região primária e os arquivos na região secundária. Para esse processo, o Cloud Cache na região primária adquire um bloqueio exclusivo de leitura-gravação nesses arquivos.

4. O mesmo usuário da Área de Trabalho Virtual agora deseja iniciar outro aplicativo publicado atribuído no pool de hosts da região secundária.

5. O componente FSLogix em execução no host de sessão da Área de Trabalho Virtual na região secundária tenta montar os arquivos VHD/X de perfil de usuário da conta de armazenamento local. Mas a montagem falha porque esses arquivos são bloqueados pelo componente Cloud Cache em execução no host da sessão Virtual Desktop na região primária.

6. Na configuração padrão do FSLogix e do Cloud Cache, o usuário não pode entrar e um erro é rastreado nos logs de diagnóstico do FSLogix, ERROR_LOCK_VIOLATION 33 (0x21).

   

Identidade

Uma das dependências mais importantes para a Área de Trabalho Virtual é a disponibilidade da identidade do usuário. Para acessar áreas de trabalho virtuais remotas completas e aplicativos remotos de seus hosts de sessão, seus usuários precisam ser capazes de autenticar. O Microsoft Entra ID é o serviço centralizado de identidade na nuvem da Microsoft que permite esse recurso. O Microsoft Entra ID é sempre usado para autenticar usuários para a Área de Trabalho Virtual. Os hosts de sessão podem ser associados ao mesmo locatário do Microsoft Entra ou a um domínio do Ative Directory usando os Serviços de Domínio Ative Directory (AD DS) ou os Serviços de Domínio Microsoft Entra, oferecendo opções de configuração flexíveis.

• Microsoft Entra ID

  • É um serviço global, multirregional e resiliente, com alta disponibilidade. Nenhuma outra ação é necessária neste contexto como parte de um plano BCDR da Área de Trabalho Virtual.

• Active Directory Domain Services

  • Para que os Serviços de Domínio Ative Directory sejam resilientes e altamente disponíveis, mesmo que haja um desastre em toda a região, você deve implantar pelo menos dois controladores de domínio (DCs) na região principal do Azure. Esses controladores de domínio devem estar em zonas de disponibilidade diferentes, se possível, e você deve garantir a replicação adequada com a infraestrutura na região secundária e, eventualmente, no local. Você deve criar pelo menos mais um controlador de domínio na região secundária com funções de catálogo global e DNS. Para obter mais informações, consulte Implantar os Serviços de Domínio Ative Directory (AD DS) em uma rede virtual do Azure.

• Microsoft Entra Connect

  • Se estiver a utilizar o Microsoft Entra ID com os Serviços de Domínio Ative Directory e, em seguida , o Microsoft Entra Connect para sincronizar dados de identidade do utilizador entre os Serviços de Domínio Ative Directory e o Microsoft Entra ID, deve considerar a resiliência e a recuperação deste serviço para proteção contra um desastre permanente.

  • Você pode fornecer alta disponibilidade e recuperação de desastres instalando uma segunda instância do serviço na região secundária e habilitar o modo de preparo.

  • Se houver uma recuperação, o administrador deverá promover a instância secundária retirando-a do modo de preparação. Eles devem seguir o mesmo procedimento que colocar um servidor no modo de preparação. As credenciais de Administrador Global do Microsoft Entra são necessárias para executar essa configuração.

    

• Microsoft Entra Domain Services

  • Você pode usar os Serviços de Domínio Microsoft Entra em alguns cenários como uma alternativa aos Serviços de Domínio Ative Directory.
  • Oferece alta disponibilidade.
  • Se a recuperação de desastres geográficos estiver no escopo do seu cenário, você deverá implantar outra réplica na região secundária do Azure usando um conjunto de réplicas. Você também pode usar esse recurso para aumentar a alta disponibilidade na região principal.

Diagramas de arquitetura

Piscina pessoal do anfitrião

Transfira um ficheiro do Visio desta arquitetura.

Pool de hosts agrupados

Transfira um ficheiro do Visio desta arquitetura.

Ativação pós-falha e reativação pós-falha

Cenário do pool de hosts pessoais

O failover e o failback para um pool de hosts pessoais são diferentes, pois não há cache em nuvem e armazenamento externo usado para contêineres de perfil e escritório. Você ainda pode usar a tecnologia FSLogix para salvar os dados em um contêiner do host da sessão. Não há nenhum pool de hosts secundário na região de recuperação de desastres, portanto, não há necessidade de criar mais espaços de trabalho e recursos da Área de Trabalho Virtual para replicar e alinhar. Você pode usar o Site Recovery para replicar VMs de host de sessão.

Você pode usar a Recuperação de Site em vários cenários diferentes. Para a Área de Trabalho Virtual, use a arquitetura de recuperação de desastres do Azure para Azure no Azure Site Recovery.

Aplicam-se as seguintes considerações e recomendações:

• O failover da Recuperação de Site não é automático — um administrador deve acioná-lo usando o portal do Azure ou o Powershell/API.
• Você pode criar scripts e automatizar toda a configuração e operações da Recuperação de Site usando o PowerShell.
• O Site Recovery tem um RTO declarado dentro de seu contrato de nível de serviço (SLA). Na maioria das vezes, o Site Recovery pode fazer failover de VMs em poucos minutos.
• Você pode usar o Site Recovery com o Backup do Azure. Para obter mais informações, consulte Suporte para usar o Site Recovery com o Backup do Azure.
• Você deve habilitar a Recuperação de Site no nível da VM, pois não há integração direta na experiência do portal da Área de Trabalho Virtual. Você também deve acionar failover e failback no nível de VM única.
• O Site Recovery fornece capacidade de failover de teste em uma sub-rede separada para VMs gerais do Azure. Não use esse recurso para VMs de Área de Trabalho Virtual, pois você teria dois hosts de sessão de Área de Trabalho Virtual idênticos chamando o plano de controle de serviço ao mesmo tempo.
• A Recuperação de Site não mantém extensões de Máquina Virtual durante a replicação. Se você habilitar quaisquer extensões personalizadas para VMs de host de sessão da Área de Trabalho Virtual, deverá reativá-las após failover ou failback. As extensões internas da Área de Trabalho Virtual joindomain e Microsoft.PowerShell.DSC só são usadas quando uma VM de host de sessão é criada. É seguro perdê-los após um primeiro failover.
• Certifique-se de revisar a matriz de suporte para recuperação de desastres de VM do Azure entre regiões do Azure e verifique os requisitos, as limitações e a matriz de compatibilidade para o cenário de recuperação de desastres do Azure para o Azure, especialmente as versões do sistema operacional com suporte.
• Quando você faz failover de uma VM de uma região para outra, a VM é iniciada na região de recuperação de desastres de destino em um estado desprotegido. O failback é possível, mas o usuário deve reproteger as VMs na região secundária e, em seguida, habilitar a replicação de volta para a região primária.
• Execute testes periódicos de procedimentos de failover e failback. Em seguida, documente uma lista exata de etapas e ações de recuperação com base em seu ambiente de área de trabalho virtual específico.

Cenário de pool de hosts em pool

Uma das características desejadas de um modelo de recuperação de desastres ativo-ativo é que a intervenção do administrador não é necessária para recuperar o serviço se houver uma interrupção. Os procedimentos de failover só devem ser necessários em uma arquitetura ativo-passivo.

Em um modelo ativo-passivo, a região secundária de recuperação de desastres deve estar ociosa, com recursos mínimos configurados e ativa. A configuração deve ser mantida alinhada com a região primária. Se houver um failover, as reatribuições de todos os usuários para todos os grupos de área de trabalho e aplicativos remotos no pool de hosts de recuperação de desastres secundário acontecerão ao mesmo tempo.

É possível ter um modelo ativo-ativo e failover parcial. Se o pool de hosts for usado apenas para fornecer grupos de área de trabalho e de aplicativos, você poderá particionar os usuários em vários grupos do Ative Directory não sobrepostos e reatribuir o grupo a grupos de área de trabalho e de aplicativos nos pools de hosts de recuperação de desastres primários ou secundários. Um usuário não deve ter acesso aos dois pools de hosts ao mesmo tempo. Se houver vários grupos de aplicativos e aplicativos, os grupos de usuários que você usa para atribuir usuários podem se sobrepor. Neste caso, é difícil implementar uma estratégia ativo-ativo. Sempre que um usuário inicia um aplicativo remoto no pool de hosts primários, o perfil de usuário é carregado pelo FSLogix em uma VM de host de sessão. Tentar fazer o mesmo no pool de hosts secundário pode causar um conflito no disco de perfil subjacente.

Aqui está a situação inicial e os pressupostos de configuração:

• Os pools de hosts na região primária e nas regiões secundárias de recuperação de desastres são alinhados durante a configuração, incluindo o Cache de Nuvem.
• Nos pools de hosts, a área de trabalho DAG1 e os grupos de aplicativos remotos APPG2 e APPG3 são oferecidos aos usuários.
• No pool de hosts na região primária, os grupos de usuários do Ative Directory GRP1, GRP2 e GRP3 são usados para atribuir usuários a DAG1, APPG2 e APPG3. Esses grupos podem ter associações de usuário sobrepostas, mas como o modelo aqui usa ativo-passivo com failover completo, isso não é um problema.

As etapas a seguir descrevem quando um failover acontece, após uma recuperação de desastre planejada ou não planejada.

1. No pool de hosts primário, remova as atribuições de usuário dos grupos GRP1, GRP2 e GRP3 para os grupos de aplicativos DAG1, APPG2 e APPG3.
2. Há uma desconexão forçada para todos os usuários conectados do pool de hosts primários.
3. No pool de hosts secundário, onde os mesmos grupos de aplicativos estão configurados, você deve conceder acesso de usuário ao DAG1, APPG2 e APPG3 usando os grupos GRP1, GRP2 e GRP3.
4. Revise e ajuste a capacidade do pool de hosts na região secundária. Aqui, você pode querer confiar em um plano de dimensionamento automático para ligar automaticamente os hosts de sessão. Você também pode iniciar manualmente os recursos necessários.

As etapas e o fluxo de failback são semelhantes, e você pode executar todo o processo várias vezes. O Cloud Cache e a configuração das contas de armazenamento garantem que os dados de contêiner do Perfil e do Office sejam replicados. Antes do failback, certifique-se de que a configuração do pool de hosts e os recursos de computação sejam recuperados. Para a parte de armazenamento, se houver perda de dados na região primária, o Cloud Cache replicará os dados de contêiner de Perfil e Office do armazenamento da região secundária.

Também é possível implementar um plano de failover de teste com algumas alterações de configuração, sem afetar o ambiente de produção.

• Crie algumas novas contas de usuário no Ative Directory para produção.
• Crie um novo grupo do Ative Directory chamado GRP-TEST e atribua usuários.
• Atribua acesso a DAG1, APPG2 e APPG3 usando o grupo GRP-TEST.
• Dê instruções aos usuários no grupo GRP-TEST para testar aplicativos.
• Teste o procedimento de failover usando o grupo GRP-TEST para remover o acesso do pool de hosts primários e conceder acesso ao pool de recuperação de desastres secundário.

Recomendações importantes:

• Automatize o processo de failover usando o PowerShell, a CLI do Azure ou outra API ou ferramenta disponível.
• Teste periodicamente todo o procedimento de failover e failback.
• Realize uma verificação regular de alinhamento de configuração para garantir que os pools de hosts na região de desastre primária e secundária estejam sincronizados.

Backup

Uma suposição neste guia é que há divisão de perfil e separação de dados entre contêineres de perfil e contêineres do Office. O FSLogix permite essa configuração e o uso de contas de armazenamento separadas. Uma vez em contas de armazenamento separadas, você pode usar diferentes políticas de backup.

• Para o Contêiner ODFC, se o conteúdo representar apenas dados armazenados em cache que podem ser reconstruídos a partir do armazenamento de dados on-line, como o Microsoft 365, não será necessário fazer backup dos dados.

• Se for necessário fazer backup dos dados de contêiner do Office, você poderá usar um armazenamento mais barato ou uma frequência de backup e um período de retenção diferentes.

• Para um tipo de pool de hosts pessoal, você deve executar o backup no nível da VM do host de sessão. Este método só se aplica se os dados forem armazenados localmente.

• Se você usar o OneDrive e o redirecionamento de pasta conhecido, o requisito para salvar dados dentro do contêiner poderá desaparecer.

  Nota

  O backup do OneDrive não é considerado neste artigo e cenário.

• A menos que haja outro requisito, o backup para o armazenamento na região principal deve ser suficiente. O backup do ambiente de recuperação de desastres não é usado normalmente.

• Para compartilhamento de Arquivos do Azure, use o Backup do Azure.

  • Para o tipo de resiliência do vault, use armazenamento com redundância de zona se o armazenamento de backup externo ou de região não for necessário. Se esses backups forem necessários, use armazenamento com redundância geográfica.

• O Azure NetApp Files fornece sua própria solução de backup interna.

  • Certifique-se de verificar a disponibilidade do recurso da região, juntamente com os requisitos e limitações.

• As contas de armazenamento separadas usadas para MSIX também devem ser cobertas por um backup se os repositórios de pacotes de aplicativos não puderem ser facilmente reconstruídos.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Ben Martin Baur - Brasil | Arquiteto de Soluções Cloud
• Igor Pagliai - Brasil | Engenheiro Principal do FastTrack for Azure (FTA)

Outros contribuidores:

• Nelson Del Villar - Brasil | Arquiteto de Soluções na Nuvem, Infraestrutura Principal do Azure
• Jason Martinez - Brasil | Redator Técnico

Próximos passos

• Plano de recuperação de desastres da Área de Trabalho Virtual
• BCDR para Desktop Virtual - Cloud Adoption Framework
• Cloud Cache para criar resiliência e disponibilidade

Recursos relacionados

• Projetar aplicativos confiáveis do Azure
• Arquivos do Azure acessados no local e protegidos pelo AD DS
• Ambiente de Trabalho Virtual para a empresa
• Compartilhamentos de arquivos corporativos com recuperação de desastres
• Exemplos de configuração do FSLogix