Compartilhar via


Considerações de rede para Solução VMware no Azure implantações de região dupla

Este artigo descreve como configurar a conectividade de rede quando Solução VMware no Azure nuvens privadas são implantadas em duas regiões do Azure para fins de resiliência de desastre. Se houver interrupções regionais parciais ou completas, a topologia de rede neste artigo permitirá que os componentes sobreviventes (nuvens privadas, recursos nativos do Azure e sites locais) mantenham a conectividade entre si e com a Internet.

Cenário de região dupla

Este artigo se concentra em um cenário típico de região dupla, mostrado na figura 1 a seguir:

  • Existe uma rede hub e spoke do Azure em cada região.
  • Uma configuração resiliente a desastres para o ExpressRoute (dois circuitos em dois locais de emparelhamento diferentes, com cada circuito conectado a redes virtuais de hub em ambas as regiões) foi implantada. As diretrizes fornecidas nas seções a seguir permanecem as mesmas caso a conectividade VPN de fall-back seja configurada.
  • Uma nuvem privada Solução VMware no Azure foi implantada em cada região.

Diagrama da Figura 1, que mostra o cenário de região dupla abordado neste artigo.

Observação

No cenário de referência da Figura 1, as duas redes virtuais de hub regional são conectadas por meio do emparelhamento VNet global. Embora não seja estritamente necessário, como o tráfego entre redes virtuais do Azure nas duas regiões pode ser roteado por conexões do ExpressRoute, é altamente recomendável essa configuração. O emparelhamento VNet minimiza a latência e maximiza a taxa de transferência, pois remove a necessidade de direcionar o tráfego por meio dos roteadores de borda meet-me do ExpressRoute.

Padrões de comunicação de região dupla

As próximas seções descrevem a configuração de rede Solução VMware no Azure necessária para habilitar, no cenário de referência de região dupla, os seguintes padrões de comunicação:

Solução VMware no Azure conectividade entre regiões

Quando existem várias nuvens privadas Solução VMware no Azure, a conectividade de Camada 3 entre elas geralmente é um requisito para tarefas como dar suporte à replicação de dados.

Solução VMware no Azure nativamente dá suporte à conectividade direta entre duas nuvens privadas implantadas em diferentes regiões do Azure. As nuvens privadas se conectam à rede do Azure em sua própria região por meio de circuitos do ExpressRoute, gerenciados pela plataforma e encerrados em locais dedicados do ExpressRoute meet-me. Ao longo deste artigo, esses circuitos são chamados de circuitos gerenciados Solução VMware no Azure. Solução VMware no Azure circuitos gerenciados não devem ser confundidos com os circuitos normais que os clientes implantam para conectar seus sites locais ao Azure. Os circuitos normais implantados pelos clientes são circuitos gerenciados pelo cliente (consulte a Figura 2).

A conectividade direta entre nuvens privadas baseia-se em conexões de Alcance Global do ExpressRoute entre Solução VMware no Azure circuitos gerenciados, conforme mostrado pela linha verde no diagrama a seguir. Para obter mais informações, consulte Tutorial: Emparelhar ambientes locais para Solução VMware no Azure. O artigo descreve o procedimento para conectar um circuito gerenciado Solução VMware no Azure com um circuito gerenciado pelo cliente. O mesmo procedimento se aplica à conexão de dois circuitos gerenciados Solução VMware no Azure.

Diagrama da Figura 2, que mostra nuvens privadas em diferentes regiões conectadas em uma conexão de Alcance Global entre circuitos gerenciados do ExpressRoute.

Conectividade híbrida

A opção recomendada para conectar Solução VMware no Azure nuvens privadas a sites locais é o Alcance Global do ExpressRoute. As conexões de Alcance Global podem ser estabelecidas entre circuitos do ExpressRoute gerenciados pelo cliente e Solução VMware no Azure circuitos do ExpressRoute gerenciados. As conexões de Alcance Global não são transitivas, portanto, uma malha completa (cada Solução VMware no Azure circuito gerenciado conectado a cada circuito gerenciado pelo cliente) é necessária para resiliência de desastre, conforme mostrado na Figura 3 a seguir (representada por linhas laranjas).

