VLANs e sub-redes no VMware Engine

O Google Cloud VMware Engine usa uma rede do VMware Engine para fornecer conetividade de rede entre uma ou mais nuvens privadas, redes da Google Cloud nuvem virtual privada Google Cloud e redes no local. O VMware Engine oferece dois tipos de rede: Padrão e Antigo. As redes padrão são a predefinição para projetos criados em novembro de 2023 ou posteriormente, são globais e usam o peering de redes VPC para a conetividade. As redes antigas só estão disponíveis em projetos criados antes de novembro de 2023, são regionais e usam o acesso privado ao serviço para a conetividade. Para mais informações, consulte o artigo Acerca das redes do VMware Engine.

Independentemente do tipo de rede, pode criar segmentos de rede (sub-redes) através do NSX-T Data Center para as suas máquinas virtuais (MVs) de carga de trabalho.

VLANs e sub-redes.

VLANs de gestão

A Google cria uma VLAN (rede de camada 2) para cada nuvem privada. O tráfego da camada 2 permanece dentro do limite de uma nuvem privada, o que lhe permite isolar o tráfego local dentro da nuvem privada. Estas VLANs são usadas para a rede de gestão. Para VMs de carga de trabalho, tem de criar segmentos de rede no NSX Manager para a sua nuvem privada.

Sub-redes

Para as VMs de carga de trabalho, tem de criar um segmento de rede no NSX Manager para a sua nuvem privada. Pode configurar qualquer intervalo de endereços IP que não se sobreponha a outras redes na sua nuvem privada, na sua rede no local, na sua rede de gestão da nuvem privada ou nos intervalos de endereços IP de sub-redes em qualquer rede da nuvem virtual privada (VPC) com intercâmbio. Para ver uma análise detalhada de como o VMware Engine atribui intervalos de endereços IP de sub-rede para gestão, consulte os Requisitos de rede.

Numa nuvem privada, os segmentos de rede de cargas de trabalho podem comunicar entre si por predefinição. A comunicação entre nuvens privadas depende do tipo de rede do VMware Engine. Para redes antigas, os dados leste-oeste em nuvens privadas na mesma região permanecem na mesma rede de camada 3 e são transferidos através da infraestrutura de rede local na região, não sendo necessária saída. Para redes padrão, a comunicação entre nuvens privadas é feita através do intercâmbio da rede da VPC e depende da configuração da VPC.

Sub-redes de gestão criadas numa nuvem privada

Quando cria uma nuvem privada, o VMware Engine cria as seguintes sub-redes de gestão:

  • Gestão do sistema: VLAN e sub-rede para a rede de gestão dos anfitriões ESXi, servidor DNS, vCenter Server
  • VMotion: VLAN e sub-rede para a rede vMotion dos anfitriões ESXi
  • VSAN: VLAN e sub-rede para a rede vSAN dos anfitriões ESXi
  • NsxtEdgeUplink1: VLAN e sub-rede para uplinks de VLAN para uma rede externa
  • NsxtEdgeUplink2: VLAN e sub-rede para uplinks de VLAN para uma rede externa
  • HCXUplink: usado pelos dispositivos HCX IX (mobilidade) e NE (extensão) para alcançar os respetivos pares e permitir a criação da malha de serviços na nuvem do HCX.
  • NsxtHostTransport: VLAN e sub-rede para a zona de transporte do anfitrião

Intervalo CIDR da rede de implementação do HCX

Quando cria uma nuvem privada no VMware Engine, o VMware Engine instala automaticamente o HCX na nuvem privada. Já não tem de especificar um intervalo CIDR dedicado para os componentes do HCX. Em alternativa, o VMware Engine atribui automaticamente o espaço de rede necessário para os componentes do HCX (como o HCX Manager, o vMotion e o WAN Uplink) a partir do intervalo CIDR de gestão que especificar para a sua nuvem privada.

Sub-redes de serviço

