Estrutura de recuperação após desastre

  • Artigo

WAN Virtual permite-lhe agregar, ligar, gerir centralmente e proteger todas as suas implementações globais. As suas implementações globais podem incluir combinações de diferentes ramos, Ponto de Presença (PoP), utilizadores privados, escritórios, redes virtuais do Azure e outras implementações multi cloud. Pode utilizar sD-WAN, VPN site a site, VPN ponto a site e ExpressRoute para ligar os seus diferentes sites a um hub virtual. Se tiver vários hubs virtuais, todos os hubs serão ligados em malha completa numa implementação de WAN Virtual padrão.

Neste artigo, vamos ver como arquitetar diferentes tipos de opções de conectividade de rede como serviço que WAN Virtual suportam a recuperação após desastre.

Opções de conectividade de rede como serviço do WAN Virtual

WAN Virtual suporta as seguintes opções de conectividade de back-end:

  • Conectividade remota do utilizador
  • Sucursal/Office/SD-WAN/VPN site a site
  • Conectividade privada (peering privado do ExpressRoute)

Para cada uma destas opções de conectividade, WAN Virtual implementa um conjunto separado de instâncias de gateway num hub virtual.

Inerentemente, WAN Virtual foi concebida para oferecer uma solução de agregação de rede de nível de transportadora elevada disponível. Para elevada disponibilidade, WAN Virtual instancia várias instâncias quando cada um destes diferentes tipos de gateways é implementado num hub WAN Virtual. Para saber mais sobre a elevada disponibilidade do ExpressRoute, veja Estruturar para elevada disponibilidade com o ExpressRoute.

Com o gateway de VPN ponto a site, o número mínimo de instâncias implementadas é dois. Com o gateway de VPN ponto a site, escolhe a capacidade de débito agregado de gateways ponto a site e várias instâncias são automaticamente aprovisionadas automaticamente. Pode escolher a capacidade de agregação de acordo com o número de clientes ou utilizadores que pretende ligar ao hub virtual. Na perspetiva da conectividade do cliente, as instâncias de gateway de VPN ponto a site estão ocultas por trás do Nome de Domínio Completamente Qualificado (FQDN) do gateway.

Para o gateway de VPN site a site, são implementadas duas instâncias do gateway num hub virtual. Cada uma das instâncias do gateway é implementada com o seu próprio conjunto de endereços IP públicos e privados. A captura de ecrã seguinte mostra os endereços IP associados às duas instâncias de uma configuração de gateway de VPN site a site de exemplo. Por outras palavras, as duas instâncias fornecem dois pontos finais de túnel independentes para estabelecer a conectividade VPN site a site a partir dos ramos. Para maximizar a elevada disponibilidade, veja Seleção do caminho do Azure em várias ligações ISP.

Captura de ecrã que mostra um exemplo de configuração do gateway V P N de site a site.

Maximizar a elevada disponibilidade da arquitetura de rede é um primeiro passo fundamental para Continuidade de Negócio e Recuperação Após Desastre (BCDR). No resto deste artigo, conforme indicado anteriormente, vamos além da elevada disponibilidade e discutir como arquitetar a sua rede de conectividade WAN Virtual para BCDR.

Necessidade de design de recuperação após desastre

O desastre pode atingir em qualquer altura, em qualquer lugar. O desastre pode ocorrer em regiões ou redes de fornecedores de cloud, numa rede de fornecedor de serviços ou numa rede no local. O impacto regional de um serviço de cloud ou de rede devido a determinados fatores como calamidade natural, erros humanos, guerra, terrorismo, configuração incorreta são difíceis de excluir. Assim, para a continuidade das suas aplicações críticas para a empresa, precisa de ter um design de recuperação após desastre. Para uma conceção abrangente de recuperação após desastre, tem de identificar todas as dependências que podem falhar no seu caminho de comunicação ponto a ponto e criar redundância não sobreposta para cada uma das dependências.

Independentemente de executar as aplicações críticas para a missão numa região do Azure, no local ou em qualquer outro lugar, pode utilizar outra região do Azure como site de ativação pós-falha. Os artigos seguintes abordam a recuperação após desastre a partir de aplicações e perspetivas de acesso de front-end:

Desafios da utilização da conectividade redundante

Quando interliga o mesmo conjunto de redes com mais do que uma ligação, introduz caminhos paralelos entre as redes. Os caminhos paralelos, quando não estão devidamente arquitetados, podem levar a encaminhamento assimétrico. Se tiver entidades com estado (por exemplo, NAT, firewall) no caminho, o encaminhamento assimétrico poderá bloquear o fluxo de tráfego. Normalmente, através da conectividade privada, não terá ou encontrará entidades com estado, como NAT ou Firewalls. Por conseguinte, o encaminhamento assimétrico através da conectividade privada não bloqueia necessariamente o fluxo de tráfego.

