Arquitetura de recuperação de desastre da VMware para o Azure – Modernizada

  • Artigo

Este artigo descreve a arquitetura e os processos usados quando você implanta a replicação de recuperação de desastre, failover e recuperação de VMs (máquinas virtuais) da VMware entre um site da VMware local e o Azure usando a experiência de proteção de computador físico/VMware Modernizada.

Observação

Crie um novo cofre dos Serviços de Recuperação para configurar o dispositivo de replicação do ASR. Não use um cofre existente.

Para obter informações sobre a arquitetura do Azure Site Recovery na arquitetura Clássica, confira este artigo.

Componentes de arquitetura

A tabela e o gráfico a seguir fornecem uma visão geral dos componentes usados para recuperação de desastre de VMs/computadores físicos da VMware para o Azure.

Arquitetura do VMware para o Azure

Componente Requisito Detalhes
Azure Uma assinatura do Azure, uma conta de Armazenamento do Azure para cache, disco gerenciado e rede do Azure. Os dados replicados de VMs locais são armazenados no armazenamento do Azure. As VMs do Azure são criadas com os dados replicados quando você faz um failover do local para o Azure. As VMs do Azure se conectam à rede virtual do Azure quando são criadas.
Aplicativo de replicação do Azure Site Recovery É o bloco de construção básico de toda a infraestrutura local do Azure Site Recovery.

Todos os componentes no dispositivo coordenam com o dispositivo de replicação. Esse serviço supervisiona todas as atividades do Site Recovery de ponta a ponta, inclusive o monitoramento da integridade de máquinas protegidas, replicação de dados, atualizações automáticas, etc.		 O dispositivo hospeda vários componentes cruciais como:

Servidor proxy: esse componente atua como um canal proxy entre o agente de mobilidade e os serviços do Site Recovery na nuvem. Ele garante que não haja outra conectividade de Internet necessária das cargas de trabalho de produção para gerar pontos de recuperação.

Itens descobertos: esse componente reúne informações do vCenter e coordena com o serviço de gerenciamento do Azure Site Recovery na nuvem.

Servidor de nova proteção: esse componente coordena entre o Azure e os computadores locais durante as operações de nova proteção e failback.

Servidor de processo: esse componente é usado para armazenamento em cache e compactação de dados antes de serem enviados para o Azure.

Saiba mais sobre o dispositivo de replicação e como usar vários dispositivos de replicação.

Agente dos serviços de recuperação: esse componente é usado para configurar os serviços do Site Recovery, registrar-se neles e para monitorar a integridade de todos os componentes.

Provedor do Site Recovery: esse componente é usado para facilitar a nova proteção. Ele identifica entre a nova proteção do local alternativo e a nova proteção do local original para um computador de origem.

Serviço de replicação: esse componente é usado para replicar dados do local de origem para o Azure.
Servidores VMware VMs de VMware são hospedadas em servidores ESXi do vSphere locais. Recomendamos um servidor vCenter para gerenciar os hosts. Durante a implantação do Site Recovery, você pode adicionar servidores VMware no cofre dos Serviços de Recuperação.
Computadores replicados O Serviço de Mobilidade é instalado em cada VM de VMware que você replicar. Recomendamos que você permita a instalação automática do serviço de mobilidade. Como alternativa, é possível instalar o serviço manualmente.

Configurar a conectividade de rede de saída

Para que o Site Recovery funcione conforme o esperado, você precisa modificar a conectividade de rede de saída para permitir que seu ambiente seja replicado.

Observação

O Site Recovery não dá suporte ao uso de um proxy de autenticação para controlar a conectividade de rede.

Conectividade de saída para URLs

Caso esteja usando um proxy de firewall baseado em URL para controlar a conectividade de saída, permita acesso a estas URLs:

URL Detalhes
portal.azure.com Navegue até o portal do Azure.
*.windows.net
*.msftauth.net
*.msauth.net
*.microsoft.com
*.live.com
*.office.com 		Para entrar em sua assinatura do Azure.
*.microsoftonline.com Crie aplicativos do Microsoft Entra para que o dispositivo se comunique com o Azure Site Recovery.
management.azure.com Crie aplicativos do Microsoft Entra para que o dispositivo se comunique com o serviço do Azure Site Recovery.
*.services.visualstudio.com Carregue logs de aplicativo usados para monitoramento interno.
*.vault.azure.net Gerencie segredos no Azure Key Vault. Observação: verifique se os computadores que precisam ser replicados têm acesso a isso.
aka.ms Permita acesso a links "também conhecidos como". Usado para atualizações de dispositivo do Azure Site Recovery.
download.microsoft.com/download Permita downloads da Microsoft.
*.servicebus.windows.net Comunicação entre o dispositivo e o serviço do Azure Site Recovery.
*.discoverysrv.windowsazure.com Conexão com a URL do serviço de descoberta do Azure Site Recovery.
*.hypervrecoverymanager.windowsazure.com Conexão com as URLs de microsserviço do Azure Site Recovery.
*.blob.core.windows.net Carregar dados no armazenamento do Azure que é usado para criar discos de destino.
*.backup.windowsazure.com URL do serviço de proteção – um microsserviço usado pelo Azure Site Recovery para processar e criar discos replicados no Azure.
*.prod.migration.windowsazure.com Para descobrir sua propriedade local.

Processo de replicação

  1. Ao habilitar a replicação para uma VM, a replicação inicial para o armazenamento do Azure começa, usando a política de replicação especificada. Observe o seguinte:

    • Para as VMs de VMware, a replicação é em nível de bloco, quase contínua, usando o agente do serviço Mobilidade em execução na VM.
    • Qualquer configuração de política de replicação é aplicada:
      • Limite de RPO. Essa configuração não afeta a replicação. Isso ajuda no monitoramento. Um evento é gerado e, opcionalmente, um email enviado, se o RPO atual exceder o limite que você especificar.
      • Retenção do ponto de recuperação. Essa configuração especifica o tempo retroativo da recuperação quando ocorrer uma interrupção. A retenção máxima é de 15 dias.
      • Instantâneos consistentes com o aplicativo. Um instantâneo consistente com o aplicativo pode de demorar de 1 a 12 horas, dependendo das necessidades do aplicativo. Instantâneos são instantâneos de blob padrão do Azure. O agente de Mobilidade executando em uma VM solicita um instantâneo de VSS de acordo com essa configuração e indica esse ponto no tempo como um ponto consistente do aplicativo no fluxo de replicação.

      Observação

      Um alto período de retenção do ponto de recuperação pode ter uma implicação no custo de armazenamento, pois pode ser necessário salvar mais pontos de recuperação.

  2. O tráfego é replicado para pontos de extremidade públicos do Armazenamento do Microsoft Azure pela Internet. Como alternativa, você pode usar o Azure ExpressRoute com emparelhamento da Microsoft. A replicação de tráfego através de uma VPN (rede virtual privada) site a site de um site local para o Azure só tem suporte ao usar pontos de extremidade privados.

  3. A operação de replicação inicial garante que todos os dados no computador no momento da habilitação da replicação sejam enviados para o Azure. Após a conclusão da replicação inicial, a replicação de alterações delta para o Azure é iniciada. As alterações controladas de uma máquina são enviadas para o servidor de processo.

  4. A comunicação ocorre da seguinte maneira:

    • As VMs se comunicam com o dispositivo local na porta HTTPS 443 de entrada para o gerenciamento de replicação.
    • As VMs enviam os dados de replicação para o dispositivo na porta de entrada HTTPS 9443. Essa porta pode ser modificada.
    • O dispositivo recebe, otimiza, criptografa e envia dados de replicação para o Armazenamento do Microsoft Azure pela porta 443 de saída.

  5. Os registros de dados de replicação primeiro ficam em uma conta de armazenamento de cache no Azure. Esses logs são processados e os dados são armazenados em um Disco Gerenciado do Azure (chamado de asrseeddisk). Os pontos de recuperação são criados nesse disco.

