Répartition du trafic pour les équilibreurs de charge réseau passthrough externes

Cette page décrit les concepts suivants pour vous aider à mieux comprendre et à personnaliser la distribution du trafic par les équilibreurs de charge réseau passthrough externes: affinité de session, suivi des connexions, équilibrement de charge pondéré, drainage de connexion, fragmentation UDP et basculement.

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 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. Pour en savoir plus, consultez la section Délai avant expiration de l'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. 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.

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 externes. Une règle de suivi des connexions inclut les paramètres suivants:

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.

Délai d'inactivité

Les entrées des tables de suivi des connexions expirent 60 secondes après que l'équilibreur de charge a traité le dernier paquet correspondant à l'entrée. Cette valeur d'inactivité ne peut pas être modifiée.

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

Poids Opérationnel 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.
  • 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 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.

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.

Étape suivante