Partilhar via

Reter endereços IP durante a ativação pós-falha

  • Artigo

O Azure Site Recovery permite a recuperação de desastres para VMs do Azure replicando VMs para outra região do Azure, fazendo failover se ocorrer uma interrupção e falhando de volta para a região principal quando as coisas voltarem ao normal.

Durante o failover, convém manter o endereço IP na região de destino idêntico à região de origem:

  • Por padrão, quando você habilita a recuperação de desastres para VMs do Azure, o Site Recovery cria recursos de destino com base nas configurações de recursos de origem. Para VMs do Azure configuradas com endereços IP estáticos, o Site Recovery tenta provisionar o mesmo endereço IP para a VM de destino, se ela não estiver em uso. Para obter uma explicação completa de como o Site Recovery lida com o endereçamento, leia este artigo.
  • Para aplicativos simples, a configuração padrão é suficiente. Para aplicativos mais complexos, talvez seja necessário provisionar recursos adicionais para garantir que a conectividade funcione conforme o esperado após o failover.

Este artigo fornece alguns exemplos para reter endereços IP em cenários de exemplo mais complexos. Os exemplos incluem:

  • Failover para uma empresa com todos os recursos em execução no Azure
  • Failover para uma empresa com uma implantação híbrida e recursos em execução no local e no Azure

Recursos no Azure: failover completo

A empresa A tem todos os seus aplicativos em execução no Azure.

Antes do failover

Nota

A replicação agora pode ser feita entre quaisquer duas regiões do Azure ao redor do mundo. Os clientes não estão mais limitados a permitir a replicação dentro de seu continente.

Aqui está a arquitetura antes do failover.

  • A empresa A tem redes e sub-redes idênticas nas regiões de origem e de destino do Azure.
  • Para reduzir o RTO (Recovery Time Objetive, objetivo de tempo de recuperação), a empresa usa nós de réplica para o SQL Server Always On, controladores de domínio, etc. Esses nós de réplica estão em uma VNet diferente na região de destino, para que possam estabelecer conectividade VPN site a site entre as regiões de origem e de destino. Isso não é possível se o mesmo espaço de endereço IP for usado na origem e no destino.
  • Antes do failover, a arquitetura de rede é a seguinte:
    • A região primária é o Azure East Asia
      • O Leste Asiático tem uma VNet (Source VNet) com espaço de endereço 10.1.0.0/16.
      • O Leste Asiático tem cargas de trabalho divididas em três sub-redes na rede virtual:
        • Sub-rede 1: 10.1.1.0/24
        • Sub-rede 2: 10.1.2.0/24
        • Sub-rede 3: 10.1.3.0/24
    • A região secundária (de destino) é o Azure Sudeste Asiático
      • O Sudeste Asiático tem uma VNet de recuperação (Recovery VNet) idêntica à VNet de origem.
      • O Sudeste Asiático tem uma VNet adicional (Azure VNet) com espaço de endereço 10.2.0.0/16.
      • A VNet do Azure contém uma sub-rede (Sub-rede 4) com espaço de endereço 10.2.4.0/24.
      • Os nós de réplica para o SQL Server Always On, controlador de domínio, etc., estão localizados na Sub-rede 4.
    • A VNet de origem e a VNet do Azure estão conectadas a uma conexão VPN site a site.
    • A VNet de recuperação não está conectada a nenhuma outra rede virtual.
    • A empresa A atribui/verifica endereços IP de destino para itens replicados. O IP de destino é o mesmo que o IP de origem para cada VM.

Recursos no Azure antes do failover completo

Após o failover

