Présentation de l'équilibreur de charge réseau passthrough externe basé sur un service de backend

Les équilibreurs de charge réseau passthrough externes sont des équilibreurs de charge régionaux de couche 4 qui distribuent du trafic externe entre les backends (groupes d'instances ou groupes de points de terminaison du réseau, aussi appelés NEG) dans la même région que l'équilibreur de charge. Ces backends doivent se trouver dans la même région et le même projet, mais peuvent se trouver sur des réseaux VPC différents. Ces équilibreurs de charge sont basés sur Maglev et la pile de virtualisation de réseau Andromeda.

Les équilibreurs de charge réseau passthrough externes peuvent recevoir du trafic provenant de :

  • N'importe quel client sur Internet
  • VM Google Cloud avec adresses IP externes
  • VM Google Cloud ayant accès à Internet via Cloud NAT ou une NAT basée sur une instance

Les équilibreurs de charge réseau passthrough externes ne sont pas des proxys. L'équilibreur de charge lui-même ne met pas fin aux connexions des utilisateurs. Les paquets à équilibrage de charge sont envoyés aux VM de backend avec leurs adresses IP source et de destination, leur protocole et, le cas échéant, leurs ports, inchangés. Les VM de backend mettent ensuite fin aux connexions des utilisateurs. Les réponses de ces VM de backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Ce processus est appelé retour direct du serveur.

Les équilibreurs de charge réseau passthrough externes basés sur un service de backend sont compatibles avec les fonctionnalités suivantes :

  • Backends de groupes d'instances gérés et non gérés. Les équilibreurs de charge réseau passthrough externes basés sur un service de backend acceptent les groupes d'instances gérés et non gérés en tant que backends. Les groupes d'instances gérés automatisent certains aspects de la gestion des backends, et offrent une meilleure évolutivité et davantage de fiabilité que les groupes d'instances non gérés.
  • Backends de NEG zonaux. Les équilibreurs de charge réseau passthrough externes basés sur un service de backend sont compatibles avec l'utilisation de NEG zonaux avec des points de terminaison GCE_VM_IP. Les points de terminaison GCE_VM_IP de NEG zonaux vous permettent d'effectuer les opérations suivantes :
    • Transférez des paquets vers n'importe quelle interface réseau, pas seulement nic0.
    • Placez le même point de terminaison GCE_VM_IP dans au moins deux NEG zonaux connectés à différents services de backend.
  • Compatibilité avec plusieurs protocoles. Les équilibreurs de charge réseau passthrough externes basés sur un service de backend peuvent équilibrer la charge du trafic TCP, UDP, ESP, GRE, ICMP et ICMPv6.
  • Compatibilité avec la connectivité IPv6 Les équilibreurs de charge réseau passthrough externes basés sur un service de backend peuvent gérer à la fois le trafic IPv4 et IPv6.
  • Contrôle ultraprécis de la répartition du trafic. Un service de backend permet de distribuer le trafic en fonction d'une affinité de session configurable, d'un mode de suivi des connexions et d'un équilibrage de charge pondéré. Le service de backend peut également être configuré afin d'activer le drainage de connexion et de désigner des backends de basculement pour l'équilibreur de charge. La plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration afin de démarrer rapidement.
  • Compatibilité avec les vérifications d'état non héritées. Les équilibreurs de charge réseau passthrough externes basés sur un service de backend vous permettent d'utiliser des vérifications d'état qui correspondent au type de trafic (TCP, SSL, HTTP, HTTPS ou HTTP/2) qu'ils distribuent.
  • Intégration de Google Cloud Armor Google Cloud Armor est compatible avec la protection DDoS avancée du réseau pour les équilibreurs de charge réseau passthrough externes. Pour en savoir plus, consultez la page Configurer la protection DDoS avancée du réseau.

  • Intégration de GKE Si vous créez des applications dans GKE, nous vous recommandons d'utiliser le contrôleur de service GKE intégré, qui déploie des équilibreurs de charge Google Cloud pour le compte des utilisateurs de GKE. Cela est identique à l'architecture d'équilibrage de charge autonome décrite sur cette page, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE.

    Documentation GKE associée :

Architecture

Le schéma suivant illustre les composants d'un équilibreur de charge réseau passthrough externe :

Équilibreur de charge réseau passthrough externe direct avec un service de backend régional
Équilibreur de charge réseau passthrough externe avec un service de backend régional

L'équilibreur de charge est constitué de plusieurs composants de configuration. Un équilibreur de charge unique peut inclure les composants suivants :

  • Une ou plusieurs adresses IP externes régionales
  • Une ou plusieurs règles de transfert externes régionales
  • Un service de backend externe régional
  • Un ou plusieurs backends : tous les groupes d'instances ou tous les backends de NEG zonaux (points de terminaison GCE_VM_IP)
  • Vérification de l'état associée au service de backend

En outre, vous devez créer des règles de pare-feu permettant à votre trafic d'équilibrage de charge et aux requêtes de vérification d'état d'atteindre les VM de backend.

Adresse IP

Un équilibreur de charge réseau passthrough externe nécessite au moins une règle de transfert. La règle de transfert fait référence à une adresse IP externe régionale accessible partout sur Internet.

  • Pour le trafic IPv4, la règle de transfert fait référence à une seule adresse IPv4 externe régionale. Les adresses IPv4 externes régionales proviennent d'un pool propre à chaque région Google Cloud. L'adresse IP peut être une adresse statique réservée ou une adresse éphémère.

  • Pour le trafic IPv6, la règle de transfert fait référence à une plage /96 d'un sous-réseau double pile avec une plage de sous-réseaux IPv6 externe dans le réseau VPC. Les adresses IPv6 externes ne sont disponibles qu'avec le niveau Premium. La plage d'adresses IPv6 peut être une adresse statique réservée ou une adresse éphémère.

Utilisez une adresse IP réservée pour la règle de transfert si vous devez conserver l'adresse associée à votre projet pour pouvoir la réutiliser après avoir supprimé une règle de transfert ou si vous avez besoin de plusieurs règles de transfert pour faire référence à la même adresse IP.

Les équilibreurs de charge réseau externes sont compatibles avec les niveaux Standard et Premium pour les adresses IPv4 externes régionales. L'adresse IP et la règle de transfert doivent utiliser le même niveau réseau. Les adresses IPv6 externes régionales ne sont disponibles qu'avec le niveau Premium.

Règle de transfert

Une règle de transfert externe régionale spécifie le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic. Les équilibreurs de charge réseau passthrough externes n'étant pas des proxys, ils transmettent le trafic aux backends sur le même protocole et le même port si le paquet contient des informations sur le port. La règle de transfert et l'adresse IP forment l'interface de l'équilibreur de charge.

L'équilibreur de charge conserve les adresses IP sources des paquets entrants. L'adresse IP de destination des paquets entrants est une adresse IP associée à la règle de transfert de l'équilibreur de charge.

Le trafic entrant est mis en correspondance avec une règle de transfert, qui consiste en la combinaison d'une adresse IP particulière (adresse IPv4 ou plage d'adresses IPv6) et d'un protocole. Si le protocole est basé sur le port, il doit utiliser l'un des ports, une plage de ports ou tous les ports. La règle de transfert dirige ensuite le trafic vers le service de backend de l'équilibreur de charge.

  • Si la règle de transfert fait référence à une adresse IPv4, elle n'est associée à aucun sous-réseau. Autrement dit, son adresse IP provient d'une plage de sous-réseau autre que Google Cloud.

  • Si la règle de transfert fait référence à une plage d'adresses IPv6 /96, la règle de transfert doit être associée à un sous-réseau, et ce sous-réseau doit (a) être à double pile et (b) avoir une plage de sous-réseaux IPv6 externe (--ipv6-access-type défini sur EXTERNAL).Le sous-réseau auquel la règle de transfert fait référence peut être le même sous-réseau utilisé par les instances backend. Cependant, les instances backend peuvent utiliser un sous-réseau distinct si vous le souhaitez. Lorsque les instances backend utilisent un sous-réseau distinct, les conditions suivantes doivent être remplies :

