Recuperação de desastres da Área de Trabalho Virtual do Azure

  • Artigo

Para manter os dados da sua organização seguros, você deve adotar e gerenciar uma estratégia de continuidade de negócios e recuperação de desastres (BCDR). Uma estratégia BCDR sólida mantém seus aplicativos e cargas de trabalho em funcionamento durante interrupções de serviço planejadas e não planejadas ou do Azure. Esses planos devem abranger as máquinas virtuais (VMs) de host de sessão gerenciadas pelos clientes, em oposição ao serviço de Área de Trabalho Virtual do Azure gerenciado pela Microsoft. Para obter mais informações sobre áreas de gerenciamento, consulte Conceitos de recuperação de desastres da Área de Trabalho Virtual do Azure.

O serviço de Área de Trabalho Virtual do Azure foi projetado com alta disponibilidade em mente. A Área de Trabalho Virtual do Azure é um serviço global gerenciado pela Microsoft, com várias instâncias de seus componentes independentes distribuídos em várias regiões do Azure. Se houver uma interrupção inesperada em qualquer um dos componentes, seu tráfego será desviado para uma das instâncias restantes ou a Microsoft iniciará um failover completo para infraestrutura redundante em outra região do Azure.

Para garantir que os usuários ainda possam se conectar durante uma interrupção de região em VMs de host de sessão, você precisa projetar sua infraestrutura com alta disponibilidade e recuperação de desastres em mente. Um plano típico de recuperação de desastres inclui a replicação de máquinas virtuais (VMs) para um local diferente. Durante interrupções, o site primário realiza failover para as VMs replicadas no local secundário. Os utilizadores podem continuar a aceder às aplicações a partir da localização secundária sem interrupção. Além da replicação de VM, você precisará manter as identidades de usuário acessíveis no local secundário. Se você estiver usando contêineres de perfil, também precisará replicá-los. Por fim, certifique-se de que seus aplicativos de negócios que dependem de dados no local principal possam fazer failover com o restante dos dados.

Para resumir, para manter seus usuários conectados durante uma interrupção, você precisará fazer o seguinte:

  • Replique as VMs para um local secundário.
  • Se você estiver usando contêineres de perfil, configure a replicação de dados no local secundário.
  • Verifique se as identidades de usuário configuradas no local principal estão disponíveis no local secundário. Para garantir a disponibilidade, verifique se os Controladores de Domínio Ative Directory estão disponíveis no local secundário ou a partir dele.
  • Certifique-se de que todos os aplicativos de linha de negócios e dados em seu local principal também sejam submetidos a failover para o local secundário.

Planos de recuperação de desastres ativo-passivo e ativo-ativo

Existem dois tipos diferentes de infraestrutura de recuperação de desastres: ativo-passivo e ativo-ativo. Cada tipo de infraestrutura funciona de uma maneira diferente, então vamos ver quais são essas diferenças.

Os planos ativo-passivo são quando você tem uma região com um conjunto de recursos que está ativo e outro que está desligado até que seja necessário (passivo). Se a região ativa for colocada offline por uma interrupção ou desastre, a organização poderá alternar para a região passiva ativando-a e direcionando todos os usuários para lá.

Outra opção é uma implantação ativa-ativa, em que você usa os dois conjuntos de infraestrutura ao mesmo tempo. Embora alguns usuários possam ser afetados por interrupções, o impacto é limitado aos usuários na região que caiu. Os usuários da outra região que ainda está online não serão afetados, e a recuperação é limitada aos usuários da região afetada que se reconectam à região ativa em funcionamento. As implantações ativas-ativas podem assumir várias formas, incluindo:

  • Superprovisionamento de infraestrutura em cada região para acomodar os usuários afetados no caso de uma das regiões cair. Uma desvantagem potencial deste método é que a manutenção dos recursos adicionais custa mais.
  • Tenha hosts de sessão extras em ambas as regiões ativas, mas desaloque-os quando não forem necessários, o que reduz os custos.
  • Provisione apenas a nova infraestrutura durante a recuperação de desastres e permita que os usuários afetados se conectem aos hosts de sessão recém-provisionados. Esse método requer testes regulares com ferramentas de infraestrutura como código para que você possa implantar a nova infraestrutura o mais rápido possível durante um desastre.

Para obter mais informações sobre os tipos de planos de recuperação de desastres que você pode usar, consulte Conceitos de recuperação de desastres da Área de Trabalho Virtual do Azure.

Identificar qual método funciona melhor para sua organização é a primeira coisa que você deve fazer antes de começar. Depois de ter o seu plano em vigor, pode começar a construir o seu plano de recuperação.

Replicação de VMs

Primeiro, você precisará replicar suas VMs para o local secundário. Suas opções para fazer isso dependem de como suas VMs estão configuradas:

  • Você pode configurar a replicação para todas as suas VMs em pools de hosts em pool e pessoais com o Azure Site Recovery. Para obter mais informações sobre como esse processo funciona, consulte Replicar VMs do Azure para outra região do Azure. No entanto, se você tiver pools de hosts agrupados criados a partir da mesma imagem e não tiver dados pessoais do usuário armazenados localmente, poderá optar por não replicá-los. Em vez disso, você tem a opção de criar as VMs com antecedência e mantê-las desligadas. Você também pode optar por provisionar apenas novas VMs na região secundária enquanto um desastre estiver acontecendo. Se você escolher esses métodos, só precisará configurar um pool de hosts e seus grupos de aplicativos e espaços de trabalho relacionados.
  • Você pode criar um novo pool de hosts na região de failover enquanto mantém todos os recursos em seu local de failover desativados. Para esse método, você precisaria configurar novos grupos de aplicativos e espaços de trabalho na região de failover. Em seguida, você pode usar um plano do Azure Site Recovery para ativar pools de hosts.
  • Você pode criar um pool de hosts preenchido por VMs criadas nas regiões primária e de failover, mantendo as VMs na região de failover desativadas. Nesse caso, você só precisa configurar um pool de hosts e seus grupos de aplicativos e espaços de trabalho relacionados. Você pode usar um plano do Azure Site Recovery para ativar pools de hosts com esse método.

