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

Cette page explique comment les équilibreurs de charge réseau passthrough internes distribuent le trafic.

Sélection du backend et suivi des connexions

La sélection du backend et le suivi des connexions fonctionnent ensemble pour équilibrer plusieurs connexions sur différents backends et pour acheminer tous les paquets de chaque connexion vers le même backend. Pour ce faire, nous avons mis en place 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. Rechercher une entrée dans la table de suivi des connexions pour utiliser 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 en suivant le 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 défini sur PER_SESSION et que l'affinité de session est définie sur 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 représente une nouvelle connexion uniquement 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 existante dans la table de suivi des connexions. Le tuple de connexion (ensemble de caractéristiques de paquets) utilisé pour comparer le paquet aux entrées existantes de la table de suivi des connexions dépend du mode de suivi des connexions et de l'affinité de session que vous avez configurés. Pour savoir quel tuple de connexion est 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 savoir combien de temps une entrée de table de suivi des connexions est conservée et dans quelles conditions, consultez l'étape Créer une entrée de table de suivi des connexions.

2. Sélectionner 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 l'enregistrement de cette connexion dans un tableau de suivi des connexions.

2.1 Identifier les backends éligibles

Cette étape modélise les backends susceptibles de recevoir de nouvelles connexions, en tenant compte de l'état et de la configuration de la stratégie de reprise après sinistre :

• Aucune règle de basculement : l'ensemble des backends éligibles dépend uniquement des vérifications de l'état :

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

• Règle de basculement configurée : l'ensemble des backends éligibles dépend de la configuration des vérifications de l'état et de la règle de basculement :

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

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

  • Lorsqu'il n'y a pas de backends 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 pour la connexion.

  • Lorsque aucun backend n'est opérationnel et que la règle 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 dans ce cas. Les backends éligibles sont tous les backends principaux.

2.2 Ajuster les backends éligibles pour l'affinité zonale

Cette étape est ignorée si l'une des conditions suivantes est remplie :

• L'affinité zonale est désactivée
• Le client est incompatible avec l'affinité zonale
• Aucune correspondance zonale n'est établie avec la zone d'un client compatible.

Si l'affinité zonale est activée, qu'un client est compatible avec l'affinité zonale et qu'une correspondance zonale se produit, les nouvelles connexions du client sont acheminées vers un ensemble ajusté de backends éligibles. Pour en savoir plus, consultez les ressources suivantes :

• Fonctionnement de ZONAL_AFFINITY_STAY_WITHIN_ZONE

• Fonctionnement de ZONAL_AFFINITY_SPILL_CROSS_ZONE et du ratio de basculement

2.3 Sélectionner un backend éligible

L'équilibreur de charge utilise le hachage cohérent pour sélectionner un backend éligible. L'équilibreur de charge conserve les hachages des backends éligibles, mappés sur un cercle unité. Lors du traitement d'un paquet pour une connexion qui ne figure pas dans la table de suivi des connexions, l'équilibreur de charge calcule un hachage des caractéristiques du paquet et mappe ce hachage au même cercle unité, 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 aucune affinité de session n'est explicitement configurée, l'affinité de session NONE est définie par défaut.

• L'équilibreur de charge attribue de nouvelles connexions aux backends éligibles de la manière la plus cohérente 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 possibles qui n'ont pas d'entrées dans la 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, telles que définies 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 possibles sont mappées au 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 à l'un des N-1 backends restants. Dans ce cas, N correspond au nombre de backends avant la suppression du backend éligible.

2.4 Créer une entrée dans le tableau de suivi des connexions

Après avoir sélectionné un backend, l'équilibreur de charge crée une entrée dans la table de suivi des connexions. L'entrée de la table de suivi des connexions mappe les caractéristiques des paquets au 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 selon les règles suivantes :

• Une entrée de table de suivi des connexions est supprimée une fois la connexion inactive. À moins que vous ne configuriez 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 Délai d'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 comporte toujours l'indicateur SYN et est traitée comme décrit dans l'étape Rechercher une entrée dans la table de suivi des connexions.

• Si une règle de basculement est configurée et que le paramètre de drainage de connexion lors du basculement et de la 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 du basculement ou de la restauration. Pour en savoir plus, consultez Drainage de connexion lors du basculement et du rétablissement.

• Les entrées de la table de suivi des connexions peuvent être supprimées si un backend devient non opérationnel. 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 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 à la suite d'un événement tel que la suppression d'une VM de backend ou le retrait d'une VM de backend d'un groupe d'instances ou d'un NEG. Pour en savoir plus, consultez 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 du 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 le hachage cohérent pour sélectionner un backend éligible. Le paramètre d'affinité de session détermine les champs des en-têtes IP et de couche 4 utilisés pour calculer le hachage.

Pour savoir comment les différents paramètres d'affinité de session affectent les méthodes de sélection du backend et 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 s'effectue toujours 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. En revanche, l'adresse IP de destination du paquet peut être n'importe quelle adresse IP qui correspond à 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 :

• S'il n'y a qu'une seule VM de backend 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 même 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, en fonction uniquement de l'adresse IP source du paquet, quelles que soient les adresses IP de destination des paquets, utilisez l'affinité de session CLIENT_IP_NO_DESTINATION. En fonction des schémas 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, avec la même adresse IP source, mais des adresses IP de destination différentes, peuvent être acheminés vers différentes VM de backend.

Règle de suivi de connexion

Cette section décrit les paramètres qui contrôlent le comportement du 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 tuples 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 acceptent.

Le mode de suivi des connexions fait référence à la précision de chaque tuple de connexion dans la table de suivi des connexions de l'équilibreur de charge. Le tuple de connexion peut être à cinq tuples ou à trois tuples (mode PER_CONNECTION), ou il peut 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 tuples 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 avec des hachages à cinq tuples. Tous les autres paquets sont suivis avec des hachages à trois tuples.

• PER_SESSION. Ce mode de suivi des connexions utilise un hachage composé des mêmes caractéristiques de paquet que le hachage de l'affinité de session. Selon 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 comment 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 à client unique

Lorsque vous testez des connexions à l'adresse IP d'un équilibreur de charge réseau passthrough interne qui ne comporte 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 distribuées 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 provenant du même client peuvent être distribuées à la même VM de backend plus souvent que prévu.

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

• Si la VM cliente est également une VM de backend de l'équilibreur de charge, les connexions envoyées à l'adresse IP de la règle de transfert de l'équilibreur de charge sont toujours traitées par la même VM de 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 un délai supplémentaire configurable pour que les connexions établies persistent dans le tableau de suivi des connexions de l'équilibreur de charge lorsque l'une des actions suivantes se produit :

• Une instance de machine virtuelle (VM) est supprimée d'un groupe d'instances de backend (y compris l'abandon d'une instance dans un groupe d'instances géré de backend)
• Une VM est arrêtée ou supprimée (y compris les actions automatiques telles que les mises à jour progressives ou la réduction de la 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 susmentionnées 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 non-Google Cloud et l'équipement réseau sur site peuvent transférer les fragments UDP à leur arrivée, retarder les paquets UDP fragmentés jusqu'à ce que tous les fragments soient arrivés, ou supprimer les paquets UDP fragmentés. Pour en savoir plus, consultez la documentation du fournisseur réseau ou de l'équipement réseau.

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

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

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

Basculement

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

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

Pour 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 dans le tableau de suivi des connexions de la section Sélection du backend et suivi des connexions.

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

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