Un équilibreur de charge réseau passthrough externe nécessite au moins une règle de transfert. Les règles de transfert peuvent être configurées pour diriger le trafic provenant d'une plage spécifique d'adresses IP sources vers un service de backend (ou une instance cible) spécifique. Pour en savoir plus, consultez Orientation du trafic. Vous pouvez définir plusieurs règles de transfert pour le même équilibreur de charge, comme décrit dans la section Plusieurs règles de transfert.

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.

Protocoles de règles de transfert

Les équilibreurs de charge réseau passthrough externes acceptent les options de protocole suivantes pour chaque règle de transfert : TCP, UDP et L3_DEFAULT.

Utilisez les options TCP et UDP pour configurer l'équilibrage de charge TCP ou UDP. L'option de protocole L3_DEFAULT permet à un équilibreur de charge réseau passthrough externe d'équilibrer le trafic TCP, UDP, ESP, GRE, ICMP et ICMPv6.

En plus d'accepter les protocoles autres que TCP et UDP, l'option L3_DEFAULT permet à une règle de transfert de diffuser plusieurs protocoles. Par exemple, les services IPSec gèrent généralement une certaine combinaison de trafic IKE basé sur ESP et UDP, et de trafic NAT-T. L'option L3_DEFAULT permet de configurer une seule règle de transfert pour traiter tous ces protocoles.

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 dont le protocole est UNSPECIFIED. Les règles de transfert L3_DEFAULT ne peuvent faire référence qu'à un service de backend avec 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 TCP TCP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE,
ICMP/ICMPv6 (requête d'écho uniquement)
 L3_DEFAULT UNSPECIFIED

Plusieurs règles de transfert

Vous pouvez configurer plusieurs règles de transfert externes régionales pour un même équilibreur de charge réseau passthrough externe. Chaque règle de transfert peut avoir sa propre adresse IP externe régionale, ou plusieurs règles de transfert peuvent avoir la même adresse IP externe régionale.

La configuration de plusieurs règles de transfert externes régionales peut être utile dans les cas suivants :

  • Vous devez configurer plusieurs adresses IP externes pour le même service de backend.
  • Vous devez configurer différents protocoles, ou des ports ou plages de ports qui ne se chevauchent pas, pour une même adresse IP externe.
  • Vous devez orienter le trafic de certaines adresses IP sources vers des backends d'équilibreur de charge spécifiques.

Google Cloud exige que les paquets entrants ne correspondent pas à plus d'une règle de transfert. À l'exception des règles de transfert qui sont décrites dans la section suivante, deux règles de transfert ou plus utilisant la même adresse IP externe régionale doivent posséder des combinaisons uniques de protocole et de port, conformément aux contraintes suivantes :

  • Une règle de transfert configurée pour tous les ports d'un protocole empêche la création d'autres règles de transfert utilisant le même protocole et la même adresse IP. Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent être configurées pour utiliser tous les ports, ou elles peuvent être configurées pour des ports spécifiques. Par exemple, si vous créez une règle de transfert basée sur l'adresse IP 198.51.100.1, le protocole TCP et tous les ports, vous ne pouvez pas créer d'autre règle de transfert spécifiant l'adresse IP 198.51.100.1 et le protocole TCP. Vous pouvez créer deux règles de transfert, utilisant toutes deux l'adresse IP 198.51.100.1 et le protocole TCP, si chacune dispose de ports uniques ou de plages de ports qui ne se chevauchent pas. Par exemple, vous pouvez créer deux règles de transfert spécifiant l'adresse IP 198.51.100.1 et le protocole TCP, avec l'une de ces règles de transfert utilisant les ports 80,443, et l'autre la plage de ports 81-442.
  • Une seule règle de transfert L3_DEFAULT peut être créée par adresse IP. En effet, le protocole L3_DEFAULT utilise par définition tous les ports, ce qui inclut les protocoles sans informations de port.

  • Une seule règle de transfert L3_DEFAULT peut coexister avec d'autres règles de transfert qui utilisent des protocoles spécifiques (TCP ou UDP). La règle de transfert L3_DEFAULT peut être utilisée en dernier recours, en présence de règles de transfert utilisant la même adresse IP, mais avec des protocoles plus spécifiques. Une règle de transfert L3_DEFAULT traite les paquets envoyés à son adresse IP de destination si et seulement si l'adresse IP de destination, le protocole et le port de destination du paquet ne correspondent pas à une règle de transfert spécifique au protocole.

    Pour illustrer cela, prenons pour exemple ces deux scénarios, dans lesquels les règles de transfert utilisent la même adresse IP 198.51.100.1.

    • Scénario 1. La première règle de transfert utilise le protocole L3_DEFAULT. La deuxième règle de transfert utilise le protocole TCP et tous les ports. Les paquets TCP envoyés à n'importe quel port de destination de l'adresse 198.51.100.1 sont traités par la deuxième règle de transfert. Les paquets utilisant des protocoles différents sont traités par la première règle de transfert.
    • Scénario 2. La première règle de transfert utilise le protocole L3_DEFAULT. La deuxième règle de transfert utilise le protocole TCP et le port 8080. Les paquets TCP envoyés à l'adresse 198.51.100.1:8080 sont traités par la seconde règle de transfert. Tous les autres paquets, y compris les paquets TCP envoyés à d'autres ports de destination, sont traités par la première règle de transfert.

Sélection des règles de transfert

Google Cloud sélectionne une règle de transfert (ou aucune règle) pour traiter un paquet entrant à l'aide du processus d'élimination ci-après, en commençant par l'ensemble de règles de transfert applicables à l'adresse IP de destination du paquet :

  • Éliminer les règles de transfert dont le protocole ne correspond pas au protocole du paquet, à l'exception des règles de transfert L3_DEFAULT. Les règles de transfert utilisant le protocole L3_DEFAULT ne sont jamais éliminées à cette étape, car L3_DEFAULT correspond à tous les protocoles. Par exemple, si le protocole du paquet est TCP, seules les règles de transfert utilisant le protocole UDP sont éliminées.

  • Éliminer les règles de transfert dont le port ne correspond pas au port du paquet. Les règles de transfert configurées pour tous les ports ne sont jamais éliminées à cette étape, car elles correspondent comme leur nom l'indique à n'importe quel port.

  • Si les règles de transfert applicables restantes incluent à la fois des règles de transfert L3_DEFAULT et des règles de transfert spécifiques à un protocole, éliminer les règles de transfert L3_DEFAULT. Si les règles de transfert applicables restantes sont toutes des règles de transfert L3_DEFAULT, aucune n'est éliminée à cette étape.

  • À ce stade, les règles de transfert applicables restantes peuvent se présenter comme suit :

    • Il ne reste qu'une seule règle de transfert, correspondant à l'adresse IP de destination, au protocole et au port du paquet, et qui est utilisée pour acheminer le paquet.
    • Il reste au moins deux règles de transfert applicables, qui correspondent à l'adresse IP de destination, au protocole et au port du paquet. Cela signifie que les règles de transfert applicables restantes incluent des règles de transfert d'orientation (décrites dans la section suivante). Sélectionnez la règle de transfert d'orientation dont la plage source inclut le CIDR le plus spécifique (correspondance du préfixe le plus long), contenant l'adresse IP source du paquet. Si aucune règle de transfert d'orientation n'a de plage source englobant l'adresse IP source du paquet, sélectionnez la règle de transfert parente.
    • Il ne reste aucune règle de transfert applicable et le paquet est supprimé.

Lorsque vous utilisez plusieurs règles de transfert, veillez à configurer le logiciel qui s'exécute sur vos VM backend, de sorte qu'il soit lié à toutes les adresses IP externes des règles de transfert de l'équilibreur de charge.

Orientation du trafic

Les règles de transfert des équilibreurs de charge réseau passthrough externes peuvent être configurées pour diriger le trafic provenant d'une plage spécifique d'adresses IP sources vers un service de backend (ou une instance cible) spécifique.

L'orientation du trafic est utile pour le dépannage et pour les configurations avancées. Avec l'orientation du trafic, vous pouvez diriger certains clients vers un ensemble de backends différent, une configuration de service de backend différente, ou les deux à la fois. Exemple :

  • L'orientation du trafic vous permet de créer deux règles de transfert qui dirigent le trafic vers le même groupe d'instances backend ou NEG, via deux services de backend. Les deux services de backend peuvent être configurés avec différentes vérifications d'état, différentes affinités de session ou différentes règles de contrôle de la distribution du trafic (suivi des connexions, drainage de connexion et basculement).
  • L'orientation du trafic vous permet de créer une règle de transfert pour rediriger le trafic d'un service de backend à faible bande passante vers un service de backend à bande passante élevée. Les deux services de backend contiennent le même ensemble de VM de backend ou de points de terminaison, mais la charge est équilibrée avec des pondérations différentes à l'aide de l'équilibrage de charge pondéré.
  • L'orientation du trafic vous permet de créer deux règles de transfert qui dirigent le trafic vers des services de backend différents, avec des backends différents (groupes d'instances ou NEG). Par exemple, un backend peut être configuré à l'aide de différents types de machines afin de mieux traiter le trafic provenant d'un certain ensemble d'adresses IP sources.

