Como projetar para recuperação de desastre com o emparelhamento privado do ExpressRoute

  • Artigo

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 obter considerações de design para maximizar a disponibilidade de um circuito do ExpressRoute, confira Como projetar para alta disponibilidade com o ExpressRoute e Well-Architectured Framework

No entanto, levando em conta a lei de Murphy, "se algo puder dar errado, dará errado" neste artigo, vamos nos concentrar em soluções que vão além das falhas que podem ser resolvidas usando um só circuito do ExpressRoute. Vamos analisar as considerações de arquitetura de rede para criar uma conectividade de rede de back-end robusta para recuperação de desastre usando circuitos do ExpressRoute com redundância geográfica.

Observação

Os conceitos descritos neste artigo se aplicam igualmente quando um circuito do ExpressRoute é criado sob a WAN Virtual ou fora dela.

Necessidade de solução de conectividade redundante

Existem possibilidades e instâncias em que um local de emparelhamento do ExpressRoute ou um serviço regional inteiro é degradado. A causa raiz para essa interrupção ao serviço em toda a região incluem calamidades naturais. Portanto, é importante planejar a recuperação de desastres para a continuidade dos negócios e aplicativos essenciais.

Observação

Quando você precisar de 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 conta os seguintes fatores:

  • Este documento fornece diretrizes sobre como implementar um projeto de recuperação de desastre robusto para vários circuitos do ExpressRoute configurados por meio de diferentes locais de emparelhamento. Esse cenário pressupõe que você tenha tempo e recursos suficientes para configurar os circuitos do ExpressRoute.
  • Se você precisar de configurar rapidamente um projeto de recuperação de desastre para um único circuito do ExpressRoute que não seja com redundância geográfica, você pode usar as seguintes alternativas:
    • Use uma VPN site a site como um backup para o tráfego de emparelhamento privado.
    • Use a conectividade com a Internet como um backup para o tráfego de emparelhamento da Microsoft.

Não importa se você executa seus aplicativos de missão crítica em uma região do Azure ou local ou em qualquer outro lugar, você pode usar outra região do Azure como seu site de failover. Os seguintes artigos abordam a recuperação de desastre de aplicativos e perspectivas de acesso de front-end:

Se você depender da conectividade do ExpressRoute entre sua rede local e a Microsoft, será necessário considerar o seguinte para planejar a recuperação de desastres no ExpressRoute:

Desafios de usar vários circuitos do ExpressRoute

Ao interconectar o mesmo conjunto de redes usando mais de uma conexão, você introduz caminhos paralelos entre as redes. Os caminhos paralelos, quando não arquitetados corretamente, podem levar ao roteamento assimétrico. Se você tiver entidades com estado, por exemplo, um NAT ou um firewall no caminho, o roteamento assimétrico poderá bloquear o fluxo de tráfego. Normalmente, no caminho de emparelhamento privado do ExpressRoute, você não encontra em entidades com estado, como NAT ou firewalls. Portanto, o roteamento assimétrico pelo emparelhamento privado do ExpressRoute 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, terá um desempenho de rede inconsistente. Esses caminhos paralelos com redundância geográfica podem ser por meio do mesmo metro ou de um metro diferente encontrado na página provedores por localização.

Redundância com circuitos do ExpressRoute no mesmo metrô

Muitos metros têm dois locais do ExpressRoute. Um exemplo seria Amsterdã e Amsterdã2. Ao projetar a redundância, você poderia criar dois caminhos paralelos para o Azure com ambos os locais no mesmo metro. Você realizar essa tarefa com o mesmo provedor ou optar por trabalhar com um provedor de serviços diferente para melhorar a resiliência. A vantagem desse design é quando o failover de aplicativo ocorre, 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 poderá não estar mais disponível.

Redundância com circuitos do ExpressRoute em diferentes metrôs

Ao usar diferentes metros para redundância, você deve selecionar a localização secundária na mesma região geopolítica. Para escolher uma localização fora da região política de área geográfica, você precisa usar a SKU Premium 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 a um custo de maior latência de ponta a ponta.

Observação

Habilitar o BFD nos circuitos do ExpressRoute ajudará na detecção mais rápida de falhas de vínculo entre os dispositivos do Microsoft Enterprise Edge (MSEE) e os roteadores de Borda do Cliente/Parceiro. No entanto, o failover geral e a convergência para o site redundante podem levar até 180 segundos em algumas condições de falha e você pode enfrentar maior latência ou degradação de desempenho durante esse tempo.

