Design de recuperação de desastre
A WAN Virtual permite agregar, conectar, gerenciar centralmente e proteger todas as suas implantações globais. Suas implantações globais podem incluir combinações de diferentes ramificações, PoPs (pontos de presença), usuários privados, escritórios, redes virtuais do Azure e outras implantações multinuvem. Você pode usar a SD-WAN, a VPN site a site, a VPN ponto a site e o ExpressRoute para conectar diferentes sites a um hub virtual. Se você tiver vários hubs virtuais, todos eles serão conectados à malha completa em uma implantação da WAN Virtual padrão.
Neste artigo, vamos ver como projetar diferentes tipos de conectividade de rede como serviço compatíveis com a WAN Virtual para recuperação de desastre.
Opções de conectividade de rede como serviço da WAN Virtual
A WAN Virtual dá suporte às seguintes opções de conectividade de back-end:
- Conectividade de usuário remoto
- VPN branch/Office/SD-WAN/Site a site
- Conectividade privada (emparelhamento privado do ExpressRoute)
Para cada uma dessas opções de conectividade, a WAN Virtual implanta um conjunto separado de instâncias de gateway em um hub virtual.
A WAN Virtual foi projetada para oferecer uma solução de agregação de rede de alta disponibilidade com nível de operadora. Para alta disponibilidade, a WAN Virtual cria várias instâncias quando cada um desses tipos de gateways é implantado em um hub da WAN Virtual. Para saber mais sobre a alta disponibilidade do ExpressRoute, confira Design para alta disponibilidade com o ExpressRoute.
Com o gateway de VPN ponto a site, o número mínimo de instâncias implantadas é dois. Com o gateway de VPN de ponto a site, você escolhe a capacidade de taxa de transferência agregada de gateways de ponto a site e várias instâncias são provisionadas automaticamente para você. Você escolhe a capacidade de agregação de acordo com o número de clientes ou usuários que pretende conectar ao hub virtual. Da perspectiva de conectividade do cliente, as instâncias do gateway de VPN ponto a site ficam ocultas por trás do FQDN (nome de domínio totalmente qualificado) do gateway.
Para o gateway de VPN site a site, duas instâncias do gateway são implantadas em um hub virtual. Cada instância do gateway é implantada com o próprio conjunto de endereços IP públicos e privados. A captura de tela a seguir mostra os endereços IP associados às duas instâncias de um exemplo de configuração de gateway de VPN site a site. Ou seja, as duas instâncias fornecem dois pontos de extremidade de túnel independentes para estabelecer a conectividade de VPN site a site de seus branches. Para maximizar a alta disponibilidade, consulte a seleção de caminho do Azure em vários links ISP.
Maximizar a alta disponibilidade da arquitetura de rede é um primeiro passo importante para a BCDR (continuidade dos negócios e recuperação de desastres). No restante deste artigo, conforme mencionado, vamos além da alta disponibilidade e abordaremos como projetar a rede de conectividade de sua WAN Virtual para BCDR.
Necessidade de design para recuperação de desastre
Desastres podem ocorrer a qualquer momento, em qualquer lugar. Eles podem ocorrer na rede ou em regiões do provedor de nuvem, em uma rede do provedor de serviços ou uma rede local. É difícil descartar o impacto regional de um serviço de nuvem ou de rede em decorrência de determinados fatores como calamidades naturais, erros humanos, guerras, terrorismo e configuração incorreta. Portanto, para ter continuidade de seus aplicativos comercialmente críticos, você precisa ter um design de recuperação de desastre. Para ter um design abrangente de recuperação de desastre, você precisa identificar todas as dependências que podem falhar em seu caminho de comunicação de ponta a ponta e criar uma redundância sem sobreposição para cada uma das dependências.
Quer esteja executando seus aplicativos críticos em uma região do Azure, localmente ou em qualquer outro lugar, você pode usar outra região do Azure como site de failover. Os seguintes artigos abordam a recuperação de desastre de aplicativos e perspectivas de acesso de front-end:
Desafios de usar a conectividade redundante
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, com a conectividade privada, você não terá nem entrará em contato com entidades com estado, como NAT ou firewalls. Portanto, o roteamento assimétrico com conectividade privada 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, terá um desempenho de rede inconsistente devido à diferença no caminho físico das conexões paralelas. Portanto, precisamos considerar o desempenho do tráfego de rede durante o estado constante (estado sem falha) e no estado de falha como parte do design de recuperação de desastre.
Redundância da rede de acesso
A maioria dos serviços de SD-WAN (soluções gerenciadas ou não) fornece conectividade de rede por meio de vários tipos de transporte (por exemplo, Internet de banda larga, MPLS, LTE). Para proteger contra falhas na rede de transporte, opte por ter conectividade em mais de uma rede de transporte. Para um cenário de usuário doméstico, você pode considerar o uso da rede móvel como backup para a conectividade de rede de banda larga.
Se a conectividade de rede em um tipo de transporte diferente não for possível, opte por ter conectividade de rede com mais de um provedor de serviços. Se você tem conectividade com mais de um provedor de serviços, verifique se os provedores de serviço mantêm redes de acesso independente não sobrepostas.
Considerações sobre conectividade de usuário remoto
A conectividade do usuário remoto é estabelecida usando a VPN ponto a site entre um dispositivo final e uma rede. Após uma falha de rede, o dispositivo final seria desconectado e tentaria restabelecer o túnel VPN. Portanto, para a VPN ponto a site, o design de recuperação de desastre deve ter o objetivo de minimizar o tempo de recuperação após uma falha. A redundância de rede a seguir ajudaria a minimizar o tempo de recuperação. Dependendo do quanto as conexões são críticas, você pode escolher algumas dessas opções ou todas elas.
- Redundância da rede de acesso (abordada acima).
- Gerenciar o hub virtual redundante para encerramento da VPN ponto a site. Quando você tem vários hubs virtuais com gateways de ponto a site, a VWAN fornece um perfil global listando todos os pontos de extremidade de ponto a site. Com o perfil global, seus dispositivos finais podem se conectar ao hub virtual mais próximo disponível que oferece o melhor desempenho de rede. Se todas as suas implantações do Azure estiverem em apenas uma região e os dispositivos finais que se conectam estiverem próximos a ela, você poderá ter hubs virtuais redundantes dentro dela. Se a implantação e os dispositivos finais estiverem distribuídos em várias regiões, você poderá implantar o hub virtual com o gateway de ponto a site em cada região selecionada. A WAN Virtual tem um gerenciador de tráfego interno que seleciona automaticamente o melhor hub para conectividade de usuário remoto.
O diagrama a seguir mostra o conceito de gerenciamento de um hub virtual redundante com o respectivo gateway de ponto a site dentro de uma região.
No diagrama acima, as linhas verdes sólidas mostram as conexões primárias da VPN ponto a site e as linhas amarelas pontilhadas mostram as conexões de backup em espera. O perfil global da VWAN ponto a site seleciona as conexões primárias e de backup com base no desempenho da rede. Confira Baixar um perfil global para clientes VPN do usuário para obter mais informações sobre o perfil global.
Considerações sobre a VPN site a site
Vamos considerar o exemplo da conexão de VPN site a site mostrada no diagrama a seguir para nossa discussão. Para estabelecer uma conexão de VPN site a site com túneis ativos-ativos de alta disponibilidade, consulte Tutorial: Criar uma conexão site a site usando a WAN Virtual do Azure.
Observação
Para facilitar a compreensão dos conceitos discutidos na seção, não estamos repetindo a discussão sobre o recurso de alta disponibilidade do gateway de VPN site a site que permite criar dois túneis para dois pontos de extremidade diferentes para cada link de VPN configurado. No entanto, ao implantar qualquer uma das arquiteturas sugeridas, lembre-se de configurar dois túneis para cada link que você estabelecer.
Topologia de múltiplos links
Para proteger contra falhas de CPE (Equipamento local do cliente) da VPN em um site de ramificação, você pode configurar links de VPN paralelos para um gateway de VPN de dispositivos de CPE paralelos no site da ramificação. Para proteger contra falhas de rede de um provedor de serviços próximo para a filial, você pode configurar links de VPN diferentes por meio da rede de um provedor de serviços diferente. O diagrama a seguir mostra vários links de VPN provenientes de dois CPEs diferentes de um site de ramificação e terminando no mesmo gateway de VPN.
Você pode configurar até quatro links para um site de ramificação de um gateway de VPN do hub virtual. Ao configurar um link para um site de ramificação, você pode identificar o provedor de serviços e a velocidade da taxa de transferência associada ao link. Quando você configura links paralelos entre um site de ramificação e um hub virtual, o gateway de VPN por padrão faz o balanceamento de carga do tráfego entre os links paralelos. O balanceamento de carga do tráfego seria feito de acordo com o ECMP (vários caminhos de mesmo custo), de acordo com o fluxo.
Topologia de vários links e vários hubs
A topologia de vários links protege contra falhas de dispositivo de CPE e falhas de rede do provedor de serviços na ramificação local. Além disso, a topologia de vários links e vários hubs ajudaria a proteger contra tempo de inatividade de um gateway de VPN do hub virtual. O diagrama a seguir mostra a topologia, na qual vários hubs virtuais são configurados em uma instância de WAN Virtual dentro de uma região:
Na topologia acima, como a latência dentro da região do Azure usando a conexão entre os hubs é insignificante, você pode usar todas as conexões de VPN site a site entre o local e os dois hubs virtuais no estado ativo-ativo distribuindo as VNets spoke entre os hubs. Na topologia, por padrão, o tráfego entre o local e uma VNET spoke atravessaria diretamente o hub virtual a que a VNET spoke está conectada durante o estado constante e usaria outro hub virtual como backup somente durante um estado de falha. O tráfego atravessaria o hub conectado diretamente no estado constante, pois as rotas BGP anunciadas pelo hub conectado diretamente teriam um caminho AS mais curto em comparação com o hub de backup.
A topologia de vários links e vários hubs protege e fornece continuidade de negócios contra a maioria dos cenários de falha. No entanto, se uma falha catastrófica afetar toda a região do Azure, você precisará de uma "topologia de vários links e várias regiões" para resistir à falha.
Topologia de vários links e várias regiões
A topologia de vários links e várias regiões protege até mesmo contra uma falha catastrófica em uma região inteira, além das proteções oferecidas pela topologia de vários links e vários hubs abordadas anteriormente. O diagrama a seguir mostra a topologia de vários links e várias regiões. Os hubs virtuais em diferentes regiões podem ser configurados na mesma instância WAN Virtual.
Do ponto de vista da engenharia de tráfego, você precisa levar em consideração a diferença significativa entre ter hubs redundantes em uma região e ter o hub de backup em uma região diferente. A diferença é a latência resultante da distância física entre as regiões primárias e secundárias. Portanto, talvez você queira implantar seus recursos de serviço de estado constante na região mais próxima dos usuários da ramificação/usuários finais e usar a região remota apenas para backup.
Se suas ramificações locais estiverem espalhadas em duas ou mais regiões do Azure, a topologia de vários links e várias regiões será mais eficiente para distribuir a carga e obter uma melhor experiência de rede durante o estado constante. O diagrama a seguir mostra a topologia de vários links e várias regiões com ramificações em regiões diferentes. Nesse cenário, a topologia também forneceria uma BCDR (continuidade dos negócios e recuperação de desastres) eficaz.
Considerações sobre o ExpressRoute
As considerações sobre recuperação de desastre com o emparelhamento privado do ExpressRoute são abordadas em Como projetar para recuperação de desastre com o emparelhamento privado do ExpressRoute. Conforme observado, os conceitos descritos nesse artigo se aplicam igualmente aos gateways do ExpressRoute criados em um hub virtual. Usar um hub virtual redundante dentro da região, conforme mostrado no diagrama a seguir, é o único aprimoramento de topologia recomendado em Considerações sobre redes locais pequenas a médias.
No diagrama acima, o ExpressRoute 2 termina em um gateway do ExpressRoute separado dentro de um segundo hub virtual na região.
Próximas etapas
Neste artigo, tratamos do design de recuperação de desastre para a WAN Virtual. Os seguintes artigos abordam a recuperação de desastre de aplicativos e perspectivas de acesso de front-end:
Para criar uma conexão ponto a site com a WAN Virtual, confira Tutorial: Criar uma conexão de VPN do Usuário usando a WAN Virtual do Azure. Para criar uma conexão site a site com a WAN Virtual, confira Tutorial: Criar uma conexão site a site usando a WAN Virtual do Azure. Para associar um circuito do ExpressRoute à WAN Virtual, confira Tutorial: Criar uma associação do ExpressRoute usando a WAN Virtual do Azure.