Projetando para alta disponibilidade com o Azure ExpressRoute

O Azure ExpressRoute foi projetado para alta disponibilidade, fornecendo conectividade de rede privada de nível de operadora para recursos da Microsoft. Isso significa que não há um único ponto de falha na rede da Microsoft. Para maximizar a disponibilidade, os segmentos de cliente e provedor de serviços do seu circuito de Rota Expressa do Azure também devem ser arquitetados para alta disponibilidade. Este artigo aborda 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 seu circuito do Azure ExpressRoute.

Nota

Os conceitos descritos neste artigo aplicam-se igualmente quer um circuito de Rota Expressa do Azure seja 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 de Rota Expressa do Azure 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 em sua rede de provedor de serviços. No mínimo, isso envolve evitar pontos únicos de falha de rede. A alimentação e o arrefecimento redundantes para dispositivos de rede melhoram ainda mais a alta disponibilidade.

Considerações sobre o projeto da camada física da primeira milha

Se você encerrar as conexões primária e secundária de um circuito da Rota Expressa do Azure no mesmo CPE (Customer Premises Equipment), comprometerá a alta disponibilidade em sua rede local. Além disso, a configuração de 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 de parceiros, conforme ilustrado abaixo.

Encerrar as conexões primária e secundária de um circuito de Rota Expressa do Azure em diferentes locais geográficos pode comprometer o desempenho da rede. Se o tráfego estiver ativamente com balanceamento de carga entre conexões terminadas em locais diferentes, diferenças substanciais na latência da rede entre os dois caminhos podem resultar em desempenho abaixo do ideal.

Para obter considerações de design com redundância geográfica, consulte Projetando para recuperação de desastres com o Azure ExpressRoute.

Conexões ativo-ativo

A rede Microsoft opera as conexões primárias e secundárias dos circuitos de Rota Expressa do Azure no modo ativo-ativo. No entanto, você pode forçar as conexões redundantes a operar no modo ativo-passivo através de seus anúncios de rota. Anunciar rotas mais específicas e o caminho BGP AS pendente são técnicas comuns para preferir um caminho em detrimento do outro.

Para melhorar a alta disponibilidade, recomenda-se operar ambas as conexões no modo ativo-ativo. Isso permite que a rede Microsoft balanceie a carga do tráfego entre as conexões por fluxo.

A execução de conexões no modo ativo-passivo corre o risco de ambas as conexões falharem se o caminho ativo falhar. As causas comuns para a falha incluem a falta de gerenciamento ativo da conexão passiva e conexão passiva anunciando rotas obsoletas.

Como alternativa, a execução de conexões no modo ativo-ativo resulta em apenas cerca de metade dos fluxos falhando e sendo redirecionados, melhorando significativamente o Tempo Médio de Recuperação (MTTR).

Nota

Durante a manutenção ou eventos não planejados que afetem uma conexão, a Microsoft usará o caminho AS pendente para drenar o tráfego para a conexão íntegra. Certifique-se de que o tráfego possa ser roteado pelo caminho íntegro quando o caminho pendente 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 comunicação entre pontos de extremidade públicos. Normalmente, os pontos de extremidade privados locais são NATed (Network Address Converted) com IPs públicos na rede do cliente ou parceiro antes de se comunicarem por 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:

O NAT é aplicado após a divisão do tráfego entre as conexões primária e secundária. Os pools NAT independentes são usados para os dispositivos primários e secundários para atender aos requisitos de NAT com monitoração de estado. O tráfego de retorno chega no mesmo dispositivo de borda pelo qual o fluxo saiu.

Se uma conexão do Azure ExpressRoute falhar, o pool NAT correspondente ficará inacessível, interrompendo 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 alcançar servidores locais usando o NAT correspondente até que a conectividade seja restaurada.

Opção 2:

Um pool NAT comum é usado antes de dividir o tráfego entre as conexões primária e secundária. Isso não introduz um único ponto de falha, mantendo assim a alta disponibilidade.

O pool NAT permanece acessível mesmo se a conexão primária ou secundária falhar, permitindo que a camada de rede redirecione pacotes e recupere mais rapidamente.

Nota

• Se usar a opção NAT 1 (pools NAT independentes para conexões primárias e secundárias) e mapear uma porta de um endereço IP de um pool NAT para um servidor local, o servidor não poderá ser acessado por meio do circuito de Rota Expressa do Azure se a conexão correspondente falhar.
• Encerrar conexões BGP do Azure ExpressRoute em dispositivos com monitoração de estado pode causar problemas de failover durante a manutenção planejada ou não planejada pela Microsoft ou pelo seu Provedor de Rota Expressa do Azure. Teste sua configuração para garantir o failover adequado e, quando possível, encerre sessões BGP em dispositivos sem monitoração de estado.

Recursos de ajuste fino para emparelhamento privado

Esta seção analisa os recursos opcionais que ajudam a melhorar a alta disponibilidade do seu circuito de Rota Expressa do Azure, dependendo da sua implantação do Azure e da sensibilidade ao MTTR. Especificamente, ele abrange a implantação com reconhecimento de zona de gateways de rede virtual do Azure ExpressRoute e BFD (Deteçã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 mais alta resiliência e disponibilidade, configure um gateway de rede virtual Azure ExpressRoute com redundância de zona. Para obter mais informações, consulte Sobre gateways de rede virtual com redundância de zona nas zonas de disponibilidade do Azure. Para configurar um gateway de rede virtual com redundância de zona, consulte Criar um gateway de rede virtual com redundância de zona nas Zonas de Disponibilidade do Azure.

Melhorar o tempo de deteção de falhas

O Azure ExpressRoute dá suporte ao BFD sobre emparelhamento privado, reduzindo o tempo de deteção de falhas na rede de Camada 2 entre Microsoft Enterprise Edge (MSEEs) e seus vizinhos BGP no lado local de cerca de 3 minutos (padrão) para menos de um segundo. A deteção rápida de falhas ajuda a acelerar a recuperação. Para obter mais informações, consulte Configurar o BFD sobre o Azure ExpressRoute.

Próximos passos

Este artigo discutiu o design para alta disponibilidade de um circuito de Rota Expressa do Azure. Um ponto de emparelhamento de circuito da Rota Expressa do Azure é fixado a uma localização geográfica e pode ser afetado por falhas catastróficas que afetam todo o local.

Para obter considerações de design para criar conectividade de rede com redundância geográfica para o backbone da Microsoft que pode resistir a falhas catastróficas que afetam uma região inteira, consulte Projetando para recuperação de desastres com emparelhamento privado do Azure ExpressRoute.