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

Cette page explique les concepts de distribution du trafic par les équilibreurs de charge réseau passthrough internes.

Sélection du backend et suivi des connexions

La sélection du backend et le suivi des connexions fonctionnent ensemble pour équilibrer plusieurs connexions entre différents backends et acheminer tous les paquets de chaque connexion vers le même backend. Pour ce faire, vous devez suivre une stratégie en deux parties. Tout d'abord, un backend est sélectionné à l'aide d'un hachage cohérent. Cette sélection est ensuite enregistrée dans un tableau de suivi des connexions.

Les étapes suivantes décrivent le processus de sélection du backend et de suivi des connexions.

1. Vérifiez si une entrée de la table de suivi des connexions utilise un backend précédemment sélectionné.

Pour une connexion existante, l'équilibreur de charge utilise la table de suivi des connexions pour identifier le backend précédemment sélectionné pour cette connexion.

L'équilibreur de charge tente de faire correspondre chaque paquet à équilibrage de charge à une entrée de sa table de suivi des connexions à l'aide du processus suivant :

• Si le paquet est un paquet TCP avec l'indicateur SYN :

  • Si le mode de suivi des connexions de l'équilibreur de charge est PER_CONNECTION, passez à l'étape Identifier les backends éligibles. En mode de suivi PER_CONNECTION, un paquet TCP avec l'indicateur SYN représente toujours une nouvelle connexion, quelle que soit l'affinité de session configurée.

  • Si le mode de suivi des connexions de l'équilibreur de charge est PER_SESSION et que l'affinité de session est NONE ou CLIENT_IP_PORT_PROTO, passez à l'étape Identifier les backends éligibles. En mode de suivi PER_SESSION, un paquet TCP avec l'indicateur SYN ne représente une nouvelle connexion que lorsque vous utilisez l'une des options d'affinité de session à cinq tuples (NONE ou CLIENT_IP_PORT_PROTO).

• Pour tous les autres paquets, l'équilibreur de charge vérifie si le paquet correspond à une entrée de table de suivi des connexions existante. Le tuple de connexion (un ensemble de caractéristiques de paquet) utilisé pour comparer le paquet aux entrées de table de suivi des connexions existantes dépend du mode de suivi des connexions et de l'affinité de session que vous avez configurés. Pour en savoir plus sur le tuple de connexion utilisé pour le suivi des connexions, consultez le tableau de la section Mode de suivi des connexions.

  • Si le paquet correspond à une entrée de la table de suivi des connexions, l'équilibreur de charge l'envoie au backend précédemment sélectionné.

  • Si le paquet ne correspond pas à une entrée de la table de suivi des connexions, passez à l'étape Identifier les backends éligibles.

  Pour en savoir plus sur la durée de conservation d'une entrée de table de suivi des connexions et les conditions de cette conservation, consultez l'étape Créer une entrée de table de suivi des connexions.

2. Sélectionnez un backend éligible pour une nouvelle connexion.

Pour une nouvelle connexion, l'équilibreur de charge utilise l'algorithme de hachage cohérent pour sélectionner un backend parmi les backends éligibles du pool actif.

Les étapes suivantes décrivent le processus de sélection d'un backend éligible pour une nouvelle connexion, puis d'enregistrement de cette connexion dans un tableau de suivi des connexions.

2.1 Identifier les backends éligibles

Cette étape modélise les backends candidats à recevoir de nouvelles connexions, en tenant compte de l'état et de la configuration de la règle de bascule :

• Aucune stratégie de basculement : l'ensemble des backends éligibles ne dépend que des vérifications d'état :

  • Lorsque au moins un backend est opérationnel, l'ensemble des backends éligibles se compose de tous les backends opérationnels.

  • Lorsque tous les backends sont non opérationnels, l'ensemble des backends éligibles se compose de tous les backends.

• Stratégie de basculement configurée : l'ensemble des backends éligibles dépend des vérifications de l'état et de la configuration de la stratégie de basculement :

  • Lorsque au moins un backend est opérationnel, l'ensemble des backends éligibles se compose de tous les backends opérationnels du pool actif.

    • Le pool actif peut être constitué de tous les backends principaux opérationnels ou de tous les backends de basculement opérationnels. L'appartenance au pool actif est déterminée par le taux de basculement configuré, le nombre de backends principaux opérationnels et le nombre total de backends principaux.

    • Indépendamment du taux de basculement, si aucun backend de basculement opérationnel n'existe, mais qu'il existe au moins un backend principal opérationnel, le pool actif se compose de tous les backends principaux opérationnels.

  • Lorsque les backends ne sont pas opérationnels et que la stratégie de basculement de l'équilibreur de charge est configurée pour supprimer les nouvelles connexions, l'ensemble des backends éligibles est vide. L'équilibreur de charge abandonne les paquets de la connexion.

  • Lorsque les backends ne sont pas opérationnels et que la stratégie de basculement de l'équilibreur de charge n'est pas configurée pour supprimer les nouvelles connexions, les vérifications d'état ne sont pas pertinentes. Les backends éligibles sont tous les backends principaux.