Diagrama da Figura 3, que mostra as conexões de Alcance Global conectando circuitos do ExpressRoute gerenciados pelo cliente e circuitos do ExpressRoute da Solução VMware.

Conectividade da Rede Virtual do Azure

Os Rede Virtual do Azure podem ser conectados a nuvens privadas Solução VMware no Azure por meio de conexões entre gateways do ExpressRoute e circuitos gerenciados Solução VMware no Azure. Essa conexão é exatamente a mesma maneira que o Azure Rede Virtual pode ser conectado a sites locais em circuitos do ExpressRoute gerenciados pelo cliente. Consulte Conectar-se à nuvem privada manualmente para obter instruções de configuração.

Em cenários de região dupla, recomendamos uma malha completa para as conexões do ExpressRoute entre os dois hubs regionais Rede Virtual e nuvens privadas, conforme mostrado na Figura 4 (representada por linhas amarelas).

Diagrama da Figura 4, que mostra que os recursos nativos do Azure em cada região têm conectividade L3 direta com Solução VMware no Azure nuvens privadas.

Conectividade com a Internet

Ao implantar Solução VMware no Azure nuvens privadas em várias regiões, recomendamos opções nativas para conectividade com a Internet (SNAT (conversão de endereço de rede de origem gerenciada) ou IPs públicos até o NSX-T). Qualquer opção pode ser configurada por meio do portal do Azure (ou por meio de modelos do PowerShell, CLI ou ARM/Bicep) no momento da implantação, conforme mostrado na Figura 5 a seguir.

Diagrama da Figura 5, que mostra as opções nativas Solução VMware no Azure para conectividade com a Internet no portal do Azure.

Ambas as opções realçadas na Figura 5 fornecem a cada nuvem privada uma fuga direta da Internet em sua própria região. As seguintes considerações devem informar a decisão sobre qual opção de conectividade de Internet nativa usar:

  • O SNAT gerenciado deve ser usado em cenários com requisitos básicos e somente de saída (volumes baixos de conexões de saída e sem necessidade de controle granular sobre o pool de SNAT).
  • Os IPs públicos até a borda NSX-T devem ser preferenciais em cenários com grandes volumes de conexões de saída ou quando você precisar de controle granular sobre endereços IP NAT. Por exemplo, quais Solução VMware no Azure VMs usam SNAT por trás dos endereços IP. Os IPs públicos até a borda NSX-T também dão suporte à conectividade de entrada por meio do DNAT. A conectividade com a Internet de entrada não é abordada neste artigo.

Alterar a configuração de conectividade com a Internet de uma nuvem privada após a implantação inicial é possível. Mas a nuvem privada perde a conectividade com a Internet, o Azure Rede Virtual e sites locais enquanto a configuração está sendo atualizada. Quando uma das opções nativas de conectividade com a Internet na Figura 5 anterior é usada, nenhuma configuração extra é necessária em cenários de região dupla (a topologia permanece a mesma mostrada na Figura 4). Para obter mais informações sobre conectividade com a Internet para Solução VMware no Azure, consulte Considerações sobre design de conectividade com a Internet.

Fuga de internet nativa do Azure

Se uma borda de Internet segura foi criada no Azure Rede Virtual antes de Solução VMware no Azure adoção, talvez seja necessário usá-la para acesso à Internet para Solução VMware no Azure nuvens privadas. O uso de uma borda segura da Internet dessa forma é necessário para o gerenciamento centralizado de políticas de segurança de rede, otimização de custos e muito mais. As bordas de segurança da Internet no Azure Rede Virtual podem ser implementadas usando Firewall do Azure ou NVAs (soluções de virtualização de rede proxy) de terceiros disponíveis no Azure Marketplace.

