Criar para recuperação após desastre com peering privado do ExpressRoute
O ExpressRoute foi concebido para elevada disponibilidade para oferecer conectividade de rede privada de nível de operadora aos recursos da Microsoft. Por outras palavras, não há um ponto único de falha no caminho do ExpressRoute na rede da Microsoft. Para obter considerações de design para maximizar a disponibilidade de um circuito de Rota Expressa, consulte Projetando para alta disponibilidade com o ExpressRoute e o Well-Architectured Framework
No entanto, levando em consideração o adágio popular de Murphy - se algo pode dar errado, vai - neste artigo, vamos nos concentrar em soluções que vão além de falhas que podem ser resolvidas usando um único circuito de Rota Expressa. Analisamos as considerações da arquitetura de rede para criar uma conectividade de rede de back-end robusta para recuperação de desastres usando circuitos de Rota Expressa com redundância geográfica.
Nota
Os conceitos descritos neste artigo se aplicam igualmente quando um circuito de Rota Expressa é criado em WAN Virtual ou fora dela.
Necessidade de solução de conectividade redundante
Há possibilidades e instâncias em que um local de emparelhamento de Rota Expressa ou um serviço regional inteiro fica degradado. A causa raiz para essa interrupção de serviço em toda a região inclui calamidade natural. Portanto, é importante planejar a recuperação de desastres para continuidade de negócios e aplicativos de missão crítica.
Nota
Quando precisar implementar um projeto de recuperação de desastres em uma situação sensível ao tempo, como manter a continuidade dos negócios durante um desastre natural, você deve levar em consideração os seguintes fatores:
- Este documento fornece orientação sobre como implementar um projeto robusto de recuperação de desastres para vários circuitos de Rota Expressa configurados por meio de diferentes locais de emparelhamento. Este cenário pressupõe que você tenha tempo e recursos suficientes para configurar os circuitos de Rota Expressa.
- Se você precisar configurar rapidamente um projeto de recuperação de desastres para um único circuito de Rota Expressa que não seja redundante geograficamente, poderá usar as seguintes alternativas:
- Use uma VPN site a site como backup para tráfego de emparelhamento privado.
- Use a conectividade com a Internet como backup para o tráfego de emparelhamento da Microsoft.
Não importa o quê, se você executar seus aplicativos de missão crítica em uma região do Azure ou no local ou em qualquer outro lugar, você pode usar outra região do Azure como seu site de failover. Os artigos a seguir abordam a recuperação de desastres de aplicativos e perspetivas de acesso frontend:
- Recuperação de desastres em escala empresarial
- Recuperação de desastres SMB com o Azure Site Recovery
Se você confia na conectividade da Rota Expressa entre sua rede local e a Microsoft, precisa considerar o seguinte para planejar a recuperação de desastres pela Rota Expressa:
- usando circuitos de Rota Expressa com redundância geográfica
- usando diversas redes de provedores de serviços para diferentes circuitos de Rota Expressa
- projetar cada um dos circuitos da Rota Expressa para alta disponibilidade
- encerrando o circuito de Rota Expressa diferente em local diferente na rede do cliente
- usando gateways de rede virtual ExpressRoute com reconhecimento de zona de disponibilidade
Desafios de usar vários circuitos de Rota Expressa
Ao interconectar o mesmo conjunto de redes usando mais de uma conexão, você introduz caminhos paralelos entre as redes. Caminhos paralelos, quando não adequadamente arquitetados, podem levar a roteamento assimétrico. Se você tiver entidades com monitoração de estado, por exemplo, um NAT ou firewall no caminho, o roteamento assimétrico poderá bloquear o fluxo de tráfego. Normalmente, no caminho de emparelhamento privado da Rota Expressa, você não se depara com entidades com monitoração de estado, como NAT ou Firewalls. Portanto, o roteamento assimétrico no emparelhamento privado da Rota Expressa não bloqueia necessariamente o fluxo de tráfego.
No entanto, se você balancear a carga do tráfego entre caminhos paralelos com redundância geográfica, independentemente de ter entidades com estado ou não, o desempenho da rede será inconsistente. Esses caminhos paralelos geo-redundantes podem ser através do mesmo metrô ou metrô diferente encontrado na página de provedores por localização .
Redundância com circuitos ExpressRoute no mesmo metro
Muitos metrôs têm dois locais de Rota Expressa. Um exemplo seriam Amesterdão e Amesterdão2. Ao projetar redundância, você pode criar dois caminhos paralelos para o Azure com ambos os locais no mesmo metrô. Você realiza essa tarefa com o mesmo provedor ou opta por trabalhar com um provedor de serviços diferente para melhorar a resiliência. Outra vantagem desse design é quando o failover de aplicativos acontece, a latência de ponta a ponta entre seus aplicativos locais e a Microsoft permanece aproximadamente a mesma. No entanto, se houver um desastre natural, como um terremoto, a conectividade para ambos os caminhos pode não estar mais disponível.
Redundância com circuitos ExpressRoute em diferentes metrôs
Ao usar metros diferentes para redundância, você deve selecionar o local secundário na mesma região geopolítica. Para escolher um local fora da região geopolítica, você precisa usar o Premium SKU para ambos os circuitos nos caminhos paralelos. A vantagem dessa configuração é que as chances de um desastre natural causar uma interrupção em ambos os links são menores, mas ao custo de maior latência de ponta a ponta.
Nota
Habilitar o BFD nos circuitos da Rota Expressa ajudará com a deteção mais rápida de falhas de link entre dispositivos Microsoft Enterprise Edge (MSEE) e os roteadores de Borda do Cliente/Parceiro. No entanto, o failover geral e a convergência para o local redundante podem levar até 180 segundos em algumas condições de falha e você pode experimentar maior latência ou degradação de desempenho durante esse tempo.
Neste artigo, vamos discutir como lidar com os desafios que você pode enfrentar ao configurar caminhos com redundância geográfica.
Considerações sobre rede local pequena a média
Vamos considerar a rede de exemplo ilustrada no diagrama a seguir. No exemplo, a conectividade de Rota Expressa com redundância geográfica é estabelecida entre o local local de uma Contoso e a rede virtual da Contoso em uma região do Azure. No diagrama, a linha azul sólida indica o caminho preferencial (via Rota Expressa 1) e a pontilhada representa o caminho em espera (via Rota Expressa 2).
Por padrão, se você anunciar rotas de forma idêntica em todos os caminhos da Rota Expressa, o Azure equilibrará a carga do tráfego vinculado local em todos os caminhos da Rota Expressa usando o roteamento ECMP (Equal-cost multi-path).
No entanto, com os circuitos de Rota Expressa geo-redundantes, precisamos levar em consideração diferentes desempenhos de rede com caminhos de rede diferentes (particularmente para latência de rede). Para obter um desempenho de rede mais consistente durante a operação normal, convém preferir o circuito ExpressRoute que oferece a latência mínima.
Você pode influenciar o Azure a preferir um circuito de Rota Expressa a outro usando uma das seguintes técnicas (listadas na ordem de eficácia):
- publicidade rota mais específica sobre o circuito de Rota Expressa preferido em comparação com outros circuitos de Rota Expressa
- configurando um Peso de Conexão mais alto na conexão que vincula a rede virtual ao circuito de Rota Expressa preferencial
- anunciando as rotas em relação ao circuito ExpressRoute menos preferido com AS Path mais longo (AS Path prepend)
Percurso mais específico
O diagrama a seguir ilustra como influenciar a seleção de caminho da Rota Expressa usando um anúncio de rota mais específico. No exemplo ilustrado, o intervalo de IP /24 local da Contoso é anunciado como dois intervalos de endereços /25 por meio do caminho preferencial (Rota Expressa 1) e como /24 pelo caminho de espera (Rota Expressa 2).
Como /25 é mais específico, em comparação com /24, o Azure enviaria o tráfego destinado a 10.1.11.0/24 via ExpressRoute 1 no estado normal. Se ambas as conexões do ExpressRoute 1 caírem, a rede virtual verá o anúncio de rota 10.1.11.0/24 somente via ExpressRoute 2; e, portanto, o circuito de espera é usado neste estado de falha.
Peso da ligação
A captura de tela a seguir ilustra a configuração do peso de uma conexão de Rota Expressa por meio do portal do Azure.
O diagrama a seguir ilustra como influenciar a seleção de caminho da Rota Expressa usando o peso da conexão. O peso da conexão padrão é 0. No exemplo a seguir, o peso da conexão para ExpressRoute 1 é configurado como 100. Quando uma rede virtual recebe um prefixo de rota anunciado através de mais de um circuito ExpressRoute, a rede virtual prefere a conexão com o maior peso.
Se ambas as conexões do ExpressRoute 1 caírem, a rede virtual verá o anúncio de rota 10.1.11.0/24 somente via ExpressRoute 2; e, portanto, o circuito de espera é usado neste estado de falha.
Caminho AS prepend
O diagrama a seguir ilustra como influenciar a seleção de caminho da Rota Expressa usando o caminho AS prepend. No diagrama, o anúncio de rota sobre ExpressRoute 1 indica o comportamento padrão do eBGP. No anúncio de rota sobre a Rota Expressa 2, o ASN da rede local é precedido adicionalmente no caminho AS da rota. Quando a mesma rota é recebida através de vários circuitos ExpressRoute, de acordo com o processo de seleção de rota eBGP, a rede virtual prefere a rota com o caminho AS mais curto.
Se ambas as conexões da Rota Expressa 1 caírem, a rede virtual verá o anúncio de rota 10.1.11.0/24 somente via Rota Expressa 2. Consequentemente, o caminho AS mais longo tornar-se-ia irrelevante. Portanto, o circuito de espera seria usado neste estado de falha.
Usando qualquer uma das técnicas, se você influenciar o Azure a preferir uma de suas Rotas Expressas em detrimento de outras, também precisará garantir que a rede local também prefira o mesmo caminho de Rota Expressa para o tráfego vinculado do Azure para evitar fluxos assimétricos. Normalmente, o valor de preferência local é usado para influenciar a rede local a preferir um circuito de Rota Expressa em detrimento de outros. A preferência local é uma métrica interna do BGP (iBGP). A rota BGP com o maior valor de preferência local é preferida.
Importante
Ao usar determinados circuitos da Rota Expressa como modo de espera, você precisa gerenciá-los ativamente e testar periodicamente a operação de failover.
Grande rede empresarial distribuída
Quando você tem uma grande rede corporativa distribuída, é provável que tenha vários circuitos de Rota Expressa. Nesta seção, vamos ver como projetar a recuperação de desastres usando os circuitos de Rota Expressa ativo-ativo, sem precisar de outros circuitos em stand-by.
Vamos considerar o exemplo ilustrado no diagrama a seguir. No exemplo, a Contoso tem dois locais conectados a duas implantações de IaaS da Contoso em duas regiões diferentes do Azure por meio de circuitos de Rota Expressa em dois locais de emparelhamento diferentes.
A forma como arquitetamos a recuperação de desastres tem um efeito sobre como o tráfego entre regiões (região1/região2 para local2/local1) é roteado. Vamos considerar duas arquiteturas de desastre diferentes que roteiam o tráfego entre regiões de forma diferente.
Cenário 1
No primeiro cenário, vamos projetar a recuperação de desastres de modo que todo o tráfego entre uma região do Azure e a rede local flua através do circuito local da Rota Expressa no estado estacionário. Se o circuito local da Rota Expressa falhar, o circuito remoto da Rota Expressa será usado para todos os fluxos de tráfego entre o Azure e a rede local.
O cenário 1 é ilustrado no diagrama a seguir. No diagrama, linhas verdes indicam caminhos para o fluxo de tráfego entre VNet1 e redes locais. As linhas azuis indicam caminhos para o fluxo de tráfego entre VNet2 e redes locais. As linhas sólidas indicam o caminho desejado no estado estacionário e as linhas tracejadas indicam o caminho do tráfego na falha do circuito de Rota Expressa correspondente que transporta o fluxo de tráfego em estado estacionário.
Você pode arquitetar o cenário usando o peso da conexão para influenciar as redes virtuais a preferirem a conexão com o local de emparelhamento local ExpressRoute para tráfego vinculado à rede local. Para completar a solução, você precisa garantir um fluxo simétrico de tráfego reverso. Você pode usar a preferência local na sessão iBGP entre seus roteadores BGP (nos quais os circuitos da Rota Expressa são encerrados no lado local) para preferir um circuito da Rota Expressa. A solução é ilustrada no diagrama a seguir.
Cenário 2
O Cenário 2 é ilustrado no diagrama a seguir. No diagrama, linhas verdes indicam caminhos para o fluxo de tráfego entre VNet1 e redes locais. As linhas azuis indicam caminhos para o fluxo de tráfego entre VNet2 e redes locais. No estado estacionário, linhas sólidas no diagrama, todo o tráfego entre redes virtuais e locais flui usando o backbone da Microsoft normalmente e flui através da interconexão entre locais somente no estado de falha, linhas pontilhadas no diagrama, de uma Rota Expressa.
A solução é ilustrada no diagrama a seguir. Conforme ilustrado, você pode arquitetar o cenário usando uma rota mais específica (Opção 1) ou um caminho AS (Opção 2) para influenciar a seleção de caminho de rede virtual. Para influenciar a seleção de rota de rede local para o tráfego vinculado do Azure, você precisa configurar a interconexão entre o local local como menos preferível. Como você configura o link de interconexão como preferível depende do protocolo de roteamento usado na rede local. Você pode usar a preferência local com iBGP ou métrica com IGP (OSPF ou IS-IS).
Importante
Quando um ou vários circuitos de Rota Expressa estão conectados a várias redes virtuais, o tráfego de rede virtual para rede virtual pode ser roteado via Rota Expressa. No entanto, isso não é recomendado. Para habilitar a conectividade de rede virtual para rede virtual, configure o emparelhamento de rede virtual.
Próximos passos
Neste artigo, discutimos como projetar a recuperação de desastres de uma conectividade de emparelhamento privado de circuito ExpressRoute. Os artigos a seguir abordam a recuperação de desastres de aplicativos e perspetivas de acesso frontend: