Projeto de recuperação de desastres
A WAN virtual permite agregar, conectar, gerenciar centralmente e proteger todas as suas implantações globais. Suas implantações globais podem incluir qualquer combinação de diferentes ramificações, Ponto de Presença (PoP), usuários particulares, escritórios, redes virtuais do Azure e outras implantações multinuvem. Você pode usar SD-WAN, VPN site a site, VPN ponto a site e ExpressRoute para conectar seus diferentes sites a um hub virtual. Se você tiver vários hubs virtuais, todos os hubs serão conectados em malha completa em uma implantação padrão de WAN Virtual.
Neste artigo, vamos analisar como arquitetar diferentes tipos de opções de conectividade de rede como serviço que a WAN Virtual suporta para recuperação de desastres.
Opções de conectividade de rede como serviço da WAN Virtual
A WAN Virtual suporta as seguintes opções de conectividade de back-end:
- Conectividade de usuário remoto
- Filial/Escritório/SD-WAN/VPN site a site
- Conectividade privada (emparelhamento privado 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.
Inerentemente, a Virtual WAN foi projetada para oferecer uma solução de agregação de rede de alta disponibilidade de nível de operadora. Para alta disponibilidade, a WAN Virtual instancia várias instâncias quando cada um desses diferentes tipos de gateways é implantado em um hub WAN Virtual. Para saber mais sobre a alta disponibilidade da Rota Expressa, consulte Projetando para alta disponibilidade com a Rota Expressa.
Com o gateway VPN ponto a site, o número mínimo de instâncias implantadas é dois. Com o gateway VPN ponto a site, você escolhe a capacidade de taxa de transferência agregada dos gateways ponto a site e várias instâncias são provisionadas automaticamente para você. Você escolhe a capacidade agregada de acordo com o número de clientes ou usuários que pretende conectar ao hub virtual. Do ponto de vista da conectividade do cliente, as instâncias do gateway VPN ponto a site estão ocultas atrás do FQDN (Nome de Domínio Totalmente Qualificado) do gateway.
Para o gateway VPN site a site, duas instâncias do gateway são implantadas em um hub virtual. Cada instância do gateway é implantada com seu próprio conjunto de endereços IP públicos e privados. As duas instâncias fornecem dois pontos de extremidade de túnel independentes para estabelecer conectividade VPN site a site de suas filiais. Para maximizar a alta disponibilidade, consulte Seleção de caminho do Azure em vários links de ISP.
Maximizar a alta disponibilidade de sua arquitetura de rede é um primeiro passo fundamental para a continuidade de negócios e recuperação de desastres (BCDR). No restante deste artigo, como dito anteriormente, vamos além da alta disponibilidade e discutir como arquitetar sua rede de conectividade WAN Virtual para BCDR.
Necessidade de projeto de recuperação de desastres
O desastre pode ocorrer a qualquer momento, em qualquer lugar. O desastre pode ocorrer em uma região ou rede de provedor de nuvem, em uma rede de provedor de serviços ou em uma rede local. O impacto regional de uma nuvem ou serviço de rede devido a certos fatores, como calamidade natural, erros humanos, guerra, terrorismo, configuração incorreta são difíceis de descartar. Portanto, para a continuidade de seus aplicativos críticos para os negócios, você precisa ter um projeto de recuperação de desastres. Para um projeto abrangente de recuperação de desastres, você precisa identificar todas as dependências que podem falhar em seu caminho de comunicação de ponta a ponta e criar redundância não sobreposta para cada uma das dependências.
Independentemente de executar seus aplicativos de missão crítica em uma região do Azure, 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:
Desafios do uso de conectividade redundante
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, NAT, firewall) no caminho, o roteamento assimétrico poderá bloquear o fluxo de tráfego. Normalmente, através da conectividade privada, você não terá ou se deparará com entidades com monitoração de estado, como NAT ou Firewalls. Portanto, o roteamento assimétrico sobre 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, o desempenho da rede será 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 estacionário (estado sem falha) e um estado de falha como parte de nosso projeto de recuperação de desastres.
Redundância de rede de acesso
A maioria dos serviços SD-WAN (soluções gerenciadas ou não) fornecem conectividade de rede através de vários tipos de transporte (por exemplo, banda larga da Internet, MPLS, LTE). Para se proteger contra falhas na rede de transporte, escolha a 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 conectividade de rede de banda larga.
Se a conectividade de rede em diferentes tipos de transporte não for possível, escolha a conectividade de rede por meio de mais de um provedor de serviços. Se você estiver obtendo conectividade por meio de mais de um provedor de serviços, certifique-se de que os provedores de serviços mantenham redes de acesso independentes não sobrepostas.
Considerações sobre conectividade de usuário remoto
A conectividade de usuário remoto é estabelecida usando VPN ponto a site entre um dispositivo final e uma rede. Após uma falha de rede, o dispositivo final cairia e tentaria restabelecer o túnel VPN. Portanto, para VPN ponto a site, seu design de recuperação de desastres deve ter como objetivo 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 de quão críticas são as conexões, você pode escolher algumas ou todas essas opções.
- Redundância de rede de acesso (discutido acima).
- Gerenciamento de hub virtual redundante para terminação de VPN ponto a site. Quando você tem vários hubs virtuais com gateways ponto-a-site, a VWAN fornece perfil global listando todos os pontos de extremidade ponto a site. Com o perfil global, seus dispositivos finais podem se conectar ao hub virtual disponível mais próximo que oferece o melhor desempenho de rede. Se todas as suas implantações do Azure estiverem em uma única região e os dispositivos finais que se conectam estiverem próximos à região, você poderá ter hubs virtuais redundantes dentro da região. Se a implantação e os dispositivos finais estiverem espalhados por várias regiões, você poderá implantar o hub virtual com gateway ponto a site em cada uma das regiões selecionadas. A WAN virtual tem um gerenciador de tráfego integrado que seleciona automaticamente o melhor hub para conectividade de usuário remoto.
O diagrama a seguir mostra o conceito de gerenciamento de hub virtual redundante com seu respetivo gateway ponto a site dentro de uma região.
No diagrama acima, as linhas verdes sólidas mostram as principais conexões VPN ponto a site e as linhas amarelas pontilhadas mostram as conexões de backup em stand-by. O perfil global ponto a site da VWAN seleciona conexões primárias e de backup com base no desempenho da rede. Consulte Baixar um perfil global para clientes VPN de usuário para obter mais informações sobre o perfil global.
Considerações sobre VPN site a site
Vamos considerar o exemplo de conexão VPN site a site mostrado no diagrama a seguir para nossa discussão. Para estabelecer uma conexão 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.
Nota
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 VPN site a site que permite criar dois túneis para dois pontos de extremidade diferentes para cada link VPN configurado. No entanto, ao implantar qualquer uma das arquiteturas sugeridas na seção, lembre-se de configurar dois túneis para cada um dos links estabelecidos.
Topologia multilink
Para proteger contra falhas de CPE (Customer Premises Equipment) VPN em um site de filial, você pode configurar links VPN paralelos para um gateway VPN a partir de dispositivos CPE paralelos no site da filial. Além disso, para proteger contra falhas de rede de um provedor de serviços de última milha para a filial, você pode configurar diferentes links VPN em diferentes redes de provedores de serviços. O diagrama a seguir mostra vários links VPN originários de dois CPEs diferentes de um site de filial terminando no mesmo gateway VPN.
Você pode configurar até quatro links para um site de filial a partir de um gateway VPN de hub virtual. Ao configurar um link para um site de filial, você pode identificar o provedor de serviços e a velocidade de taxa de transferência associada ao link. Quando você configura links paralelos entre um site de filial e um hub virtual, o gateway VPN por padrão equilibraria a carga do tráfego entre os links paralelos. O balanceamento de carga do tráfego seria de acordo com o ECMP (Equal-Cost Multi-Path) por fluxo.
Topologia multi-hub multi-link
A topologia multilink protege contra falhas de dispositivo CPE e uma falha de rede do provedor de serviços no local da filial local. Além disso, para proteger contra qualquer tempo de inatividade de um gateway VPN de hub virtual, a topologia multilink multi-hub ajudaria. 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 intrarregião do Azure sobre a conexão entre os hubs é insignificante, você pode usar todas as conexões VPN site a site entre os hubs locais e os dois virtuais em estado ativo-ativo espalhando as VNets spoke pelos hubs. Na topologia, por padrão, o tráfego entre uma rede virtual local e uma rede virtual spoke atravessaria diretamente o hub virtual ao qual a rede virtual spoke está conectada durante o estado estacionário e usaria outro hub virtual como backup somente durante um estado de falha. O tráfego atravessaria o hub diretamente conectado no estado estacionário, porque as rotas BGP anunciadas pelo hub diretamente conectado teriam um caminho AS mais curto em comparação com o hub de backup.
A topologia multilink multihub protegeria e forneceria continuidade de negócios contra a maioria dos cenários de falha. No entanto, se uma falha catastrófica derrubar toda a região do Azure, você precisará de "topologia multilink multirregião" para resistir à falha.
Topologia multi-região multi-link
A topologia multilink multi-região protege contra até mesmo uma falha catastrófica de uma região inteira, além das proteções oferecidas pela topologia multi-hub multi-link que discutimos anteriormente. O diagrama a seguir mostra a topologia multilink de várias regiões. Os hubs virtuais em diferentes regiões podem ser configurados na mesma instância de WAN Virtual.
Do ponto de vista da engenharia de tráfego, você precisa levar em consideração uma diferença substancial entre ter hubs redundantes em uma região versus 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ária e secundária. Portanto, convém implantar seus recursos de serviço de estado estacionário na região mais próxima de sua filial/usuários finais e usar a região remota exclusivamente para backup.
Se os locais das filiais locais estiverem espalhados por duas ou mais regiões do Azure, a topologia multilink 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 estacionário. O diagrama a seguir mostra a topologia multi-região multi-link com ramificações em diferentes regiões. Nesse cenário, a topologia também forneceria BCDR (Business Continuity Disaster Recovery) eficaz.
Considerações sobre a Rota Expressa
As considerações sobre recuperação de desastres para emparelhamento privado da Rota Expressa são discutidas em Projetando para recuperação de desastres com emparelhamento privado da Rota Expressa. Conforme observado no artigo, os conceitos descritos nesse artigo se aplicam igualmente aos gateways de Rota Expressa criados dentro de um hub virtual. O uso de um hub virtual redundante na região, conforme mostrado no diagrama a seguir, é o único aprimoramento de topologia recomendado para considerações de rede local pequena a média.
No diagrama acima, a Rota Expressa 2 é encerrada em um gateway de Rota Expressa separado dentro de um segundo hub virtual dentro da região.
Próximos passos
Neste artigo, discutimos sobre o design de recuperação de desastres da WAN Virtual. Os artigos a seguir abordam a recuperação de desastres de aplicativos e perspetivas de acesso frontend:
Para criar uma conectividade ponto a site com a WAN Virtual, consulte Tutorial: Criar uma conexão VPN de usuário usando a WAN Virtual do Azure. Para criar uma conectividade site a site com a WAN Virtual, consulte Tutorial: Criar uma conexão site a site usando a WAN Virtual do Azure. Para associar um circuito de Rota Expressa à WAN Virtual, consulte Tutorial: Criar uma associação de Rota Expressa usando a WAN Virtual do Azure.