Sobreposição do NSX e roteamento de borda

A solução da VMware no Google Cloud usa o VMware NSX para fornecer rede definida por software (SDN) e segurança para as máquinas virtuais (VMs) de carga de trabalho do VMware Cloud Foundation (VCF). Neste documento, descrevemos como a rede de sobreposição do NSX interage com o Google Cloud underlay da nuvem privada virtual (VPC) e comparamos as arquiteturas de roteamento entre os nós do NSX Edge e sua rede VPC.

Visão geral do NSX no Google Cloud

Na solução VMware, a rede VPC do Google Cloud fornece o underlay físico e virtualizado para os hosts ESXi bare metal (instâncias Compute Engine z3-highmem-192-highlssd-metal) e dispositivos de gerenciamento. O VMware NSX fica sobre essa base para fornecer uma topologia de rede abstrata para as VMs de carga de trabalho do VCF:

  • Encapsulamento de sobreposição Geneve: os hosts ESXi e os nós de borda NSX estabelecem interfaces de endpoint de transporte (TEP, na sigla em inglês) (vmk10 ou vmk3) na sub-rede VPC NSX-TEP dedicada. O tráfego da VM de carga de trabalho é encapsulado em pacotes Geneve (porta UDP 6081) e roteado entre TEPs de host pela rede de sobreposição da VPC do Google Cloud usando uma unidade máxima de transmissão (MTU) de 8896 bytes.
  • Endereçamento IP desacoplado: as VMs de carga de trabalho conectadas a segmentos de sobreposição do NSX podem usar intervalos de endereços IP arbitrários sem consumir endereços IP das sub-redes VPC do Google Cloud ou atingir as cotas de IP da sub-rede VPC.
  • Arquitetura de roteamento em vários níveis:
    • Gateways de nível 1 (T1): fornecem roteamento leste-oeste entre segmentos de sobreposição, serviços DHCP localizados e regras de firewall de gateway.
    • Gateways de nível 0 (T0): fornecem roteamento norte-sul entre o ambiente de sobreposição do NSX e a rede VPC do Google Cloud .
  • Segurança distribuída: o firewall distribuído (DFW) do NSX aplica políticas de microssegmentação com estado diretamente na placa de interface de rede virtual (vNIC) de cada VM de carga de trabalho, independentemente do segmento de sobreposição ou do host ESXi em que a VM reside.

Topologia de subjacência x sobreposição

A arquitetura de rede é dividida em duas camadas distintas: a rede de base da VPC do Google Cloud e a rede de sobreposição do VMware NSX, conforme mostrado no diagrama a seguir (clique para ampliar):

VPCGoogle Cloud que hospeda instâncias Z3 e dispositivos VCF abaixo da sobreposição do VMware NSX. Underlay da VPCGoogle Cloud que hospeda instâncias Z3 e dispositivos VCF abaixo do overlay do VMware NSX.

A tabela a seguir resume os componentes e as responsabilidades de cada camada de rede:

Camada de rede Principais componentes Responsabilidades
Google Cloud Underlay da VPC
  • Hosts ESXi bare metal (NICs primárias e dinâmicas)
  • VMs de gerenciamento do VCF (vCenter Server, SDDC Manager, cluster do NSX Manager, VMware HCX)
  • Sub-redes VPC (Management, vSAN, vMotion, NSX-TEP, NSX-Uplink)
  • Balanceadores de carga internos regionais e dispositivos roteadores do Network Connectivity Center
  • Fornece acessibilidade de IP entre as portas VMkernel do host ESXi
  • Hospeda dispositivos do plano de controle do VCF diretamente em sub-redes VPC
  • Transporta pacotes Geneve encapsulados entre TEPs de host ESXi e TEPs de NSX Edge
  • Conecta as redes locais, VPCs com peering e serviços do Google Cloud
Sobreposição de SDN do NSX
  • Clusters do NSX Edge (roteadores lógicos de nível 0 e nível 1)
  • Segmentos de sobreposição do NSX
  • VMs de carga de trabalho
  • Firewall distribuído (DFW) e firewall de gateway do NSX
  • Fornece domínios de camada 2 isolados e roteamento leste-oeste para VMs de carga de trabalho
  • Anuncia blocos CIDR de carga de trabalho para a base da VPC por meio de gateways de nível 0
  • Oferece balanceamento de carga, NAT e segurança de borda norte-sul

Casos de uso de arquitetura avançada