Se ocorrer uma interrupção regional de origem, a empresa A poderá fazer failover de todos os seus recursos para a região de destino.

  • Com os endereços IP de destino já instalados antes do failover, a empresa A pode orquestrar o failover e estabelecer automaticamente conexões após o failover entre a VNet de recuperação e a VNet do Azure. Isto é ilustrado no diagrama a seguir..
  • Dependendo dos requisitos do aplicativo, as conexões entre as duas VNets (VNet de Recuperação e VNet do Azure) na região de destino podem ser estabelecidas antes, durante (como uma etapa intermediária) ou após o failover.

    • A empresa pode usar planos de recuperação para especificar quando as conexões serão estabelecidas.

    • Eles podem se conectar entre as redes virtuais usando emparelhamento de rede virtual ou VPN site a site.

      • O emparelhamento de rede virtual não usa um gateway VPN e tem restrições diferentes.
      • O preço do emparelhamento de VNet é calculado de forma diferente do preço do Gateway VPN VNet-to-VNet. Para failovers, geralmente aconselhamos usar o mesmo método de conectividade que as redes de origem, incluindo o tipo de conexão, para minimizar incidentes de rede imprevisíveis.

      Recursos no failover completo do Azure

Recursos no Azure: failover de aplicativo isolado

Talvez seja necessário fazer failover no nível do aplicativo. Por exemplo, para fazer failover de um aplicativo específico ou camada de aplicativo localizado em uma sub-rede dedicada.

  • Nesse cenário, embora você possa manter o endereçamento IP, geralmente não é aconselhável, pois aumenta a chance de inconsistências de conectividade. Você também perderá a conectividade de sub-rede com outras sub-redes dentro da mesma VNet do Azure.
  • Uma maneira melhor de fazer failover de aplicativo no nível de sub-rede é usar endereços IP de destino diferentes para failover (se você precisar de conectividade com outras sub-redes na VNet de origem) ou isolar cada aplicativo em sua própria VNet dedicada na região de origem. Com a última abordagem, você pode estabelecer conectividade entre redes na região de origem e emular o mesmo comportamento quando fizer failover para a região de destino.

Neste exemplo, a Empresa A coloca aplicativos na região de origem em VNets dedicadas e estabelece conectividade entre essas VNets. Com esse design, eles podem executar failover de aplicativo isolado e reter os endereços IP privados de origem na rede de destino.

Antes do failover

Antes do failover, a arquitetura é a seguinte:

  • As VMs de aplicativo são hospedadas na região principal do Azure East Asia:

    • As VMs do App1 estão localizadas na VNet Source VNet 1: 10.1.0.0/16.
    • As VMs do App2 estão localizadas na VNet Source VNet 2: 10.2.0.0/16.
    • A VNet 1 de origem tem duas sub-redes.
    • A VNet 2 de origem tem duas sub-redes.

  • A região secundária (de destino) é o Azure Sudeste Asiático - o Sudeste Asiático tem uma VNets de recuperação (VNet de Recuperação 1 e VNet de Recuperação 2) idênticas à VNet de Origem 1 e à VNet de Origem 2. - A VNet de Recuperação 1 e a VNet de Recuperação 2 têm duas sub-redes que correspondem às sub-redes na VNet de Origem 1 e na VNet de Origem 2 - o Sudeste Asiático tem uma VNet adicional (Azure VNet) com espaço de endereço 10.3.0.0/16. - A VNet do Azure contém uma sub-rede (Sub-rede 4) com espaço de endereço 10.3.4.0/24. - Os nós de réplica para SQL Server Always On, controlador de domínio, etc. estão localizados na Sub-rede 4.

  • Há várias conexões VPN site a site:

    • VNet de origem 1 e Azure VNet
    • VNet 2 de origem e VNet do Azure
    • A VNet de origem 1 e a VNet de origem 2 estão conectadas com VPN site a site

  • A VNet de Recuperação 1 e a VNet de Recuperação 2 não estão conectadas a nenhuma outra VNet.

  • A empresa A configura gateways VPN na VNet de recuperação 1 e na VNet de recuperação 2, para reduzir o RTO.

  • A VNet1 de recuperação e a VNet2 de recuperação não estão conectadas a nenhuma outra rede virtual.

  • Para reduzir o RTO (Recovery Time Objetive, objetivo de tempo de recuperação), os gateways VPN são configurados na VNet1 de recuperação e na VNet2 de recuperação antes do failover.

    Recursos no Azure antes do failover do aplicativo

Após o failover

