Identificar o cenário correto de recuperação de desastre
Para ajudar a limitar o impacto de uma falha de datacenter ou uma interrupção regional, sua organização deve preparar a proteção de recuperação de desastre correta. Definir a estratégia de proteção correta depende principalmente de quais dos vários cenários de falha provavelmente afetarão a funcionalidade da Área de Trabalho Virtual do Azure.
Objetivos e métricas
O processo de recuperação de desastre requer coordenação entre cada um dos procedimentos que são realizados para trazer uma organização de volta à operação completa. O que reúne esses procedimentos coletivamente é a presença de objetivos de nível de serviço comuns e claramente definidos. Os serviços de recuperação após desastre (DR) devem incluir as seguintes métricas:
- Objetivo de ponto de recuperação (RPO): A quantidade mínima de dados permitidos que você deve entregar aos clientes para o serviço, com base nos ativos de backup considerados como recuperados. Por outro lado, esse valor pode ser considerado a perda máxima de dados aceitável, expressa como uma porcentagem subtraída de 100.
- Objetivo de tempo de recuperação (RTO): A janela máxima de tempo permitida para que um processo de restauração ocorra, que também pode ser considerada uma medida de quanto tempo de inatividade a organização está disposto a dar.
- Período de retenção: O período máximo permitido para um conjunto de backup ser retido antes que ele precise ser atualizado e substituído.
O RPO e o RTO podem ser percebidos como balanceados entre si, para que um cliente possa decidir permitir tempos de recuperação mais longos para atingir pontos de recuperação mais altos. Se o tempo de recuperação for um problema para um cliente devido à largura de banda disponível ou ao risco de tempo de inatividade, o cliente poderá não conseguir obter um RPO alto.
O restante da unidade explora três cenários de falha diferentes e como preparar a BCDR (continuidade dos negócios e recuperação de desastre) para a Área de Trabalho Virtual do Azure:
- Cenário 1: Corrupção local de dados, metadados ou recursos
- Cenário 2: Falha de datacenter único da zona de disponibilidade em uma região do Azure
- Cenário 3: Interrupção da região do Azure
Observação
Para saber mais sobre como proteger componentes individuais da Área de Trabalho Virtual do Azure, consulte a seção "Saiba mais" na unidade resumo deste módulo.
Cenário 1: Corrupção local de dados, metadados ou recursos
Suponha que seu ambiente de Área de Trabalho Virtual do Azure seja afetado por uma falha de host de sessão ou uma corrupção do perfil FSLogix. Nessas situações, o método mais comum de recuperação é restaurar os perfis de um backup ou recompilar o host da sessão. Esta unidade examina como cada um desses métodos se aplica a cada componente de ambiente da Área de Trabalho Virtual do Azure.
Serviços da Área de Trabalho Virtual do Azure
O serviço de Área de Trabalho Virtual do Azure permanece totalmente funcional e não afetado por esses tipos de falha. A Microsoft é responsável por colocar tudo de volta em funcionamento no Contrato de Nível de Serviço (SLA) fornecido.
AD DS e Microsoft Entra Domain Services
Os controladores de domínio do Active Directory são componentes críticos da Área de Trabalho Virtual do Azure e devem estar sempre acessíveis. Para garantir que a falha não afete sua funcionalidade, verifique se você criou vários controladores de domínio. Se tiver controladores de domínio nas Máquinas Virtuais do Azure, confirme que os configurou para estarem no mesmo conjunto de disponibilidade. Se os controladores de domínio estiverem sendo executados como computadores locais, você deverá projetar a conectividade entre sua rede local e a rede virtual do Azure com redundância. Use Azure ExpressRoute para gerenciar caminhos e conexões redundantes. Faça backup do estado do sistema do Active Directory e restaure-o se necessário. Se estiver a utilizar o Microsoft Entra Domain Services, a Microsoft é responsável por manter controladores de domínio redundantes e ajudar a protegê-los contra falhas não planeadas.
Pools de hosts
Os pools de hosts podem ficar indisponíveis no curso normal da operação. Os pools de hosts entregam aplicativos e Áreas de Trabalho Virtuais do Azure aos usuários. Eles são configurados a partir da imagem da área de trabalho, portanto, se ocorrer uma falha e uma imagem da área de trabalho estiver disponível, você poderá recriá-las. Você também pode usar um pool de hosts separado para aplicativos que são consumidos por meio da Área de Trabalho Virtual do Azure. Você também deve considerar uma abordagem de recuperação de desastre semelhante para esse pool de hosts.
Redes virtuais
As redes virtuais são serviços gerenciados que não são afetados por esse tipo de falha. A Rede Virtual do Azure fornece um bloco IP privado em que você pode implantar todos os seus recursos para conectividade privada e, em seguida, pode proteger esses recursos dentro de um limite. Portanto, uma rede virtual nunca falhará ou ocorrerá uma interrupção se ocorrer uma falha local do recurso em um único datacenter.
Perfis FSLogix e anexação de aplicativo MSIX
Dependendo de sua opção de tecnologia de armazenamento FSLogix, você pode configurar o Backup do Azure para compartilhamentos de Arquivos do Azure e instantâneos do Azure NetApp Files. Como alternativa, você pode usar o serviço de backup para proteger arquivos e pastas em VMs de servidor.
Imagens
Você pode fazer alterações frequentes em imagens da área de trabalho durante o curso normal da manutenção do ambiente da Área de Trabalho Virtual do Azure. Deve manter cópias de segurança de imagens para que possa recuperá-las rapidamente em caso de danos.
Cenário 2: Falha de datacenter único da zona de disponibilidade em uma região do Azure
Uma região do Azure é um conjunto de datacenters implantados em um perímetro definido por latência e conectados por meio de uma rede regional dedicada de baixa latência. No caso de uma interrupção de um datacenter ou zona em uma região do Azure, a BCDR para Área de Trabalho Virtual do Azure deve incluir as recomendações listadas nas seções a seguir.
Serviços da Área de Trabalho Virtual do Azure
O serviço de Área de Trabalho Virtual do Azure permanece totalmente funcional e não afetado por esse tipo de falha. A Microsoft é responsável por colocar tudo de volta em funcionamento no SLA (Contrato de Nível de Serviço) fornecido.
AD DS e Microsoft Entra Domain Services
Para evitar uma única falha de datacenter, implante pelo menos dois controladores de domínio em uma zona de disponibilidade. Se estiver a utilizar o Microsoft Entra Domain Services, a Microsoft gere os dois controladores de domínio do seu inquilino numa zona de disponibilidade separada, se for suportado pela região.
Pools de hosts
Para resiliência de VM do pool de hosts, você pode implantar um pool de hosts da Área de Trabalho Virtual do Azure usando zonas de disponibilidade para VMs. Você pode distribuir VMs no pool de hosts entre diferentes datacenters que ainda estão dentro da mesma região.
Rede virtual
As redes virtuais são um serviço gerenciado e não afetadas por esse tipo de falha. Você deve garantir que os recursos confiáveis estejam sempre configurados com a conectividade de rede apropriada. Por exemplo, o uso de um balanceador de carga básico pode ser afetado por esse tipo de falha porque ele não dá suporte à disponibilidade de zona.
Perfis FSLogix e anexação de aplicativo MSIX
Use Arquivos do Azure com Armazenamento Redundante de Zona Premium para aproveitar o suporte para zonas de disponibilidade. Neste cenário, os perfis FSLogix e os VHDs da anexação de aplicativo MSIX continuam disponíveis se houver uma interrupção do datacenter.
Imagens
Este tipo de falha não afeta as imagens porque ficam disponíveis noutra zona.
Cenário 3: Interrupção da região do Azure
A falha de regiões completas do Azure é altamente improvável e rara. Mas você também deve estar preparado caso ocorra uma falha desse tipo. Considere implementar as recomendações a seguir para implementar a BCDR para a Área de Trabalho Virtual do Azure.
Serviços da Área de Trabalho Virtual do Azure
O serviço de Área de Trabalho Virtual do Azure permanece totalmente funcional e não afetado por esse tipo de falha. A Microsoft é responsável por colocar tudo de volta em funcionamento no SLA (Contrato de Nível de Serviço) fornecido.
AD DS e Microsoft Entra Domain Services
Para se preparar para este tipo de falha, pode expandir um domínio gerido para ter mais do que um conjunto de réplicas por inquilino do Microsoft Entra. Os conjuntos de réplicas podem ser adicionados a qualquer rede virtual em modo de peering em qualquer região do Azure que suporte o Microsoft Entra Domain Services.
Se utilizar controladores de domínio no local, terá de configurar a conectividade à rede virtual na nova região com uma VPN, o ExpressRoute ou uma rede de área alargada virtual (WAN virtual). Se utilizar o Microsoft Entra Domain Services, pode criar um conjunto de réplicas adicional noutra região. A rede virtual na região adicional que aloja o novo conjunto de réplicas tem de conseguir comunicar com a rede que aloja o conjunto primário do Microsoft Entra Domain Services. Recomendamos que você use o emparelhamento entre redes virtuais para replicação dentro do site entre conjuntos de réplicas.
Pools de hosts
Pode implementar um conjunto de anfitriões do Azure Virtual Desktop em configurações ativa-ativa e ativa-passiva :
Ativo-ativo: Com uma configuração ativa-ativa, um único pool de hosts pode ter VMs de várias regiões. Você deve combinar recursos de cache de nuvem para replicar ativamente o perfil FSLogix de um usuário no armazenamento em várias regiões. Para anexar a aplicação MSIX, utilize outra cópia numa partilha de ficheiros adicional na outra região. As VMs em cada região devem conter o Registro de cache de nuvem para especificar os locais. Além disso, você deve configurar as Políticas de Grupo para dar precedência ao local de armazenamento local. Essa implantação da Área de Trabalho Virtual do Azure fornece a maior eficiência de uma perspectiva do usuário. Isso ocorre porque, se houver uma falha, os usuários na região restante poderão continuar a usar o serviço sem precisar se conectar novamente. No entanto, essa configuração é mais dispendiosa e mais complexa de implantar e não é otimizada para desempenho.
Ativo-passivo: Para uma configuração ativo-passivo, você pode usar o Azure Site Recovery para replicar suas VMs na região secundária com seus controladores de domínio. Se você usar o Azure Site Recovery, não precisará registrar essas VMs manualmente. Em vez disso, o agente do Azure Virtual Desktop na VM secundária utiliza automaticamente o token de segurança mais recente para ligar à instância de serviço mais próxima da mesma. Isto garante que o anfitrião da sessão se associa automaticamente ao conjunto de anfitriões e que o utilizador precisa de voltar a ligar-se apenas para aceder às VMs. Para essa configuração, você também pode criar um pool de host secundário (conhecido como um de espera ativa) na região de failover com todos os recursos desativados. Em seguida, você poderá usar um plano de recuperação no Azure Site Recovery para ativar pools de host e criar um processo orquestrado. Você também precisa criar um novo grupo de aplicativos na região de failover e atribuir usuários a eles.
Redes virtuais
As falhas de região afetam as redes virtuais e os serviços implantados dentro das redes virtuais. Você deve planejar uma rede virtual em sua região secundária. Você pode criar uma rede virtual manualmente e, em seguida, configurar o emparelhamento com a rede primária. Você também pode usar o Azure Site Recovery para configurar a rede virtual na região de failover e preservar as configurações da rede primária.
Em uma Área de Trabalho Virtual do Azure conectada à sua rede local, você deve configurar a rede virtual na região secundária com conectividade com a rede local.
Perfis FSLogix e anexação de aplicativo MSIX
Você pode usar Azure NetApp Files como uma opção de armazenamento para perfis FSXlogix e anexação de aplicativo MSIX porque eles dão suporte à replicação entre regiões. Arquivos do Azure com o desempenho Standard também dão suporte à replicação entre regiões. Você pode configurar o agente FSLogix para dar suporte a vários locais de perfil, o que ajuda a garantir a disponibilidade em caso de falha. Se a localização primária falhar, o agente FSLogix será replicado como parte da VM do Azure Site Recovery. O agente tenta utilizar automaticamente o caminho do perfil que aponta para a região secundária.
Para o cenário ativo-ativo e se o RTO ou o RTA for menor que um dia, recomendamos que você use perfis FSLogix para usar o Cache de Nuvem. O Cache de Nuvem é um recurso do FSLogix que deve ser habilitado e configurado especificamente. Ele permite que você use vários locais remotos, que são atualizados continuamente durante a sessão do usuário.
Imagens
Deve replicar imagens na região secundária após cada modificação da imagem de ambiente de trabalho primária. Pode utilizar uma Galeria de Computação do Azure para partilhar imagens personalizadas entre regiões. Durante uma falha de região primária, você pode usar imagens da área de trabalho clonadas como fontes para a criação dos pools de host.
Dependências do aplicativo
As aplicações dependentes dos recursos disponíveis na região primária necessitam dos mesmos recursos na localização secundária. Por exemplo, se alguns de seus aplicativos estão conectados a um back-end do SQL implantado em uma região, certifique-se de replicar o SQL no local secundário. Para o SQL Server em Máquinas Virtuais do Azure, pode utilizar o Azure Site Recovery. Para o SQL como uma solução plataforma como serviço (PaaS), você pode usar a replicação geográfica ativa ou grupos de failover automático. Você deve incluir esses recursos no plano geral de BCDR. Além disso, você deve incluir um Azure Site Recovery que possa modelar dependências de aplicativo no plano de proteção.