VLANs e sub-redes no VMware Engine

O Google Cloud VMware Engine cria uma rede em cada região em que o serviço VMware Engine é implantado. A rede é um único espaço de endereço de camada 3 do TCP com roteamento ativado por padrão. Todas as nuvens privadase sub-redes criadas nesta região podem se comunicar sem nenhuma configuração adicional. Você pode criar segmentos de rede (sub-redes) usando NSX-T para suas máquinas virtuais (VMs) de carga de trabalho.

VLANs e sub-redes

VLANs de gerenciamento

O Google cria uma VLAN (rede da camada 2) para cada nuvem privada. O tráfego da camada 2 permanece dentro do limite de uma nuvem privada, permitindo isolar o tráfego local na nuvem privada. Essas VLANs são usadas para a rede de gerenciamento. Para VMs de carga de trabalho, é preciso criar segmentos de rede no gerenciador NSX-T para sua nuvem privada.

Sub-redes

Você precisa criar um segmento de rede no gerente NSX-T para sua nuvem privada. Um único espaço de endereço particular da camada 3 é atribuído por cliente e região. É possível configurar qualquer intervalo de endereços IP que não se sobreponha a outras redes na nuvem privada, na rede local, na rede de gerenciamento de nuvem privada ou nos intervalos de endereços IP de sub-rede na Rede de nuvem privada virtual (VPC). Para uma análise detalhada de como o VMware Engine aloca intervalos de endereços IP de sub-rede, consulte Requisitos de rede.

Todas as sub-redes podem se comunicar entre si por padrão, reduzindo a sobrecarga de configuração para roteamento entre a nuvem privada. Os dados leste-oeste entre nuvens privadas na mesma região permanecem na mesma rede da camada 3 e são transferidos pela infraestrutura de rede local na região. Nenhuma saída é necessária para a comunicação entre nuvens privadas em uma região. Essa abordagem elimina qualquer penalidade de desempenho de WAN/saída na implantação de diferentes cargas de trabalho em diferentes nuvens privadas do mesmo projeto.

Sub-redes de gerenciamento criadas em uma nuvem privada

Quando você cria uma nuvem privada, o VMware Engine cria as seguintes sub-redes de gerenciamento:

  • Gerenciamento do sistema: VLAN e sub-rede para a rede de gerenciamento dos hosts ESXi, servidor DNS, servidor vCenter
  • VMotion: VLAN e sub-rede para a rede vMotion dos hosts ESXi
  • VSAN: VLAN e sub-rede para a rede vSAN de hosts ESXi
  • NsxtEdgeUplink1: VLAN e sub-rede para uplinks de VLAN em uma rede externa
  • NsxtEdgeUplink2: VLAN e sub-rede para uplinks de VLAN em uma rede externa
  • HCXUplink:usado por dispositivos HCX IX (mobilidade) e NE (extensão) para alcançar semelhantes e permitir a criação da malha de serviço do HCX.
  • NstHostTransport: VLAN e sub-rede para zona de transporte host

Intervalo CIDR da rede de implantação do HCX

Quando você cria uma nuvem privada no VMware Engine, o HCX é instalado automaticamente na nuvem privada. Você pode especificar um intervalo de CIDR de rede para uso de componentes do HCX. O prefixo do intervalo CIDR precisa ser /26 ou /27.

A rede fornecida é dividida em três sub-redes. O gerente do HCX está instalado na sub-rede de gerenciamento de HCX. A sub-rede HCX vMotion é usada para vMotion de máquinas virtuais entre o ambiente local e a nuvem privada do VMware Engine. A sub-rede HCX WANUplink é usada para estabelecer o túnel entre o ambiente local e a nuvem privada do VMware Engine.

Sub-redes de serviço

Quando você cria uma nuvem privada, o VMware Engine cria automaticamente sub-redes de serviço adicionais. É possível segmentar sub-redes de serviço para cenários de implantação de dispositivos ou serviços, como armazenamento, backup, recuperação de desastres (DR), streaming de mídia, capacidade de processamento linear em alta escala e processamento de pacotes para até as maiores nuvens privadas escalonadas. Os nomes das sub-redes de serviço são os seguintes:

  • service-1
  • service-2
  • service-3
  • service-4
  • service-5

A comunicação da máquina virtual em uma sub-rede de serviço sai do host do VMware ESXi diretamente para a infraestrutura de rede do Google Cloud, permitindo uma comunicação de alta velocidade.

Como configurar sub-redes de serviço

Quando o VMware Engine cria uma sub-rede de serviço, ele não aloca um intervalo ou prefixo CIDR. É necessário especificar um intervalo e um prefixo CIDR não sobrepostos. O primeiro endereço utilizável se tornará o endereço de gateway. Para alocar um intervalo CIDR e um prefixo, edite uma das sub-redes de serviço.

As sub-redes de serviço poderão ser atualizadas se os requisitos do CIDR mudarem. A modificação de um CIDR de sub-rede de serviço pode causar interrupção da disponibilidade de rede das VMs anexadas a essa sub-rede de serviço.

Como configurar grupos de portas distribuídas do vSphere

Para conectar uma VM a uma sub-rede de serviço, crie um novo grupo de portas distribuídas. Esse grupo mapeia o ID da sub-rede de serviço para um nome de rede em uma nuvem privada do vCenter.

Para fazer isso, navegue até a seção de configuração de rede da interface do vCenter, selecione Datacenter-dvs e selecione Novo grupo de portas distribuído.

Depois que o grupo de portas distribuídas for criado, será possível anexar VMs selecionando o nome correspondente na configuração de rede das propriedades da VM.

Veja a seguir os valores de configuração críticos do grupo de portas distribuído:

  • Vinculação de portas: vinculação estática
  • Alocação de porta: elástica
  • Número de portas: 120
  • Tipo VLAN: VLAN
  • ID da VLAN: o ID da sub-rede correspondente na seção de sub-redes da interface do Google Cloud VMware Engine

A Unidade máxima de transmissão (MTU, na sigla em inglês) é o tamanho em bytes do maior pacote compatível com um protocolo de camada de rede, incluindo cabeçalhos e dados. Para evitar problemas relacionados à fragmentação, recomendamos as configurações de MTU a seguir.

Para VMs que se comunicam somente com outros endpoints em uma nuvem particular, é possível usar as configurações de MTU de até 8.800 bytes.

Para VMs que se comunicam de ou para uma nuvem privada sem encapsulamento, use a configuração padrão de MTU de 1.500 bytes. Essa configuração padrão comum é válida para interfaces de VM que enviam tráfego das seguintes maneiras:

  • De uma VM em uma nuvem particular para uma VM em outra nuvem particular
  • De um endpoint local para uma nuvem particular
  • De uma VM em uma nuvem particular até um endpoint local
  • Da Internet a uma nuvem particular
  • De uma VM em uma nuvem privada para a Internet

Para VMs que se comunicam de ou para uma nuvem privada com o encapsulamento, calcule a melhor configuração de MTU com base nas configurações de endpoint da VPN. Isso geralmente resulta em uma configuração de MTU de 1.350 a 1.390 bytes ou menos para interfaces de VM que enviam tráfego das seguintes maneiras:

  • De um endpoint local para uma nuvem privada com encapsulamento
  • De uma VM na nuvem particular até um endpoint local com encapsulamento
  • De uma VM em uma nuvem privada para uma VM em outra nuvem privada com encapsulamento

Essas recomendações são especialmente importantes nos casos em que um aplicativo não pode controlar o tamanho máximo do payload. Para orientações adicionais sobre como calcular a sobrecarga de encapsulamento, consulte os seguintes recursos: