Présentation de l'équilibreur de charge réseau passthrough interne

Un équilibreur de charge réseau passthrough interne est un équilibreur de charge régional basé sur la pile de virtualisation de réseau Andromeda.

Les équilibreurs de charge réseau passthrough internes répartissent le trafic entre les instances de machines virtuelles (VM) internes de la même région sur un réseau de cloud privé virtuel (VPC). Il vous permet d'exécuter et de faire évoluer vos services derrière une adresse IP interne accessible uniquement aux systèmes du même réseau VPC ou des systèmes connectés à votre réseau VPC.

Utilisez un équilibreur de charge réseau passthroughinterne dans les cas suivants :

  • Vous avez besoin d'un équilibreur de charge hautes performances passthrough de couche 4 pour les protocoles TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE.
  • Si le trafic diffusé via TLS (SSL) est accepté, le trafic SSL doit être interrompu par vos backends plutôt que par l'équilibreur de charge. L'équilibreur de charge réseau passthrough interne ne peut pas interrompre le trafic SSL.
  • Vous devez transférer les paquets d'origine sans proxy. Par exemple, si vous souhaitez que l'adresse IP source du client soit préservée.
  • Vous disposez d'une configuration existante qui utilise un équilibreur de charge pass-through et vous souhaitez la transférer sans modification.

Les équilibreurs de charge réseau passthrough internes répondent à de nombreux cas d'utilisation. Pour obtenir des exemples généraux, consultez la page Présentation de l'équilibreur de charge réseau passthrough.

Fonctionnement des équilibreurs de charge réseau passthrough internes

Un équilibreur de charge réseau passthrough interne dispose d'une interface (la règle de transfert) et d'un backend (le service de backend). Vous pouvez utiliser des groupes d'instances ou des NEG zonaux GCE_VM_IP en tant que backends sur le service de backend. Cet exemple montre les backends de groupe d'instances.

Vue d'ensemble d'un équilibreur de charge réseau passthrough interne
Vue d'ensemble d'un équilibreur de charge réseau passthrough interne (cliquez pour agrandir)

Contrairement à un équilibreur de charge proxy, un équilibreur de charge réseau passthrough interne ne met pas fin aux connexions des clients pour ouvrir ensuite de nouvelles connexions aux backends. À la place, un équilibreur de charge réseau passthrough interne achemine les connexions directement des clients vers les backends opérationnels, sans interruption. Les réponses de ces VM de backend opérationnelles vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Les réponses TCP utilisent le retour direct du serveur. Pour plus d'informations, consultez la section Paquets de requêtes et de retours TCP et UDP.

L'équilibreur de charge surveille l'intégrité du backend à l'aide de requêtes de vérification d'état. Pour plus d'informations, consultez la section Vérification d'état.

L'environnement invité Linux de Google Cloud, l'environnement invité Windows de Google Cloud, ou un processus équivalent, configure chaque VM de backend avec l'adresse IP de l'équilibreur de charge. Pour les VM créées à partir d'images Google Cloud, l'agent invité (anciennement "environnement invité Windows" ou "environnement invité Linux") installe la route locale pour l'adresse IP de l'équilibreur de charge. Les instances Google Kubernetes Engine basées sur Container-Optimized OS implémentent ceci en utilisant plutôt iptables.

La mise en réseau virtuelle de Google Cloud gère la diffusion du trafic et le scaling de la manière appropriée.

Protocoles, schéma et champ d'application

Chaque équilibreur de charge réseau passthrough interne est compatible avec les éléments suivants :

  • Un service de backend avec le schéma d'équilibrage de charge INTERNAL et un protocole compatible. Pour en savoir plus, consultez la section Service de backend.
  • Les VM de backend spécifiées de l'une des manières suivantes :
  • Compatibilité avec le trafic IPv4 et IPv6 lors de l'utilisation de backends de groupes d'instances. Les groupes de points de terminaison du réseau (NEG) zonaux avec des points de terminaison GCE_VM_IP n'acceptent que le trafic IPv4.
  • Une ou plusieurs règles de transfert, chacune utilisant le protocole TCP, UDP ou L3_DEFAULT correspondant au protocole du service de backend.
  • Chaque règle de transfert avec sa propre adresse IP unique ou plusieurs règles de transfert partageant une adresse IP commune.
  • Chaque règle de transfert avec un maximum de cinq ports ou tous les ports.
  • Si l'accès mondial est activé, les clients peuvent se trouver dans n'importe quelle région.
  • Si l'accès mondial est désactivé, les clients doivent se trouver dans la même région que l'équilibreur de charge.

Un équilibreur de charge réseau passthrough interne n'est pas compatible avec :

Accès des clients

Par défaut, l'équilibreur de charge n'accepte que les clients situés dans la même région que lui. Les clients peuvent se trouver sur le même réseau que l'équilibreur de charge ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC. Vous pouvez activer l'accès mondial pour autoriser les clients de n'importe quelle région à accéder à votre équilibreur de charge réseau passthrough interne.

Équilibreur de charge réseau passthrough interne avec accès mondial.
Équilibreur de charge réseau passthrough interne avec accès mondial (cliquez pour agrandir)

Le tableau suivant récapitule l'accès des clients.

Accès mondial désactivé Accès mondial activé
Les clients doivent se trouver dans la même région que l'équilibreur de charge. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC. Les clients peuvent se trouver dans n'importe quelle région. Ils doivent toujours se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.
Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements doivent se trouver dans la même région que l'équilibreur de charge. Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements peuvent se trouver dans n'importe quelle région.

Adresses IP pour les paquets de requêtes et de retours

Lorsqu'une VM de backend reçoit un paquet à équilibrage de charge d'un client, la source et la destination du paquet sont les suivantes :

  • Source : adresse IPv4, IPv6 interne ou adresse IPv4 du client à partir de l'une des plages d'adresses IPv4 d'alias du client.
  • Destination : adresse IP de la règle de transfert de l'équilibreur de charge. La règle de transfert utilise une seule adresse IPv4 interne ou une plage d'adresses IPv6 internes.

L'équilibreur de charge est un équilibreur de charge à stratégie directe (et non un proxy). Par conséquent, les paquets qui arrivent contiennent l'adresse IP de destination de la règle de transfert de l'équilibreur de charge. Le logiciel exécuté sur les VM de backend doit être configuré pour effectuer les opérations suivantes :

  • Écouter (être lié à) l'adresse IP de la règle de transfert de l'équilibreur de charge ou toute adresse IP (0.0.0.0 ou ::)
  • Si le protocole de la règle de transfert de l'équilibreur de charge est compatible avec les ports : écouter (être lié à) un port inclus dans la règle de transfert de l'équilibreur de charge.

