Integre a Rota Expressa com a recuperação de desastres para VMs do Azure

Este artigo descreve como integrar o Azure ExpressRoute com o Azure Site Recovery, quando você configura a recuperação de desastres para VMs do Azure em uma região secundária do Azure.

O Site Recovery permite a recuperação de desastres de VMs do Azure replicando dados de VM do Azure para o Azure.

  • Se as VMs do Azure usarem discos gerenciados do Azure, os dados da VM serão replicados para um disco gerenciado replicado na região secundária.
  • Se as VMs do Azure não usarem discos gerenciados, os dados da VM serão replicados para uma conta de armazenamento do Azure.
  • Os pontos de extremidade de replicação são públicos, mas o tráfego de replicação para VMs do Azure não atravessa a Internet.

O ExpressRoute permite que você estenda redes locais para a nuvem do Microsoft Azure por meio de uma conexão privada, facilitada por um provedor de conectividade. Se você tiver a Rota Expressa configurada, ela se integrará à Recuperação de Site da seguinte maneira:

  • Durante a replicação entre regiões do Azure: o tráfego de replicação para recuperação de desastres de VM do Azure está apenas no Azure e a Rota Expressa não é necessária ou usada para replicação. No entanto, se você estiver se conectando de um site local às VMs do Azure no site principal do Azure, há muitos problemas a serem observados ao configurar a recuperação de desastres para essas VMs do Azure.
  • Failover entre regiões do Azure: quando ocorrem interrupções, você faz failover de VMs do Azure da região principal para a secundária do Azure. Depois de fazer failover para uma região secundária, há muitas etapas a serem executadas para acessar as VMs do Azure na região secundária usando a Rota Expressa.

Antes de começar

Antes de começar, certifique-se de que compreende os seguintes conceitos:

  • Circuitos de Rota Expressa
  • Domínios de roteamento ExpressRoute
  • Localizações da Rota Expressa.
  • Arquitetura de replicação de VM do Azure
  • Como configurar a replicação para VMs do Azure.
  • Como fazer failover de VMs do Azure.

Recomendações gerais

Para obter práticas recomendadas e garantir RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) eficientes para recuperação de desastres, recomendamos que você faça o seguinte ao configurar a Recuperação de Site para integração com a Rota Expressa:

  • Provisione componentes de rede antes do failover para uma região secundária:
    • Quando você habilita a replicação para VMs do Azure, o Site Recovery pode implantar automaticamente recursos de rede, como redes, sub-redes e gateways na região do Azure de destino, com base nas configurações de rede de origem.
    • O Site Recovery não pode configurar automaticamente recursos de rede, como gateways VNet.
    • Recomendamos que você provisione esses recursos de rede adicionais antes do failover. Um pequeno tempo de inatividade está associado a essa implantação e pode afetar o tempo de recuperação geral, se você não o levou em conta durante o planejamento da implantação.
  • Execute exercícios regulares de recuperação de desastres:
    • Um teste valida a sua estratégia de replicação sem perda de dados ou tempo de inatividade e não afeta o seu ambiente de produção. Ele ajuda a evitar problemas de configuração de última hora que podem afetar negativamente o RTO.
    • Quando você executa um failover de teste para o drill, recomendamos que você use uma rede VM do Azure separada, em vez da rede padrão que é configurada quando você habilita a replicação.
  • Use diferentes espaços de endereço IP se você tiver um único circuito de Rota Expressa.
    • Recomendamos que você use um espaço de endereço IP diferente para a rede virtual de destino. Isso evita problemas ao estabelecer conexões durante interrupções regionais.
    • Se não for possível usar um espaço de endereçamento separado, execute o failover do teste de drill de recuperação de desastres em uma rede de teste separada com endereços IP diferentes. Não é possível conectar duas VNets com espaço de endereço IP sobreposto ao mesmo circuito de Rota Expressa.

Replicar VMs do Azure ao usar a Rota Expressa

Se você quiser configurar a replicação para VMs do Azure em um site primário e estiver se conectando a essas VMs do seu site local pela Rota Expressa, aqui está o que você precisa fazer:

  1. Habilite a replicação para cada VM do Azure.
  2. Opcionalmente, deixe o Site Recovery configurar a rede:
    • Quando você configura e habilita a replicação, o Site Recovery configura redes, sub-redes e sub-redes de gateway na região de destino do Azure, para corresponder às da região de origem. O Site Recovery também mapeia entre as redes virtuais de origem e de destino.
    • Se você não quiser que o Site Recovery faça isso automaticamente, crie os recursos de rede do lado de destino antes de habilitar a replicação.
  3. Crie outros elementos de rede:
    • A Recuperação de Site não cria tabelas de rotas, gateways de rede virtual, conexões de gateway de rede virtual, emparelhamento de rede virtual ou outros recursos e conexões de rede na região secundária.
    • Você precisa criar esses elementos de rede adicionais na região secundária, a qualquer momento, antes de executar um failover da região primária.
    • Você pode usar planos de recuperação e scripts de automação para configurar e conectar esses recursos de rede.
  4. Se você tiver um dispositivo virtual de rede (NVA) implantado para controlar o fluxo de tráfego de rede:
    • A rota de sistema padrão do Azure para replicação de VM do Azure é 0.0.0.0/0.
    • Normalmente, as implantações de NVA também definem uma rota padrão (0.0.0.0/0) que força o tráfego de saída da Internet a fluir através do NVA. A rota padrão é usada quando nenhuma outra configuração de rota específica pode ser encontrada.
    • Nesse caso, o NVA pode estar sobrecarregado se todo o tráfego de replicação passar pelo NVA.
    • A mesma limitação também se aplica ao usar rotas padrão para rotear todo o tráfego de VM do Azure para implantações locais.
    • Nesse cenário, recomendamos que você crie um ponto de extremidade de serviço de rede em sua rede virtual para o serviço Microsoft.Storage, para que o tráfego de replicação não saia do limite do Azure.

Exemplo de replicação

Normalmente, as implantações corporativas têm cargas de trabalho divididas em várias redes virtuais do Azure, com um hub de conectividade central para conectividade externa à Internet e a sites locais. Uma topologia de hub e spoke é normalmente usada em conjunto com a Rota Expressa.

On-premises-to-Azure with ExpressRoute before failover

  • Região. Os aplicativos são implantados na região do Azure Ásia Oriental.
  • Falou vNets. Os aplicativos são implantados em duas vNets faladas:
    • Fonte vNet1: 10.1.0.0/24.
    • Fonte vNet2: 10.2.0.0/24.
    • Cada rede virtual spoke está conectada ao Hub vNet.
  • Hub vNet. Há um hub vNet Source Hub vNet: 10.10.10.0/24.
    • Este hub vNet atua como o gatekeeper.
    • Todas as comunicações entre sub-redes passam por este hub.
      • Sub-redes Hub vNet. O hub vNet tem duas sub-redes:
      • Sub-rede NVA: 10.10.10.0/25. Esta sub-rede contém um NVA (10.10.10.10).
      • Sub-rede do gateway: 10.10.10.128/25. Essa sub-rede contém um gateway de Rota Expressa conectado a uma conexão de Rota Expressa que roteia para o site local por meio de um domínio de roteamento de emparelhamento privado.
  • O datacenter local tem uma conexão de circuito de Rota Expressa por meio de uma borda de parceiro na Região Administrativa Especial de Hong Kong.
  • Todo o roteamento é controlado por meio de tabelas de rotas do Azure (UDR).
  • Todo o tráfego de saída entre vNets ou para o datacenter local é roteado através do NVA.

Configurações de emparelhamento de hub e spoke

Spoke para hub

Direção Definição Distrito
Spoke para hub Permitir endereço de rede virtual Ativado(a)
Spoke para hub Permitir tráfego encaminhado Ativado(a)
Spoke para hub Permitir o trânsito do gateway Disabled
Spoke para hub Usar remover gateways Ativado(a)

Spoke to hub peering configuration

Hub para spoke

Direção Definição Distrito
Hub para spoke Permitir endereço de rede virtual Ativado(a)
Hub para spoke Permitir tráfego encaminhado Ativado(a)
Hub para spoke Permitir o trânsito do gateway Ativado(a)
Hub para spoke Usar remover gateways Disabled

Hub to spoke peering configuration

Exemplos de passos

Em nosso exemplo, o seguinte deve acontecer ao habilitar a replicação para VMs do Azure na rede de origem:

  1. Você habilita a replicação para uma VM.
  2. O Site Recovery cria vNets de réplica, sub-redes e sub-redes de gateway na região de destino.
  3. O Site Recovery cria mapeamentos entre as redes de origem e as redes de destino de réplica que cria.
  4. Você cria manualmente gateways de rede virtual, conexões de gateway de rede virtual, emparelhamento de rede virtual ou quaisquer outros recursos ou conexões de rede.

Failover de VMs do Azure ao usar a Rota Expressa

Depois de falhar as VMs do Azure na região do Azure de destino usando o Site Recovery, você poderá acessá-las usando o emparelhamento privado da Rota Expressa.

  • Você precisa conectar o ExpressRoute à vNet de destino com uma nova conexão. A conexão de Rota Expressa existente não é transferida automaticamente.
  • A maneira como você configura sua conexão de Rota Expressa com a vNet de destino depende de sua topologia de Rota Expressa.

Acesso com dois circuitos

Dois circuitos com dois locais de emparelhamento