No entanto, se o balanceamento de carga do tráfego entre caminhos paralelos georredundantes, ocorrerá um desempenho de rede inconsistente devido à diferença no caminho físico das ligações paralelas. Por isso, temos de considerar o desempenho do tráfego de rede durante o estado estável (estado de não falha) e um estado de falha como parte do nosso design de recuperação após desastre.

Redundância de rede de acesso

A maioria dos serviços SD-WAN (soluções geridas ou não) fornecem-lhe conectividade de rede através de vários tipos de transporte (por exemplo, banda larga da Internet, MPLS, LTE). Para proteger contra falhas de rede de transporte, selecione conectividade em mais do que uma rede de transporte. Para um cenário de utilizador doméstico, pode considerar a utilização da rede móvel como uma cópia de segurança para conectividade de rede de banda larga.

Se a conectividade de rede através de diferentes tipos de transporte não for possível, selecione conectividade de rede através de mais do que um fornecedor de serviços. Se estiver a obter conectividade através de mais do que um fornecedor de serviços, certifique-se de que os fornecedores de serviços mantêm redes de acesso independentes não sobrepostas.

Considerações de conectividade remota do utilizador

A conectividade remota do utilizador é estabelecida através da VPN ponto a site entre um dispositivo final para uma rede. Na sequência de uma falha de rede, o dispositivo final será largado e tentará reativar o túnel VPN. Por conseguinte, para a VPN ponto a site, a estrutura de recuperação após desastre deve ter como objetivo minimizar o tempo de recuperação após uma falha. A seguinte redundância de rede ajudaria a minimizar o tempo de recuperação. Dependendo da importância das ligações, pode escolher algumas ou todas estas opções.

  • Redundância de rede de acesso (abordada acima).
  • Gerir o hub virtual redundante para terminação de VPN ponto a site. Quando tem vários hubs virtuais com gateways ponto a site, a VWAN fornece um perfil global que lista todos os pontos finais ponto a site. Com o perfil global, os seus dispositivos finais podem ligar-se ao hub virtual disponível mais próximo que oferece o melhor desempenho de rede. Se todas as implementações do Azure estiverem numa única região e os dispositivos finais que se ligam estiverem próximos da região, pode ter hubs virtuais redundantes na região. Se a implementação e os dispositivos finais estiverem distribuídos por várias regiões, pode implementar o hub virtual com gateway ponto a site em cada uma das regiões selecionadas. WAN Virtual tem um gestor de tráfego incorporado que seleciona o melhor hub para a conectividade remota do utilizador automaticamente.

O diagrama seguinte mostra o conceito de gerir o hub virtual redundante com o respetivo gateway ponto a site numa região.

Diagrama da agregação ponto a site de vários hubs.

No diagrama acima, as linhas verdes sólidas mostram as ligações VPN ponto a site primárias e as linhas amarelas pontilhadas mostram as ligações de cópia de segurança stand-by. O perfil global ponto a site da VWAN seleciona ligações primárias e de cópia de segurança com base no desempenho da rede. Veja Transferir um perfil global para clientes VPN de utilizador para obter mais informações sobre o perfil global.

Considerações de VPN site a site

Vamos considerar o exemplo de ligação VPN site a site apresentada no diagrama seguinte para o nosso debate. Para estabelecer uma ligação VPN site a site com túneis ativos-ativos de elevada disponibilidade, veja Tutorial: Criar uma ligação Site a Site com o Azure WAN Virtual.

Diagrama de ligação de um ramo no local à wan virtual através do V P N site a site.

Nota

Para compreender facilmente os conceitos abordados na secção, não estamos a repetir o debate sobre a funcionalidade de elevada disponibilidade do gateway de VPN site a site que lhe permite criar dois túneis para dois pontos finais diferentes para cada ligação VPN que configurar. No entanto, ao implementar qualquer uma das arquiteturas sugeridas na secção, lembre-se de configurar dois túneis para cada uma das ligações que estabelecer.

Para proteger contra falhas do Equipamento de Instalação do Cliente (CPE) da VPN num site de ramo, pode configurar ligações VPN paralelas para um gateway de VPN a partir de dispositivos CPE paralelos no site do ramo. Além de proteger contra falhas de rede de um fornecedor de serviços de última milha para a sucursal, pode configurar ligações VPN diferentes através de diferentes redes de fornecedores de serviços. O diagrama seguinte mostra várias ligações VPN provenientes de duas CPEs diferentes de um site de ramo terminando no mesmo gateway de VPN.

Diagrama de ligações site a site V P N redundantes a um site de ramo.