Les paquets de retour sont envoyés directement aux VM de backend de l'équilibreur de charge au client. Les adresses IP source et de destination du paquet de retour dépendent du protocole :

  • TCP est orienté connexion. Les VM de backend doivent donc répondre avec des paquets dont les adresses IP sources correspondent à l'adresse IP de la règle de transfert, de sorte que le client puisse associer les paquets de réponse à la connexion TCP appropriée.
  • Le protocole UDP est sans connexion. Les VM de backend peuvent donc envoyer des paquets de réponse dont les adresses IP sources correspondent à l'adresse IP de la règle de transfert ou à toute adresse IP attribuée à la VM. En pratique, la plupart des clients s'attendent à ce que la réponse provienne de l'adresse IP à laquelle ils ont envoyé des paquets.

Le tableau suivant résume les sources et les destinations des paquets de réponses :

Type de trafic Source Destination
TCP Adresse IP de la règle de transfert de l'équilibreur de charge Source du paquet à l'origine de la requête
UDP Dans la plupart des cas, adresse IP de la règle de transfert de l'équilibreur de charge† Source du paquet à l'origine de la requête

† Il est possible de définir la source du paquet de réponse sur l'adresse IPv4 interne principale de la carte d'interface réseau de la VM ou sur une plage d'adresses IP d'alias. Si le transfert IP est activé sur la VM, vous pouvez également utiliser des sources d'adresse IP arbitraires. Ne pas utiliser l'adresse IP de la règle de transfert en tant que source est un scénario avancé, car le client reçoit un paquet de réponse provenant d'une adresse IP interne qui ne correspond pas à l'adresse IP à laquelle il a envoyé un paquet de requête.

Architecture

Un équilibreur de charge réseau passthrough interne avec plusieurs backends distribue les connexions entre tous les backends. Pour en savoir plus sur la méthode de distribution et ses options de configuration, consultez la section Distribution du trafic.

Vous pouvez utiliser des groupes d'instances ou des NEG zonaux, mais pas une combinaison des deux, en tant que backends pour un équilibreur de charge réseau passthrough interne :

  • Si vous choisissez des groupes d'instances, vous pouvez utiliser des groupes d'instances non gérés, des groupes d'instances gérés zonaux, des groupes d'instances gérés régionaux ou une combinaison de ces types de groupes d'instances.
  • Si vous choisissez des NEG zonaux, vous devez utiliser des NEG zonaux GCE_VM_IP.

La section Haute disponibilité décrit comment concevoir un équilibreur de charge interne qui ne dépend pas d'une seule zone.

Les instances qui participent en tant que VM de backend pour les équilibreurs de charge réseau passthrough internes doivent exécuter l'environnement invité Linux ou Windows, ou d'autres processus appropriés présentant des fonctionnalités équivalentes. Cet environnement invité doit pouvoir contacter le serveur de métadonnées (metadata.google.internal, 169.254.169.254) pour lire les métadonnées d'instance afin de générer des routes locales pour accepter le trafic envoyé à l'adresse IP interne de l'équilibreur de charge.

Ce schéma illustre la distribution du trafic entre les VM situées dans deux groupes d'instances distincts. Le trafic envoyé depuis l'instance client vers l'adresse IP de l'équilibreur de charge (10.10.10.9) est réparti entre les VM backend dans l'un des deux groupes d'instances. Les réponses envoyées par l'une des VM backend de diffusion sont directement envoyées à la VM cliente.

Vous pouvez utiliser un équilibreur de charge réseau passthrough interne avec un réseau VPC en mode personnalisé ou en mode automatique. Vous pouvez également créer des équilibreurs de charge réseau passthrough internes avec un ancien réseau.

Un équilibreur de charge réseau passthrough interne est constitué des composants Google Cloud suivants.

Composant Usage Exigences
Adresse IP interne Il s'agit de l'adresse de l'équilibreur de charge. L'adresse IP interne doit se situer dans le même sous-réseau que la règle de transfert interne. Le sous-réseau doit se trouver dans la même région et sur le même réseau VPC que le service de backend.
Règle de transfert interne Une règle de transfert interne, associée à l'adresse IP interne, constitue l'interface de l'équilibreur de charge. Elle définit le protocole et les ports acceptés par l'équilibreur de charge, et dirige le trafic vers un service de backend régional interne. Les règles de transfert des équilibreurs de charge réseau passthrough internes doivent :
avoir un schéma d'équilibrage de charge (load-balancing-scheme) défini sur INTERNAL ;
• utiliser le protocole IP (ip-protocol) TCP ou UDP, selon le protocole (protocol) du service de backend ;
• référencer un sous-réseau (subnet) dans le même réseau VPC et dans la même région que le service de backend.
Service de backend régional interne Le service de backend régional interne définit le protocole utilisé pour communiquer avec les backends et spécifie une vérification d'état. Les backends peuvent être des groupes d'instances non gérés, des groupes d'instances gérés zonaux, des groupes d'instances gérés régionaux ou des NEG zonaux avec des points de terminaison GCE_VM_IP. Le service de backend doit :
• avoir un schéma d'équilibrage de charge (load-balancing-scheme) défini sur INTERNAL ;
• utiliser le protocole (protocol) TCP ou UDP, selon le protocole IP (ip-protocol) de la règle de transfert ;
• être associé à une vérification d'état ;
• être associé à une région. La règle de transfert et tous les backends doivent se trouver dans la même région que le service de backend
• être associé à un seul réseau VPC ; Lorsqu'il n'est pas spécifié, le réseau est déduit en fonction du réseau utilisé par l'interface réseau par défaut de chaque VM de backend (nic0)).

Bien que le service de backend ne soit pas lié à un sous-réseau spécifique, le sous-réseau de la règle de transfert doit se trouver sur le même réseau VPC que le service de backend.
Vérification de l'état Chaque service de backend doit être associé à une vérification d'état. La vérification de l'état définit les paramètres qui permettent à Google Cloud de déterminer si les backends qu'il gère sont autorisés à recevoir du trafic. Seules les VM backend opérationnelles reçoivent le trafic envoyé par les VM clientes à l'adresse IP de l'équilibreur de charge.
 Même si la règle de transfert et le service de backend peuvent utiliser TCP ou UDP, Google Cloud n'effectue pas de vérification d'état pour le trafic UDP. Pour en savoir plus, consultez la section Vérifications d'état et trafic UDP.

Un équilibreur de charge réseau passthrough interne n'est pas compatible avec :

Adresse IP interne

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les sous-réseaux IPv4 uniquement (pile unique) et les sous-réseaux IPv4 et IPv6 (double pile). Pour plus d'informations, consultez la section Types de sous-réseaux.

Un équilibreur de charge réseau passthrough interne nécessite au moins une règle de transfert. La règle de transfert référence l'adresse IP interne :

  • Pour le trafic IPv4, la règle de transfert référence une adresse IPv4 de la plage de sous-réseau IPv4 principale.
  • Pour le trafic IPv6, la règle de transfert référence une plage d'adresses IPv6 internes /96 de la plage d'adresses IPv6 internes du sous-réseau /64. Le sous-réseau doit être un sous-réseau à deux piles avec une plage d'adresses IPv6 internes (ipv6-access-type défini sur INTERNAL).

Configuration du pare-feu

Les équilibreurs de charge réseau passthrough internes doivent configurer les règles de pare-feu hiérarchiques et les règles de pare-feu VPC comme suit :

Pour en savoir plus, consultez la section Configurer les règles de pare-feu.

Règles de transfert

Une règle de transfert spécifie le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic. Les équilibreurs de charge réseau passthrough internes n'étant pas des proxys, ils transmettent le trafic aux backends sur le même protocole et le même port.

Un équilibreur de charge réseau passthrough interne nécessite au moins une règle de transfert interne. Vous pouvez définir plusieurs règles de transfert pour le même équilibreur de charge.

Si vous souhaitez que l'équilibreur de charge gère à la fois le trafic IPv4 et IPv6, créez deux règles de transfert : une règle pour le trafic IPv4 qui pointe vers les backends IPv4 (ou double pile), et une règle pour le trafic IPv6 qui pointe uniquement vers les backends à deux piles. Il est possible de disposer d'une règle de transfert IPv4 et d'une règle de transfert IPv6 faisant référence au même service de backend, mais le service de backend doit faire référence à des backends à double pile.

La règle de transfert doit référencer un sous-réseau spécifique sur le même réseau VPC et dans la même région que les composants backend de l'équilibreur de charge. Cette exigence a les implications suivantes :

  • Le sous-réseau que vous spécifiez pour la règle de transfert n'a pas besoin d'être identique à l'un des sous-réseaux utilisés par les VM de backend. Toutefois, le sous-réseau doit se trouver dans la même région que la règle de transfert.
  • Pour le trafic IPv4, la règle de transfert interne référence l'adresse IPv4 interne régionale de la plage d'adresses IPv4 principale du sous-réseau que vous sélectionnez. Cette adresse IPv4 peut être sélectionnée automatiquement ou vous pouvez utiliser une adresse IPv4 statique (réservée).
  • Pour le trafic IPv6, la règle de transfert référence une plage d'adresses IP /96 de la plage d'adresses IPv6 internes du sous-réseau. Le sous-réseau doit être un sous-réseau à deux piles, avec le paramètre ipv6-access-type défini sur INTERNAL. La plage d'adresses IPv6 /96 est attribuée automatiquement ou vous pouvez utiliser une adresse IP interne réservée.

Protocoles de règles de transfert

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options de protocole IPv4 suivantes pour chaque règle de transfert : TCP, UDP ou L3_DEFAULT.

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options de protocole IPv6 suivantes pour chaque règle de transfert : TCP ou UDP.

L'option L3_DEFAULT vous permet d'équilibrer la charge des protocoles TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE.

En plus d'accepter les protocoles autres que TCP et UDP, l'option L3_DEFAULT permet à une règle de transfert unique de transférer simultanément le trafic pour plusieurs protocoles Par exemple, vous pouvez non seulement effectuer des requêtes HTTP, mais aussi pinguer l'adresse IP de l'équilibreur de charge.

Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent faire référence à un service de backend utilisant le même protocole que la règle de transfert ou à un service de backend utilisant le protocole UNSPECIFIED.

Si vous utilisez le protocole L3_DEFAULT, vous devez configurer la règle de transfert de façon à accepter le trafic sur tous les ports. Pour configurer tous les ports, définissez --ports=ALL à l'aide de Google Cloud CLI ou définissez allPorts sur True à l'aide de l'API.

Le tableau suivant récapitule comment utiliser ces paramètres pour différents protocoles :

