Partilhar via

Considerações de rede para Azure VMware Solution implementações de duas regiões

  • Artigo

Este artigo descreve como configurar a conectividade de rede quando Azure VMware Solution clouds privadas são implementadas em duas regiões do Azure para fins de resiliência após desastre. Se existirem interrupções regionais parciais ou completas, a topologia de rede neste artigo permite que os componentes sobreviventes (clouds privadas, recursos nativos do Azure e sites no local) mantenham a conectividade entre si e com a Internet.

Cenário de duas regiões

Este artigo centra-se num cenário típico de duas regiões, apresentado na seguinte Figura 1:

  • Existe uma rede hub-and-spoke do Azure em cada região.
  • Foi implementada uma configuração resiliente a desastres para o ExpressRoute (dois circuitos em duas localizações de peering diferentes, com cada circuito ligado a redes virtuais hub em ambas as regiões). A documentação de orientação fornecida nas secções seguintes permanece a mesma caso a conectividade VPN inativa esteja configurada.
  • Foi implementada uma Azure VMware Solution cloud privada em cada região.

Diagrama da Figura 1, que mostra o cenário de duas regiões abrangido neste artigo.

Nota

No cenário de referência da Figura 1, as duas redes virtuais do hub regional estão ligadas através do VNet Peering global. Embora não seja estritamente necessário, uma vez que o tráfego entre redes virtuais do Azure nas duas regiões poderia ser encaminhado através de ligações do ExpressRoute, recomendamos vivamente esta configuração. O VNet Peering minimiza a latência e maximiza o débito, uma vez que remove a necessidade de colocar o tráfego de gancho de cabelo através dos routers de extremidade meet-me do ExpressRoute.

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

As secções seguintes descrevem a configuração de rede Azure VMware Solution necessária para ativar, no cenário de referência de duas regiões, os seguintes padrões de comunicação:

Azure VMware Solution conectividade entre regiões

Quando existem várias Azure VMware Solution clouds privadas, a conectividade da Camada 3 entre elas é, muitas vezes, um requisito para tarefas como suportar a replicação de dados.

Azure VMware Solution suporta nativamente a conectividade direta entre duas clouds privadas implementadas em diferentes regiões do Azure. As clouds privadas ligam-se à rede do Azure na sua própria região através de circuitos do ExpressRoute, geridas pela plataforma e terminadas em localizações dedicadas do ExpressRoute meet-me. Ao longo deste artigo, estes circuitos são referidos como Azure VMware Solution circuitos geridos. Azure VMware Solution circuitos geridos não devem ser confundidos com os circuitos normais que os clientes implementam para ligar os respetivos sites no local ao Azure. Os circuitos normais que os clientes implementam são circuitos geridos pelo cliente (veja Figura 2).

A conectividade direta entre clouds privadas baseia-se nas ligações do Alcance Global do ExpressRoute entre Azure VMware Solution circuitos geridos, conforme mostrado pela linha verde no diagrama seguinte. Para obter mais informações, veja Tutorial: Peer on-premises environments to Azure VMware Solution (Tutorial: Peer on-premises environments to Azure VMware Solution). O artigo descreve o procedimento para ligar um circuito gerido Azure VMware Solution com um circuito gerido pelo cliente. O mesmo procedimento aplica-se à ligação de dois circuitos geridos Azure VMware Solution.

Diagrama da Figura 2, que mostra nuvens privadas em diferentes regiões ligadas através de uma ligação de Alcance Global entre circuitos do ExpressRoute geridos.

Conectividade híbrida

A opção recomendada para ligar Azure VMware Solution clouds privadas a sites no local é o Alcance Global do ExpressRoute. As ligações de Alcance Global podem ser estabelecidas entre circuitos do ExpressRoute geridos pelo cliente e Azure VMware Solution circuitos do ExpressRoute geridos. As ligações de Alcance Global não são transitivas, pelo que é necessária uma malha completa (cada Azure VMware Solution circuito gerido ligado a cada circuito gerido pelo cliente) para resiliência após desastre, conforme mostrado na seguinte Figura 3 (representada por linhas laranja).

Diagrama da Figura 3, que mostra ligações de Alcance Global que ligam circuitos do ExpressRoute geridos pelo cliente e circuitos expressRoute da Solução VMware.

Conectividade do Azure Rede Virtual

O Azure Rede Virtual pode ser ligado a Azure VMware Solution clouds privadas através de ligações entre Gateways do ExpressRoute e circuitos geridos Azure VMware Solution. Esta ligação é exatamente a mesma forma que o Azure Rede Virtual pode ser ligado a sites no local através de circuitos do ExpressRoute geridos pelo cliente. Consulte Ligar à nuvem privada manualmente para obter instruções de configuração.

Em cenários de duas regiões, recomendamos uma malha completa para as ligaçõ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 para Azure VMware Solution clouds privadas.

Conectividade Internet

Ao implementar Azure VMware Solution clouds privadas em várias regiões, recomendamos opções nativas para a conectividade à Internet (tradução de endereços de rede de origem gerida (SNAT) ou IPs públicos até ao NSX-T). Qualquer uma das opções pode ser configurada através do portal do Azure (ou através de modelos do PowerShell, CLI ou ARM/Bicep) no momento da implementação, conforme mostrado na seguinte Figura 5.