L'orientation du trafic est configurée avec un paramètre d'API de règle de transfert appelé sourceIPRanges. Les règles de transfert pour lesquelles au moins une plage d'adresses IP sources est configurée sont appelées des règles de transfert d'orientation.

Une règle de transfert d'orientation peut répertorier jusqu'à 64 plages d'adresses IP sources. Vous pouvez à tout moment mettre à jour la liste des plages d'adresses IP sources configurées pour une règle de transfert d'orientation.

Chaque règle de transfert d'orientation nécessite d'abord de créer une règle de transfert parente. Les règles de transfert parente et d'orientation partagent les mêmes adresses IP externes régionales, le même protocole et les mêmes informations de port. Cependant, la règle de transfert parente ne comporte aucune information d'adresse IP source. Exemple :

  • Règle de transfert parente : adresse IP : 198.51.100.1, protocole IP : TCP, port : 80
  • Règle de transfert d'orientation : adresse IP : 198.51.100.1, protocole IP : TCP, port : 80, plage d'adresses IP sources : 203.0.113.0/24

Une règle de transfert parente pointant vers un service de backend peut être associée à une règle de transfert d'orientation qui pointe vers un service de backend ou une instance cible.

Pour une règle de transfert parente donnée, deux règles de transfert d'orientation ou plus peuvent avoir des plages d'adresses IP sources qui se chevauchent, sans être identiques. Par exemple, une règle de transfert d'orientation peut avoir la plage d'adresses IP sources 203.0.113.0/24 et une autre règle de transfert d'orientation pour la même règle parente peut avoir la plage d'adresses IP sources 203.0.113.0.

Avant de pouvoir supprimer une règle de transfert parente, vous devez supprimer toutes les règles de transfert d'orientation dépendant de cette règle parente.

Pour savoir comment les paquets entrants sont traités lors de l'utilisation des règles de transfert d'orientation, consultez la section Sélection des règles de transfert.

Comportement d'affinité de session lors des changements d'orientation

Cette section décrit les conditions dans lesquelles l'affinité de session peut échouer lorsque les plages d'adresses IP sources pour les règles de transfert d'orientation sont mises à jour :

  • Si une connexion existante continue de correspondre à la même règle de transfert après la modification des plages d'adresses IP sources d'une règle de transfert d'orientation, l'affinité de session n'est pas interrompue. Si par contre une connexion existante correspond à une autre règle de transfert, suite à votre modification, alors :
  • l'affinité de session est toujours interrompue dans les cas suivants :
    • la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend (ou une instance cible) qui ne fait pas référence à la VM de backend précédemment sélectionnée ;
    • la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend qui fait référence à la VM de backend précédemment sélectionnée, mais le service de backend n'est pas configuré pour faire persister les connexions lorsque les backends ne sont pas opérationnels, et la VM de backend échoue à la vérification de l'état du service de backend ;
  • l'affinité de session peut être interrompue lorsque la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend, et que celui-ci fait référence à la VM précédemment sélectionnée, mais la combinaison du mode d'affinité de session et du mode de suivi des connexions du service de backend génère un hachage de suivi de connexion différent.

Préserver l'affinité de session lors des changements d'orientation

Cette section explique comment éviter d'interrompre l'affinité de session lorsque les plages d'adresses IP sources pour les règles de transfert d'orientation sont mises à jour :

  • Règles de transfert d'orientation pointant vers des services de backend. Si la règle de transfert parente et la règle de transfert d'orientation pointent vers des services de backend, vous devez vérifier manuellement que les paramètres d'affinité de session et de règle de suivi de connexion sont identiques. Google Cloud ne rejette pas automatiquement les configurations si elles ne sont pas identiques.
  • Règles de transfert d'orientation pointant vers des instances cibles. Une règle de transfert parente pointant vers un service de backend peut être associée à une règle de transfert d'orientation qui pointe vers une instance cible. Dans ce cas, la règle de transfert d'orientation hérite des paramètres d'affinité de session et de règle de suivi de connexion de la règle de transfert parente.

Pour obtenir des instructions sur la configuration de l'orientation du trafic, consultez Configurer l'orientation du trafic.

Service de backend régional

Chaque équilibreur de charge réseau passthrough externe dispose d'un service de backend régional qui définit le comportement de l'équilibreur de charge et la façon dont le trafic est distribué à ses backends. Le nom du service de backend correspond au nom de l'équilibreur de charge réseau passthrough externe affiché dans la console Google Cloud.

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

  • Protocole. Un service de backend accepte du trafic sur l'adresse IP et les ports spécifiés (le cas échéant) par une ou plusieurs règles de transfert externes régionales. Le service de backend transmet des paquets aux VM de backend tout en conservant les adresses IP source et de destination des paquets, le protocole et, si le protocole est basé sur le port, les ports source et de destination.

    Les services de backend utilisés avec les équilibreurs de charge réseau passthrough externes acceptent les options de protocole suivantes : TCP, UDP ou UNSPECIFIED.

    Les services de backend avec le protocole UNSPECIFIED peuvent être utilisés avec n'importe quelle règle de transfert, quel que soit le protocole de cette règle. Les services de backend avec un protocole spécifique (TCP ou UDP) ne peuvent être référencés que par des règles de transfert ayant le même protocole (TCP ou UDP). Les règles de transfert avec le protocole L3_DEFAULT ne peuvent faire référence qu'aux services de backend avec le protocole UNSPECIFIED.

    Pour obtenir le tableau des combinaisons possibles de règles de transfert et de protocoles de services de backend, consultez la section 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, d'un mode de suivi des connexions et d'un équilibrage de charge pondéré. Le service de backend peut également être configuré afin d'activer le drainage de connexion et de désigner des backends de basculement pour l'équilibreur de charge.

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

  • Backends : chaque service de backend fonctionne dans une seule région et distribue le trafic vers des groupes d'instances ou des NEG zonaux de la même région. 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 externe :

    • 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.

    Chaque groupe d'instances ou backend de NEG est associé à un réseau VPC, même si ce groupe d'instances ou ce NEG n'a pas encore été connecté à un service de backend. Pour en savoir plus sur la manière dont un réseau est associé à chaque type de backend, consultez les sections suivantes : Backends de groupes d'instances et interfaces réseau et Backends de NEG zonaux et interfaces réseau.

Groupes d'instances

Un équilibreur de charge réseau passthrough externe distribue les connexions entre les VM backend appartenant à des groupes d'instances gérés ou non gérés. Les groupes d'instances peuvent être régionaux ou zonaux.

Un équilibreur de charge réseau passthrough externe ne distribue que le trafic vers la première interface réseau (nic0) des VM de backend. L'équilibreur de charge accepte les groupes d'instances dont les instances membres utilisent n'importe quel réseau VPC de la même région, à condition que ce réseau VPC se trouve dans le même projet que le service de backend. (Toutes les VM d'un groupe d'instances donné doivent utiliser le même réseau VPC.)

