VLAN et sous-réseaux sur VMware Engine

Google Cloud VMware Engine utilise un réseau VMware Engine pour fournir une connectivité réseau entre un ou plusieurs clouds privés, des réseaux Google Cloud Virtual Private Cloud et des réseaux sur site. VMware Engine propose deux types de réseaux : Standard et Ancien. Les réseaux standards sont définis par défaut pour les projets créés en novembre 2023 ou après. Ils sont mondiaux et utilisent l'appairage de réseaux VPC pour la connectivité. Les anciens réseaux ne sont disponibles que dans les projets créés avant novembre 2023. Ils sont régionaux et utilisent l'accès aux services privés pour la connectivité. Pour en savoir plus, consultez À propos des réseaux VMware Engine.

Quel que soit le type de réseau, vous pouvez créer des segments de réseau (sous-réseaux) à l'aide de NSX-T Data Center pour vos machines virtuelles (VM) de charge de travail.

VLAN et sous-réseaux

VLAN de gestion

Google crée un VLAN (réseau de Couche 2) pour chaque cloud privé. Le trafic de Couche 2 reste dans les limites d'un cloud privé, ce qui vous permet d'isoler le trafic local dans le cloud privé. Ces VLAN sont utilisés pour le réseau de gestion. Pour les VM de charge de travail, vous devez créer des segments de réseau sur NSX Manager pour votre cloud privé.

Sous-réseaux

Pour vos VM de charge de travail, vous devez créer un segment de réseau sur le gestionnaire NSX pour votre cloud privé. Vous pouvez configurer n'importe quelle plage d'adresses IP qui ne chevauche pas d'autres réseaux de votre cloud privé, réseau sur site, réseau de gestion de votre cloud privé ou plages d'adresses IP de sous-réseau de votre réseau de cloud privé virtuel (VPC) appairé. Pour en savoir plus sur la manière dont VMware Engine alloue les plages d'adresses IP de sous-réseau pour la gestion, consultez la section Configuration réseau requise.

Dans un cloud privé, les segments de réseau de charge de travail peuvent communiquer entre eux par défaut. La communication entre les clouds privés dépend du type de réseau VMware Engine. Pour les anciens réseaux, les données Est-Ouest sur les clouds privés d'une même région demeurent sur le même réseau de Couche 3 et sont transférées sur l'infrastructure du réseau local de la région, sans nécessiter de sortie. Pour les réseaux standards, la communication entre les clouds privés s'effectue via l'appairage de réseaux VPC et dépend de votre configuration VPC.

Sous-réseaux de gestion créés sur un cloud privé

Lorsque vous créez un cloud privé, VMware Engine crée les sous-réseaux de gestion suivants :

  • Gestion du système : VLAN et sous-réseau pour le réseau de gestion des hôtes ESXi, le serveur DNS et le serveur vCenter
  • VMotion : VLAN et sous-réseau pour le réseau vMotion des hôtes ESXi
  • VSAN : VLAN et sous-réseau pour le réseau vSAN des hôtes ESXi
  • NsxtEdgeUplink1 : VLAN et sous-réseau pour les liaisons VLAN avec un réseau externe
  • NsxtEdgeUplink2 : VLAN et sous-réseau pour les liaisons VLAN avec un réseau externe
  • HCXUplink : utilisé par les appliances HCX IX (mobilité) et NE (extension) pour atteindre leurs pairs et permettre la création du maillage de services HCX Cloud.
  • NsxtHostTransport : VLAN et sous-réseau pour la zone de transport hôte

Plage CIDR du réseau de déploiement HCX

Lorsque vous créez un cloud privé sur VMware Engine, VMware Engine installe automatiquement HCX sur le cloud privé. Vous n'avez plus besoin de spécifier de plage CIDR dédiée pour les composants HCX. VMware Engine alloue automatiquement l'espace réseau requis pour les composants HCX (tels que HCX Manager, vMotion et liaison montante WAN) à partir de la plage CIDR de gestion que vous spécifiez pour votre cloud privé.

Sous-réseaux de service

Lorsque vous créez un cloud privé, VMware Engine crée automatiquement des sous-réseaux de service supplémentaires. Vous pouvez les utiliser pour le déploiement de dispositifs ou de services, le stockage, la sauvegarde, la reprise après sinistre, le streaming multimédia, et le débit linéaire et le traitement de paquets à grande échelle, même pour les clouds privés les plus étendus. Les noms des sous-réseaux de service sont les suivants :

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

La communication avec les machines virtuelles d'un sous-réseau de service passe directement de l'hôte VMware ESXi à l'infrastructure réseau Google Cloud , ce qui permet une communication à haut débit.

Configurer des sous-réseaux de service

Lorsque VMware Engine crée un sous-réseau de service, il n'alloue pas de plage ni de préfixe CIDR. Vous devez spécifier un préfixe et une plage CIDR sans chevauchement. La première adresse utilisable deviendra l'adresse de la passerelle. Pour allouer une plage et un préfixe CIDR, modifiez l'un des sous-réseaux de service.

Les sous-réseaux de service peuvent être mis à jour si les exigences CIDR changent. La modification du CIDR d'un sous-réseau de service existant peut entraîner une interruption de la disponibilité du réseau pour les VM associées à ce sous-réseau de service.

Configurer les groupes de ports distribués vSphere

Pour connecter une VM à un sous-réseau de service, vous devez créer un groupe de ports distribués. Ce groupe mappe l'ID de sous-réseau de service à un nom de réseau dans un cloud privé vCenter.

Pour ce faire, accédez à la section de configuration réseau de l'interface vCenter, sélectionnez Datacenter-dvs, puis New Distributed Port Group (Nouveau groupe de ports distribué).

Une fois le groupe de ports distribué créé, vous pouvez associer des VM en sélectionnant le nom correspondant dans la configuration réseau des propriétés de la VM.

Voici les valeurs de configuration critiques des groupes de ports distribués :

  • Association de ports : association statique
  • Allocation de ports : élastique
  • Nombre de ports : 120
  • Type de VLAN : VLAN
  • ID de VLAN : ID de sous-réseau correspondant dans la section "Sous-réseaux" de l'interface Google Cloud VMware Engine

L'unité de transmission maximale (MTU) correspond à la taille, en octets, du plus grand paquet accepté par un protocole de couche réseau. Elle inclut les en-têtes et les données. Pour éviter les problèmes liés à la fragmentation, nous vous recommandons d'utiliser les paramètres de MTU suivants :

  • Pour les VM qui ne communiquent qu'avec d'autres points de terminaison dans un cloud privé standard, vous pouvez utiliser des paramètres de MTU allant jusqu'à 8 800 octets.

  • Pour les VM qui ne communiquent qu'avec d'autres points de terminaison dans un cloud privé étendu, vous pouvez utiliser des paramètres de MTU allant jusqu'à 8 600 octets.

  • Pour les VM qui communiquent vers ou depuis un cloud privé sans encapsulation, utilisez le paramètre de MTU standard de 1 500 octets. Ce paramètre par défaut commun est valide pour les interfaces de VM qui envoient du trafic des manières suivantes :

    • d'une VM dans un cloud privé vers une VM dans un autre cloud privé
    • d'un point de terminaison sur site vers un cloud privé
    • d'une VM dans un cloud privé vers un point de terminaison sur site
    • d'Internet vers un cloud privé
    • d'une VM dans un cloud privé vers Internet

  • Pour les VM qui communiquent vers ou depuis Internet avec de grands flux de trafic UDP sensibles à la fragmentation, utilisez un paramètre de MTU de 1 370 octets ou moins. Cette recommandation s'applique aux communications utilisant des connexions ou des adresses IP publiques fournies par VMware Engine. Le processus de limitation de la taille MSS résout généralement les problèmes de fragmentation avec les flux de trafic basés sur TCP.

  • Pour les VM qui communiquent vers ou depuis un cloud privé ou avec encapsulation, calculez le paramètre de MTU optimal en fonction des configurations des points de terminaison du VPN. Cela se traduit généralement par un paramètre de MTU de 1 350 à 1 390 octets ou moins pour les interfaces de VM qui envoient du trafic des manières suivantes :

    • d'un point de terminaison sur site vers un cloud privé avec encapsulation
    • d'une VM cloud privé vers un point de terminaison sur site avec encapsulation
    • d'une VM cloud privé vers une VM dans un autre cloud privé avec encapsulation

Ces recommandations sont particulièrement importantes dans les cas où une application n'est pas en mesure de contrôler la taille de la charge utile maximale. Pour plus d'informations sur le calcul de la surcharge d'encapsulation, consultez les ressources suivantes :