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

  • Artigo

O Azure Site Recovery permite a recuperação após desastre para as VMs do Azure ao replicar VMs para outra região do Azure, efetuar a ativação pós-falha se ocorrer uma falha e efetuar a reativação pós-falha para a região primária quando as coisas voltarem ao normal.

Durante a ativação pós-falha, poderá querer manter o endereço IP na região de destino idêntico à região de origem:

  • Por predefinição, quando ativa a recuperação após desastre para VMs do Azure, Site Recovery cria recursos de destino com base nas definições de recursos de origem. Para VMs do Azure configuradas com endereços IP estáticos, Site Recovery tenta aprovisionar o mesmo endereço IP para a VM de destino, se não estiver a ser utilizada. Para obter uma explicação completa sobre como Site Recovery lida com o endereçamento, veja este artigo.
  • Para aplicações simples, a configuração predefinida é suficiente. Para aplicações mais complexas, poderá ter de aprovisionar recursos adicionais para garantir que a conectividade funciona conforme esperado após a ativação pós-falha.

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

  • Ativação pós-falha para uma empresa com todos os recursos em execução no Azure
  • Ativação pós-falha para uma empresa com uma implementação híbrida e recursos em execução no local e no Azure

Recursos no Azure: ativação pós-falha completa

A Empresa A tem todas as suas aplicações em execução no Azure.

Antes da ativação pós-falha

Nota

A replicação pode agora ser feita entre duas regiões do Azure em todo o mundo. Os clientes já não se limitam a ativar a replicação no seu continente.

Eis a arquitetura antes da ativação pós-falha.

  • A empresa A tem redes e sub-redes idênticas nas regiões do Azure de origem e de destino.
  • Para reduzir o objetivo de tempo de recuperação (RTO), a empresa utiliza nós de réplica para SQL Server AlwaysOn, controladores de domínio, etc. Estes nós de réplica estão numa VNet diferente na região de destino, para que possam estabelecer conectividade site a site de VPN entre as regiões de origem e de destino. Isto não é possível se o mesmo espaço de endereços IP for utilizado na origem e no destino.
  • Antes da ativação pós-falha, a arquitetura de rede é a seguinte:
    • A região primária é a Ásia Oriental do Azure
      • A Ásia Oriental tem uma VNet (VNet de Origem) com espaço de endereços 10.1.0.0/16.
      • A Ásia Oriental tem cargas de trabalho divididas em três sub-redes na VNet:
        • 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 (destino) é o Azure Sudeste Asiático
      • O Sudeste Asiático tem uma VNet de recuperação (VNet de Recuperação) idêntica à VNet de Origem.
      • O Sudeste Asiático tem uma VNet adicional (VNet do Azure) com espaço de endereços 10.2.0.0/16.
      • A VNet do Azure contém uma sub-rede (Sub-rede 4) com espaço de endereços 10.2.4.0/24.
      • Os nós de réplica para SQL Server AlwaysOn, controlador de domínio, etc. estão localizados na Sub-rede 4.
    • A VNet de origem e a VNet do Azure estão ligadas a uma ligação site a site VPN.
    • A VNet de recuperação não está ligada 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 da ativação pós-falha completa

Após a ativação pós-falha

Se ocorrer uma indisponibilidade regional de origem, a Empresa A pode efetuar a ativação pós-falha de todos os recursos para a região de destino.

  • Com os endereços IP de destino já implementados antes da ativação pós-falha, a Empresa A pode orquestrar a ativação pós-falha e estabelecer automaticamente ligações após a ativação pós-falha entre a VNet de Recuperação e a VNet do Azure. Isto é ilustrado no diagrama seguinte.
  • Dependendo dos requisitos da aplicação, as ligações entre as duas VNets (VNet de Recuperação e VNet do Azure) na região de destino podem ser estabelecidas antes, durante (como um passo intermédio) ou após a ativação pós-falha.

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

    • Podem ligar-se entre as VNets através do VNet Peering ou da VPN site a site.

      • O VNet Peering não utiliza um gateway de VPN e tem restrições diferentes.
      • Os preços do VNet Peering são calculados de forma diferente dos preços de VNet a VNet Gateway de VPN. Para ativações pós-falha, geralmente aconselhamos a utilizar o mesmo método de conectividade que as redes de origem, incluindo o tipo de ligação, para minimizar incidentes de rede imprevisíveis.

      Recursos na ativação pós-falha completa do Azure

Recursos no Azure: ativação pós-falha de aplicações isoladas

Poderá ter de efetuar a ativação pós-falha ao nível da aplicação. Por exemplo, para efetuar a ativação pós-falha de uma aplicação ou camada de aplicação específica localizada numa sub-rede dedicada.

  • Neste cenário, embora possa manter o endereçamento IP, não é geralmente aconselhável, uma vez que aumenta a probabilidade de inconsistências de conectividade. Também perderá a conectividade de sub-rede a outras sub-redes na mesma VNet do Azure.
  • Uma forma melhor de efetuar a ativação pós-falha de aplicações ao nível da sub-rede é utilizar diferentes endereços IP de destino para ativação pós-falha (se precisar de conectividade a outras sub-redes na VNet de origem) ou isolar cada aplicação na sua própria VNet dedicada na região de origem. Com esta última abordagem, pode estabelecer conectividade entre redes na região de origem e emular o mesmo comportamento quando efetua a ativação pós-falha para a região de destino.

Neste exemplo, a Empresa A coloca aplicações na região de origem em VNets dedicadas e estabelece conectividade entre essas VNets. Com esta estrutura, podem efetuar a ativação pós-falha de aplicações isoladas e manter os endereços IP privados de origem na rede de destino.

Antes da ativação pós-falha