Diagrama da Figura 5, que mostra as opções nativas Azure VMware Solution para a conectividade à Internet no portal do Azure.

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

  • O SNAT gerido deve ser utilizado em cenários com requisitos básicos e apenas de saída (volumes baixos de ligações de saída e sem necessidade de controlo granular sobre o conjunto SNAT).
  • Os IPs públicos até à margem NSX-T devem ser preferidos em cenários com grandes volumes de ligações de saída ou quando necessita de controlo granular sobre endereços IP NAT. Por exemplo, que Azure VMware Solution VMs utilizam SNAT por trás dos endereços IP. Os IPs públicos até à margem NSX-T também suportam conectividade de entrada através do DNAT. A conectividade à Internet de entrada não está abrangida neste artigo.

Alterar a configuração de conectividade à Internet de uma cloud privada após a implementação inicial ser possível. Mas a cloud privada perde a conectividade à Internet, ao Azure Rede Virtual e aos sites no local enquanto a configuração está a ser atualizada. Quando uma das opções de conectividade à Internet nativa na Figura 5 anterior é utilizada, não é necessária qualquer configuração adicional em cenários de região dupla (a topologia permanece igual à mostrada na Figura 4). Para obter mais informações sobre a conectividade à Internet para Azure VMware Solution, veja Considerações de conceção da conectividade à Internet.

Fuga na Internet nativa do Azure

Se uma margem de Internet segura tiver sido criada no Azure Rede Virtual antes da Azure VMware Solution adoção, poderá ser necessário utilizá-la para acesso à Internet para Azure VMware Solution clouds privadas. Desta forma, é necessário utilizar uma margem de Internet segura para a gestão centralizada de políticas de segurança de rede, otimização de custos e muito mais. As margens de segurança da Internet no Azure Rede Virtual podem ser implementadas com Azure Firewall ou firewall de terceiros e aplicações virtuais de rede proxy (NVAs) disponíveis no Azure Marketplace.

O tráfego vinculado à Internet emitido por Azure VMware Solution máquinas virtuais pode ser atraído para uma VNet do Azure ao originar uma rota predefinida e ao anunciá-lo, através do protocolo BGP (Border Gateway Protocol), para o circuito do ExpressRoute gerido pela cloud privada. Esta opção de conectividade à Internet pode ser configurada através do portal do Azure (ou através de modelos do PowerShell, CLI ou ARM/Bicep) no momento da implementação, conforme mostrado na seguinte Figura 6. Para obter mais informações, veja Desativar o acesso à Internet ou ativar uma rota predefinida.

Diagrama da Figura 6, que mostra a configuração do Azure VMware Solution para ativar a conectividade à Internet através das margens da Internet no Azure Rede Virtual.

As NVAs de internet edge podem originar a rota predefinida se suportarem BGP. Caso contrário, tem de implementar outras NVAs compatíveis com BGP. Para obter mais informações sobre como implementar a conectividade de saída da Internet para Azure VMware Solution numa única região, veja Implementar a conectividade à Internet para Azure VMware Solution com as NVAs do Azure. No cenário de duas regiões abordado neste artigo, a mesma configuração tem de ser aplicada a ambas as regiões.

A principal consideração em cenários de duas regiões é que a rota predefinida originada em cada região deve ser propagada apenas através do ExpressRoute para o Azure VMware Solution cloud privada na mesma região. Esta propagação permite que Azure VMware Solution cargas de trabalho acedam à Internet através de uma fuga local (na região). No entanto, se utilizar a topologia apresentada na Figura 4, cada Azure VMware Solution cloud privada também recebe uma rota predefinida de custo igual da região remota através das ligações expressRoute entre regiões. As linhas tracejadas vermelhas representam esta propagação da rota predefinida entre regiões indesejada na Figura 7.

O diagrama da Figura 7, que mostra as ligações entre regiões entre os Gateways do ExpressRoute e os circuitos do ExpressRoute geridos pela Solução VMware, tem de ser removido.

Remover as Azure VMware Solution ligações do ExpressRoute entre regiões alcança o objetivo de injetar, em cada nuvem privada, uma rota predefinida para reencaminhar ligações vinculadas à Internet do Azure na região local.

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

A propagação entre regiões através do Alcance Global de uma rota predefinida menos preferencial proporciona resiliência contra falhas do limite da Internet local. Se o limite da Internet de uma região ficar offline, deixa de originar a rota predefinida. Nesse caso, a rota predefinida menos preferencial aprendida com a região remota é instalada na Azure VMware Solution cloud privada, para que o tráfego ligado à Internet seja encaminhado através da fuga da região remota.

A topologia recomendada para implementações de duas regiões com fugas de Internet nas VNets do Azure é apresentada na seguinte Figura 8.

Diagrama da Figura 8, que mostra a topologia recomendada para implementações de duas regiões com acesso de saída da Internet através das margens da Internet.

Quando origina rotas predefinidas no Azure, tem de ter especial cuidado para evitar a propagação para sites no local, a menos que exista um requisito para fornecer acesso à Internet a sites no local através de uma periferia da Internet no Azure. Os dispositivos operados pelo cliente que terminam os circuitos do ExpressRoute geridos pelo cliente têm de ser configurados para filtrar as rotas predefinidas recebidas do Azure, conforme mostrado na Figura 9. Esta configuração é necessária para evitar interromper o acesso à Internet para os sites no local.

Diagrama da Figura 9, que mostra que os altifalantes BGP que terminam os circuitos do ExpressRoute geridos pelo cliente estão a filtrar as rotas predefinidas das NVAs do Azure.

Passos seguintes