2.2 Sélectionnez un backend éligible.

L'équilibreur de charge utilise le hachage cohérent pour sélectionner un backend éligible. L'équilibreur de charge gère les hachages des backends éligibles, mappés sur un cercle unitaire. Lorsque l'équilibreur de charge traite un paquet pour une connexion qui ne figure pas dans la table de suivi des connexions, il calcule un hachage des caractéristiques du paquet et le met en correspondance avec le même cercle unitaire, en sélectionnant un backend éligible sur la circonférence du cercle. L'ensemble des caractéristiques des paquets utilisées pour calculer le hachage des paquets est défini par le paramètre d'affinité de session.

• Si une affinité de session n'est pas configurée explicitement, l'affinité de session NONE est utilisée par défaut.

• L'équilibreur de charge attribue les nouvelles connexions aux backends éligibles de manière aussi cohérente que possible, même si le nombre de backends éligibles change. Les avantages suivants du hachage cohérent montrent comment l'équilibreur de charge sélectionne les backends éligibles pour les nouvelles connexions potentielles qui n'ont pas d'entrées de table de suivi des connexions :

  • L'équilibreur de charge sélectionne le même backend pour toutes les nouvelles connexions possibles qui présentent des caractéristiques de paquet identiques, comme défini par l'affinité de session, si l'ensemble des backends éligibles ne change pas.

  • Lorsqu'un nouveau backend éligible est ajouté, environ 1/N nouvelles connexions sont mappées sur le backend nouvellement ajouté. Dans ce cas, N correspond au nombre de backends éligibles après l'ajout du nouveau backend.

  • Lorsqu'un backend éligible est supprimé, environ 1/N nouvelles connexions possibles sont mappées sur l'un des N-1 backends restants. Dans ce cas, N correspond au nombre de backends avant la suppression du backend éligible.

2.3 Créer une entrée de table de suivi des connexions

Après avoir sélectionné un backend, l'équilibreur de charge crée une entrée de table de suivi des connexions. L'entrée de la table de suivi des connexions met en correspondance les caractéristiques des paquets avec le backend sélectionné. Les champs d'en-tête de paquet utilisés pour ce mappage dépendent du mode de suivi des connexions et de l'affinité de session que vous avez configurés.

L'équilibreur de charge supprime les entrées de la table de suivi des connexions conformément aux règles suivantes :

• Une entrée de la table de suivi des connexions est supprimée une fois la connexion inactive. Sauf si vous configurez un délai d'inactivité personnalisé, l'équilibreur de charge utilise un délai d'inactivité par défaut de 600 secondes. Pour en savoir plus, consultez la section Délai avant expiration de l'inactivité.

• Les entrées de la table de suivi des connexions ne sont pas supprimées lorsqu'une connexion TCP est fermée avec un paquet FIN ou RST. Toute nouvelle connexion TCP porte toujours l'indicateur SYN et est traitée comme décrit à l'étape Vérifier une entrée de table de suivi des connexions.

• Si une règle de basculement est configurée et que le drainage de connexion en cas de basculement et de restauration est désactivé, l'équilibreur de charge supprime toutes les entrées du tableau de suivi des connexions lorsque le pool actif change lors d'un basculement ou d'une restauration. Pour en savoir plus, consultez la section Drainage de connexion en cas de basculement et de retour.

• Les entrées de la table de suivi des connexions peuvent être supprimées si un backend ne fonctionne plus. Ce comportement dépend du mode de suivi des connexions, du protocole et du paramètre de persistance des connexions sur les backends non opérationnels. Pour en savoir plus, consultez la section Persistance des connexions sur les backends non opérationnels.

• Les entrées du tableau de suivi des connexions sont supprimées après le délai avant expiration du drainage de connexion qui se produit après un événement tel que la suppression d'une VM de backend ou la suppression d'une VM de backend d'un groupe d'instances ou d'un NEG. Pour en savoir plus, consultez la section Activer le drainage de connexion.

Affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux backends de l'équilibreur de charge. Les équilibreurs de charge réseau passthrough internes utilisent l'affinité de session pour sélectionner un backend parmi un ensemble de backends éligibles, comme décrit dans les étapes Identifier les backends éligibles et Sélectionner un backend éligible de la section Sélection de backend et suivi des connexions. Vous configurez l'affinité de session sur le service de backend, et non sur chaque groupe d'instances backend ou NEG.

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les paramètres d'affinité de session suivants. Chaque paramètre d'affinité de session utilise un hachage cohérent pour sélectionner un backend éligible. Le paramètre d'affinité de session détermine les champs de l'en-tête IP et des en-têtes de couche 4 utilisés pour calculer le hachage.

Pour découvrir comment les différents paramètres d'affinité de session affectent la sélection du backend et les méthodes de suivi des connexions, consultez le tableau de la section Mode de suivi des connexions.

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. 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 (hachage à un tuple), 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 sur cette 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 des connexions
• Persistance des connexions sur les backends non opérationnels
• Délai d'inactivité

Mode de suivi des connexions

La table de suivi des connexions de l'équilibreur de charge mappe les tupels de connexion aux backends précédemment sélectionnés dans une table de hachage. L'ensemble des caractéristiques des paquets qui composent chaque tuple de connexion est déterminé par le mode de suivi des connexions et l'affinité de session.

Les équilibreurs de charge réseau passthrough internes suivent les connexions pour tous les protocoles qu'ils prennent en charge.

Le mode de suivi des connexions fait référence à la granularité de chaque tuple de connexion dans la table de suivi des connexions de l'équilibreur de charge. Le tuple de connexion peut être un tuple à cinq ou trois tuples (mode PER_CONNECTION), ou correspondre au paramètre d'affinité de session (mode PER_SESSION).

• PER_CONNECTION : il s'agit du mode de suivi des connexions par défaut. Ce mode de suivi des connexions utilise un hachage à cinq ou trois tuples. Les paquets non fragmentés qui incluent des informations sur le port, tels que les paquets TCP et les paquets UDP non fragmentés, sont suivis à l'aide de hachages à cinq tuples. Tous les autres paquets sont suivis à l'aide de hachages à trois tuplets.

• PER_SESSION : ce mode de suivi des connexions utilise un hachage composé des mêmes caractéristiques de paquets que le hachage d'affinité de session. En fonction de l'affinité de session choisie, PER_SESSION peut entraîner des connexions qui correspondent plus fréquemment à une entrée de table de suivi des connexions existante, ce qui réduit la fréquence à laquelle un backend doit être sélectionné par le hachage d'affinité de session.

Le tableau suivant récapitule la manière dont le mode de suivi des connexions et l'affinité de session fonctionnent ensemble pour acheminer tous les paquets de chaque connexion vers le même backend.

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

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.

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

Délai d'inactivité

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

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

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

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 de backend), les nouvelles connexions sont transmises aux VM de 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 du 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 que la VM de backend soit opérationnelle ou non. et pour tout le trafic envoyé à l'adresse IP de l'équilibreur de charge, pas uniquement pour le trafic sur le protocole et les ports spécifiés dans la règle de transfert interne de l'équilibreur de charge.

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

Drainage de connexion

Le drainage de connexion fournit une durée supplémentaire configurable pour que les connexions établies persistent dans la table de suivi des connexions de l'équilibreur de charge lorsqu'une des actions suivantes se produit :

• Une instance de machine virtuelle (VM) est supprimée d'un groupe d'instances de backend (cela inclut l'abandon d'une instance dans un groupe d'instances géré de backend)
• Une VM est arrêtée ou supprimée (cela inclut les actions automatiques telles que les mises à niveau progressives ou la réduction de capacité d'un groupe d'instances géré de backend)
• Un point de terminaison est supprimé d'un groupe de points de terminaison du réseau (NEG) de backend

Par défaut, le drainage de connexion pour les actions mentionnées ci-dessus est désactivé. 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 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 en savoir plus sur l'utilisation du basculement pour la sélection du backend et le suivi des connexions, consultez les étapes Identifier les backends éligibles et Créer une entrée de table de suivi des connexions dans la section Sélection du backend et suivi des connexions.

Pour en savoir plus sur le fonctionnement du basculement, consultez la page Basculement des équilibreurs de charge réseau passthrough interne.

Étapes suivantes

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