Design voltado à alta disponibilidade com o ExpressRoute
O ExpressRoute foi projetado para alta disponibilidade para fornecer conectividade de rede privada de nível da operadora para recursos da Microsoft. Em outras palavras, não há um ponto único de falha no caminho do ExpressRoute dentro da rede da Microsoft. Para maximizar a disponibilidade, a arquitetura do cliente e do segmento do provedor de serviços do circuito do ExpressRoute também deve ser voltada à alta disponibilidade. Neste artigo, serão apresentadas considerações de arquitetura de rede para a criação de uma conectividade de rede robusta usando um ExpressRoute. Em seguida, será feita a análise dos recursos de ajuste fino que o ajudarão a melhorar a alta disponibilidade do circuito do ExpressRoute.
Observação
Os conceitos descritos neste artigo se aplicam igualmente quando um circuito do ExpressRoute é criado sob a WAN Virtual ou fora dela.
Considerações sobre a arquitetura
A figura a seguir ilustra a maneira recomendada de se conectar usando um circuito do ExpressRoute para maximizar a disponibilidade dele.
Para obter alta disponibilidade, é essencial manter a redundância do circuito do ExpressRoute em toda a rede de ponta a ponta. Em outras palavras, você precisa manter a redundância em sua rede local e não deve comprometê-la na rede do provedor de serviços. Manter o mínimo de redundância ajuda a evitar o ponto único de falhas de rede. Ter energia e resfriamento redundantes para os dispositivos de rede melhora ainda mais a alta disponibilidade.
Considerações de design da camada física de primeira milha
Ao encerrar as conexões primária e secundária dos circuito de um ExpressRoute no mesmo CPE (equipamento local do cliente), você compromete a alta disponibilidade em sua rede local. Além disso, se você configurar as conexões primária e secundária usando a mesma porta de um CPE, estará forçando o parceiro a comprometer a alta disponibilidade também no segmento de rede. Esse evento pode ocorrer ao encerrar as duas conexões em subinterfaces diferentes ou ao mesclar as duas conexões na rede do parceiro. Esse impacto é ilustrado na figura a seguir.
Por outro lado, ao encerrar as conexões primária e secundária de um circuito do ExpressRoute em diferentes localizações geográficas, você pode comprometer o desempenho de rede da conectividade. Se o tráfego tiver a carga balanceada ativamente nas conexões primária e secundária encerradas nas diferentes localizações geográficas, uma possível diferença substancial na latência de rede entre os dois caminhos resultará em um desempenho de rede abaixo do ideal.
Para considerações de design com redundância geográfica, consulte Design voltado à recuperação de desastre com o ExpressRoute.
Conexões ativa/ativa
A rede da Microsoft está configurada para operar as conexões primária e secundária dos circuitos do ExpressRoute no modo ativo/ativo. No entanto, você pode forçar as conexões redundantes de um circuito do ExpressRoute a operar no modo ativo/passivo por meio de seus anúncios de rota. O anúncio de rotas mais específicas e a anexação do caminho BGP AS são as técnicas comuns usadas para fazer com que um caminho tenha preferência em vez de outro.
Para melhorar a alta disponibilidade, recomenda-se operar as duas conexões de um circuito do ExpressRoute no modo ativo/ativo. Se você permitir que as conexões operem no modo ativo/ativo, a rede da Microsoft balanceará carga do tráfego entre as conexões com base no fluxo.
A execução das conexões primária e secundária de um circuito do ExpressRoute no modo ativo/passivo acarreta no risco de ambas as conexões falharem após uma falha no caminho ativo. As causas de falha comuns ao realizar a alternância são 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 das conexões primária e secundária de um circuito ExpressRoute no modo ativo/ativo resulta em apenas cerca de metade dos fluxos falhando e sendo redirecionados. Portanto, uma conexão ativo/ativo ajuda a melhorar significativamente o MTTR (tempo médio de recuperação).
Observação
Durante uma atividade de manutenção ou em caso de eventos não planejados que afetem uma das conexões, a Microsoft vai preferir usar o caminho AS prefixado, para drenar o tráfego até a conexão íntegra. Você precisará garantir que o tráfego possa rotear pelo caminho íntegro quando o caminho precedido for configurado pela Microsoft e que os anúncios de rota necessários sejam configurados adequadamente para evitar qualquer 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 traduzidos em endereços de rede (NAT) com o IP público no cliente ou na rede de parceiros antes de se comunicarem pelo emparelhamento da Microsoft. Supondo que você use as conexões primária e secundária em uma configuração ativo/ativo. Onde e como o seu NAT afeta a rapidez com que você se recupera após uma falha em uma das conexões do ExpressRoute. Duas opções de NAT diferentes são ilustradas na figura a seguir:
Opção 1:
O NAT é aplicado após dividir o tráfego entre as conexões primárias e secundárias do circuito ExpressRoute. Para atender aos requisitos de estado do NAT, pools de NAT independentes são usados para os dispositivos primários e secundários. O tráfego de retorno chega ao mesmo dispositivo de borda pelo qual o fluxo saiu.
Se a conexão do ExpressRoute falhar, a capacidade de alcançar o pool de NAT correspondente será interrompida. Portanto, todos os fluxos de rede interrompidos devem ser restabelecidos pelo TCP ou pela camada do aplicativo após o tempo limite da janela correspondente. Durante a falha, o Azure não pode acessar os servidores locais usando o NAT correspondente até que a conectividade seja restaurada para as conexões primárias ou secundárias do circuito do ExpressRoute.
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 do circuito do ExpressRoute. É importante distinguir que o pool NAT comum antes da divisão do tráfego não significa que ele apresenta um ponto único de falha, comprometendo assim a alta disponibilidade.
O pool de NAT é acessível mesmo após a falha da conexão primária ou secundária. Assim, a própria camada de rede pode redirecionar os pacotes e ajudar na recuperação mais rápida após uma falha.
Observação
- Ao usar a opção NAT 1 (pools de NAT independentes para as conexões primária e secundária do ExpressRoute) e mapear 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 ExpressRoute quando a conexão correspondente falhar.
- O encerramento de conexões BGP do ExpressRoute em dispositivos com estado pode causar problemas com failover durante as manutenções planejadas ou não planejadas pela Microsoft ou pelo seu provedor do ExpressRoute. Você deve testar a configuração para garantir que o tráfego fará o failover corretamente e, quando possível, encerrar as sessões BGP em dispositivos sem estado.
Recursos de ajuste fino para o emparelhamento privado
Nesta seção, serão analisados recursos opcionais (dependendo de sua implantação do Azure e de sua sensibilidade ao MTTR) que ajudam a melhorar a alta disponibilidade do circuito do ExpressRoute. Especificamente, serão abordadas a implantação com detecção de zona dos gateways de rede virtual do ExpressRoute e a BFD (detecção de encaminhamento bidirecional).
Gateways de rede virtual do ExpressRoute com detecção de zona de disponibilidade
Uma Zona de Disponibilidade em uma região do Azure é uma combinação de um domínio de falha e um domínio de atualização. Para obter a maior resiliência e disponibilidade, você deve configurar um gateway de rede virtual ExpressRoute com redundância de zona. Para saber mais, confira Sobre os 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, 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 ExpressRoute dá suporte ao BFD sobre o emparelhamento privado. O BFD reduz o tempo de detecção de falha na rede da Camada 2 entre o Microsoft Enterprise Edge (MSEEs) e seus vizinhos BGP no lado local de cerca de três minutos (padrão) para menos de um segundo. Um tempo de detecção de falhas rápido ajuda a melhorar a recuperação de falha. Para saber mais, consulte Configurar o BFD no ExpressRoute.
Próximas etapas
Neste artigo, foi discutido o design voltado à alta disponibilidade para a conectividade de um circuito do ExpressRoute. Um ponto de emparelhamento de circuito do ExpressRoute é fixado em uma localização geográfica e, portanto, é afetado por uma falha catastrófica que afeta todo o local.
Para considerações de design ao criar uma 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, confira Design para a recuperação de desastres com o emparelhamento privado do ExpressRoute.