Recomendamos que você use o Azure Site Recovery para gerenciar VMs replicadas para outros locais do Azure, conforme descrito na arquitetura de recuperação de desastres do Azure para o Azure. Recomendamos especialmente o uso do Azure Site Recovery para pools de hosts pessoais porque, fiel ao nome, os pools de hosts pessoais tendem a ter algo pessoal sobre eles para seus usuários. O Azure Site Recovery dá suporte a SKUs baseadas em servidor e em cliente.

Se você usar o Azure Site Recovery, não precisará registrar essas VMs manualmente. O agente da Área de Trabalho Virtual do Azure na VM secundária usará automaticamente o token de segurança mais recente para se conectar à instância de serviço mais próxima dela. A VM (host de sessão) no local secundário se tornará automaticamente parte do pool de hosts. O usuário final terá que se reconectar durante o processo, mas, além disso, não há outras operações manuais.

Se houver conexões de usuário existentes durante a interrupção, antes que o administrador possa começar a fazer failover para a região secundária, você precisará encerrar as conexões de usuário na região atual.

Para desconectar usuários na Área de Trabalho Virtual do Azure (clássico), execute este cmdlet:

Invoke-RdsUserSessionLogoff

Para desconectar usuários na Área de Trabalho Virtual do Azure, execute este cmdlet:

Remove-AzWvdUserSession

Depois de sair de todos os usuários na região primária, você pode fazer failover das VMs na região primária e permitir que os usuários se conectem às VMs na região secundária.

Rede virtual

Em seguida, considere a conectividade de rede durante a interrupção. Terá de se certificar de que configurou uma rede virtual (VNET) na sua região secundária. Se os usuários precisarem acessar recursos locais, você precisará configurar essa VNET para acessá-los. Você pode estabelecer conexões locais com uma VPN, Rota Expressa ou WAN virtual.

Recomendamos que você use o Azure Site Recovery para configurar a VNET na região de failover, pois ela preserva as configurações da rede principal e não precisa de emparelhamento.

Identidades de utilizador

Em seguida, verifique se o controlador de domínio está disponível no local secundário.

Há três maneiras de manter o controlador de domínio disponível:

  • Ter um ou mais Controladores de Domínio Ative Directory no local secundário
  • Usar um Controlador de Domínio Ative Directory local
  • Replicar o Controlador de Domínio Ative Directory usando o Azure Site Recovery

Perfis de utilizador

Recomendamos que você use FSLogix para gerenciar perfis de usuário. Para obter informações, consulte Opções de continuidade de negócios e recuperação de desastres para FSLogix.

Criar cópias de segurança dos dados

Você também tem a opção de fazer backup de seus dados. Você pode escolher um dos seguintes métodos para fazer backup dos dados da Área de Trabalho Virtual do Azure:

  • Para dados de computação, recomendamos apenas fazer backup de pools de hosts pessoais com o Backup do Azure.
  • Para dados de armazenamento, a solução de backup que recomendamos varia com base no armazenamento back-end usado para armazenar perfis de usuário:

Dependências do aplicativo

Por fim, certifique-se de que todos os aplicativos de negócios que dependem de dados localizados na região primária possam fazer failover para o local secundário. Além disso, certifique-se de definir as configurações que os aplicativos precisam para funcionar no novo local. Por exemplo, se um dos aplicativos depender do back-end SQL, certifique-se de replicar o SQL no local secundário. Você deve configurar o aplicativo para usar o local secundário como parte do processo de failover ou como sua configuração padrão. Você pode modelar dependências de aplicativos em planos do Azure Site Recovery. Para saber mais, consulte Sobre planos de recuperação.

Testes de recuperação de desastres

Depois de concluir a configuração da recuperação de desastres, convém testar seu plano para garantir que ele funcione.

Aqui estão algumas sugestões de como testar o seu plano:

  • Se as VMs de teste tiverem acesso à Internet, elas assumirão qualquer host de sessão existente para novas conexões, mas todas as conexões existentes com o host de sessão original permanecerão ativas. Certifique-se de que o administrador que executa o teste desconecta todos os usuários ativos antes de testar o plano.
  • Você só deve fazer testes completos de recuperação de desastres durante uma janela de manutenção para não interromper seus usuários.
  • Certifique-se de que seu teste abrange todos os aplicativos e dados críticos para os negócios.
  • Recomendamos que você faça failover apenas de até 100 VMs de cada vez. Se você tiver mais VMs do que isso, recomendamos fazer failover delas em lotes com 10 minutos de intervalo.

Próximos passos

Se você tiver dúvidas sobre como manter seus dados seguros, além de planejar interrupções, confira nosso guia de segurança.