Équilibrage de charge à haute disponibilité pour les appliances VCF

Ce document explique comment les équilibreurs de charge internes régionaux et les groupes de points de terminaison du réseau (NEG) zonaux de la solution VMware sur Google Cloud fournissent une haute disponibilité de couche 2, une mobilité des machines virtuelles (vMotion) et un basculement automatisé pour les dispositifs de gestion VMware Cloud Foundation (VCF) déployés dans la sous-couche du cloud privé virtuel (VPC), comme illustré dans le diagramme suivant (cliquez pour l'agrandir) :

Équilibreur de charge interne et service de backend régional avec GARP_RA dirigeant le trafic via un NEG zonal pendant vMotion. Équilibreur de charge interne et service de backend régional avec GARP_RA dirigeant le trafic via un NEG zonal pendant vMotion.

Pourquoi les appliances sous-jacentes nécessitent un équilibreur de charge

Dans les centres de données sur site, les machines virtuelles de gestion (telles que vCenter Server, SDDC Manager et les nœuds NSX Manager en cluster) s'appuient sur des domaines de diffusion physiques de couche 2. Lorsqu'un appareil bascule ou migre entre des hôtes ESXi à l'aide de vMotion, il diffuse un paquet ARP spontané (GARP) pour mettre à jour les tables d'adresses MAC des commutateurs ToR (Top-of-Rack) physiques afin que son adresse IP flotte sur les serveurs physiques.

Un réseau VPC Google Cloud est un réseau défini par logiciel (SDN) de couche 3 routé, qui présente les comportements suivants :

  • Chaque adresse IP est liée de manière programmatique à une interface réseau virtuelle (vNIC) Compute Engine spécifique dans la table de transfert SDN.
  • Le plan de routage VPC ne s'appuie pas sur l'apprentissage MAC du commutateur physique pour acheminer le trafic de couche 3 vers des adresses IP flottantes.
  • Si une VM de gestion de sous-couche est déplacée vers un autre hôte ESXi bare metal, la table de routage VPC nécessite un mécanisme explicite pour diriger le trafic de l'adresse IP de cette appliance vers la nouvelle interface hôte.

Pour assurer la mobilité des adresses IP sans mises à jour manuelles des routes ni réadressage des VM, la solution VMware provisionne un équilibreur de charge réseau passthrough interne régional configuré avec le déplacement rapide des adresses IP (GARP_RA) pour chaque appareil de gestion sous-jacent flottant.

Composants d'architecture à haute disponibilité

Chaque dispositif réseau de la solution VMware utilise une architecture d'équilibrage de chargeGoogle Cloud à trois niveaux pour assurer la haute disponibilité et la mobilité vMotion :

Groupes de points de terminaison du réseau (NEG) zonaux

  • Type de construction : NEG zonaux de type GCE_VM_IP_DEDICATED_BACKEND configurés dans le sous-réseau VPC cible.
  • Fonction : un NEG dédié dans chaque zone regroupe les interfaces réseau principales ou dynamiques de toutes les instances ESXi bare metal appartenant au domaine de mobilité vMotion du cluster.
  • Réutilisabilité : tous les équilibreurs de charge de l'appareil sous-jacent du même cluster et du même sous-réseau partagent un seul ensemble de NEG zonaux.

Service de backend régional avec déplacement rapide des adresses IP

  • Type de construction : service de backend régional (loadBalancingScheme: INTERNAL, protocol: UNSPECIFIED) qui référence les NEG zonaux du cluster.
  • Règle de basculement (haPolicy) : configurée avec fastIPMove: GARP_RA.
  • Fonction : indique au plan de données Google Cloud Andromeda de surveiller le sous-réseau compatible avec la diffusion pour les trames GARP et d'annonce de routeur (RA) émises par la VM de l'appareil de gestion et de mettre à jour de manière dynamique l'hôte de backend actif.

Équilibreur de charge réseau passthrough interne régional

  • Type de construction : règle de transfert interne régionale configurée avec l'adresse IP virtuelle (VIP) réservée de l'appareil.
  • Fonction : sert de point de terminaison IP persistant pour l'appliance de gestion ou l'adresse IP virtuelle du cluster. Les administrateurs, les charges de travail et les autres composants VCF se connectent à cette adresse VIP.

Haute disponibilité de la sous-couche avec des NEG dédiés

Lorsque plusieurs interfaces réseau (telles que l'interface principale nic0 et les cartes d'interface réseau dynamiques avec marquage VLAN) se connectent au même réseau VPC, les NEG GCE_VM_IP standards ne peuvent pas cibler des sous-interfaces arbitraires. À la place, la solution VMware utilise des NEG GCE_VM_IP_DEDICATED_BACKEND, qui fonctionnent comme suit :

  • Ciblage automatique de l'interface : associe automatiquement la vNIC principale ou la carte d'interface réseau dynamique spécifique qui correspond au sous-réseau du NEG.
  • Un seul NEG par zone : un service de backend régional configuré avec des NEG GCE_VM_IP_DEDICATED_BACKEND ne peut contenir qu'un seul NEG par zone.
  • Exigence de règle de haute disponibilité interne : les NEG GCE_VM_IP_DEDICATED_BACKEND ne sont compatibles qu'avec les services de backend régionaux configurés pour les équilibreurs de charge réseau passthrough internes (loadBalancingScheme: INTERNAL) qui utilisent haPolicy.

Restrictions des règles de haute disponibilité sur les sous-réseaux de diffusion

Lorsque vous déployez des services de backend haPolicy dans des sous-réseaux où la diffusion ARP et l'apprentissage MAC sont activés, les règles suivantes s'appliquent :

  • Schéma d'équilibrage de charge : seuls les équilibreurs de charge réseau passthrough internes (INTERNAL) sont acceptés.
  • Alignement des sous-réseaux : tous les NEG de backend de toutes les zones d'un service de backend donné doivent appartenir au même sous-réseau VPC.
  • Mappage des règles de transfert : un service de backend configuré avec des NEG de diffusion ne peut être référencé que par une seule règle de transfert.
  • Type de sous-réseau de backend immuable : vous devez associer des backends dans un sous-réseau de diffusion ARP lorsque vous créez le service de backend. Vous ne pouvez pas les remplacer ultérieurement par des backends dans des sous-réseaux sans diffusion.

Empêcher la revendication croisée des règles de haute disponibilité

Dans un sous-réseau où la diffusion ARP est activée, une interface hôte appartenant à un service de backend de règle de haute disponibilité peut temporairement revendiquer le rôle de leader pour une règle de haute disponibilité non liée si elle diffuse une trame GARP pour l'adresse IP virtuelle de la règle de transfert de cette règle.

Pour éviter les revendications croisées involontaires, incluez exactement le même ensemble de backends d'hôte ESXi (tous les hôtes du NEG zonal du cluster) dans tous les services de backend de stratégie de haute disponibilité fonctionnant dans ce sous-réseau.

Étapes suivantes