Rede de várias regiões com o Servidor de Rota do Azure
Aplicativos com requisitos de alta disponibilidade ou de recuperação de desastre geralmente precisam ser implantados em mais de uma região do Azure. Nesses casos, as VNets (redes virtuais) spoke em regiões diferentes precisam se comunicar entre si. Uma maneira de habilitar essa comunicação é emparelhando todas as VNets spoke necessárias entre si. No entanto, essa abordagem ignoraria as NVAs (soluções de virtualização de rede) centralizados, como firewalls nos hubs. Uma alternativa é usar UDRs (rotas definidas pelo usuário) nas sub-redes em que as NVAs do hub são implantados, mas manter UDRs pode ser um desafio. O Servidor de Rota do Azure oferece uma alternativa dinâmica que se adapta às alterações de topologia automaticamente, sem a necessidade de intervenção manual.
Topologia
O diagrama a seguir mostra uma arquitetura de região dupla, em que uma topologia hub e spoke existe em cada região e as VNets do hub são emparelhadas pelo emparelhamento global da VNet:
A NVA em cada região aprende os prefixos das VNets de hub local e spoke por meio do Servidor de Rota do Azure e as compartilha com a NVA na outra região usando BGP. Para evitar loops de roteamento, é crucial estabelecer essa comunicação entre as NVAs usando uma tecnologia de encapsulamento, como IPsec ou VXLAN (Virtual eXtensible LAN).
Para permitir que o Servidor de Rota do Azure 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 o gateway de rede virtual remota ou o Servidor de Rota para o emparelhamento entre as VNets spoke e a VNet hub.
As NVAs anunciam as rotas que aprendem da região remota para o Servidor de Rota local, o que configurará essas rotas nas VNets spoke locais, atraindo o tráfego adequadamente. Se houver várias NVAs na mesma região (o Servidor de Rota dá suporte a até 8 pares de BGP), o caminho AS pendente poderá ser usado para tornar uma das NVAs preferencial, estabelecendo efetivamente uma topologia NVA ativa/em espera.
Importante
Para garantir que o Servidor de Rota local possa aprender as rotas anunciadas pela NVA da região remota, a NVA deve remover o número do sistema autônomo (ASN) 65515 do caminho AS das rotas. Às vezes, essa técnica é chamada de "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 Rota local aprenda essas rotas, pois proíbe a aprendizagem de rotas que já contêm o ASN local.
ExpressRoute
Esse design para várias regiões pode ser combinado com o ExpressRoute ou gateways de VPN. O diagrama a seguir mostra uma topologia, incluindo um gateway do ExpressRoute conectado a uma rede local em uma das regiões do Azure. Nesse caso, uma rede de sobreposição no circuito do ExpressRoute ajuda a simplificar a rede, para que os prefixos no local só apareçam no Azure como anunciados pela NVA (e não pelo gateway do ExpressRoute).
Design sem sobreposições
Os túneis entre regiões entre as NVAs são necessários porque, caso contrário, um loop de roteamento é formado. Por exemplo, observando a NVA na região 1:
- A NVA na região 1 aprende os prefixos da região 2 e os anuncia para o Servidor de Rota na região 1.
- O Servidor de Rota na região 1 injetará rotas para esses prefixos em todas as sub-redes na região 1, com a NVA na região 1 como o próximo salto.
- Para o tráfego da região 1 para a região 2, quando a NVA na região 1 envia o tráfego para a outra NVA, sua própria sub-rede herda, bem como as rotas programadas pelo Servidor de Rota, que estão apontando para si mesma (a NVA). Portanto, o pacote é retornado para a NVA e um loop de roteamento é exibido.
Se as UDRs forem uma opção, você pode desabilitar a propagação da rota BGP nas sub-redes das NVAs e configurar UDRs estáticos em vez de uma sobreposição, para que o Azure possa rotear o tráfego para as VNets spoke remotas.