Design voltado à alta disponibilidade com o Azure ExpressRoute
O Azure ExpressRoute foi projetado visando a alta disponibilidade para fornecer conectividade de rede privada de nível de operadora aos recursos da Microsoft. Isso significa que não há um ponto único de falha na rede da Microsoft. Para maximizar a disponibilidade, os segmentos do cliente e do provedor de serviços do circuito do Azure ExpressRoute também devem ser arquitetados para alta disponibilidade. Este artigo aborda as considerações de arquitetura de rede para criar conectividade robusta usando o Azure ExpressRoute e recursos de ajuste fino para melhorar a alta disponibilidade do circuito do Azure ExpressRoute.
Observação
Os conceitos descritos neste artigo se aplicam igualmente se um circuito do Azure ExpressRoute é criado em WAN Virtual ou fora dela.
Considerações sobre arquitetura
A figura a seguir ilustra a maneira recomendada de se conectar usando um circuito do Azure ExpressRoute para maximizar a disponibilidade.
Para alta disponibilidade, é essencial manter a redundância em toda a rede de ponta a ponta. Isso significa manter a redundância em sua rede local e não comprometer a redundância na rede do provedor de serviços. No mínimo, isso envolve evitar pontos únicos de falha de rede. A energia e o resfriamento redundantes para dispositivos de rede melhoram ainda mais a alta disponibilidade.
Considerações de design da camada física de primeira milha
Se você encerrar as conexões primárias e secundárias de um circuito do Azure ExpressRoute no mesmo CPE (Equipamento Local do Cliente), você comprometerá a alta disponibilidade em sua rede local. Além disso, configurar ambas as conexões usando a mesma porta de um CPE força o parceiro a comprometer a alta disponibilidade em seu segmento de rede. Isso pode ocorrer terminando as duas conexões em subinterfaces diferentes ou mesclando as duas conexões dentro da rede do parceiro, conforme ilustrado abaixo.
Terminar as conexões primárias e secundárias de um circuito do Azure ExpressRoute em diferentes localizações geográficas pode comprometer o desempenho da rede. Se o tráfego for balanceado ativamente entre conexões terminadas em locais diferentes, diferenças substanciais na latência de rede entre os dois caminhos poderão resultar em um desempenho abaixo do ideal.
Para considerações de design com redundância geográfica, consulte Design voltado à recuperação de desastre com o Azure ExpressRoute.
Conexões ativa/ativa
A rede da Microsoft opera as conexões primária e secundária dos circuitos do Azure ExpressRoute no modo ativo/ativo. No entanto, você pode forçar as conexões redundantes a operar no modo ativo-passivo por meio de seus anúncios de rota. Anunciar rotas mais específicas e o BGP AS path prepending são técnicas comuns para preferir um caminho em vez do outro.
Para melhorar a alta disponibilidade, é recomendável operar ambas as conexões no modo ativo-ativo. Isso permite que a rede da Microsoft faça o balanceamento de carga do tráfego entre as conexões em uma base por fluxo.
A execução de conexões no modo ativo-passivo arrisca que ambas as conexões falhem, se o caminho ativo falhar. As causas comuns de falha incluem a falta de gerenciamento ativo da conexão passiva e o anúncio de rotas obsoletas pela conexão passiva.
Como alternativa, a execução de conexões no modo ativo-ativo resulta em falha e redirecionamento de apenas cerca de metade dos fluxos, melhorando significativamente o MTTR (Tempo Médio de Recuperação).
Observação
Durante a manutenção ou eventos não planejados que afetam uma conexão, a Microsoft usará o AS path prepending para esvaziar o tráfego para a conexão íntegra. Assegure-se de que o tráfego possa ser roteado pelo caminho íntegro quando o path prepending for configurado pela Microsoft e os anúncios de rota necessários forem definidos adequadamente para evitar a interrupção do serviço.
NAT para emparelhamento da Microsoft
O emparelhamento da Microsoft foi projetado para a comunicação entre pontos de extremidade públicos. Normalmente, os pontos de extremidade privados locais são NATed (Conversão de Endereço de Rede) com IPs públicos na rede de clientes ou parceiros antes de se comunicarem pelo emparelhamento da Microsoft. O uso de conexões primárias e secundárias em uma configuração ativa-ativa afeta a rapidez com que você se recupera de uma falha em uma das conexões. Duas opções diferentes de NAT são ilustradas abaixo:
Opção 1:
A NAT é aplicada após a divisão do tráfego entre as conexões primária e secundária. Os pools de NAT independentes são usados para os dispositivos primários e secundários para atender aos requisitos de NAT com estado. O tráfego de retorno chega no mesmo dispositivo de borda por meio do qual o fluxo foi enviado.
Se uma conexão do Azure ExpressRoute falhar, o pool de NAT correspondente se tornará inacessível, quebrando todos os fluxos de rede. Esses fluxos devem ser restabelecidos pelo TCP ou pela camada de aplicativo após o tempo limite da janela. Durante a falha, o Azure não pode acessar servidores locais usando a NAT correspondente até que a conectividade seja restaurada.
Opção 2:
Um pool de NAT comum é usado antes da divisão do tráfego entre as conexões primária e secundária. Isso não introduz um ponto único de falha, mantendo assim a alta disponibilidade.
O pool de NAT permanece acessível mesmo se a conexão primária ou secundária falhar, permitindo que a camada de rede redirecione pacotes e se recupere mais rapidamente.
Observação
- Se estiver usando a opção NAT 1 (pools de NAT independentes para conexões primárias e secundárias) e mapeando uma porta de um endereço IP de um pool de NAT para um servidor local, o servidor não poderá ser acessado por meio do circuito do Azure ExpressRoute se a conexão correspondente falhar.
- O encerramento de conexões BGP do Azure ExpressRoute em dispositivos com estado pode causar problemas de failover durante a manutenção planejada ou não planejada pela Microsoft ou pelo provedor do Azure ExpressRoute. Teste sua configuração para garantir o failover adequado e, quando possível, encerre as sessões BGP em dispositivos sem estado.
Recursos de ajuste fino para o emparelhamento privado
Esta seção analisa os recursos opcionais que ajudam a melhorar a alta disponibilidade do circuito do Azure ExpressRoute, dependendo da implantação do Azure e da sensibilidade ao MTTR. Especificamente, ela aborda a implantação com reconhecimento de zona dos gateways de rede virtual do Azure ExpressRoute e da BFD (Detecção de Encaminhamento Bidirecional).
Gateways de rede virtual do Azure ExpressRoute com reconhecimento de zona de disponibilidade
Uma Zona de Disponibilidade em uma região do Azure combina um domínio de falha e um domínio de atualização. Para obter a maior resiliência e disponibilidade, configure um gateway de rede virtual do Azure ExpressRoute com redundância de zona. Para obter mais informações, consulte Sobre gateways de rede virtual com redundância de zona em Zonas de Disponibilidade do Azure. Para configurar um gateway de rede virtual com redundância de zona, confira Criar um gateway de rede virtual com redundância de zona nas Zonas de Disponibilidade do Azure.
Melhorando o tempo de detecção de falhas
O Azure ExpressRoute dá suporte ao BFD por emparelhamento privado, reduzindo o tempo de detecção de falhas na rede de Camada 2 entre o Microsoft Enterprise Edge (MSEEs) e seus vizinhos BGP no lado local de cerca de 3 minutos (padrão) para menos de um segundo. A detecção rápida de falhas ajuda a acelerar a recuperação. Para obter mais informações, consulte Configurar o BFD no Azure ExpressRoute.
Próximas etapas
Este artigo discutiu a criação para alta disponibilidade de um circuito do Azure ExpressRoute. Um ponto de emparelhamento do circuito do ExpressRoute do Azure é fixado a uma localização geográfica e pode ser afetado por falhas catastróficas que afetam toda a localização.
Para considerações de design para criar conectividade de rede com redundância geográfica para o backbone da Microsoft que pode suportar falhas catastróficas que afetam uma região inteira, consulte Projetar para recuperação de desastre com o emparelhamento privado do Azure ExpressRoute.