Essa configuração ajuda a proteger os circuitos da Rota Expressa contra desastres regionais. Se o local de emparelhamento principal ficar inativo, as conexões poderão continuar a partir do outro local.

  • O circuito conectado ao ambiente de produção é geralmente o principal. O circuito secundário normalmente tem menor largura de banda, que pode ser aumentada se ocorrer um desastre.
  • Após o failover, você pode estabelecer conexões do circuito secundário da Rota Expressa para a vNet de destino. Como alternativa, você pode ter conexões configuradas e prontas em caso de desastre, para reduzir o tempo geral de recuperação.
  • Com conexões simultâneas com vNets primário e de destino, certifique-se de que seu roteamento local use apenas o circuito secundário e a conexão após o failover.
  • Os vNets de origem e destino podem receber novos endereços IP, ou manter os mesmos, após o failover. Em ambos os casos, as conexões secundárias podem ser estabelecidas antes do failover.

Dois circuitos com um único local de emparelhamento

Essa configuração ajuda a proteger contra falhas do circuito primário da Rota Expressa, mas não se o único local de emparelhamento da Rota Expressa ficar inativo, afetando ambos os circuitos.

  • Você pode ter conexões simultâneas do datacenter local para o vNEt de origem com o circuito primário e para o vNet de destino com o circuito secundário.
  • Com conexões simultâneas com o primário e o destino, certifique-se de que o roteamento local use apenas o circuito secundário e a conexão após o failover.
  • Não é possível conectar ambos os circuitos à mesma vNet quando os circuitos são criados no mesmo local de emparelhamento.

Acesso com um único circuito

Nesta configuração, há apenas um circuito de rota expressa. Embora o circuito tenha uma conexão redundante no caso de um cair, um circuito de rota única não fornecerá resiliência se sua região de emparelhamento cair. Tenha em atenção que:

  • Se a região do Azure de destino não estiver no mesmo local que a origem, você precisará habilitar o ExpressRoute Premium se estiver usando um único circuito de Rota Expressa. Saiba mais sobre os locais da Rota Expressa e os preços da Rota Expressa.
  • Não é possível conectar vNets de origem e de destino simultaneamente ao circuito se o mesmo espaço de endereço IP for usado na região de destino. Neste cenário:
    • Desconecte a conexão do lado da origem e estabeleça a conexão do lado do destino. Essa alteração de conexão pode ser executada por script como parte de um plano de recuperação de site. Note-se que:
      • Em uma falha regional, se a região primária estiver inacessível, a operação de desconexão poderá falhar. Isso pode afetar a criação de conexão com a região de destino.
      • Se você criou a conexão na região de destino e a região primária se recupera mais tarde, você pode enfrentar quedas de pacotes se duas conexões simultâneas tentarem se conectar ao mesmo espaço de endereço.
      • Para evitar isso, encerre a conexão principal imediatamente.
      • Após o failback da VM para a região primária, a conexão primária pode ser estabelecida novamente, depois que você desconectar a conexão secundária.
  • Se um espaço de endereço diferente for usado na vNet de destino, você poderá se conectar simultaneamente às vNets de origem e de destino a partir do mesmo circuito de Rota Expressa.

Exemplo de failover

Em nosso exemplo, estamos usando a seguinte topologia:

  • Dois circuitos ExpressRoute diferentes em dois locais de emparelhamento diferentes.
  • Retenha endereços IP privados para as VMs do Azure após o failover.
  • A região de recuperação de destino é o Azure Sudeste Asiático.
  • Uma conexão de circuito de Rota Expressa secundária é estabelecida através de uma borda de parceiro em Cingapura.

Para obter uma topologia simples que usa um único circuito de Rota Expressa, com o mesmo endereço IP após failover, revise este artigo.

Exemplos de passos

Para automatizar a recuperação neste exemplo, veja o que você precisa fazer:

  1. Siga as etapas para configurar a replicação.

  2. Faça failover das VMs do Azure, com essas etapas adicionais durante ou após o failover.

    a. Crie o Gateway de Rota Expressa do Azure na VNet do hub da região de destino. Isso é necessário para conectar o hub de destino vNet ao circuito ExpressRoute.

    b. Crie a conexão do hub de destino vNet para o circuito ExpressRoute de destino.

    c. Configure os emparelhamentos de VNet entre o hub da região de destino e as redes virtuais faladas. As propriedades de emparelhamento na região de destino são as mesmas da região de origem.

    d. Configure as UDRs na VNet do hub e as duas VNets faladas.

    • As propriedades dos UDRs do lado de destino são as mesmas do lado de origem ao usar os mesmos endereços IP.
    • Com diferentes endereços IP de destino, os UDRs devem ser modificados de acordo.

As etapas acima podem ser roteirizadas como parte de um plano de recuperação. Dependendo da conectividade do aplicativo e dos requisitos de tempo de recuperação, as etapas acima também podem ser concluídas antes de iniciar o failover.

Após a recuperação

Depois de recuperar as VMs e concluir a conectividade, o ambiente de recuperação é o seguinte.

On-premises-to-Azure with ExpressRoute after Failover

Próximos passos

Saiba mais sobre como usar planos de recuperação para automatizar o failover de aplicativos.