Antes da ativação pós-falha, a arquitetura é a seguinte:

  • As VMs de aplicação estão alojadas na região primária do Azure Leste Asiático:

    • Aplicação1 As VMs estão localizadas na VNet de Origem da VNet 1: 10.1.0.0/16.
    • Aplicação2 As VMs estão localizadas na VNet de Origem da VNet 2: 10.2.0.0/16.
    • A VNet de origem 1 tem duas sub-redes.
    • A VNet de origem 2 tem duas sub-redes.

  • A região secundária (destino) é Azure Sudeste Asiático – Sudeste Asiático tem 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 VNet de Origem 2 - Sudeste Asiático tem uma VNet adicional (VNet do Azure) com espaço de endereços 10.3.0.0/16. - A VNet do Azure contém uma sub-rede (Sub-rede 4) com espaço de endereços 10.3.4.0/24. - Os nós de réplica para SQL Server AlwaysOn, controlador de domínio, etc. estão localizados na Sub-rede 4.

  • Existem várias ligações VPN site a site:

    • VNet de origem 1 e VNet do Azure
    • VNet de origem 2 e VNet do Azure
    • A VNet de origem 1 e a VNet de Origem 2 estão ligadas à VPN site a site

  • A VNet de Recuperação 1 e a VNet de Recuperação 2 não estão ligadas a outras VNets.

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

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

  • Para reduzir o objetivo de tempo de recuperação (RTO), os gateways de VPN são configurados na VNet de Recuperação1 e VNet2 de Recuperação antes da ativação pós-falha.

    Recursos no Azure antes da ativação pós-falha da aplicação

Após a ativação pós-falha

Em caso de indisponibilidade ou problema que afete uma única aplicação (em **VNet de origem 2 no nosso exemplo), a Empresa A pode recuperar a aplicação afetada da seguinte forma:

  • Desligue as ligações VPN entre a VNet de Origem 1 e a VNet2 de Origem e entre a VNet de Origem2 e a VNet do Azure .
  • Estabeleça ligações VPN entre a VNet de Origem 1 e a VNet de Recuperação2 e entre a VNet de Recuperação2 e a VNet do Azure.
  • Efetuar a ativação pós-falha de VMs na VNet de Origem2 para a VNet2 de Recuperação.

Recursos na ativação pós-falha de aplicações do Azure

  • Este exemplo pode ser expandido para incluir mais aplicações e ligações de rede. A recomendação é seguir um modelo de ligação semelhante, na medida do possível, ao efetuar a ativação pós-falha da origem para o destino.
  • Os Gateways de VPN utilizam endereços IP públicos e saltos de gateway para estabelecer ligações. Se não quiser utilizar endereços IP públicos ou quiser evitar saltos adicionais, pode utilizar o peering da VNet do Azure para peering de redes virtuais em várias regiões do Azure suportadas.

Recursos híbridos: ativação pós-falha completa

Neste cenário, a Empresa B executa uma empresa híbrida, com parte da infraestrutura de aplicações em execução no Azure e o restante em execução no local.

Antes da ativação pós-falha

Eis o aspeto da arquitetura de rede antes da ativação pós-falha.

  • As VMs da aplicação estão alojadas no Azure East Asia.
  • A Ásia Oriental tem uma VNet (VNet de Origem) com espaço de endereços 10.1.0.0/16.
    • A Ásia Oriental 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ços 10.1.0.0/16. Esta rede virtual tem o nome VNet de Origem
  • A região secundária (destino) é o Azure Sudeste Asiático:
    • O Sudeste Asiático tem uma VNet de recuperação (VNet de Recuperação) idêntica à VNet de Origem.
  • As VMs na Ásia Oriental estão ligadas a um datacenter no local com o Azure ExpressRoute ou uma VPN site a site.
  • Para reduzir o RTO, a Empresa B aprovisiona gateways na VNet de Recuperação no Azure Sudeste Asiático antes da ativação pós-falha.
  • 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 no local para o Azure antes da ativação pós-falha

Após a ativação pós-falha

Se ocorrer uma indisponibilidade regional de origem, a Empresa B pode efetuar a ativação pós-falha de todos os recursos para a região de destino.

  • Com os endereços IP de destino já implementados antes da ativação pós-falha, a Empresa B pode orquestrar a ativação pós-falha e estabelecer automaticamente ligações após a ativação pós-falha entre a VNet de Recuperação e a VNet do Azure.
  • Dependendo dos requisitos da aplicação, as ligações entre as duas VNets (VNet de Recuperação e VNet do Azure) na região de destino podem ser estabelecidas antes, durante (como um passo intermédio) ou após a ativação pós-falha. A empresa pode utilizar planos de recuperação para especificar quando as ligações serão estabelecidas.
  • A ligação original entre o Azure East Asia e o datacenter no local deve ser desligada antes de estabelecer a ligação entre o Azure Sudeste Asiático e o datacenter no local.
  • O encaminhamento no local é reconfigurado para apontar para a região de destino e os gateways após a ativação pós-falha.

Conectividade no local para o Azure após a ativação pós-falha

Recursos híbridos: ativação pós-falha da aplicação isolada

A empresa B não pode efetuar a ativação pós-falha de aplicações isoladas ao nível da sub-rede. Isto acontece porque o espaço de endereços nas VNets de origem e recuperação é o mesmo e a origem original para a ligação no local está ativa.

  • Para a resiliência da aplicação, a Empresa B terá de colocar cada aplicação na sua própria VNet dedicada do Azure.
  • Com cada aplicação numa VNet separada, a Empresa B pode efetuar a ativação pós-falha de aplicações isoladas e encaminhar ligações de origem para a região de destino.

Passos seguintes

Saiba mais sobre os planos de recuperação.