Neste artigo, vamos discutir como abordar os desafios que você pode enfrentar ao configurar caminhos com redundância geográfica.

Considerações de rede local de pequeno a médio porte

Vamos considerar a rede de exemplo ilustrada no diagrama a seguir. No exemplo, a conectividade do ExpressRoute com redundância geográfica é estabelecida entre a localização local da Contoso e a VNet da Contoso em uma região do Azure. No diagrama, uma linha azul contínua indica o caminho preferencial (pelo ExpressRoute 1) e a pontilhada representa o caminho de espera (pelo ExpressRoute 2).

Diagram of small to medium size on-premises network considerations.

Por padrão, se você anunciar rotas de modo idêntico em todos os caminhos do ExpressRoute, o Azure balanceará a carga do tráfego de entrada local em todos os caminhos do ExpressRoute usando o roteamento de ECMP (vários caminhos de custo igual).

No entanto, com os circuitos do ExpressRoute com redundância geográfica, precisamos levar em consideração diferentes desempenhos de rede com diferentes caminhos de rede (especialmente para latência de rede). Para obter um desempenho de rede mais consistente durante a operação normal, convém preferir o circuito do ExpressRoute que oferece a latência mínima.

Você pode influenciar o Azure a preferir um circuito de ExpressRoute a outro usando uma das seguintes técnicas (listadas na ordem de eficácia):

  • anunciar uma rota mais específica sobre o circuito de ExpressRoute preferencial em comparação a outros circuitos do ExpressRoute
  • configurar um peso de conexão maior na conexão que vincula a rede virtual ao circuito do ExpressRoute preferencial
  • anunciar as rotas em um circuito do ExpressRoute menos preferencial com caminho mais longo do que (como caminho do demarcador)

Rota mais específica

O diagrama a seguir ilustra a influência da seleção de caminho do ExpressRoute usando um anúncio de rota mais específica. No exemplo ilustrado, o intervalo de IP local /24 da Contoso é anunciado como dois intervalos de endereço /25 por meio do caminho preferencial (ExpressRoute 1) e como /24 por meio do caminho de espera (ExpressRoute 2).

Diagram of influencing path selection using more specific routes.

Como /25 é mais específico comparado a/24, o Azure enviaria o tráfego destinado a 10.1.11.0/24 por meio do ExpressRoute 1 no estado normal. Se ambas as conexões do ExpressRoute 1 ficarem inativas, a VNet verá o anúncio de rota 10.1.11.0/24 somente por meio do ExpressRoute 2, portanto, o circuito em espera será usado nesse estado de falha.

Peso da conexão

A captura de tela a seguir ilustra a configuração do peso de uma conexão do ExpressRoute por meio do portal do Azure.

Screenshot of configuring connection weight via Azure portal.

O diagrama a seguir ilustra a influência da seleção de caminho do ExpressRoute usando o peso da conexão. O peso de conexão padrão é 0. No exemplo a seguir, o peso da conexão para o ExpressRoute 1 é configurado como 100. Quando uma VNet recebe um prefixo de rota anunciado por mais de um circuito do ExpressRoute, a VNet prefere a conexão com o peso mais alto.

Diagram of influencing path selection using connection weight.

Se ambas as conexões do ExpressRoute 1 ficarem inativas, a VNet verá o anúncio de rota 10.1.11.0/24 somente por meio do ExpressRoute 2, portanto, o circuito em espera será usado nesse estado de falha.

Prefixação do caminho AS

O diagrama a seguir ilustra influência na seleção de caminho do ExpressRoute usando prefixação de caminho AS. No diagrama, o anúncio de rota no ExpressRoute 1 indica o comportamento padrão do eBGP. No anúncio de rota no ExpressRoute 2, o ASN da rede local é anexado adicionalmente à rota como caminho. Quando a mesma rota é recebida por meio de vários circuitos do ExpressRoute, de acordo com o processo de seleção de rota eBGP, a VNet prefere a rota com o caminho mais curto.

Diagram of influencing path selection using AS path prepend.

Se ambas as conexões do ExpressRoute 1 ficarem inativas, a VNet verá o anúncio de rota 10.1.11.0/24 somente por meio do ExpressRoute 2. Assim, o caminho AS mais longo se tornaria irrelevante. Portanto, o circuito em espera seria usado nesse estado de falha.

