Como projetar para recuperação de desastre com o emparelhamento privado do 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 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 examinar 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

Há possibilidades e instâncias em que um serviço regional inteiro (seja o que a Microsoft, os provedores de serviços de rede, o cliente ou outros provedores de serviço de nuvem) é degradado. A causa raiz para esse impacto ao serviço em toda a região incluem calamidades naturais. É por isso que, para a continuidade dos negócios e aplicativos de missão crítica, é importante planejar a recuperação de desastres.

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 para operações críticas, seu plano de recuperação de desastres também deverá incluir conectividade de rede com redundância geográfica.

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, NAT, 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 entrará em entidades com estado, como NAT ou firewalls. É por isso que 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.

Mesmo metro

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. 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.

Metros diferentes

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ê precisará 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 muito menores, mas a um custo de maior latência de ponta a ponta.

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 verde sólida indica o caminho preferencial (via ExpressRoute 1) e o pontilhado representa o caminho de espera (via ExpressRoute 2).

1

Ao criar a conectividade de ExpressRoute para recuperação de desastres, você precisa considerar:

  • usar circuitos do ExpressRoute com redundância geográfica
  • usar diferentes redes de provedor de serviços para um circuito do ExpressRoute diferente
  • projetar cada um dos circuitos do ExpressRoute para alta disponibilidade
  • encerrar o circuito do ExpressRoute diferente em uma localização diferente na rede do cliente

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).

2

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.

3

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, ela prefere a conexão com o peso mais alto.

4

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.

5

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.

6

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.

7

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.

8

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 por meio do back-bone da Microsoft em sua maioria e flui pela interconexão entre lugares locais apenas no estado de falha (linhas pontilhadas no diagrama) de um ExpressRoute.

9

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).

10

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: