Share via

Integre o ExpressRoute à recuperação de desastres para VMs do Azure

  • Artigo

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

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

  • Se as VMs do Azure usarem Discos gerenciados do Azure, os dados da VM serão replicados em 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 das VMs do Azure não cruza a Internet.

A ExpressRoute permite que você estenda as redes locais para a nuvem do Microsoft Azure por meio de uma conexão privada, facilitada por um provedor de conectividade. Se você tiver configurado o ExpressRoute, ele se integra ao Site Recovery da seguinte maneira:

  • Durante a replicação entre as regiões do Azure: o tráfego de replicação para a recuperação de desastres da VM do Azure está somente no Azure, e a Rota Expressa não é necessária ou usada para replicação. Entretanto, se você estiver se conectando de um site local às VMs do Azure no site primário do Azure, existem muitos problemas que deverão ser considerados ao configurar a recuperação de desastres para essas VMs do Azure.
  • Failover entre as regiões do Azure: quando ocorrem interrupções, você faz failover das VMs do Azure da região primária para secundária do Azure. Após fazer o failover para uma região secundária, existem muitas etapas a serem seguidas para acessar as VMs do Azure na região secundária usando o ExpressRoute.

Antes de começar

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

Recomendações gerais

Para práticas recomendadas e para garantir RTOs (Recovery Time Objectives) eficientes para recuperação de desastres, recomendamos que você faça o seguinte ao configurar o Site Recovery para integrar-se ao ExpressRoute:

  • Provisione os componentes de rede antes do failover para uma região secundária:
    • Quando você ativa 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.
    • Recuperação de site não pode configurar automaticamente os recursos de rede, como gateways de rede virtual.
    • Recomendamos que você provisione esses recursos de rede adicionais antes do failover. Um pequeno tempo de inatividade é associado a essa implantação e pode afetar o tempo de recuperação geral, se você não tiver contabilizado durante o planejamento da implantação.
  • Execute o desastre regular exercícios de recuperação:
    • Uma simulação valida sua estratégia de replicação sem perda de dados ou tempo de inatividade e não afeta seu ambiente de produção. Isso ajuda a evitar problemas de configuração de última hora que podem afetar negativamente o RTO.
    • Quando você executa um failover de teste para a simulação, recomendamos usar uma rede separada da VM do Azure, em vez da rede padrão que é configurada quando você habilita a replicação.
  • Use espaços de endereço IP diferentes 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 paralisações regionais.
    • Se você não puder usar um espaço de endereço separado, execute o failover de teste de simulação de recuperação de desastre em uma rede de teste separada com endereços IP diferentes. Você não pode conectar duas VNets com espaço de endereço IP sobreposto ao mesmo circuito da Rota Expressa.

Replicar VMs do Azure ao usar o ExpressRoute

Se você quiser configurar a replicação para VMs do Azure em um site primário e estiver se conectando a essas VMs em seu site local através da ExpressRoute, veja o que você precisa fazer:

  1. Ative 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 do Azure de destino, para corresponder àquelas na 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 no lado do alvo antes de habilitar a replicação.
  3. Crie outros elementos de rede:
    • O Site Recovery não cria tabelas de rotas, gateways VNet, conexões de gateway VNet, peering VNet ou outros recursos e conexões de rede na região secundária.
    • É necessário criar esses elementos de rede adicionais na região secundária, a qualquer momento, antes de executar um failover a partir 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 uma solução de virtualização de rede (NVA) implantada para controlar o fluxo do tráfego de rede:
    • 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 pelo NVA. A rota padrão é usada quando nenhuma outra configuração de rota específica pode ser encontrada.
    • Nesse caso, o NVA poderá ficar 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 no local.
    • Nesse cenário, é recomendável que você crie um ponto de extremidade de serviço de rede em sua rede virtual para o serviço de Microsoft. Storage, para que o tráfego de replicação não saia do limite do Azure.

Exemplo de replicação

Geralmente, as implantações corporativas têm cargas de trabalho divididas em várias VNets do Azure, com um hub de conectividade central para conectividade externa à Internet e a sites locais. Uma topologia hub e spoke é normalmente usada junto com o ExpressRoute.

On-premises-to-Azure with ExpressRoute before failover

  • Região. Os aplicativos são implantados na região Leste da Ásia do Azure.
  • Redes virtuais de spoke. Aplicativos são implantados em duas redes virtuais de spoke:
    • VNet1 de origem: 10.1.0.0/24.
    • VNet2 de origem: 10.2.0.0/24.
    • Cada rede virtual spoke é conectado ao vNet do Hub.
  • VNet do hub. Há uma vNet do hub vNet do Hub de código-fonte: 10.10.10.0/24.
    • Este hub vNet atua como o gatekeeper.
    • Todas as comunicações entre sub-redes passam por esse hub.
      • Subredes Hub vNet. O hub vNet tem duas sub-redes:
      • Subrede NVA: 10.10.10.0/25. Essa sub-rede contém uma NVA (10.10.10.10).
      • A sub-rede de gateway: 10.10.10.128/25. Essa sub-rede contém um gateway da Rota Expressa conectado a uma conexão da Rota Expressa que direciona para o site local por meio de um domínio de roteamento de emparelhamento.
  • O datacenter local tem uma conexão de circuito do ExpressRoute por meio de uma borda de parceiro na Região Administrativa Especial de Hong Kong.
  • Todo o roteamento é controlado por meio das tabelas de rota do Azure (UDR).
  • Todo o tráfego de saída entre o vNets ou o datacenter no local é roteado pelo NVA.

Hub e spoke, configurações de emparelhamento

Do spoke para o hub

Direção Configuração State
Do spoke para o hub Permitir que o endereço de rede virtual habilitado
Do spoke para o hub Permitir tráfego encaminhado habilitado
Do spoke para o hub Permitir trânsito de gateway Desabilitado
Do spoke para o hub Use remover gateways Enabled

Spoke to hub peering configuration

Do hub para o spoke

Direção Configuração State
Do hub para o spoke Permitir que o endereço de rede virtual habilitado
Do hub para o spoke Permitir tráfego encaminhado habilitado
Do hub para o spoke Permitir trânsito de gateway habilitado
Do hub para o spoke Use remover gateways Desabilitadas

Hub to spoke peering configuration

Etapas de exemplo

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

  1. Você habilita a replicação para uma VM.
  2. O Site Recovery cria réplicas de VNets, 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 da réplica que cria.
  4. Você cria manualmente gateways de rede virtual, conexões de gateway de rede virtual, emparelhamento de rede virtual ou qualquer outro recurso ou conexão de rede.

Falha nas VMs do Azure ao usar o ExpressRoute

Após a falha das VMs do Azure na região do Azure de destino usando o Site Recovery, você pode acessá-las usando o ExpressRoute emparelhamento privado.

  • Você precisa conectar o ExpressRoute ao alvo vNet com uma nova conexão. A conexão ExpressRoute existente não é transferida automaticamente.
  • A maneira como você configura sua conexão do ExpressRoute com o vNet de destino depende da sua topologia do ExpressRoute.

Acesso com dois circuitos

Dois circuitos com dois locais de emparelhamento

Essa configuração ajuda a proteger os circuitos do ExpressRoute em relação a desastres regionais. Se a localização primária de emparelhamento ficar inativa, as conexões poderão continuar da outra localização.

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

Dois circuitos com localização de emparelhamento único

Essa configuração ajuda a proteger contra falhas do circuito ExpressRoute primário, mas não se o único local de emparelhamento ExpressRoute cair, afetando os dois circuitos.

  • Você pode ter conexões simultâneas do datacenter no local para acessar o vNEt com o circuito principal e para o vNet de destino com o circuito secundário.
  • Com conexões simultâneas ao principal e ao destino, certifique-se de que o roteamento local use apenas o circuito secundário e a conexão após o failover.
  • Você não pode conectar os dois circuitos à mesma rede virtual quando os circuitos são criados no mesmo local de emparelhamento.

Acesso com um único circuito

Nessa configuração, há apenas um circuito do Expressroute. Embora o circuito tenha uma conexão redundante no caso de uma falha, um circuito de rota única não fornecerá resiliência se a região de emparelhamento falhar. Observe que:

  • Se a região do Azure de destino não estiver no mesmo local da origem, você precisará ativar o ExpressRoute Premium se estiver usando um único circuito de Rota Expressa. Saiba mais sobre localizações de ExpressRoute e preços de ExpressRoute.
  • Você não pode conectar redes virtuais de origem e de destino simultaneamente o circuito se o mesmo espaço de endereço IP é usado na região de destino. Neste cenário:
    • Desconectar a conexão do lado de origem e, em seguida, estabelecer a conexão do lado de destino. Essa alteração de conexão pode ser inserida como parte de um plano de recuperação de Site Recovery. Observe 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 da conexão para a região de destino.
      • Se você criou a conexão na região de destino e a região primária for recuperada posteriormente, poderá ocorrer queda de pacotes se duas conexões simultâneas tentarem se conectar ao mesmo espaço de endereço.
      • Para evitar isso, encerrar imediatamente a conexão primária.
      • Após o failback de VM para a região principal, a conexão principal 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á conectar-se simultaneamente às VNets de origem e de destino a partir do mesmo circuito do ExpressRoute.

Exemplo de failover

No nosso exemplo, estamos usando a topologia a seguir:

  • Dois circuitos ExpressRoute diferentes em dois locais de emparelhamentos diferentes.
  • Reter endereços IP privados para as VMs do Azure após o failover.
  • Região de recuperação de destino é o Azure do Sudeste Asiático.
  • Uma conexão de circuito do ExpressRoute secundário é estabelecida por meio de uma borda de parceiro em Singapura.

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

Etapas de exemplo

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

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

  2. Falha nas VMs do Azure, com essas etapas adicionais durante ou após o failover.

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

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

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

    d. Configurar os UDRs na VNet do hub, e as duas VNets spoke.

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

As etapas acima podem ser inseridas como parte de um plano de recuperação. De acordo com a conectividade do aplicativo e com os 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 máquinas virtuais e concluir a conectividade, o ambiente de recuperação é da seguinte maneira.

On-premises-to-Azure with ExpressRoute after Failover

Próximas etapas

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