Usando qualquer uma das técnicas, se você influenciar o Azure a preferir um dos ExpressRoute a outros, também precisará garantir que a rede local também prefira o mesmo caminho do ExpressRoute para o tráfego associado 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 ExpressRoute a outros. A preferência local é uma métrica iBGP (BGP interna). A rota BGP com o maior valor de preferência local é preferida.

Importante

Ao usar determinados circuitos do ExpressRoute como em espera, você precisa gerenciá-los de modo ativo e testar periodicamente a operação de failover.

Grande rede corporativa distribuída

Quando você tem uma grande rede corporativa distribuída, provavelmente tem vários circuitos do ExpressRoute. Nesta seção, vamos ver como projetar a recuperação de desastres usando os circuitos do ExpressRoute ativo-ativo sem a necessidade de outros circuitos de espera.

Vamos considerar o exemplo ilustrado no diagrama a seguir. No exemplo, a Contoso tem dois lugares locais conectados a duas implantações de IaaS da Contoso em duas regiões diferentes do Azure por meio de circuitos do ExpressRoute em dois locais de emparelhamento diferentes.

Diagram of large distributed on-premises network considerations.

A maneira como arquitetamos a recuperação de desastres afeta como o tráfego entre as regiões cruzadas e a localização cruzada (region1/region2 para location2/location1) é roteado. Vamos considerar duas arquiteturas de desastre diferentes que roteiam o tráfego de localização entre regiões de modo 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 uma rede local flua pelo circuito do ExpressRoute no estado estacionário. Se o circuito do ExpressRoute local falhar, o circuito do ExpressRoute remoto 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, as linhas verdes indicam caminhos para o fluxo de tráfego entre a VNet1 e as redes locais. As linhas azuis indicam caminhos para o fluxo de tráfego entre a VNet2 e redes locais. As linhas sólidas indicam o caminho desejado no estado estacionário e as linhas tracejadas indicam o caminho de tráfego na falha do circuito de ExpressRoute correspondente que transporta o fluxo de tráfego de estado estacionário.

Diagram of traffic flow for first scenario.

Você pode arquitetar o cenário usando o peso de conexão para influenciar VNets para preferir a conexão à localização de emparelhamento local do ExpressRoute para tráfego de rede local. Para concluir a solução, você precisa garantir o fluxo de tráfego inverso simétrico. Você pode usar a preferência local na sessão de iBGP entre os roteadores BGP (nos quais os circuitos de ExpressRoute são encerrados no lado local) para preferir um circuito do ExpressRoute. A solução é ilustrada no diagrama a seguir.

Diagram of active-active ExpressRoute circuits solution 1.

Cenário 2

O Cenário 2 é ilustrado no diagrama a seguir. No diagrama, as linhas verdes indicam caminhos para o fluxo de tráfego entre a VNet1 e as redes locais. As linhas azuis indicam caminhos para o fluxo de tráfego entre a VNet2 e redes locais. No estado estacionário (linhas sólidas no diagrama), todo o tráfego entre os locais VNets e lugares locais fluem usando o back-bone da Microsoft normalmente e flui pela interconexão entre lugares locais apenas no estado de falha (linhas pontilhadas no diagrama) de um ExpressRoute.

Diagram of traffic flow for second scenario.

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 acrescentado ao início (Opção 2) para influenciar a seleção do caminho da VNet. Para influenciar a seleção de rota de rede local para o tráfego associado do Azure, você precisa configurar a interconexão entre a localização local como menos preferível. A maneira de configurar 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 o IGP (OSPF ou IS-IS).

Diagram of active-active ExpressRoute circuits solution 2.

Importante

Quando um ou vários circuitos do ExpressRoute estão conectados a várias redes virtuais, a rede virtual para o tráfego de rede virtual pode rotear por meio do ExpressRoute. No entanto, isso não é recomendado. Para habilitar a rede virtual para conectividade de rede virtual, configure o emparelhamento de rede virtual.

Próximas etapas

Neste artigo, discutimos como projetar para a recuperação de desastre de uma conectividade de emparelhamento privado do circuito do ExpressRoute. Os seguintes artigos abordam a recuperação de desastre de aplicativos e perspectivas de acesso de front-end: