Roteamento de Anycast com o Servidor de Rota do Azure
Você pode implantar um aplicativo entre Zonas de Disponibilidade em uma única região do Azure para conseguir maior disponibilidade, mas as vezes você pode precisar implantar os aplicativos em várias regiões, seja para obter maior resiliência, melhor desempenho para usuários em todo o mundo ou melhor continuidade dos negócios. Diferentes abordagens podem ser seguidas para direcionar os usuários para um dos locais em que um aplicativo de várias regiões é implantado: abordagens baseadas em DNS, como Gerenciador de Tráfego do Azure ou serviços baseados em roteamento, como o Azure Front Door ou o Load Balancer.
Os serviços anteriores do Azure são recomendados para levar os usuários ao melhor local do aplicativo pela Internet pública usando o endereçamento de IP público, mas eles não têm suporte para redes privadas e endereços IP. Este artigo explora o uso de uma abordagem baseada em rota (IP anycast) para fornecer implantações de aplicativos multi-regionais em rede privada.
O IP anycast consiste essencialmente em anunciar exatamente o mesmo endereço IP de mais de um local, para que os pacotes dos usuários do aplicativo sejam roteados para a região mais próxima (em termos de roteamento). A acessibilidade de várias regiões em relação ao anycast oferece algumas vantagens em relação a abordagens baseadas em DNS, como não precisar contar com clientes que não armazenam suas respostas DNS em cache e não exigir a modificação do design de DNS para o aplicativo.
Topologia
No design deste cenário é anuciado das redes virtuais em diferentes regiões do Azure, onde as NVAs (soluções de virtualização de rede) anunciam o endereço IP do aplicativo Através do Servidor de Rota do Azure. O diagrama a seguir ilustra duas topologias de Hub e Spoke simples, cada uma em uma região diferente do Azure. Uma NVA em cada região anuncia a mesma rota (a.b.c.d/32 neste exemplo) para seu Servidor de Rota do Azure local (o prefixo de rota não deve se sobrepor às redes locais e do Azure). As rotas serão propagadas para a rede local por meio do ExpressRoute. Quando os usuários do aplicativo quiserem acessar o aplicativo localmente, a infraestrutura DNS (não abrangida por este documento) resolve o nome DNS do aplicativo para o endereço IP anycast (a.b.c.d), que os dispositivos de rede locais roteiam para uma das duas regiões.
A decisão de qual região disponível é selecionada é totalmente baseada em atributos de roteamento. Se as rotas de ambas as regiões forem idênticas, a rede local normalmente usa o roteamento ECMP (Equal Cost MultiPathing) para enviar os fluxos de aplicativo para cada região. Também é possível modificar os anúncios gerados por cada NVA no Azure para tornar uma das regiões preferidas. Por exemplo, usando o prefixo de Caminho AS do BGP para estabelecer um caminho determinístico do local para a carga de trabalho do Azure.
Importante
As NVAs que anunciam as rotas devem incluir um mecanismo de verificação de integridade para parar de anunciar a rota quando o aplicativo não estiver disponível em suas respectivas regiões, para evitar o tráfego blackholing.
Tráfego de retorno
Quando o tráfego do aplicativo do cliente local chega a um dos NVAs no Azure, a NVA executa o proxy reverso de conexão ou o Conversão de Endereços de Rede de Destino (DNAT). Em seguida, ele envia os pacotes para o aplicativo real, que normalmente reside em uma rede virtual spoke emparelhada com a rede virtual do hub em que a NVA é implantada. O tráfego retornado do aplicativo volta pela NVA, o que ocorreria naturalmente se a NVA estivesse executando proxy reverso da conexão (ou executar a NAT de origem além da NAT de destino).
Caso contrário, o tráfego que chega ao aplicativo ainda será originado do endereço IP do cliente local original. Nesse caso, os pacotes podem ser roteados de volta para a NVA com Rotas Definidas pelo Usuário (UDRs). É necessário ter cuidado especial se houver mais de uma instância de NVA em cada região, pois o tráfego pode ser assimétrico (o tráfego de entrada e saída passam por instâncias de NVA diferentes). O tráfego assimétrico normalmente não é um problema se as NVAs forem sem estado, mas resultam em erros se as NVAs controlam os estados de conexão, como firewalls.