Compartilhar via


Integrar o ExpressRoute à recuperação de desastre para máquinas virtuais do Azure

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

O Site Recovery permite a recuperação de desastre de máquinas virtuais do Azure com a replicação dos dados das máquinas virtuais do Azure para o Azure.

  • Se as máquinas virtuais do Azure usarem discos gerenciados do Azure, os dados delas serão replicados para um disco gerenciado replicado na região secundária.
  • Se as máquinas virtuais do Azure não usarem discos gerenciados, os dados delas 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 máquinas virtuais do Azure não atravessa 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 desastre das máquinas virtuais do Azure fica somente no Azure, e o ExpressRoute não é necessário nem usado para a replicação. Entretanto, caso você esteja se conectando de um site local às máquinas virtuais do Azure no site primário do Azure, há muitos problemas a serem considerados ao configurar a recuperação de desastre para essas máquinas virtuais do Azure.
  • Failover entre as regiões do Azure: quando ocorrem interrupções, você faz failover das máquinas virtuais do Azure da região primária do Azure para a secundária. Após o failover para uma região secundária, existem muitas etapas a serem seguidas para acessar as máquinas virtuais 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ê habilita a replicação nas máquinas virtuais do Azure, o Site Recovery pode implantar automaticamente recursos de rede usando as configurações da rede de origem. Por exemplo, redes, sub-redes e gateways na região de destino do Azure.
    • 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 extras 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ê executar um failover de teste para a simulação, recomendaremos usar uma rede de máquina virtual do Azure separada em vez da rede padrão configurada durante 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 máquinas virtuais do Azure ao usar o ExpressRoute

Se você quiser configurar a replicação nas máquinas virtuais do Azure em um site primário e estiver se conectando a essas máquinas virtuais no site local por meio do ExpressRoute, confira o que você precisa fazer:

  1. Habilite a replicação para cada máquina virtual 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 à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 extras na região secundária, a qualquer momento, antes de executar um failover na 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:
    • A rota do sistema padrão do Azure para a replicação de máquina virtual 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 da máquina virtual 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

Em implantações corporativas típicas, as cargas de trabalho são distribuídas entre várias VNets do Azure com um hub central para a Internet e a conectividade local. Em geral, essa configuração usa uma topologia hub-and-spoke com o ExpressRoute.

Local-para-Azure com o ExpressRoute antes do 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 habilitado

Configuração do emparelhamento spoke-hub

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 Desabilitado

Configuração do emparelhamento hub-spoke

Etapas de exemplo

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

  1. Você habilita a replicação para uma máquina virtual.
  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.

Fazer failover de máquinas virtuais do Azure ao usar o ExpressRoute

Após o failover das máquinas virtuais do Azure para a região de destino do Azure por meio do Site Recovery, você pode acessá-las usando o emparelhamento privado do ExpressRoute.

  • 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 no 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 das máquinas virtuais 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.
  • Mantenha endereços IP privados para as máquinas virtuais 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. Faça failover das máquinas virtuais do Azure, com estas etapas extras 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 que você recuperar as máquinas virtuais e concluir a conectividade, o ambiente de recuperação será conforme descrito a seguir.

Local-para-o Azure com o ExpressRoute após o Failover

Próximas etapas

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