Quando cria uma nuvem privada, o VMware Engine cria automaticamente sub-redes de serviços adicionais. Pode segmentar sub-redes de serviços para cenários de implementação de dispositivos ou serviços, como armazenamento, cópia de segurança, recuperação de desastres (DR), streaming de multimédia e fornecimento de débito linear de grande escala e processamento de pacotes, mesmo para as nuvens privadas de maior escala. 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 numa sub-rede de serviço sai do anfitrião do VMware ESXi diretamente para a Google Cloud infraestrutura de rede, o que permite uma comunicação de alta velocidade.

Configurar sub-redes de serviço

Quando o VMware Engine cria uma sub-rede de serviço, não atribui um intervalo ou um prefixo CIDR. Tem de especificar um prefixo e um intervalo CIDR não sobrepostos. O primeiro endereço utilizável torna-se o endereço de gateway. Para atribuir um intervalo e um prefixo CIDR, edite uma das sub-redes de serviço.

As sub-redes de serviço podem ser atualizadas se os requisitos de CIDR mudarem. A modificação de um CIDR de sub-rede de serviço existente pode causar uma interrupção da disponibilidade da rede para as VMs anexadas a essa sub-rede de serviço.

Configurar grupos de portas distribuídas do vSphere

Para associar uma VM a uma sub-rede de serviço, tem de criar um novo grupo de portas distribuídas. Este grupo mapeia o ID da sub-rede de serviço para um nome de rede numa nuvem privada do vCenter.

Para o fazer, navegue para a secção de configuração de rede da interface do vCenter, selecione Datacenter-dvs e, de seguida, selecione New Distributed Port Group.

Depois de criar o grupo de portas distribuídas, pode anexar VMs selecionando o nome correspondente na configuração de rede das propriedades da VM.

Seguem-se os valores de configuração críticos do grupo de portas distribuídas:

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

A unidade de transmissão máxima (MTU) é o tamanho, em bytes, do maior pacote suportado por um protocolo de camada de rede, incluindo cabeçalhos e dados. Para evitar problemas relacionados com a fragmentação, recomendamos as seguintes definições de MTU:

  • Para VMs que comunicam apenas com outros pontos finais numa nuvem privada padrão, pode usar definições de MTU até 8800 bytes.

  • Para VMs que comunicam apenas com outros pontos finais numa nuvem privada expandida, pode usar definições de MTU até 8600 bytes.

  • Para VMs que comunicam com ou a partir de uma nuvem privada sem encapsulamento, use a definição de MTU padrão de 1500 bytes. Esta predefinição comum é válida para interfaces de VMs que enviam tráfego das seguintes formas:

    • De uma VM numa nuvem privada para uma VM noutra nuvem privada
    • De um ponto final no local para uma nuvem privada
    • De uma VM numa nuvem privada para um ponto final nas instalações
    • Da Internet para uma nuvem privada
    • De uma VM numa nuvem privada para a Internet

  • Para VMs que comunicam com a Internet ou a partir desta com fluxos de tráfego UDP de pacotes grandes sensíveis à fragmentação, use uma definição de MTU de 1370 bytes ou inferior. Esta recomendação aplica-se a comunicações que usam ligações públicas ou endereços IP fornecidos pelo VMware Engine. A restrição MSS resolve geralmente problemas de fragmentação com fluxos de tráfego baseados em TCP.

  • Para VMs que comunicam para ou a partir de uma nuvem privada com encapsulamento, calcule a melhor definição de MTU com base nas configurações do ponto final da VPN. Geralmente, isto resulta numa definição de MTU de 1350 a 1390 bytes ou inferior para interfaces de VM que enviam tráfego das seguintes formas:

    • De um ponto final no local para uma nuvem privada com encapsulamento
    • De uma VM de nuvem privada para um ponto final no local com encapsulamento
    • De uma VM numa nuvem privada para uma VM noutra nuvem privada com encapsulamento

Estas recomendações são especialmente importantes nos casos em que uma aplicação não consegue controlar o tamanho máximo da carga útil. Para orientações adicionais sobre o cálculo da sobrecarga de encapsulamento, consulte os seguintes recursos: