Roteamento Anycast com o Azure Route Server
Você pode implantar seu aplicativo em Zonas de Disponibilidade em uma única região do Azure para obter maior disponibilidade, mas, às vezes, talvez seja necessário implantar seus aplicativos em várias regiões, seja para obter uma maior resiliência, um melhor desempenho para usuários em todo o mundo ou uma melhor continuidade de negócios. Há diferentes abordagens que podem ser adotadas para direcionar os usuários para um dos locais onde um aplicativo de várias regiões é implantado: abordagens baseadas em DNS, como o Gerenciador de Tráfego do Azure, serviços baseados em roteamento, como o Azure Front Door, ou o Balanceador de Carga entre regiões do Azure.
Os serviços anteriores do Azure são recomendados para levar os usuários ao melhor local de aplicativo pela Internet pública usando endereçamento IP público, mas eles não oferecem suporte a 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 multirregionais e de rede privada.
IP anycast consiste essencialmente em anunciar exatamente o mesmo endereço IP de mais de um local, de modo que os pacotes dos usuários do aplicativo são roteados para a região mais próxima (em termos de roteamento). Fornecer acessibilidade de várias regiões sobre anycast oferece algumas vantagens em relação às abordagens baseadas em DNS, como não ter que confiar em clientes que não armazenam suas respostas DNS em cache e não exigir modificar o design do DNS para o aplicativo.
Topologia
No design desse cenário, o mesmo endereço IP é anunciado de redes virtuais em diferentes regiões do Azure, onde os dispositivos virtuais de rede (NVAs) anunciam o endereço IP do aplicativo por meio do Azure Route Server. O diagrama a seguir mostra duas topologias simples de hub e spoke, cada uma em uma região diferente do Azure. Um NVA em cada região anuncia a mesma rota (neste exemplo) para seu Servidor de Rota do Azure local (a.b.c.d/32 o prefixo de rota não deve se sobrepor ao Azure e às redes locais). As rotas são propagadas para a rede local por meio da Rota Expressa. Quando os usuários do aplicativo desejam acessar o aplicativo localmente, a infraestrutura DNS (não coberta 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 encaminham para uma das duas regiões.
A decisão de qual das regiões disponíveis é selecionada é inteiramente baseada nos atributos de roteamento. Se as rotas de ambas as regiões forem idênticas, a rede local normalmente usa o roteamento ECMP (equal-cost multi-path) para enviar cada fluxo 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 BGP AS Path prepending para estabelecer um caminho determinístico do local para a carga de trabalho do Azure.
Importante
Os NVAs que anunciam as rotas devem incluir algum mecanismo de verificação de saúde para parar de anunciar a rota quando o aplicativo não estiver disponível em suas respetivas regiões, para evitar o bloqueio do tráfego.
Tráfego de retorno
Quando o tráfego do aplicativo do cliente local chega a um dos NVAs no Azure, o NVA executa o proxy reverso de conexão ou a Tradução de Endereço de Rede de Destino (DNAT). Em seguida, ele envia os pacotes para o aplicativo real, que normalmente reside em uma rede virtual spoke emparelhada à rede virtual do hub onde o NVA é implantado. O tráfego de volta do aplicativo volta através do NVA, o que aconteceria naturalmente se o NVA estiver fazendo proxy reverso da conexão (ou executar NAT de origem adicionalmente ao NAT de destino).
Caso contrário, o tráfego que chega ao aplicativo ainda é originado do endereço IP do cliente local original. Nesse caso, os pacotes podem ser roteados de volta para o NVA com rotas definidas pelo usuário (UDRs). Cuidado especial deve ser tomado se houver mais de uma instância NVA em cada região, uma vez que o tráfego pode ser assimétrico (o tráfego de entrada e saída passando por diferentes instâncias NVA). O tráfego assimétrico normalmente não é um problema se os NVAs forem sem monitoração de estado, mas resulta em erros se os NVAs controlarem os estados de conexão, como firewalls.