Distribution du trafic pour les équilibreurs de charge réseau passthrough internes

Cette page décrit les concepts suivants pour vous aider à mieux comprendre et à personnaliser la façon dont les équilibreurs de charge réseau passthrough internes distribuent le trafic: affinité de session, suivi des connexions, fragmentation UDP et basculement.

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

Remarque : Pour les équilibreurs de charge UDP internes, la définition de l'affinité de session est possible dans gcloud CLI et dans l'API. Vous ne pouvez pas définir l'affinité de session pour le trafic UDP à l'aide de la console Google Cloud .

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

Lorsque vous configurez une route statique pour utiliser un équilibreur de charge réseau passthrough interne de prochain saut, l'équilibreur de charge utilise la même méthode de suivi du backend et de la connexion que celle décrite précédemment. La sélection du backend est toujours effectuée en calculant un hachage en fonction de l'affinité de session configurée. À l'exception de l'affinité de session CLIENT_IP_NO_DESTINATION, le hachage de sélection du backend dépend, en partie, de l'adresse IP de destination du paquet.

Lorsqu'un équilibreur de charge réseau passthrough interne est le prochain saut d'une route statique, l'adresse IP de destination n'est pas limitée à l'adresse IP de la règle de transfert de l'équilibreur de charge. À la place, l'adresse IP de destination du paquet peut être n'importe quelle adresse IP qui se trouve dans la plage de destination de la route statique.

Si le nombre de VM backend configurées et opérationnelles est constant (lorsque le basculement n'est pas configuré ou, lorsque le basculement est configuré, mais qu'aucun événement de basculement ou de retour n'a lieu), l'équilibreur de charge se comporte comme suit :

• Si une seule VM de backend est configurée et opérationnelle (dans le pool actif, si le basculement est configuré), l'affinité de session que vous utilisez n'a pas d'importance, car tous les hachages sont mappés à la seule VM de backend.

• Si plusieurs VM de backend configurées et opérationnelles sont présentes (dans le pool actif, si le basculement est configuré), le choix de l'affinité de session est important :

  • Si vous avez besoin que la même VM de backend traite tous les paquets d'un client, uniquement en fonction de l'adresse IP source du paquet, quelle que soit l'adresse IP de destination du paquet, utilisez l'affinité de session CLIENT_IP_NO_DESTINATION. Selon les modèles de trafic, certaines VM de backend peuvent recevoir plus de paquets ou de connexions que d'autres.

  • Si vous utilisez une option d'affinité de session autre que CLIENT_IP_NO_DESTINATION, l'équilibreur de charge sélectionne une VM de backend en fonction d'informations qui incluent au moins à la fois l'adresse IP source et l'adresse IP de destination du paquet. Les paquets envoyés par le même client, à l'aide de la même adresse IP source, mais avec des adresses IP de destination différentes, peuvent être acheminés vers différentes VM backend.

Règle de suivi de connexion

Cette section décrit les paramètres qui contrôlent le comportement de suivi des connexions des équilibreurs de charge réseau passthrough internes. Une règle de suivi des connexions inclut les paramètres suivants:

• Mode de suivi
• Persistance des connexions sur les backends non opérationnels
• Délai d'inactivité

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.

Remarque : Lorsque l'équilibreur de charge déplace une connexion à partir d'un backend non opérationnel, il crée une entrée de table de suivi. La nouvelle entrée mappe la connexion à un backend différent en fonction de l'affinité de session configurée. La nouvelle entrée reste valide, comme toute autre entrée. Si le backend non opérationnel redevient opérationnel, cela seul n'entraîne pas la suppression de l'entrée de la table de suivi des connexions (à moins que cela déclenche une restauration automatique et que le drainage de connexion lors du basculement et de la restauration ait été désactivé).

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.

Connexions pour les déploiements à un seul client

Lorsque vous testez des connexions à l'adresse IP d'un équilibreur de charge réseau passthrough interne qui ne compte qu'un seul client, gardez les points suivants à l'esprit:

• Si la VM cliente n'est pas une VM équilibrée en charge (c'est-à-dire qu'elle n'est pas également une VM backend), les nouvelles connexions sont transmises aux VM backend opérationnelles de l'équilibreur de charge. Toutefois, comme toutes les options d'affinité de session reposent au moins sur l'adresse IP du système client, les connexions d'un même client peuvent être distribuées à la même VM backend plus fréquemment que vous ne le pensez.

  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 également une VM 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 même VM backend (qui est également la VM cliente). Cela se produit quel que soit l'état de la VM backend. Cela se produit pour tout le trafic envoyé à l'adresse IP de l'équilibreur de charge, pas seulement 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.

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é).

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 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.
• Google Cloud Les réseaux VPC transfèrent les fragments UDP dès leur arrivée (sans attendre que tous les fragments arrivent).
• Les réseaux autres queGoogle 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.

Étape suivante

• Pour configurer et tester un équilibreur de charge réseau passthrough interne qui utilise le basculement, consultez la page Configurer le basculement pour les équilibreurs de charge réseau à stratégie interne.
• Pour configurer et tester un équilibreur de charge réseau passthrough interne, consultez la page Configurer un équilibreur de charge réseau à stratégie interne.