Chaque groupe d'instances est associé à un réseau VPC, même si celui-ci n'a pas encore été connecté à un service de backend. Pour en savoir plus sur la manière dont un réseau est associé aux groupes d'instances, consultez la section Backends de groupes d'instances et interfaces réseau.

  • Groupes d'instances gérés régionaux 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.

    Un exemple de déploiement utilisant un groupe d'instances géré régional est présenté ici. Le groupe d'instances dispose d'un modèle d'instance qui définit la manière dont les instances doivent être provisionnées, et chaque groupe déploie des instances dans trois zones de la région us-central1.

    Équilibreur de charge réseau passthrough externe direct avec un groupe d'instances géré régional
    Équilibreur de charge réseau passthrough externe avec un groupe d'instances géré régional

  • Groupes d'instances gérés ou non gérés zonaux. Utilisez des groupes d'instances zonaux dans différentes zones (de la même région) pour vous protéger contre les problèmes potentiels pouvant survenir dans une zone donnée.

    Un exemple de déploiement utilisant des groupes d'instances zonaux est présenté ici. Cet équilibreur de charge assure la disponibilité sur deux zones.

    Équilibreur de charge réseau passthrough externe avec des groupes d'instances zonaux
    Équilibreur de charge réseau passthrough externe avec des groupes d'instances zonaux

NEG zonaux

Un équilibreur de charge réseau passthrough externe répartit les connexions entre les points de terminaison GCE_VM_IP contenus dans les groupes de points de terminaison du réseau zonaux. Ces points de terminaison doivent être situés dans la même région que l'équilibreur de charge. Pour obtenir des cas d'utilisation recommandés de NEG zonaux, consultez la page Présentation des groupes de points de terminaison du réseau zonaux.

Les points de terminaison du NEG doivent être des adresses IPv4 internes principales des interfaces réseau de VM situées dans le même sous-réseau et la même zone que le NEG zonal. L'adresse IPv4 interne principale de n'importe quelle interface réseau d'une instance de VM à plusieurs cartes d'interface réseau peut être ajoutée à un NEG tant qu'elle se trouve dans le sous-réseau du NEG.

Les NEG zonaux sont compatibles avec les VM IPv4 et à double pile (IPv4 et IPv6). Pour les VM IPv4 et à double pile, il est suffisant de spécifier uniquement l'instance de VM lors de l'association d'un point de terminaison à un NEG. Vous n'avez pas besoin de spécifier l'adresse IP du point de terminaison. L'instance de VM doit toujours se trouver dans la même zone que le NEG.

Chaque NEG zonal est associé à un réseau VPC et à un sous-réseau, même s'il n'a pas encore été connecté à un service de backend. Pour plus d'informations sur la manière dont un réseau est associé à des NEG zonaux, consultez la section Backends de NEG zonaux et interfaces réseau.

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.

Les services de backend ne peuvent pas distribuer de trafic vers les VM membres du groupe d'instances sur des interfaces autres que nic0. Si vous souhaitez recevoir du trafic sur une interface réseau autre que celle par défaut (nic1 via nic7), vous devez utiliser des NEG zonaux avec des points de terminaison GCE_VM_IP.

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.

Services de backend et réseaux VPC

Le service de backend n'est associé à aucun réseau VPC. Cependant, chaque groupe d'instances backend ou NEG zonal est associé à un réseau VPC, comme indiqué précédemment. Tant que tous les backends sont situés dans la même région et le même projet, et qu'ils sont du même type (groupes d'instances ou NEG zonaux), vous pouvez ajouter des backends utilisant le même réseau VPC ou un réseau VPC différent.

Pour distribuer des paquets à nic1 via nic7, vous devez utiliser des backends de NEG zonaux (avec des points de terminaison GCE_VM_IP), car le réseau VPC associé à un groupe d'instances correspond toujours au réseau VPC utilisé par l'interface nic0 de toutes les instances membres.

Backends à double pile (IPv4 et IPv6)

Si vous souhaitez que l'équilibreur de charge accepte le trafic IPv6, les backends doivent répondre aux exigences suivantes:

  • Les backends doivent être configurés dans des sous-réseaux à deux piles, situés dans la même région que la règle de transfert IPv6 de l'équilibreur de charge. Pour les backends, vous pouvez utiliser un sous-réseau avec le paramètre ipv6-access-type défini sur EXTERNAL ou INTERNAL. L'utilisation d'un sous-réseau avec ipv6-access-type défini sur INTERNAL nécessite l'utilisation d'un sous-réseau double pile distinct avec ipv6-access-type défini sur EXTERNAL pour la règle de transfert externe de l'équilibreur de charge. Pour obtenir des instructions, reportez-vous à la section Ajouter un sous-réseau double pile.
  • Les backends doivent être configurés pour être double pile, avec le paramètre --ipv6-network-tier défini sur PREMIUM. Pour obtenir des instructions, consultez la page Créer un modèle d'instance avec des adresses IPv6.

Vérifications d'état

Les équilibreurs de charge réseau passthrough externes utilisent des vérifications d'état régionales pour déterminer les instances qui peuvent recevoir de nouvelles connexions. Le service de backend de chaque équilibreur de charge réseau passthrough externe doit être associé à une vérification d'état régionale. Les équilibreurs de charge utilisent l'état de la vérification d'état pour déterminer comment acheminer les nouvelles connexions vers les instances backend.

Pour en savoir plus sur le fonctionnement des vérifications d'état de Google Cloud, consultez la page Fonctionnement des vérifications d'état.

Les équilibreurs de charge réseau passthrough externes sont compatibles avec les types de vérification d'état suivants :

Vérifications d'état pour le trafic d'autres protocoles

Google Cloud n'offre pas de vérification d'état spécifique au protocole en plus de celles répertoriées ici. Lorsque vous utilisez un équilibreur de charge réseau passthrough externe pour équilibrer la charge d'un protocole autre que TCP, vous devez quand même exécuter un service basé sur TCP sur vos VM backend pour fournir les informations requises sur la vérification d'état.

Par exemple, si vous équilibrez la charge du trafic UDP, la charge des requêtes client est équilibrée à l'aide du protocole UDP, et vous devez exécuter un service TCP pour fournir des informations aux vérificateurs d'état Google Cloud. Pour ce faire, vous pouvez exécuter un simple serveur HTTP sur chaque VM de backend qui renvoie une réponse HTTP 200 aux vérificateurs d'état. 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é.

Règles de pare-feu

