Share via


Rede multirregião com o Azure Route Server

Aplicativos com requisitos exigentes de alta disponibilidade ou recuperação de desastres geralmente exigem ser implantados em mais de uma região do Azure. Nesses casos, as redes virtuais faladas (VNets) em diferentes regiões precisam se comunicar entre si. Uma maneira de habilitar essa comunicação é emparelhando todas as VNets faladas necessárias entre si. No entanto, essa abordagem ignoraria quaisquer dispositivos virtuais de rede central (NVAs), como firewalls nos hubs. Uma alternativa é usar rotas definidas pelo usuário (UDRs) nas sub-redes onde os NVAs de hub são implantados, mas manter UDRs pode ser um desafio. O Azure Route Server oferece uma alternativa dinâmica que se adapta às alterações de topologia automaticamente, sem exigir intervenção manual.

Topologia

O diagrama a seguir mostra uma arquitetura de região dupla, onde existe uma topologia de hub e spoke em cada região, e as VNets de hub são emparelhadas entre si por meio de emparelhamento global de VNet:

Diagram showing multi-region design with Azure Route Server.

O NVA em cada região aprende os prefixos do hub local e das VNets faladas por meio do Servidor de Rotas do Azure e os compartilha com o NVA na outra região usando BGP. Para evitar loops de roteamento, é crucial estabelecer essa comunicação entre os NVAs usando uma tecnologia de encapsulamento, como IPsec ou Virtual eXtensible LAN (VXLAN).

Para permitir que o Azure Route Server anuncie os prefixos das VNets spoke para as NVAs locais e injete as rotas aprendidas de volta nas VNets spoke , é essencial usar a configuração Usar gateway de rede virtual remota ou Servidor de Rotas para emparelhamento entre as VNets spoke e a VNet de hub.

Os NVAs anunciam as rotas que aprendem da região remota para seu servidor de rotas local, que configurará essas rotas nas VNets locais, atraindo tráfego de acordo. Nos casos em que existem vários NVAs na mesma região (o Route Server suporta até oito pares BGP), o caminho AS pendente pode ser utilizado para tornar um dos NVAs preferidos sobre os outros, estabelecendo efetivamente uma topologia NVA ativa/standby.

Importante

Para garantir que o Servidor de Rotas local possa aprender as rotas anunciadas pelo NVA a partir da região remota, o NVA deve remover o número de sistema autônomo (ASN) 65515 do caminho AS das rotas. Esta técnica é por vezes referida como "AS override" ou "AS-path rewrite" em determinadas plataformas BGP. Caso contrário, o mecanismo de prevenção de loop BGP impedirá que o Servidor de Rotas local aprenda essas rotas, uma vez que proíbe o aprendizado de rotas que já contêm o ASN local.

ExpressRoute

O design de várias regiões pode ser combinado com gateways ExpressRoute ou VPN. O diagrama a seguir mostra uma topologia incluindo um gateway de Rota Expressa conectado a uma rede local em uma das regiões do Azure. Nesse caso, uma rede de sobreposição no circuito de Rota Expressa ajuda a simplificar a rede, de modo que os prefixos locais só apareçam no Azure conforme anunciado pelo NVA (e não do gateway de Rota Expressa).

Diagram showing multi-region design with Route Server and ExpressRoute.

Design sem sobreposições

Os túneis entre regiões entre os NVAs são necessários porque, caso contrário, um loop de roteamento é formado. Por exemplo, olhando para o NVA na região 1:

  • O NVA na região 1 aprende os prefixos da região 2 e os anuncia para o Servidor de Rotas na região 1.
  • O Servidor de Rotas na região 1 injetará rotas para esses prefixos em todas as sub-redes da região 1, com o NVA na região 1 como o próximo salto.
  • Para o tráfego da região 1 para a região 2, quando o NVA na região 1 envia tráfego para o outro NVA, sua própria sub-rede herda também as rotas programadas pelo Servidor de Rotas, que estão apontando para si mesmo (o NVA). Assim, o pacote é retornado ao NVA e um loop de roteamento aparece.

Se UDRs forem uma opção, você poderá desabilitar a propagação de rota BGP nas sub-redes dos NVAs e configurar UDRs estáticos em vez de uma sobreposição, para que o Azure possa rotear o tráfego para as VNets de raios remotos.