No caso de uma interrupção ou problema que afete um único aplicativo (em **Source VNet 2 em nosso exemplo), a Empresa A pode recuperar o aplicativo afetado da seguinte maneira:

  • Desconecte as conexões VPN entre a VNet1 de Origem e a VNet2 de Origem e entre a VNet2 de Origem e a VNet do Azure.
  • Estabeleça conexões VPN entre a VNet1 de Origem e a VNet2 de Recuperação e entre a VNet2 de Recuperação e a VNet do Azure.
  • Failover de VMs na VNet2 de origem para a VNet2 de recuperação.

Recursos em failover de aplicativo do Azure

  • Este exemplo pode ser expandido para incluir mais aplicativos e conexões de rede. A recomendação é seguir um modelo de conexão semelhante, na medida do possível, ao fazer failover da origem para o destino.
  • Os gateways VPN usam endereços IP públicos e saltos de gateway para estabelecer conexões. Se você não quiser usar endereços IP públicos ou evitar saltos extras, poderá usar o emparelhamento de VNet do Azure para emparelhar redes virtuais em regiões do Azure com suporte.

Recursos híbridos: failover completo

Nesse cenário, a empresa B executa um negócio híbrido, com parte da infraestrutura de aplicativos em execução no Azure e o restante no local.

Antes do failover

Veja como é a arquitetura de rede antes do failover.

  • As VMs de aplicativo são hospedadas no Azure East Asia.
  • O Leste Asiático tem uma VNet (Source VNet) com espaço de endereço 10.1.0.0/16.
    • O Leste Asiático tem cargas de trabalho divididas em três sub-redes na VNet de origem:
      • Sub-rede 1: 10.1.1.0/24
      • Sub-rede 2: 10.1.2.0/24
      • Sub-rede 3: 10.1.3.0/24, utilizando uma rede virtual do Azure com espaço de endereço 10.1.0.0/16. Essa rede virtual é chamada de VNet de origem
  • A região secundária (de destino) é o Azure Sudeste Asiático:
    • O Sudeste Asiático tem uma VNet de recuperação (Recovery VNet) idêntica à VNet de origem.
  • As VMs no Leste Asiático são conectadas a um datacenter local com o Azure ExpressRoute ou VPN site a site.
  • Para reduzir o RTO, a Empresa B provisiona gateways na VNet de Recuperação no Sudeste Asiático do Azure antes do failover.
  • A empresa B atribui/verifica endereços IP de destino para VMs replicadas. O endereço IP de destino é o mesmo que o endereço IP de origem para cada VM.

Conectividade local com o Azure antes do failover

Após o failover

Se ocorrer uma interrupção regional de origem, a empresa B pode fazer failover de todos os seus recursos para a região de destino.

  • Com os endereços IP de destino já instalados antes do failover, a Empresa B pode orquestrar o failover e estabelecer automaticamente conexões após o failover entre a VNet de Recuperação e a VNet do Azure.
  • Dependendo dos requisitos do aplicativo, as conexões entre as duas VNets (VNet de Recuperação e VNet do Azure) na região de destino podem ser estabelecidas antes, durante (como uma etapa intermediária) ou após o failover. A empresa pode usar planos de recuperação para especificar quando as conexões serão estabelecidas.
  • A conexão original entre o Azure East Asia e o datacenter local deve ser desconectada antes de estabelecer a conexão entre o Azure Sudeste Asiático e o datacenter local.
  • O roteamento local é reconfigurado para apontar para a região de destino e os gateways postam failover.

Conectividade local com o Azure após failover

Recursos híbridos: failover de aplicativo isolado

A empresa B não pode fazer failover de aplicativos isolados no nível da sub-rede. Isso ocorre porque o espaço de endereço nas redes virtuais de origem e recuperação é o mesmo e a fonte original para a conexão local está ativa.

  • Para resiliência de aplicativos, a Empresa B precisará colocar cada aplicativo em sua própria VNet do Azure dedicada.
  • Com cada aplicativo em uma VNet separada, a Empresa B pode fazer failover de aplicativos isolados e rotear conexões de origem para a região de destino.

Próximos passos

Saiba mais sobre os planos de recuperação.