Étant donné que les équilibreurs de charge réseau passthrough externes sont des équilibreurs de charge à stratégie directe, vous contrôlez l'accès aux backends de l'équilibreur de charge à l'aide de règles de pare-feu Google Cloud. Vous devez créer des règles de pare-feu ou une règle de pare-feu hiérarchique autorisant les entrées pour autoriser les vérifications d'état et le trafic dont vous équilibrez la charge.

Les règles de transfert et les règles de pare-feu ou les règles de pare-feu spécifiques autorisant les entrées fonctionnent ensemble de la manière suivante : une règle de transfert spécifie le protocole et, lorsque la règle est définie, les exigences de port qu'un paquet doit respecter pour être transféré à une VM de backend. Les règles de pare-feu autorisant les entrées contrôlent si les paquets transférés sont distribués à la VM ou supprimés. Tous les réseaux VPC possèdent une règle de pare-feu implicite interdisant les entrées qui bloque les paquets entrants, quelle que soit leur source. Le réseau VPC par défaut de Google Cloud inclut un ensemble limité de règles de pare-feu prédéfinies autorisant les entrées.

  • Pour accepter le trafic provenant de n'importe quelle adresse IP sur Internet, vous devez créer une règle de pare-feu autorisant les entrées avec la plage d'adresses IP sources 0.0.0.0/0. Pour autoriser uniquement le trafic provenant de certaines plages d'adresses IP, utilisez des plages sources plus restrictives.

  • Selon les bonnes pratiques de sécurité, vos règles de pare-feu autorisant les entrées doivent se limiter aux seuls protocoles IP et ports dont vous avez besoin. Il est particulièrement important de limiter la configuration du protocole (et, si possible, du port) lorsque vous utilisez des règles de transfert dont le protocole est défini sur L3_DEFAULT. Les règles de transfert L3_DEFAULT transfèrent les paquets pour tous les protocoles IP compatibles (sur tous les ports si le protocole et les paquets contiennent des informations de port).

  • Les équilibreurs de charge réseau passthrough externes utilisent des vérifications d'état Google Cloud. Par conséquent, vous devez toujours autoriser le trafic provenant des plages d'adresses IP associées aux vérifications d'état. Ces règles de pare-feu autorisant le trafic entrant peuvent être spécifiques au protocole et aux ports de la vérification d'état de l'équilibreur de charge.

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 IP externe associée à une VM Google Cloud ou adresse IP routable sur Internet d'un système se connectant à l'équilibreur de charge.
  • Destination : adresse IP de la règle de transfert de l'équilibreur de charge.

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.
  • Les protocoles UDP, ESP, GRE et ICMP sont sans connexion. Les VM de backend peuvent 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 externe 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, ESP, GRE, ICMP 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.

† Lorsqu'une VM possède une adresse IP externe ou lorsque vous utilisez Cloud NAT, il est également possible de définir l'adresse IP source du paquet de réponse sur l'adresse IPv4 interne principale de la carte d'interface réseau de la VM. Google Cloud ou Cloud NAT remplace l'adresse IP source du paquet de réponse par l'adresse IPv4 externe de la carte d'interface réseau ou une adresse IPv4 externe Cloud NAT afin d'envoyer le paquet de réponse à l'adresse IP externe du client. 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 externe qui ne correspond pas à l'adresse IP à laquelle il a envoyé un paquet de requête.

Chemin de retour

Les équilibreurs de charge réseau passthrough externes utilisent des routes spéciales en dehors de votre réseau VPC pour diriger les requêtes entrantes et les vérifications d'état vers chaque VM backend.

L'équilibreur de charge préserve les adresses IP sources des paquets. Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Le terme utilisé dans le secteur est retour direct du serveur.

Architecture du VPC partagé

À l'exception de l'adresse IP, tous les composants d'un équilibreur de charge réseau passthrough externe doivent exister dans le même projet. Le tableau suivant récapitule les composants du VPC partagé pour les équilibreurs de charge réseau passthrough externes :

Adresse IP Règle de transfert Composants backend
Une adresse IP externe régionale doit être définie dans le même projet que l'équilibreur de charge ou dans le projet hôte du VPC partagé. Une règle de transfert externe régionale doit être définie dans le même projet que les instances du service de backend.

