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 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
Configurações de MTU recomendadas
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:
- Considerações sobre MTU do Cloud VPN.
- VPNs NSX-T do VMware.
- Engenharia de tráfego no HCX Enterprise.