Trafic dont la charge doit être équilibrée Protocole de règle de transfert Protocole de service de backend
TCP (IPv4 ou IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 ou IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE L3_DEFAULT UNSPECIFIED

Règles de transfert et accès mondial

Les règles de transfert d'un équilibreur de charge réseau passthrough interne sont régionales, même lorsque l'accès mondial est activé. Après avoir activé l'accès mondial, l'option allowGlobalAccess de la règle de transfert régionale interne est définie sur true.

Règles de transfert et spécifications de ports

Lorsque vous créez une règle de transfert interne, vous devez sélectionner l'une des spécifications de port suivantes :

  • Spécifiez au moins un port et jusqu'à cinq ports par leur numéro.
  • Spécifiez ALL pour transférer le trafic sur tous les ports.

Une règle de transfert interne qui accepte tous les ports TCP ou tous les ports UDP permet aux VM de backend d'exécuter plusieurs applications, chacune sur son propre port. Le trafic envoyé à un port donné est transmis à l'application correspondante, et toutes les applications utilisent la même adresse IP.

Lorsque vous devez transférer le trafic sur plus de cinq ports spécifiques, associez les règles de pare-feu aux règles de transfert. Lorsque vous créez la règle de transfert, spécifiez tous les ports, puis créez des règles de pare-feu d'entrée allow qui autorisent uniquement le trafic vers les ports souhaités. Appliquez les règles de pare-feu aux VM de backend.

Vous ne pouvez pas modifier une règle de transfert après l'avoir créée. Si vous devez modifier les ports spécifiés ou l'adresse IP interne d'une règle de transfert interne, vous devez la supprimer et la recréer.

Plusieurs règles de transfert pour un même service de backend

Vous pouvez configurer plusieurs règles de transfert internes qui font toutes référence au même service de backend interne. Un équilibreur de charge réseau passthrough interne nécessite au moins une règle de transfert interne.

La configuration de plusieurs règles de transfert pour le même service de backend vous permet d'effectuer les opérations suivantes :

  • Attribuer plusieurs adresses IP à l'équilibreur de charge. Vous pouvez créer plusieurs règles de transfert, chacune utilisant une adresse IP unique. Chaque règle de transfert peut spécifier tous les ports ou un ensemble de cinq ports maximum.

  • Attribuer à l'équilibreur de charge un ensemble spécifique de ports utilisant la même adresse IP. Vous pouvez créer plusieurs règles de transfert partageant la même adresse IP, chaque règle de transfert utilisant un ensemble spécifique de cinq ports maximum. Il s'agit d'une alternative à la configuration d'une règle de transfert unique qui spécifie tous les ports.

Pour plus d'informations sur les scénarios impliquant deux règles de transfert internes minimum ou une adresse IP interne commune, consultez la page Règles de transfert multiples avec la même adresse IP.

Lorsque vous utilisez plusieurs règles de transfert internes, veillez à configurer le logiciel qui s'exécute sur vos VM de backend pour qu'il soit lié à toutes les adresses IP de la règle de transfert ou à toute adresse (0.0.0.0/0 pour IPv4 ou ::/0 pour IPv6). L'adresse IP de destination d'un paquet distribué via l'équilibreur de charge est l'adresse IP interne associée à la règle de transfert interne correspondante. Pour plus d'informations, consultez la section Paquets de requêtes et de retours TCP et UDP.

Service de backend

Chaque équilibreur de charge réseau passthrough interne dispose d'un service de backend interne régional qui définit les paramètres et le comportement des backends. Le nom du service de backend correspond au nom de l'équilibreur de charge réseau passthrough interne affiché dans la console Google Cloud.

Chaque service de backend définit les paramètres de backend suivants :

  • Protocole. Un service de backend accepte le trafic IPv4 et IPv6. Si le protocole comporte un concept de port (tel que TCP ou UDP), le service de backend envoie des paquets aux VM de backend sur le même port de destination auquel le trafic a été envoyé.

    Les services de backend sont compatibles avec les options de protocole IPv4 suivantes : TCP, UDP ou UNSPECIFIED.

    Les services de backend sont compatibles avec les options de protocole IPv6 suivantes : TCP ou UDP. Le protocole du service de backend doit se coordonner avec le protocole de règle de transfert.

    Pour obtenir le tableau des combinaisons possibles de règles de transfert et de protocoles de services de backend, consultez la page Spécification du protocole d'une règle de transfert.

  • Distribution du trafic. Un service de backend permet de distribuer le trafic en fonction d'une affinité de session configurable.

  • Vérification de l'état. Un service de backend doit être associé à une vérification d'état.

Chaque service de backend fonctionne dans une seule région et distribue le trafic pour les VM de backend sur un seul réseau VPC :

Backends de groupes d'instances et interfaces réseau

Le réseau VPC associé à un groupe d'instances est le réseau VPC utilisé par l'interface réseau nic0 de chaque VM membre.

  • Pour les groupes d'instances gérés (MIG), le réseau VPC du groupe d'instances est défini dans le modèle d'instance.
  • Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini comme le réseau VPC utilisé par l'interface réseau nic0 de la première instance de VM que vous ajoutez au groupe d'instances non géré.

Dans un groupe d'instances donné (géré ou non), toutes les instances de VM doivent avoir leurs interfaces réseau nic0 sur le même réseau VPC. Chaque VM membre peut éventuellement avoir des interfaces réseau supplémentaires (nic1 via nic7), mais chaque interface réseau doit être associée à un réseau VPC différent. Ces réseaux doivent également être différents du réseau VPC associé au groupe d'instances.

Backends de NEG zonaux et interfaces réseau

Lorsque vous créez un NEG zonal avec des points de terminaison GCE_VM_IP, vous devez explicitement associer le NEG au sous-réseau d'un réseau VPC avant de pouvoir lui attribuer des points de terminaison. Ni le sous-réseau ni le réseau VPC ne peuvent être modifiés une fois le NEG créé.

Dans un NEG donné, chaque point de terminaison GCE_VM_IP représente une interface réseau. L'interface réseau doit se trouver dans le sous-réseau associé au NEG. Du point de vue d'une instance Compute Engine, l'interface réseau peut utiliser n'importe quel identifiant (nic0 via nic7). Du point de vue d'un point de terminaison dans un NEG, l'interface réseau est identifiée à l'aide de son adresse IPv4 principale.

Il existe deux manières d'ajouter un point de terminaison GCE_VM_IP à un NEG :

  • Si vous ne spécifiez qu'un nom de VM (sans aucune adresse IP) lors de l'ajout d'un point de terminaison, Google Cloud exige que la VM dispose d'une interface réseau dans le sous-réseau associé au NEG. L'adresse IP choisie par Google Cloud pour le point de terminaison est l'adresse IPv4 interne principale de l'interface réseau de la VM dans le sous-réseau associé au NEG.
  • Si vous spécifiez à la fois un nom de VM et une adresse IP lors de l'ajout d'un point de terminaison, l'adresse IP que vous fournissez doit être une adresse IPv4 interne principale pour l'une des interfaces réseau de la VM. Cette interface réseau doit se trouver dans le sous-réseau associé au NEG. Notez que la spécification d'une adresse IP est redondante, car une seule interface réseau peut se trouver dans le sous-réseau associé au NEG.

Spécification du réseau du service de backend

Vous pouvez explicitement associer un réseau VPC à un service de backend à l'aide de l'option --network lors de la création du service de backend. Les règles du réseau du service de backend entrent en vigueur immédiatement.

Si vous omettez l'option --network lorsque vous créez un service de backend, Google Cloud utilise l'un des événements éligibles suivants pour définir implicitement le réseau VPC associé au service de backend : Une fois défini, le réseau VPC associé au service de backend ne peut plus être modifié :

  • Si le service de backend n'est pas encore associé à des backends et que vous configurez la première règle de transfert pour référencer le service de backend, Google Cloud définit le réseau VPC associé au service de backend sur le réseau VPC qui contient sous-réseau utilisé par cette règle de transfert.

  • Si le service de backend ne fait pas encore référence à une règle de transfert et que vous ajoutez le premier backend de groupe d'instances au service de backend, Google Cloud définit les paramètres du service de backend du réseau VPC au réseau VPC associé à ce premier backend de groupe d'instances. Cela signifie que le réseau VPC associé au service de backend est le réseau utilisé par l'interface réseau nic0 de chaque VM du backend du premier groupe d'instances.

  • Si le service de backend ne fait pas encore référence à une règle de transfert et que vous ajoutez le premier backend de NEG zonal (avec des points de terminaison GCE_VM_IP) au service de backend, Google Cloud définit les paramètres du service de backend du réseau VPC au réseau VPC associé à ce premier backend de NEG.

Une fois que le réseau VPC du service de backend a été défini par un événement éligible, les règles de transfert, les groupes d'instances backend ou les NEG zonaux supplémentaires que vous ajoutez doivent respecter les règles de réseau du service de backend.

Règles de réseau du service de backend

Les règles suivantes s'appliquent une fois qu'un service de backend est associé à un réseau VPC spécifique :

  • Lors de la configuration d'une règle de transfert pour référencer le service de backend, la règle de transfert doit utiliser un sous-réseau du réseau VPC du service de backend. La règle de transfert et le service de backend ne peuvent pas utiliser des réseaux VPC différents, même s'ils sont connectés via l'appairage de réseaux VPC.

  • Lorsque vous ajoutez des backends de groupe d'instances, l'une des conditions suivantes doit être remplie :

    • Le réseau VPC associé au groupe d'instances, c'est-à-dire le réseau VPC utilisé par l'interface réseau nic0 de chaque VM du groupe d'instances, doit correspondre au réseau VPC associé au service de backend.
    • Chaque VM de backend doit avoir une interface non-nic0 (nic1 à nic7) sur le réseau VPC associé au service de backend.

  • Lorsque vous ajoutez des backends de NEG zonaux disposant de points de terminaison GCE_VM_IP, le réseau VPC associé au NEG doit correspondre au réseau VPC associé au service de backend.

Sous-paramètre du backend

Le sous-paramètre de backend est une fonctionnalité facultative qui améliore les performances en limitant le nombre de backends vers lesquels le trafic est distribué.

Vous ne devez activer le sous-paramètre que si vous devez accepter plus de 250 VM de backend sur un seul équilibreur de charge. Pour en savoir plus, consultez la section Sous-paramètre du backend pour l'équilibreur de charge réseau passthrough interne.

Vérification d'état

Le service de backend de l'équilibreur de charge doit être associé à une vérification d'état globale ou régionale. Des routes spéciales en dehors du réseau VPC facilitent les communications entre les systèmes de vérification d'état et les backends.

Vous pouvez utiliser une vérification d'état existante ou en définir une nouvelle. Les équilibreurs de charge réseau passthrough internes utilisent l'état de la vérification pour déterminer comment router les nouvelles connexions, comme décrit dans la section Distribution du trafic.

Vous pouvez utiliser l'un des protocoles de vérification d'état suivants (le protocole de la vérification d'état ne doit pas nécessairement correspondre au protocole de l'équilibreur de charge) :

  • HTTP, HTTPS ou HTTP/2. Si vos VM de backend acheminent du trafic via HTTP, HTTPS ou HTTP/2, il est préférable d'utiliser une vérification d'état correspondant au protocole, car les vérifications d'état basées sur HTTP offrent des options adaptées à ce protocole. Notez que le fait de diffuser du trafic de type HTTP via un équilibreur de charge réseau passthrough interne signifie que le protocole de l'équilibreur de charge est TCP.
  • SSL ou TCP. Si vos VM de backend ne diffusent pas de trafic de type HTTP, vous devez utiliser une vérification d'état SSL ou TCP.

Quel que soit le type de vérification d'état que vous créez, Google Cloud envoie des tests de vérification d'état à l'adresse IP de la règle de transfert de l'équilibreur de charge réseau passthrough interne, à l'interface réseau dans le réseau VPC sélectionné par le service de backend de l'équilibreur de charge. Ce procédé simule la distribution du trafic à équilibrage de charge. Le logiciel s'exécutant sur vos VM de backend doit répondre à la fois au trafic soumis à l'équilibrage de charge et aux tests de vérification d'état envoyés à l'adresse IP de chaque règle de transfert (le logiciel doit écouter sur 0.0.0.0:<port> plutôt que sur une adresse IP spécifique attribuée à une interface réseau). Pour en savoir plus, consultez la section Destination des paquets associés à la vérification d'état.

Vérifications d'état et trafic UDP

Google Cloud n'offre pas de vérification d'état qui utilise le protocole UDP. Lorsque vous utilisez un équilibreur de charge réseau passthrough interne avec du trafic UDP, vous devez exécuter sur vos VM backend un service basé sur TCP pour fournir des informations de vérification d'état.

Dans cette configuration, les requêtes client sont soumises à l'équilibrage de charge à l'aide du protocole UDP, et un service TCP est utilisé pour fournir des informations aux vérifications d'état de Google Cloud. Par exemple, vous pouvez exécuter un simple serveur HTTP sur chaque VM de backend qui renvoie une réponse HTTP 200 à Google Cloud. Dans cet exemple, vous devez utiliser votre propre logique s'exécutant sur la VM de backend pour vous assurer que le serveur HTTP renvoie la réponse 200 uniquement si le service UDP est correctement configuré et exécuté.

Architecture à haute disponibilité

L'équilibreur de charge réseau passthrough interne est hautement disponible par nature. Aucune étape particulière ne permet de rendre l'équilibreur de charge hautement disponible, car le mécanisme ne repose pas sur un seul appareil ou une seule instance de VM.

Pour vous assurer que vos instances de VM de backend sont déployées dans plusieurs zones, suivez les recommandations suivantes :

  • Utilisez des groupes d'instances gérés régionaux si vous pouvez déployer votre logiciel à l'aide de modèles d'instance. Les groupes d'instances gérés régionaux distribuent automatiquement le trafic entre plusieurs zones, offrant ainsi la meilleure option pour éviter les problèmes potentiels dans une zone donnée.

  • Si vous exploitez des groupes d'instances gérés ou non gérés zonaux, utilisez plusieurs groupes d'instances dans des zones différentes (de la même région) pour le même service de backend. L'utilisation de plusieurs zones offre une protection contre les problèmes potentiels dans une zone donnée.

Architecture du VPC partagé

Le tableau suivant récapitule la configuration requise pour les équilibreurs de charge réseau passthrough internes utilisés avec les réseaux VPC partagés. Pour obtenir un exemple, consultez la création d'un équilibreur de charge réseau passthrough interne sur la page Provisionner un VPC partagé.

Adresse IP Règle de transfert Composants backend
Une adresse IP interne doit être définie dans le même projet que les VM de backend.

Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, l'adresse IP interne de Google Cloud doit être définie dans le même projet de service que les VM de backend et doit faire référence à un sous-réseau du réseau VPC partagé souhaité dans le projet hôte. L'adresse elle-même provient de la plage d'adresses IP principale du sous-réseau référencé.

Si vous créez une adresse IP interne dans un projet de service et que le sous-réseau d'adresses IP se trouve dans le réseau VPC du projet de service, votre équilibreur de charge réseau passthrough interne est local au projet de service. Il n'est associé à aucun projet hôte du réseau VPC partagé.		 Une règle de transfert interne doit être définie dans le même projet que les VM de backend.

Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, la règle de transfert interne doit être définie dans le même projet de service que les VM backend et elle doit faire référence au même sous-réseau (dans le réseau VPC partagé) que celui auquel l'adresse IP interne associée fait référence.

Si vous créez une règle de transfert interne dans un projet de service et que le sous-réseau de la règle de transfert se trouve dans le réseau VPC du projet de service, votre équilibreur de charge réseau passthrough interne est local au projet de service. Il n'est associé à aucun projet hôte du réseau VPC partagé.		 Dans un scénario de VPC partagé, les VM backend sont situées dans un projet de service. Un service de backend interne régional et une vérification d'état doivent être définis dans ce projet de service.

Répartition du trafic

La façon dont un équilibreur de charge réseau passthrough interne distribue les nouvelles connexions dépend du fait que vous ayez ou non configuré le basculement :

  • Si vous n'avez pas configuré le basculement, un équilibreur de charge réseau passthrough interne distribue les nouvelles connexions à ses VM backend opérationnelles si au moins l'une d'entre elles est opérationnelle. Lorsqu'aucune VM de backend n'est opérationnelle, l'équilibreur de charge distribue les nouvelles connexions entre tous les backends, en dernier recours. Dans ce cas, l'équilibreur de charge achemine chaque nouvelle connexion vers une VM de backend non opérationnelle.

  • Si vous avez configuré le basculement, un équilibreur de charge réseau passthrough interne distribue les nouvelles connexions entre les VM de son pool actif, selon une stratégie de basculement que vous configurez. Lorsqu'aucune VM de backend n'est opérationnelle, vous pouvez choisir l'un des comportements suivants :

    • (Par défaut) L'équilibreur de charge ne distribue le trafic que vers les VM principales. Cette opération est réalisée en dernier recours. Les VM de secours sont exclues de cette distribution des connexions de dernier recours.
    • L'équilibreur de charge est configuré pour abandonner le trafic.

La méthode de distribution des nouvelles connexions dépend du paramètre d'affinité de session de l'équilibreur de charge.

La vérification d'état contrôle la distribution des nouvelles connexions. Par défaut, les connexions TCP persistent sur les backends non opérationnels. Pour en savoir plus et découvrir comment modifier ce comportement, consultez la section Persistance des connexions sur les backends non opérationnels.

Sélection du backend et suivi des connexions

Les équilibreurs de charge réseau passthrough internes utilisent des algorithmes de sélection et de suivi des connexions configurables pour déterminer la façon dont le trafic est distribué entre les VM backend. Les équilibreurs de charge réseau passthrough internes utilisent l'algorithme suivant pour distribuer les paquets entre les VM backend (dans son pool actif, si vous avez configuré le basculement) :

  1. Si l'équilibreur de charge possède une entrée dans sa table de suivi des connexions correspondant aux caractéristiques d'un paquet entrant, le paquet est envoyé au backend spécifié par l'entrée de la table de suivi des connexions. Le paquet étant considéré comme faisant partie d'une connexion établie précédemment, il est envoyé à la VM de backend que l'équilibreur de charge a précédemment déterminée et enregistrée dans sa table de suivi des connexions.

  2. Lorsque l'équilibreur de charge reçoit un paquet pour lequel il n'a aucune entrée de suivi de connexion, l'équilibreur de charge effectue les opérations suivantes :

    1. L'équilibreur de charge sélectionne un backend. L'équilibreur de charge calcule un hachage en fonction de l'affinité de session configurée. Il utilise ce hachage pour sélectionner un backend :

      • Si au moins un backend est opérationnel, le hachage sélectionne l'un des backends opérationnels.
      • Si aucun backend n'est opérationnel et qu'aucune règle de basculement n'est configurée, le hachage sélectionne l'un des backends.
      • Si aucun des backends n'est opérationnel, qu'une règle de basculement est configurée et que cette règle n'est pas configurée pour abandonner le trafic dans cette situation, le hachage sélectionne l'un des backends de VM principaux.

      L'affinité de session par défaut NONE utilise un hachage à cinq tuples de l'adresse IP source, du port source, de l'adresse IP de destination et du port de destination du paquet, ainsi que du protocole.

      La sélection du backend peut être personnalisée à l'aide d'un algorithme de hachage qui utilise moins d'informations. Pour connaître toutes les options compatibles, consultez la section Options d'affinité de session.

    2. L'équilibreur de charge ajoute une entrée à sa table de suivi des connexions. Cette entrée enregistre le backend sélectionné pour la connexion du paquet afin que tous les futurs paquets de cette connexion soient envoyés au même backend. L'utilisation du suivi des connexions dépend du protocole :

      Pour les paquets TCP et UDP, le suivi des connexions est toujours activé et ne peut pas être désactivé. Par défaut, le suivi des connexions est assuré par un hachage à cinq tuples, mais il peut être configuré à un niveau inférieur.

      Lorsque le hachage de suivi des connexions est à cinq tuples, les paquets TCP SYN créent toujours une entrée dans la table de suivi des connexions.

      Le suivi de connexion par défaut à cinq tuples est utilisé lorsque :

      • le mode de suivi est PER_CONNECTION (toutes les affinités de session), ou
      • le mode de suivi est PER_SESSION et l'affinité de session est NONE, ou
      • le mode de suivi est PER_SESSION et l'affinité de session est CLIENT_IP_PORT_PROTO.

      Pour en savoir plus sur l'utilisation du suivi des connexions et sur la méthode de suivi utilisée, consultez la section Mode de suivi des connexions.

      Notez également les points suivants :

      • Par défaut, une entrée de la table de suivi des connexions expire 600 secondes après le traitement du dernier paquet correspondant à l'entrée par l'équilibreur de charge. Pour en savoir plus sur la personnalisation du délai d'inactivité, consultez la section Délai d'inactivité.
      • Selon le protocole, l'équilibreur de charge peut supprimer les entrées de la table de suivi des connexions lorsque les backends ne sont plus opérationnels. Pour plus d'informations et pour personnaliser ce comportement, consultez la section Persistance des connexions sur les backends non opérationnels.

Options d'affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux VM backend de l'équilibreur de charge. Vous définissez l'affinité de session lorsque vos VM de backend doivent suivre les informations d'état de leurs clients. Il s'agit d'une exigence courante pour les applications Web.

L'affinité de session fonctionne de la manière la plus optimale possible.

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options d'affinité de session suivantes, que vous spécifiez pour l'ensemble du service de backend interne, et non pour chaque groupe d'instances de backend.

  • Aucune (NONE) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination
  • Adresse IP client, aucune destination (CLIENT_IP_NO_DESTINATION). Hachage à un tuple créé à partir de l'adresse IP source uniquement.
  • Adresse IP client (CLIENT_IP) : hachage à deux tuples composé de l'adresse IP source et de l'adresse IP de destination. Les équilibreurs de charge réseau passthrough externes appellent l'option d'affinité de session Adresse IP client, adresse IP de destination.
  • Adresse IP client, adresse IP de destination, protocole (CLIENT_IP_PROTO) : hachage à trois tuples composé de l'adresse IP source, de l'adresse IP de destination et du protocole
  • Adresse IP client, port client, adresse IP de destination, port de destination, protocole (CLIENT_IP_PORT_PROTO) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

À moins que vous n'utilisiez l'équilibreur de charge comme saut suivant pour une route statique personnalisée, l'adresse IP de destination d'un paquet doit correspondre à l'adresse IP de la règle de transfert de l'équilibreur de charge pour que le paquet soit distribué à l'équilibreur de charge. Pour en savoir plus concernant l'utilisation de l'équilibreur de charge en tant que saut suivant pour une route statique personnalisée, consultez la section Affinité de session et équilibreur de charge réseau passthrough interne comme saut suivant.

Affinité de session et équilibreur de charge réseau passthrough interne comme saut suivant

Lorsque vous utilisez un équilibreur de charge réseau passthrough interne en tant que saut suivant pour une route statique personnalisée, la destination du paquet n'est probablement pas l'adresse IP de la règle de transfert de l'équilibreur de charge.

Un paquet est distribué à l'équilibreur de charge si la destination du paquet correspond à la destination de la route statique personnalisée et que la route statique personnalisée est une route applicable.

Toutes les options d'affinité de session, à l'exception de l'adresse IP client, aucune destination utilisent l'adresse IP de destination du paquet. Lorsque vous utilisez une route statique personnalisée dont le saut suivant est un équilibreur de charge réseau passthrough interne :

  • Si votre équilibreur de charge ne comporte qu'un seul backend (son pool actif, si vous avez configuré le basculement), toutes les options d'affinité de session choisissent ce backend. Le choix d'affinité de session ne fait pas de différence lorsqu'il existe un seul backend (dans le pool actif).

  • Si votre équilibreur de charge comporte plusieurs backends (dans son pool actif, si vous avez configuré le basculement) et que vous choisissez une option d'affinité de session à l'exception de l'adresse IP client, aucune destination, les paquets envoyés depuis le même client vers n'importe quelle adresse IP de la destination de la route ne sont pas garantis d'être traités par le même backend. En effet, le hachage d'affinité de session est calculé à partir d'informations incluant l'adresse IP de destination du paquet, qui peut être n'importe quelle adresse dans la plage de destination de la route.

  • Si vous devez vous assurer que le même backend traite tous les paquets envoyés depuis le même client vers une adresse IP dans la destination de la route, vous devez utiliser l'option d'affinité de session Adresse IP client, aucune destination.

Mode de suivi des connexions

Le mode de suivi spécifie l'algorithme de suivi des connexions à utiliser. Il existe deux modes de suivi : PER_CONNECTION (par défaut) et PER_SESSION.

  • PER_CONNECTION (par défaut). Dans ce mode, le trafic TCP et UDP est toujours suivi par hachage à cinq tuples, quel que soit le paramètre d'affinité de session. Cela implique que la clé de suivi des connexions (cinq tuples) peut être différente du paramètre d'affinité de session configuré (par exemple, trois tuples avec le paramètre CLIENT_IP_PROTO). Par conséquent, l'affinité de session peut être divisée et les nouvelles connexions pour une session peuvent sélectionner un backend différent si l'ensemble des backends ou leur état change.

  • PER_SESSION. Dans ce mode, le trafic TCP et UDP est suivi en fonction de l'affinité de session configurée. En d'autres termes, si l'affinité de session est CLIENT_IP ou CLIENT_IP_PROTO, la configuration de ce mode entraîne respectivement un suivi des connexions à deux tuples et à trois tuples. Cela peut être souhaitable dans les scénarios où l'affinité est coûteuse et doit être évitée même après l'ajout de plus de backends.

Le paramètre de mode de suivi des connexions est redondant si l'affinité de session est définie sur NONE ou CLIENT_IP_PORT_PROTO. Pour comprendre comment ces modes de suivi fonctionnent avec différents paramètres d'affinité de session pour chaque protocole, consultez le tableau suivant.

Sélection du backend Mode de suivi des connexions
Paramètre d'affinité de session Méthode de hachage pour la sélection du backend PER_CONNECTION (par défaut) PER_SESSION
Par défaut : aucune affinité de session

NONE

 Hachage à cinq tuples Suivi des connexions à cinq tuples Suivi des connexions à cinq tuples

Adresse IP client, aucune destination

CLIENT_IP_NO_DESTINATION

 Hachage à un tuple Suivi des connexions à cinq tuples Suivi des connexions à un tuple

IP client

CLIENT_IP

(identique à "Adresse IP client, adresse IP de destination" pour les équilibreurs de charge réseau passthrough externes)

 Hachage à deux tuples Suivi des connexions à cinq tuples Suivi des connexions à deux tuples

Adresse IP client, adresse IP de destination, protocole

CLIENT_IP_PROTO

 Hachage à trois tuples Suivi des connexions à cinq tuples Suivi des connexions à trois tuples

Adresse IP client, port client, adresse IP de destination, port de destination, protocole

CLIENT_IP_PORT_PROTO

 Hachage à cinq tuples Suivi des connexions à cinq tuples Suivi des connexions à cinq tuples

Pour savoir comment modifier le mode de suivi des connexions, consultez la page Configurer une règle de suivi des connexions.

Persistance des connexions sur les backends non opérationnels

La persistance des connexions sur les paramètres de backends non opérationnels détermine si une connexion existante est conservée sur un backend sélectionné après que ce backend n'est plus opérationnel (tant que le backend reste dans le groupe d'instances configuré du backend de l'équilibreur de charge).

Le comportement décrit dans cette section ne s'applique pas aux cas où vous supprimez une VM de backend de son groupe d'instances ou du groupe d'instances du service de backend. Dans ce cas, les connexions établies ne sont conservées que comme décrit dans la section Activer le drainage de connexion.

Les options de persistance de connexion suivantes sont disponibles :

  • DEFAULT_FOR_PROTOCOL (par défaut)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

Le tableau suivant récapitule les options de persistance des connexions et indique leur comportement de persistance en fonction des différents protocoles, options d'affinité de session et modes de suivi.

Persistance de connexion sur les backends non opérationnels Mode de suivi des connexions
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)

UDP : les connexions ne persistent jamais sur les backends non opérationnels

TCP : les connexions persistent sur les backends non opérationnels si l'affinité de session est NONE ou CLIENT_IP_PORT_PROTO

UDP : les connexions ne persistent jamais sur les backends non opérationnels
NEVER_PERSIST TCP, UDP : les connexions ne persistent jamais sur les backends non opérationnels
ALWAYS_PERSIST

TCP, UDP : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)

N'utilisez cette option que pour les cas d'utilisation avancée.

 Configuration impossible

Pour savoir comment modifier le comportement de la persistance des connexions, consultez la page Configurer une règle de suivi des connexions.

Délai d'inactivité

Par défaut, une entrée de la table de suivi des connexions expire 600 secondes après que l'équilibreur de charge a traité le dernier paquet correspondant à l'entrée. Cette valeur de délai d'inactivité par défaut ne peut être modifiée que lorsque le suivi des connexions est inférieur à cinq tuples (c'est-à-dire, lorsque l'affinité de session est configurée pour être CLIENT_IP ou CLIENT_IP_PROTO, et que le mode de suivi est PER_SESSION).

La valeur maximale du délai d'inactivité configurable est de 57 600 secondes (16 heures).

Pour savoir comment modifier la valeur du délai d'inactivité, consultez la section Configurer une règle de suivi des connexions.

Tester les connexions à partir d'un seul client

Lorsque vous testez des connexions à l'adresse IP d'un équilibreur de charge réseau passthrough interne à partir d'un seul système client, gardez les points suivants à l'esprit :

  • Si le système client n'est pas une VM soumise à l'équilibrage de charge (c'est-à-dire, si ce n'est pas une VM de backend), les nouvelles connexions sont distribuées aux VM de backend opérationnelles de l'équilibreur de charge. Toutefois, comme toutes les options d'affinité de session dépendent au moins de l'adresse IP du système client, les connexions du même client peuvent être distribuées à la même VM de backend plus souvent que prévu.

    En pratique, cela signifie que vous ne pouvez pas surveiller précisément la distribution du trafic via un équilibreur de charge réseau passthrough interne en vous y connectant à partir d'un seul client. Le nombre de clients requis pour surveiller la distribution du trafic dépend du type d'équilibreur de charge, du type de trafic et du nombre de backends opérationnels.

  • Si la VM cliente est une VM de backend de l'équilibreur de charge, les connexions envoyées à l'adresse IP de la règle de transfert de l'équilibreur de charge sont toujours traitées par la VM cliente/VM de backend. Cela se produit que la VM de backend soit opérationnelle ou non, et pour tout le trafic envoyé à l'adresse IP de l'équilibreur de charge, pas uniquement pour le trafic sur le protocole et les ports spécifiés dans la règle de transfert interne de l'équilibreur de charge.

    Pour en savoir plus, consultez la section Envoyer des requêtes à partir de VM soumises à l'équilibrage de charge.