Fluxo de dados do VMware para o Azure com portas

Processo de ressincronização

  1. Às vezes, durante a replicação inicial ou ao transferir alterações delta, poderão ocorrer problemas de conectividade de rede entre o computador de origem e o servidor de processo ou entre o servidor de processo para Azure. Qualquer um deles pode levar a falhas na transferência de dados para o Azure momentaneamente.
  2. Para evitar problemas de integridade de dados e minimizar os custos de transferência de dados, o Site Recovery marcará um computador para ressincronização.
  3. Um computador também pode ser marcado para ressincronização em situações como as indicadas a seguir, para manter a consistência entre o computador de origem e os dados armazenados no Azure
    • Se um computador passar por um desligamento forçado
    • Se um computador passar por alterações de configuração como o redimensionamento de disco (modificando o tamanho do disco de 2 TB para 4 TB)
  4. A ressincronização envia apenas dados delta para o Azure. Transferência de dados entre o local e o Azure minimizada pela computação de somas de verificação de dados entre o computador de origem e os dados armazenados no Azure.
  5. Por padrão, a ressincronização está agendada para execução automática fora das horas de trabalho. Se você não quiser aguardar a ressincronização fora do horário de trabalho, você poderá ressincronizar uma VM manualmente. Para fazer isso, acesse o portal do Azure e selecione VM >Ressincronizar.
  6. Se a ressincronização padrão falhar fora do horário comercial e uma intervenção manual for necessária, um erro será gerado no computador específico no portal do Azure. Você pode resolver o erro e disparar a ressincronização manualmente.
  7. Após a conclusão da ressincronização, a replicação de alterações delta será retomada.

Política de replicação

Quando você habilita a replicação de VM do Azure, por padrão, o Site Recovery cria uma política de replicação com as configurações padrão resumidas na tabela.

Configuração de política Detalhes Padrão
Retenção do ponto de recuperação Especifica por quanto tempo o Site Recovery mantém os pontos de recuperação 1 dia
Frequência de instantâneos consistentes com aplicativo A frequência com que o Site Recovery tira um instantâneo consistente com aplicativos Desabilitado

Gerenciando políticas de replicação

Você pode gerenciar e modificar as configurações padrão das políticas de replicação da seguinte maneira:

  • Modifique as configurações quando habilitar a replicação.
  • Você pode criar ou editar uma nova política de replicação ao tentar habilitar a replicação.

Consistência de várias VMs

Caso deseje que as VMs sejam replicadas juntas e tenham pontos de recuperação consistentes com aplicativo e com falhas compartilhados no failover, você poderá reuni-las em um grupo de replicação. A consistência de várias VMs afeta o desempenho da carga de trabalho e só deve ser usada para quatro cargas de trabalho de VMs que precisam de consistência em todos os computadores.

Instantâneos e pontos de recuperação

Os pontos de recuperação são criados com base em instantâneos de discos de VMs tirados em um ponto específico no tempo. Quando você faz failover de uma VM, você usa um ponto de recuperação para restaurar a VM na localização de destino.

Durante o failover, em geral, queremos garantir que a VM seja iniciada sem dados corrompidos nem perda de dados e que os dados da VM sejam consistentes para o sistema operacional e para os aplicativos executados na VM. Isso depende do tipo de instantâneos tirados.

O Site Recovery tira instantâneos da seguinte maneira:

  1. O Site Recovery tira instantâneos consistentes com falhas de dados por padrão e instantâneos consistentes com aplicativo se você especifica uma frequência para eles.
  2. Os pontos de recuperação são criados com base nos instantâneos e armazenados de acordo com as configurações de retenção na política de replicação.