Pode configurar até quatro ligações para um site de ramo a partir de um gateway de VPN do hub virtual. Ao configurar uma ligação para um site de ramo, pode identificar o fornecedor de serviços e a velocidade de débito associada à ligação. Quando configura ligações paralelas entre um site de ramo e um hub virtual, o gateway de VPN, por predefinição, faria o balanceamento de carga do tráfego nas ligações paralelas. O balanceamento de carga do tráfego seria de acordo com Equal-Cost Multi-Path (ECMP) por fluxo.

A topologia de várias ligações protege contra falhas de dispositivos CPE e uma falha de rede do fornecedor de serviços na localização do ramo no local. Além disso, para proteger contra qualquer período de inatividade de um VPN-gateway de hub virtual, a topologia multi-hub multi-ligação ajudaria. O diagrama seguinte mostra a topologia, na qual vários hubs virtuais são configurados numa instância WAN Virtual numa região:

Diagrama de ligações V P N de site a site multilocais a um site de ramo.

Na topologia acima, uma vez que a latência intra-Azure-região sobre a ligação entre os hubs é insignificante, pode utilizar todas as ligações de VPN site a site entre o local e os dois hubs virtuais no estado ativo-ativo ao distribuir as VNets spoke pelos hubs. Na topologia, por predefinição, o tráfego entre o local e uma VNET spoke atravessaria diretamente através do hub virtual ao qual a VNET spoke está ligada durante o estado estável e utilizaria outro hub virtual como uma cópia de segurança apenas durante um estado de falha. O tráfego atravessaria o hub diretamente ligado no estado estável, uma vez que as rotas BGP anunciadas pelo hub diretamente ligado teriam um caminho AS mais curto em comparação com o hub de cópia de segurança.

A topologia multi-hub multi-link protegeria e forneceria continuidade de negócio contra a maioria dos cenários de falha. No entanto, se uma falha catastrófica derrubar toda a região do Azure, precisa de "topologia multi-região de várias ligações" para suportar a falha.

A topologia multi-ligação de várias regiões protege contra uma falha catastrófica de toda uma região, além das proteções oferecidas pela topologia multi-hub multi-ligações que abordámos anteriormente. O diagrama seguinte mostra a topologia de várias regiões com várias ligações. Os hubs virtuais em diferentes regiões podem ser configurados na mesma instância WAN Virtual.

Diagrama de ligações V P N de várias regiões a um site de ramo.

Do ponto de vista da engenharia de tráfego, tem de ter em consideração uma diferença substancial entre ter hubs redundantes numa região vs. ter o hub de cópia de segurança numa região diferente. A diferença é a latência resultante da distância física entre as regiões primária e secundária. Por conseguinte, poderá querer implementar os seus recursos de serviço de estado estável na região mais próxima do seu ramo/utilizadores finais e utilizar a região remota apenas para cópia de segurança.

Se as suas localizações de ramo no local estiverem distribuídas por duas ou mais regiões do Azure, a topologia de várias regiões de várias regiões será mais eficaz na distribuição da carga e na obtenção de uma melhor experiência de rede durante o estado estável. O diagrama seguinte mostra a topologia de várias regiões com ramos em diferentes regiões. Neste cenário, a topologia forneceria adicionalmente uma Recuperação Após Desastre de Continuidade de Negócio (BCDR) eficaz.

Diagrama de ligações V P N de várias regiões a vários ramos.

Considerações do ExpressRoute

As considerações de recuperação após desastre do peering privado do ExpressRoute são abordadas na estruturação da recuperação após desastre com o peering privado do ExpressRoute. Conforme indicado no artigo, os conceitos descritos nesse artigo aplicam-se igualmente aos gateways do ExpressRoute criados num hub virtual. A utilização de um hub virtual redundante na região, conforme mostrado no diagrama seguinte, é a única melhoria de topologia recomendada para considerações de rede pequenas a médias no local.

Diagrama da conectividade do Expresss Route multi-hub.

No diagrama acima, o ExpressRoute 2 é terminado num gateway do ExpressRoute separado dentro de um segundo hub virtual na região.

Passos seguintes

Neste artigo, abordámos WAN Virtual design de recuperação após desastre. Os artigos seguintes abordam a recuperação após desastre a partir de aplicações e perspetivas de acesso de front-end:

Para criar uma conectividade ponto a site para WAN Virtual, veja Tutorial: Criar uma ligação VPN de Utilizador com o Azure WAN Virtual. Para criar uma conectividade site a site para WAN Virtual veja Tutorial: Criar uma ligação Site a Site com o Azure WAN Virtual. Para associar um circuito do ExpressRoute a WAN Virtual, veja Tutorial: Criar uma associação do ExpressRoute com o Azure WAN Virtual.