Fragmentation UDP

Les équilibreurs de charge réseau passthrough internes peuvent traiter à la fois les paquets UDP fragmentés et non fragmentés. Si votre application utilise des paquets UDP fragmentés, gardez à l'esprit les points suivants :
  • Les paquets UDP peuvent être fragmentés avant d'atteindre un réseau VPC Google Cloud.
  • Les réseaux VPC Google Cloud transfèrent les fragments UDP dès leur arrivée (sans attendre que tous les fragments arrivent).
  • Les réseaux non-Google Cloud et l'équipement réseau sur site peuvent transférer les fragments UDP à leur arrivée, retarder les paquets UDP fragmentés jusqu'à ce que tous les fragments soient arrivés, ou supprimer les paquets UDP fragmentés. Pour en savoir plus, consultez la documentation du fournisseur réseau ou de l'équipement réseau.

Si vous prévoyez des paquets UDP fragmentés et que vous devez les acheminer vers les mêmes backends, utilisez la règle de transfert et les paramètres de configuration de service de backend suivants :

  • Configuration de la règle de transfert : N'utilisez qu'une seule règle de transfert UDP par adresse IP à équilibrage de charge, puis configurez la règle de transfert de façon à accepter le trafic sur tous les ports. Les fragments arriveront ainsi à la même règle de transfert. Même si les paquets fragmentés (autres que le premier fragment) ne disposent pas de port de destination, la configuration de la règle de transfert lui permettant de traiter le trafic pour tous les ports permet également de recevoir des fragments UDP dépourvus d'informations de port. Pour configurer tous les ports, utilisez Google Cloud CLI pour définir --ports=ALL ou l'API pour définir allPorts sur True.

  • Configuration du service de backend : Définissez l'affinité de session du service de backend sur CLIENT_IP (hachage à deux tuples) ou CLIENT_IP_PROTO (hachage à trois tuples) de sorte que le même backend soit sélectionné pour les paquets UDP incluant des informations de port et pour les fragments UDP (autres que le premier fragment) dépourvus d'informations de port. Définissez le mode de suivi des connexions du service de backend sur PER_SESSION afin que les entrées de la table de suivi des connexions soient créées à l'aide des mêmes hachages à deux ou trois tuples.

Basculement

Un équilibreur de charge réseau passthrough interne vous permet de désigner certains backends en tant que backends de basculement. Ces backends ne sont utilisés que lorsque le nombre de VM opérationnelles dans les groupes d'instances backend principales est inférieur à un seuil configurable. Par défaut, si aucune VM principale ni aucune VM de basculement ne sont opérationnelles, Google Cloud ne distribue les nouvelles connexions qu'entre toutes les VM principales en dernier recours.

Lorsque vous ajoutez un backend au service de backend d'un équilibreur de charge réseau passthrough interne, ce backend est par défaut un backend principal. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend de l'équilibreur de charge, ou en modifiant le service de backend ultérieurement.

Pour obtenir une présentation détaillée du concept de basculement dans les équilibreurs de charge réseau passthrough internes, consultez la page Basculement pour les équilibreurs de charge réseau passthrough internes.

Quotas et limites

Pour en savoir plus sur les quotas et les limites, consultez la page Quotas et limites des ressources d'équilibrage de charge.

Limites

  • Vous ne pouvez pas utiliser la console Google Cloud pour créer un équilibreur de charge réseau interne à stratégie directe avec des backends de NEG zonaux.

Étapes suivantes