É possível estruturar as topologias do NSX e da VPC para atender a diferentes requisitos de isolamento e multilocação:

  • Domínios de carga de trabalho consolidados em uma única VPC: implante o domínio de gerenciamento do VCF e um ou mais domínios de carga de trabalho do VI em uma única rede VPC doGoogle Cloud . Cada domínio de carga de trabalho usa sub-redes dedicadas vSAN, vMotion e NSX-TEP na mesma VPC, enquanto compartilha ou isola clusters do NSX Edge para roteamento norte-sul.
  • Mapeamentos de várias VPCs: conecte gateways de nível 0 do NSX distintos ou clusters de borda do NSX separados a redes VPC isoladas do Google Cloud (por exemplo, VPCs separadas para cargas de trabalho de produção, redes de perímetro e serviços compartilhados). Essa topologia preserva limites rígidos de firewall e roteamento no nível da VPC no Google Cloud , mantendo o gerenciamento centralizado do ciclo de vida do VCF.

Roteamento do NSX Edge

Para rotear o tráfego entre os segmentos de sobreposição do NSX e sua rede VPC do Google Cloud , as VMs do NSX Edge precisam trocar rotas ou encaminhar pacotes pela sub-rede VPC do NSX-Uplink. É possível configurar o roteamento norte-sul entre gateways de nível 0 do NSX e sua rede VPC usando uma das seguintes opções:

Opção 1: roteamento estático de VPC (ativo-em espera)

Em uma topologia de roteamento estático, um par ativo-em espera de nós do NSX Edge usa um endereço IP virtual (VIP) flutuante na sub-rede VPC NSX-Uplink, que é precedida por um balanceador de carga de rede de passagem interno regional, conforme mostrado no diagrama a seguir (clique para ampliar):

Rotas estáticas de VPC que direcionam o tráfego de sobreposição do NSX por um balanceador de carga interno para nós do NSX Edge em espera ativa. Rotas estáticas de VPC que direcionam o tráfego de sobreposição do NSX por um balanceador de carga interno para nós do NSX Edge em espera ativa.

  • Mecanismo de roteamento: crie rotas estáticas personalizadas na tabela de rotas da VPC doGoogle Cloud que especifiquem os blocos CIDR de carga de trabalho de sobreposição do NSX como destino e o VIP flutuante do NSX Edge (ou regra de encaminhamento do balanceador de carga interno) como o próximo salto.
  • Alta disponibilidade: quando você usa um serviço de back-end interno regional com a política de alta disponibilidade GARP_RA (ou uma transferência de intervalo de IP de alias), o tráfego é redirecionado automaticamente para o nó de borda NSX em espera se o nó de borda ativo falhar.
  • Caso de uso: mais adequado para implantações menores ou topologias de sobreposição estática em que os blocos CIDR de carga de trabalho não mudam com frequência e a largura de banda de borda única atende aos requisitos de capacidade de processamento.

Opção 2: roteamento dinâmico do BGP usando o dispositivo roteador do Network Connectivity Center (ativo-ativo)

Para configurar a troca dinâmica de rotas e o escalonamento horizontal de largura de banda, use o peering do protocolo de gateway de borda (BGP) entre o gateway de nível 0 do NSX e o Cloud Router usando o dispositivo roteador do Network Connectivity Center, conforme mostrado no diagrama a seguir (clique para ampliar):

Peering do Cloud Router por BGP com dispositivos roteadores NSX Edge fixados em hosts Z3 por regras de afinidade do DRS. Peering do Cloud Router por BGP com dispositivos roteadores NSX Edge fixados em hosts Z3 por regras de afinidade do DRS.

  • Troca de rota dinâmica: o gateway de nível 0 do NSX anuncia automaticamente os blocos CIDR do segmento de sobreposição do NSX recém-criados para o Cloud Router por BGP e aprende as rotas VPC e locais (0.0.0.0/0 ou prefixos específicos) por meio de anúncios de rota personalizados. Essa arquitetura elimina as atualizações manuais de rotas estáticas da VPC.
  • Escalonamento de ECMP ativo-ativo: oferece suporte ao roteamento de vários caminhos de custo igual (ECMP, na sigla em inglês) em até oito nós ativos do NSX Edge por gateway de nível 0, escalonando a capacidade de processamento norte-sul e oferecendo suporte ao failover com detecção de encaminhamento bidirecional (BFD, na sigla em inglês).
  • Requisito de fixação de borda para host: como uma VM do NSX Edge é executada em um host ESXi, a interface de uplink virtual dela é mapeada para uma NIC dinâmica específica na instância bare metal do Compute Engine. Para garantir que o Cloud Router encaminhe o tráfego do BGP e do plano de dados para o host exato de bare metal em que cada VM do NSX Edge reside, configure as regras de afinidade do VMware Distributed Resource Scheduler (DRS) (regras de afinidade VM-Host) para fixar cada VM do NSX Edge ao host ESXi designado.
  • Sessões redundantes do BGP: configure sessões duplas do BGP entre as interfaces de uplink de cada nó do NSX Edge na sub-rede NSX-Uplink e as interfaces redundantes do Cloud Router para manter a disponibilidade contínua do plano de controle durante eventos de manutenção do host.

A seguir