O tráfego vinculado à Internet emitido por máquinas virtuais Solução VMware no Azure pode ser atraído para uma VNet do Azure originando uma rota padrão e anunciando-a, por protocolo BGP (gateway de borda), para o circuito do ExpressRoute gerenciado da nuvem privada. Essa opção de conectividade com a Internet pode ser configurada por meio do portal do Azure (ou por meio de modelos do PowerShell, CLI ou ARM/Bicep) no momento da implantação, conforme mostrado na Figura 6 a seguir. Para obter mais informações, consulte Desabilitar o acesso à Internet ou habilitar uma rota padrão.

Diagrama da Figura 6, que mostra a configuração de Solução VMware no Azure para habilitar a conectividade com a Internet por meio de bordas da Internet no Azure Rede Virtual.

Os NVAs de borda da Internet podem originar a rota padrão se oferecerem suporte a BGP. Caso contrário, você deve implantar outros NVAs compatíveis com BGP. Para obter mais informações sobre como implementar a conectividade de saída da Internet para Solução VMware no Azure em uma única região, consulte Implementando a conectividade com a Internet para Solução VMware no Azure com NVAs do Azure. No cenário de região dupla discutido neste artigo, a mesma configuração deve ser aplicada a ambas as regiões.

A principal consideração em cenários de região dupla é que a rota padrão originada em cada região deve ser propagada pelo ExpressRoute apenas para a nuvem privada Solução VMware no Azure na mesma região. Essa propagação permite que Solução VMware no Azure cargas de trabalho acessem a Internet por meio de um breakout local (na região). No entanto, se você usar a topologia mostrada na Figura 4, cada Solução VMware no Azure nuvem privada também receberá uma rota padrão de custo igual da região remota nas conexões do ExpressRoute entre regiões. As linhas tracejadas vermelhas representam essa propagação de rota padrão de região cruzada indesejada na Figura 7.

Diagrama da Figura 7, que mostra as conexões entre regiões entre gateways do ExpressRoute e circuitos do ExpressRoute gerenciados pela Solução VMware, deve ser removido.

Remover o Solução VMware no Azure conexões do ExpressRoute entre regiões atinge a meta de injetar, em cada nuvem privada, uma rota padrão para encaminhar conexões associadas à Internet para a borda da Internet do Azure na região local.

Deve-se observar que, se as conexões do ExpressRoute entre regiões (linhas tracejadas vermelhas na Figura 7) forem removidas, a propagação entre regiões da rota padrão ainda ocorrerá no Alcance Global. No entanto, as rotas propagadas pelo Alcance Global têm um caminho as mais longo do que os originados localmente e são descartados pelo processo de seleção de rota BGP.

A propagação entre regiões sobre o Alcance Global de uma rota padrão menos preferencial fornece resiliência contra falhas da borda da Internet local. Se a borda da Internet de uma região ficar offline, ela deixará de originar a rota padrão. Nesse caso, a rota padrão menos preferencial aprendida com a região remota é instalada na nuvem privada Solução VMware no Azure, de modo que o tráfego associado à Internet seja roteado por meio da fuga da região remota.

A topologia recomendada para implantações de região dupla com intervalos de Internet em VNets do Azure é mostrada na Figura 8 a seguir.

Diagrama da Figura 8, que mostra a topologia recomendada para implantações de região dupla com acesso de saída à Internet por meio de bordas da Internet.

Quando você origina rotas padrão no Azure, é necessário ter cuidado especial para evitar a propagação para sites locais, a menos que haja um requisito para fornecer acesso à Internet a sites locais por meio de uma borda da Internet no Azure. Os dispositivos operados pelo cliente que encerram os circuitos do ExpressRoute gerenciados pelo cliente devem ser configurados para filtrar as rotas padrão recebidas do Azure, conforme mostrado na Figura 9. Essa configuração é necessária para evitar interromper o acesso à Internet para os sites locais.

Diagrama da Figura 9, que mostra os alto-falantes BGP que encerram os circuitos do ExpressRoute gerenciados pelo cliente estão filtrando as rotas padrão dos NVAs do Azure.

Próximas etapas