Consistência

A tabela a seguir explica os diferentes tipos de consistência.

Consistente com falhas

Descrição Detalhes Recomendação
Um instantâneo consistente com falha captura os dados que estavam no disco quando o instantâneo foi tirado. Ele não inclui nada na memória.

Ele contém o equivalente dos dados em disco que estariam presentes se a VM falhasse ou se o cabo de alimentação fosse puxado do servidor no instante em que o instantâneo foi tirado.

Um ponto de recuperação consistente com falhas não garante a consistência dos dados para o sistema operacional nem para os aplicativos na VM.		 O Site Recovery cria pontos de recuperação consistentes com falhas a cada cinco minutos por padrão. Essa configuração não pode ser modificada.

 Hoje, a maioria dos aplicativos pode se recuperar bem de pontos consistentes com falhas.

Os pontos de recuperação consistentes com falhas geralmente são suficientes para a replicação de sistemas operacionais e aplicativos, como servidores DHCP e servidores de impressão.

Consistente com aplicativo

Descrição Detalhes Recomendação
Os pontos de recuperação consistentes com aplicativo são criados com base nos instantâneos consistentes com aplicativo.

Um instantâneo consistente com aplicativo contêm todas as informações em um instantâneo consistente com falhas, além de todos os dados na memória e as transações em andamento.		 Os instantâneos consistentes com aplicativo usam o VSS (Serviço de Cópias de Sombra de Volume):

1) O Azure Site Recovery usa o método de backup Somente Cópia (VSS_BT_COPY) que não altera o tempo de backup do log de transações nem o número de sequência de SQL da Microsoft

2) Quando um instantâneo é iniciado, o VSS executa uma operação COW (cópia na gravação) no volume.

3) Antes de executar a COW, o VSS informa todos os aplicativos do computador de que precisa liberar seus dados residentes na memória para o disco.

4) Em seguida, o VSS permite que o aplicativo de backup/recuperação de desastre (nesse caso, o Site Recovery) leia os dados de instantâneo e continue.		 Os instantâneos consistentes com aplicativo são tirados de acordo com a frequência especificada. Essa frequência sempre deve ser inferior àquela definida para a retenção de pontos de recuperação. Por exemplo, se você retém os pontos de recuperação usando a configuração padrão de 24 horas, defina a frequência como inferior a 24 horas.

Eles são mais complexos e levam mais tempo para serem concluídos do que os instantâneos consistentes com falhas.

Elas afetam o desempenho de aplicativos executados em uma VM habilitada para replicação.

Processo de failover e failback

Depois que a replicação é configurada e você executou uma simulação de recuperação de desastre (failover de teste) para verificar se tudo está funcionando conforme o esperado, você poderá executar failover e failback conforme necessário.

  1. Você pode fazer failover de uma única máquina ou criar um plano de recuperação para fazer failover de várias VMs ao mesmo tempo. As vantagens de um plano de recuperação em vez de failover de única máquina incluem:

    • Você pode modelar dependências do aplicativo, incluindo todas as VMs entre o aplicativo em um único plano de recuperação.
    • Você pode adicionar scripts, runbooks do Azure e pausar para ações manuais.

  2. Depois de disparar o failover inicial, você confirma-o para começar a acessar a carga de trabalho da VM do Azure.

  3. Quando o site primário local estiver disponível novamente, você poderá se preparar executar o failback. Se você precisar fazer failback de grandes volumes de tráfego, configure um novo dispositivo de replicação do Azure Site Recovery.

    • Estágio 1: proteja novamente as VMs do Azure para que elas comecem a replicação para as VMs de VMware locais.
    • Estágio 2: execute um failover para o site local.
    • Etapa 3: depois que as cargas de trabalho fizeram failback, você reabilitará a replicação para as VMs locais.

Próximas etapas

Siga este tutorial para habilitar a replicação de VMware para o Azure.