Le service de backend régional doit être défini dans le même projet et dans la même région que les backends (groupe d'instances ou NEG zonal).

Les vérifications d'état associées au service de backend doivent être définies dans le même projet et dans la même région que le service de backend.

Répartition du trafic

La manière dont les équilibreurs de charge réseau passthrough externes distribuent 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 externe distribue les nouvelles connexions à ses VM backend opérationnelles si au moins l'une d'entre elles est opérationnelle. Lorsqu'aucune VM 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 backend non opérationnelle.
  • Si vous avez configuré le basculement, un équilibreur de charge réseau passthrough externe distribue les nouvelles connexions entre les VM de son pool actif, selon une règle 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 abandonne le trafic.

Pour en savoir plus sur la distribution des connexions, consultez la section suivante Sélection du backend et suivi des connexions.

Pour en savoir plus sur le fonctionnement du basculement, consultez la section Basculement.

Sélection du backend et suivi des connexions

Les équilibreurs de charge réseau passthrough externes 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 externes 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 parmi ceux qui sont actuellement opérationnels (sauf si tous les backends sont considérés comme non opérationnels, auquel cas tous les backends sont pris en compte tant la règle de basculement n'a pas été configurée pour supprimer le trafic dans cette situation. L'affinité de session par défaut, NONE, utilise les algorithmes de hachage suivants :

      • Pour les paquets TCP et UDP non fragmentés, un hachage à cinq tuples de l'adresse IP source, du port source, de l'adresse IP de destination, du port de destination et du protocole du paquet.
      • Pour les paquets UDP fragmentés et tous les autres protocoles, un hachage à trois tuples de l'adresse IP source, de l'adresse IP de destination et du protocole du paquet.

      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.

      Notez également les points suivants :

      Si vous activez l'équilibrage de charge pondéré, la sélection du backend basé sur le hachage devient pondérée en fonction des pondérations signalées par les instances backend. Exemple :

      • Prenons l'exemple d'un service de backend configuré avec l'affinité de session définie sur NONE et une règle de transfert avec le protocole UDP. S'il existe deux instances backend opérationnelles avec des pondérations 1 et 4, les backends obtiennent respectivement 20% et 80% des paquets UDP.
      • Prenons l'exemple d'un service de backend configuré avec une affinité de session à trois tuples et un suivi des connexions. L'affinité de session est CLIENT_IP_PROTO et le mode de suivi des connexions est PER_SESSION. S'il existe trois instances backend opérationnelles avec des pondérations 0, 2 et 6, les backends reçoivent respectivement le trafic pour 0%, 25% et 75% des nouvelles adresses IP sources (les adresses IP sources pour lesquelles il n'existe pas d'entrées de la table de suivi des connexions existantes). Le trafic pour les connexions existantes est dirigé vers les backends précédemment attribués.

    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 :

      • Paquets TCP. 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. Lorsqu'à cinq tuples, les paquets TCP SYN sont traités différemment. Contrairement aux paquets non-SYN, ils suppriment toute entrée de suivi de connexion correspondante et sélectionnent toujours un nouveau backend.

        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.

      • Paquets UDP, ESP et GRE. Le suivi des connexions n'est activé que si l'affinité de session est définie sur une valeur autre que NONE.

      • Paquets ICMP et ICMPv6 Il n'est pas possible d'utiliser le suivi des connexions.

      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 :

      • Une entrée dans la table de suivi des connexions expire 60 secondes après le traitement de l'équilibreur de charge par le dernier paquet correspondant à l'entrée. Cette valeur de 60 secondes d'inactivité n'est pas configurable.
      • 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. L'affinité de session est spécifiée pour l'ensemble du service de backend externe régional, et non pour chaque backend.

Les équilibreurs de charge réseau passthrough externes sont compatibles avec les options d'affinité de session suivantes :

  • 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, adresse IP de destination (CLIENT_IP) : hachage à deux tuples composé de l'adresse IP source et de l'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.

Pour découvrir comment ces options d'affinité de session affectent les méthodes de sélection du backend et de suivi des connexions, consultez ce tableau.

Mode de suivi des connexions

L'activation du suivi des connexions ne dépend que du protocole du trafic à équilibrage de charge et des paramètres d'affinité de session. Le mode de suivi spécifie l'algorithme de suivi des connexions à utiliser lorsque le suivi des connexions est activé. Il existe deux modes de suivi : PER_CONNECTION (par défaut) et PER_SESSION.

  • PER_CONNECTION (par défaut). Il s'agit du mode de suivi par défaut. Avec ce mode de suivi des connexions, le trafic TCP est toujours suivi par hachage à 5 tuples, quel que soit le paramètre d'affinité de session. Pour le trafic UDP, ESP et GRE, le suivi des connexions est activé lorsque le paramètre d'affinité de session sélectionné n'est pas NONE. Le suivi des paquets UDP, ESP et GRE s'effectue via les méthodes de suivi décrites dans ce tableau.

  • PER_SESSION. Si l'affinité de session est CLIENT_IP ou CLIENT_IP_PROTO, la configuration de ce mode entraîne le suivi des connexions à deux tuples et à trois tuples, respectivement, pour tous les protocoles (sauf ICMP et ICMPv6 qui ne sont pas compatibles avec le suivi des connexions). Pour les autres paramètres d'affinité de session, le mode PER_SESSION se comporte de la même manière que le mode PER_CONNECTION.

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)

TCP et UDP non fragmenté : hachage à cinq tuples

UDP fragmenté et tous les autres protocoles : hachage à trois tuples
  • TCP : suivi des connexions à cinq tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP : suivi des connexions à cinq tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, adresse IP de destination

(CLIENT_IP)

 Tous les protocoles : hachage à deux tuples
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP, GRE : suivi des connexions à deux tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, adresse IP de destination, protocole

(CLIENT_IP_PROTO)

 Tous les protocoles : hachage à trois tuples
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP, GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, port client, adresse IP de destination, port de destination, protocole

(CLIENT_IP_PORT_PROTO)

TCP et UDP non fragmenté : hachage à cinq tuples

UDP fragmenté et tous les autres protocoles : hachage à trois tuples
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé

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

Les paramètres de persistance de connexion contrôlent si une connexion existante persiste sur une VM de backend ou un point de terminaison sélectionné après que ce backend n'est plus opérationnel, tant que le backend reste dans le groupe de backend configuré de l'équilibreur de charge (dans un groupe d'instances ou un NEG).

Le comportement décrit dans cette section ne s'applique pas aux cas où vous supprimez une instance backend d'un groupe d'instances, un point de terminaison backend de son NEG ou le groupe d'instances ou le NEG du service de backend. Dans ce cas, les connexions établies ne sont conservées que comme décrit dans la section 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)

Tous les autres protocoles : 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

Tous les autres protocoles : les connexions ne persistent jamais sur les backends non opérationnels.
NEVER_PERSIST Tous les protocoles : les connexions ne persistent jamais sur les backends non opérationnels.
ALWAYS_PERSIST

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

ESP, GRE, UDP : les connexions persistent sur les backends non opérationnels si l'affinité de session n'est pas définie sur NONE.

ICMP, ICMPv6 : non applicable, car ces protocoles ne sont pas compatibles avec le suivi des connexions

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

 Configuration impossible

Comportement de la persistance de connexion TCP sur les backends non opérationnels

Chaque fois qu'une connexion TCP avec un suivi à cinq tuples persiste sur un backend non opérationnel :

  • Si le backend non opérationnel continue de répondre aux paquets, la connexion se poursuit jusqu'à ce qu'elle soit réinitialisée ou fermée (par le backend non opérationnel ou le client).
  • Si le backend non opérationnel envoie un paquet de réinitialisation TCP (RST) ou ne répond pas aux paquets, le client peut effectuer une nouvelle tentative de connexion, laissant ainsi l'équilibreur de charge sélectionner un autre backend opérationnel. Les paquets TCP SYN sélectionnent toujours un nouveau backend opérationnel.

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

Équilibrage de charge pondéré

Vous pouvez configurer un équilibreur de charge réseau pour répartir le trafic entre ses instances backend en fonction des pondérations signalées par une vérification d'état HTTP à l'aide de l'équilibrage de charge pondéré.

L'équilibrage de charge pondéré nécessite la configuration des deux éléments suivants:

  • Vous devez définir la règle d'équilibrage de charge de la localité (localityLbPolicy) du service de backend sur WEIGHTED_MAGLEV.
  • Vous devez configurer le service de backend avec une vérification d'état HTTP. Les réponses de vérification d'état HTTP doivent contenir un champ d'en-tête de réponse HTTP personnalisé X-Load-Balancing-Endpoint-Weight pour spécifier les pondérations avec des valeurs comprises entre 0 et 1000 pour chaque instance backend.

Si vous utilisez le même backend (groupe d'instances ou NEG) pour plusieurs équilibreurs de charge réseau passthrough externes basés sur un service de backend utilisant l'équilibrage de charge pondéré, nous vous recommandons d'utiliser un paramètre request-path unique pour chaque vérification d'état du backend. Cela permet à l'instance de point de terminaison d'attribuer différentes pondérations à différents services de backend. Pour en savoir plus, consultez la section Critères de réussite pour les vérifications d'état HTTP, HTTPS et HTTP/2.

Pour sélectionner un backend pour une nouvelle connexion, les backends se voient attribuer un ordre de priorité strict en fonction de leur pondération et de leur état de fonctionnement, comme indiqué dans le tableau suivant:

Pondération Opérationnelle Priorité de sélection du backend
Pondération supérieure à zéro Oui 4
Pondération supérieure à zéro Non 3
Pondération égale à zéro Oui 2
Pondération égale à zéro Non 1

Seuls les backends ayant la priorité la plus élevée sont éligibles à la sélection du backend. Si tous les backends éligibles ont une pondération nulle, l'équilibreur de charge répartit les nouvelles connexions entre tous les backends éligibles et les traite avec une pondération égale. Pour obtenir des exemples d'équilibrage de charge pondéré, consultez la page Sélection du backend et suivi des connexions.

L'équilibrage de charge pondéré peut être utilisé dans les scénarios suivants:

  • Si certaines connexions traitent plus de données que d'autres ou que certaines connexions existent plus longtemps que d'autres, la distribution de la charge du backend peut être inégale. En signalant une pondération par instance inférieure, une instance avec une charge élevée peut réduire sa part des nouvelles connexions, tout en conservant les connexions existantes.

  • Si un backend est surchargé et que l'attribution de connexions supplémentaires peut interrompre les connexions existantes, ces backends s'attribuent zéro pondération. En signalant une pondération nulle, une instance backend cesse de traiter les nouvelles connexions, mais continue à desservir les connexions existantes.

  • Si un backend draine des connexions existantes avant la maintenance, il s'attribue une pondération nulle. En signalant une pondération nulle, l'instance backend cesse de traiter les nouvelles connexions, mais continue à traiter les connexions existantes.

Pour en savoir plus, consultez la page Configurer l'équilibrage de charge pondéré.

Drainage de connexion

Le drainage de connexion est un processus appliqué aux connexions établies dans les cas suivants :

  • Une VM ou un point de terminaison est supprimé d'un backend (groupe d'instances ou NEG).
  • Un backend supprime une VM ou un point de terminaison (en cas de remplacement, d'abandon, de mises à niveau progressives ou de réduction de capacité).
  • Un backend est supprimé d'un service de backend.

Par défaut, le drainage de connexion est désactivé. Dans ce cas, les connexions établies sont interrompues le plus rapidement possible. Lorsque le drainage de connexion est activé, les connexions établies sont autorisées à persister pendant un délai configurable, après quoi l'instance de VM de backend est arrêtée.

Pour en savoir plus sur le déclenchement et l'activation du drainage de connexion, consultez la page Activer le drainage de connexion.

Fragmentation UDP

Les équilibreurs de charge réseau passthrough externes basés sur un service de backend 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 ou L3_DEFAULT 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.

Utiliser des instances cibles en tant que backends

Si vous utilisez des instances cibles en tant que backends pour l'équilibreur de charge réseau passthrough externe et prévoyez des paquets UDP fragmentés, utilisez une seule règle de transfert UDP ou L3_DEFAULT par adresse IP et configurez la règle de transfert pour qu'elle accepte le trafic sur tous les ports. Cela garantit que tous les fragments arrivent à la même règle de transfert, même s'ils n'ont pas le même port de destination. Pour configurer tous les ports, définissez --ports=ALL à l'aide de gcloud ou définissez allPorts sur True à l'aide de l'API.

Basculement

Vous pouvez configurer un équilibreur de charge réseau passthrough externe pour répartir les connexions entre les instances de VM ou les points de terminaison des backends principaux (groupes d'instances ou NEG), puis, si nécessaire, utiliser des backends de basculement. Avec le basculement, vous disposez d'une autre méthode permettant d'augmenter la disponibilité tout en étant mieux à même de contrôler la gestion de votre charge de travail lorsque les backends principaux ne sont pas opérationnels.

Par défaut, lorsque vous ajoutez un backend à un service de backend d'un équilibreur de charge réseau passthrough externe, ce backend est 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 en savoir plus sur le fonctionnement du basculement, consultez la page Présentation du basculement pour les équilibreurs de charge réseau passthrough externes.

Limites

  • Vous ne pouvez pas effectuer les tâches suivantes à l'aide de Google Cloud Console :

    • Créez ou modifiez un équilibreur de charge réseau passthrough externe dont la règle de transfert utilise le protocole L3_DEFAULT.
    • Créez ou modifiez un équilibreur de charge réseau passthrough externe dont le protocole de service de backend est défini sur UNSPECIFIED.
    • Créez ou modifiez un équilibreur de charge réseau passthrough externe qui configure une règle de suivi des connexions.
    • Créer ou modifier l'orientation du trafic basée sur l'adresse IP source pour une règle de transfert.

    Utilisez plutôt Google Cloud CLI ou l'API REST.

  • Les équilibreurs de charge réseau passthrough externes ne sont pas compatibles avec l'appairage de réseaux VPC.

Étapes suivantes