Présentation de l'équilibrage de charge réseau TCP/UDP externe basé sur un service de backend

L'équilibrage de charge réseau TCP/UDP externe de Google Cloud (nommé "équilibrage de charge réseau" ci-après) est un équilibreur de charge régional à stratégie directe. Un équilibreur de charge réseau distribue le trafic externe entre les instances de machines virtuelles (VM) de la même région.

Vous pouvez configurer un équilibreur de charge réseau pour le trafic TCP, UDP, ESP et ICMP. La compatibilité avec ESP et ICMP est disponible en version bêta.

Un équilibreur de charge réseau peut recevoir du trafic provenant des éléments suivants :

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

L'équilibrage de charge réseau présente les caractéristiques suivantes :

  • L'équilibrage de charge réseau est un service géré.
  • L'équilibrage de charge réseau est mis en œuvre à l'aide du réseau virtuel Andromeda et de Google Maglev.
  • Les équilibreurs de charge réseau ne sont pas des proxys.
    • Les paquets à équilibrage de charge sont reçus par les VM de backend avec les adresses IP source et de destination de paquet, le protocole et, si celui-ci est basé sur le port, les ports source et de destination inchangés.
    • Les connexions à équilibrage de charge sont interrompues par les VM backend.
    • Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Le terme utilisé dans le secteur est retour direct du serveur.

Les équilibreurs de charge réseau basés sur un service de backend présentent les caractéristiques suivantes :

  • Backends de groupes d'instances gérés. Les équilibreurs de charge réseau basés sur un service de backend acceptent l'utilisation de groupes d'instances gérés comme backends. Les groupes d'instances gérés automatisent certains aspects de la gestion des backends, et offrent une meilleure évolutivité et davantage de fiabilité que les groupes d'instances non gérés.
  • Contrôle ultraprécis de la répartition du trafic. La configuration d'un service de backend contient un ensemble de valeurs, telles que les vérifications d'état, l'affinité de session, le suivi des connexions, les règles de drainage de connexion et les règles de basculement. La plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration afin de démarrer rapidement.
  • Vérifications d'état. Les équilibreurs de charge réseau basés sur un service de backend utilisent des vérifications d'état qui correspondent au type de trafic (TCP, SSL, HTTP, HTTPS ou HTTP/2) qu'ils distribuent.

Architecture

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

Équilibreur de charge réseau TCP/UDP externe avec un service de backend régional
Équilibrage de charge réseau avec un service de backend régional

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

  • Une ou plusieurs adresses IP externes régionales
  • Une ou plusieurs règles de transfert externes régionales
  • Un service de backend externe régional
  • Un ou plusieurs groupes d'instances backend
  • Vérification de l'état associée au service de backend

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

Adresse IP

Un équilibreur de charge réseau nécessite au moins une règle de transfert. La règle de transfert fait référence à une adresse IP externe régionale unique. Les adresses IP externes régionales sont accessibles partout sur Internet, mais elles proviennent d'un pool propre à chaque région Google Cloud.

Lorsque vous créez une règle de transfert, vous pouvez spécifier le nom ou l'adresse IP d'une adresse IP externe régionale réservée existante. Si vous ne spécifiez pas d'adresse IP, la règle de transfert fait référence à une adresse IP externe régionale éphémère. Utilisez une adresse IP réservée si vous devez conserver l'adresse associée à votre projet pour pouvoir la réutiliser après avoir supprimé une règle de transfert ou si vous avez besoin de plusieurs règles de transfert pour faire référence à la même adresse IP.

L'équilibrage de la charge réseau est compatible avec les adresses IP externes régionales du niveau Standard et Premium. L'adresse IP et la règle de transfert doivent utiliser le même niveau réseau.

Pour connaître les étapes à suivre pour réserver une adresse IP, consultez la page Adresses IP externes.

Règle de transfert

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

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

Le trafic entrant est mis en correspondance avec une règle de transfert, qui associe une adresse IP, un protocole, et si ce protocole est basé sur un port, un des ports, une plage de ports ou tous les ports. La règle de transfert dirige ensuite le trafic vers le service de backend de l'équilibreur de charge.

Un équilibreur de charge réseau nécessite au moins une règle de transfert. Vous pouvez définir plusieurs règles de transfert pour le même équilibreur de charge, comme décrit dans la section Plusieurs règles de transfert.

Protocoles de règles de transfert

L'équilibrage de charge réseau est compatible avec les options de protocole suivantes pour chaque règle de transfert : TCP, UDP et L3_DEFAULT (version bêta).

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

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

Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent faire référence à un service de backend utilisant le même protocole que la règle de transfert ou à un service de backend dont le protocole est UNSPECIFIED (version bêta). Les règles de transfert L3_DEFAULT ne peuvent faire référence qu'à un service de backend avec le protocole UNSPECIFIED.

Le tableau suivant récapitule comment utiliser ces paramètres pour différents protocoles.

Trafic dont la charge doit être équilibrée Protocole de règle de transfert Protocole de service de backend
TCP TCP TCP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP L3_DEFAULT UNSPECIFIED
ICMP (requête d'écho uniquement) L3_DEFAULT UNSPECIFIED

Plusieurs règles de transfert

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

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

  • Vous devez configurer plusieurs adresses IP externes pour le même service de backend.
  • Vous devez configurer différents protocoles, et ports ou plages de ports qui ne se chevauchent pas, pour une même adresse IP externe.

Pour une adresse IP donnée, une règle de transfert L3_DEFAULT peut coexister avec des règles de transfert utilisant d'autres protocoles (TCP ou UDP), mais non avec une autre règle de transfert L3_DEFAULT.

Un paquet arrivant sur l'adresse IP de l'équilibreur de charge correspond à une règle de transfert L3_DEFAULT uniquement si aucune règle de transfert plus spécifique n'est disponible (par exemple, pour le trafic TCP ou UDP). Plus précisément, un paquet arrivant sur une adresse IP, un protocole et un port correspond à une règle de transfert L3_DEFAULT, sauf s'il n'existe pas d'autres règles de transfert pour cette adresse IP qui correspondent au protocole et au port de destination du paquet.

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

Service backend régional

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

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

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

    Les services de backend utilisés avec les équilibreurs de charge réseau acceptent les options de protocole suivantes : TCP, UDP ou UNSPECIFIED (version bêta).

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

    Pour obtenir le tableau des combinaisons possibles de règles de transfert et de protocoles de services de backend, consultez la section Spécification du protocole d'une règle de transfert.

  • Distribution du trafic. Un service de backend permet de distribuer le trafic en fonction de règles d'affinité de session et de suivi de connexion configurables. Le service de backend peut également être configuré afin d'activer le drainage de connexion et de désigner des backends de basculement pour l'équilibreur de charge.

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

Chaque service de backend fonctionne dans une seule région et distribue le trafic vers la première interface réseau (nic0) des VM de backend. Les backends doivent être des groupes d'instances de la même région que le service de backend (et la règle de transfert). Les backends peuvent être des groupes d'instances non gérés zonaux, des groupes d'instances gérés zonaux ou des groupes d'instances gérés régionaux.

Les équilibreurs de charge réseau basés sur un service de backend acceptent les groupes d'instances dont les instances membres utilisent n'importe quel réseau VPC de la même région, à condition que ce réseau VPC se trouve dans le même projet que le service de backend. (Toutes les VM d'un groupe d'instances donné doivent utiliser le même réseau VPC.)

Groupes d'instances backend

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

  • Groupes d'instances gérés régionaux Utilisez des groupes d'instances gérés régionaux si vous pouvez déployer votre logiciel à l'aide de modèles d'instance. Les groupes d'instances gérés régionaux distribuent automatiquement le trafic entre plusieurs zones, offrant ainsi la meilleure option pour éviter les problèmes potentiels dans une zone donnée.

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

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

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

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

Vérifications d'état

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

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

L'équilibrage de charge réseau est compatible avec les types de vérification d'état suivants :

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

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

Par exemple, si vous équilibrez la charge du trafic UDP, la charge des requêtes client est équilibrée à l'aide du protocole UDP, et vous devez exécuter un service TCP pour fournir des informations aux vérificateurs d'état Google Cloud. Pour ce faire, vous pouvez exécuter un simple serveur HTTP sur chaque VM de backend qui renvoie une réponse HTTP 200 aux vérificateurs d'état. Dans cet exemple, vous devez utiliser votre propre logique s'exécutant sur la VM de backend pour vous assurer que le serveur HTTP renvoie la réponse 200 uniquement si le service UDP est correctement configuré et exécuté.

Règles de pare-feu

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

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

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

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

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

Chemin de retour

L'équilibrage de charge réseau utilise des routes spéciales en dehors de votre réseau VPC pour diriger les requêtes entrantes et les vérifications d'état vers chaque VM backend.

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

Architecture du VPC partagé

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

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

Le service de backend régional doit être défini dans le même projet et dans la même région que les instances du groupe d'instances backend.

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

Distribution du trafic

La manière dont un équilibreur de charge réseau 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 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 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

L'équilibrage de charge réseau utilise 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 de backend.

L'équilibrage de charge réseau utilise l'algorithme suivant pour distribuer les paquets entre les VM de backend (dans son pool actif, si vous avez configuré le basculement) :

  1. Si l'équilibreur de charge possède une entrée dans sa table de suivi des connexions correspondant aux caractéristiques d'un paquet entrant, le paquet est envoyé au backend spécifié par l'entrée de la table de suivi des connexions. Le paquet étant considéré comme faisant partie d'une connexion établie précédemment, il est envoyé à la VM de backend que l'équilibreur de charge a précédemment déterminée et enregistrée dans sa table de suivi des connexions.
  2. Lorsque l'équilibreur de charge reçoit un paquet pour lequel il n'a aucune entrée de suivi de connexion, l'équilibreur de charge effectue les opérations suivantes :

    1. L'équilibreur de charge sélectionne un backend. L'équilibreur de charge calcule un hachage en fonction de l'affinité de session configurée. Il utilise ce hachage pour sélectionner un backend parmi ceux qui sont actuellement opérationnels (sauf si tous les backends sont considérés comme non opérationnels, auquel cas tous les backends sont pris en compte tant la règle de basculement n'a pas été configurée pour supprimer le trafic dans cette situation. L'affinité de session par défaut, NONE, utilise les algorithmes de hachage suivants :

      • Pour les paquets TCP et 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.

    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.
      • UDP et paquets ESP. Le suivi des connexions n'est activé que si l'affinité de session est définie sur une valeur autre que NONE.

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

      Pour en savoir plus sur l'utilisation du suivi des connexions et sur la méthode de suivi utilisée, consultez la section Mode de suivi des connexions.

      Notez également les points suivants :

      • Une entrée dans la table de suivi des connexions expire 60 secondes après le traitement de l'équilibreur de charge par le dernier paquet correspondant à l'entrée. Cette valeur de 60 secondes d'inactivité n'est pas configurable.
      • Selon le protocole, l'équilibreur de charge peut supprimer les entrées de la table de suivi des connexions lorsque les backends ne sont plus opérationnels. Pour plus d'informations et pour personnaliser ce comportement, consultez la section Persistance des connexions sur les backends non opérationnels.

Options d'affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux VM backend de l'équilibreur de charge. L'affinité de session est spécifiée pour l'ensemble du service de backend externe régional, et non pour chaque groupe d'instances backend.

L'équilibrage de charge réseau est compatible avec les options d'affinité de session suivantes :

  • Aucune (NONE) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination
  • Adresse IP client, adresse IP de destination (CLIENT_IP) : hachage à deux tuples composé de l'adresse IP source et de l'adresse IP de destination
  • Adresse IP client, adresse IP de destination, protocole (CLIENT_IP_PROTO) : hachage à trois tuples composé de l'adresse IP source, de l'adresse IP de destination et du protocole
  • Adresse IP client, port client, adresse IP de destination, port de destination, protocole (CLIENT_IP_PORT_PROTO) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

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

Mode de suivi des connexions

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

  • PER_CONNECTION (par défaut). Il s'agit du mode de suivi par défaut. Avec ce mode de suivi des connexions, le trafic TCP est toujours suivi par hachage à 5 tuples, quel que soit le paramètre d'affinité de session. Pour le trafic UDP et ESP, le suivi des connexions est activé lorsque l'affinité de session sélectionnée n'est pas NONE. Le suivi des paquets UDP et ESP est effectué à l'aide des 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 qui n'est pas traçable en connexion). 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 et ESP fragmentés : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP : suivi des connexions à 2 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 et ESP fragmentés : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP : 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 et ESP fragmentés : 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 et ESP fragmentés : 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 de connexion sur les backends non opérationnels

Les paramètres de persistance de connexion contrôlent si une connexion existante persiste sur un backend sélectionné après que ce backend devient non opérationnel (tant que le backend reste dans le groupe d'instances backend configuré 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 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, UDP : les connexions persistent sur les backends non opérationnels si l'affinité de session n'est pas NONE.

ICMP : non applicable, car le protocole ICMP n'est pas compatible 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.

Drainage de connexion

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

  • Lorsque vous supprimez une VM de backend d'un groupe d'instances
  • Lorsqu'un groupe d'instances géré supprime une VM de backend (en cas de remplacement, d'abandon, de mises à niveau progressives ou de réduction de capacité)
  • Lorsqu'un groupe d'instances 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

L'équilibrage de charge réseau traite les paquets UDP fragmentés et non fragmentés. Les paquets non fragmentés sont traités normalement dans toutes les configurations. Si votre application utilise des paquets UDP fragmentés, gardez à l'esprit les points suivants :

  • Les paquets UDP peuvent être fragmentés avant d'atteindre un réseau VPC Google Cloud.
  • Les réseaux VPC Google Cloud transfèrent les fragments UDP dès leur arrivée (sans attendre que tous les fragments arrivent).
  • Les réseaux non-Google Cloud et l'équipement réseau sur site peuvent transférer les fragments UDP à leur arrivée, retarder les paquets UDP fragmentés jusqu'à ce que tous les fragments soient arrivés, ou supprimer les paquets UDP fragmentés. Pour en savoir plus, consultez la documentation de l'autre fournisseur ou équipement réseau.

Si vous prévoyez des paquets UDP fragmentés, procédez comme suit :

  • N'utilisez qu'une seule règle de transfert UDP par adresse IP à équilibrage de charge, et configurez la règle de transfert de façon à accepter le trafic sur tous les ports. Cela garantit que tous les fragments arrivent à la même règle de transfert, même s'ils n'ont pas le même port de destination. Pour configurer tous les ports, définissez --ports=ALL à l'aide de l'outil de ligne de commande gcloud ou définissez allPorts sur True à l'aide de l'API.

  • Utilisez l'une des approches suivantes pour configurer le service de backend :

    • Désactivez l'affinité de session et le suivi des connexions. Définissez l'affinité de session sur NONE. L'équilibreur de charge utilise un hachage à cinq tuples afin de sélectionner un backend pour les paquets non fragmentés (qui contiennent des informations de port) et un hachage à trois tuples pour les paquets fragmentés (qui ne disposent pas d'informations de port). Dans cette configuration, les paquets UDP fragmentés et non fragmentés d'un même client peuvent être transférés vers différents backends.
    • Activez l'affinité de session à deux ou trois tuples et le suivi des connexions. Définissez l'affinité de session sur CLIENT_IP ou CLIENT_IP_PROTO et le mode de suivi des connexions sur PER_SESSION. Dans cette configuration, les paquets UDP fragmentés et non fragmentés d'un même client sont transférés vers le même backend (sans utiliser d'informations de port).

Utiliser des instances cibles en tant que backends

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

Basculement

Vous pouvez configurer un équilibreur de charge réseau pour répartir les connexions entre les instances de machines virtuelles (VM) des groupes d'instances backend principaux. Par la suite, vous pouvez utiliser des groupes d'instances backend de basculement si cela s'avère nécessaire. 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 VM de vos backends principaux ne sont pas opérationnelles.

Par défaut, lorsque vous ajoutez un backend au service de backend d'un équilibreur de charge réseau, il s'agit d'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 l'équilibrage de charge réseau.

Limites

  • Les groupes de points de terminaison du réseau (NEG, Network Endpoint Group) ne sont pas acceptés comme backends pour les équilibreurs de charge réseau.
  • Les équilibreurs de charge réseau basés sur les services de backend ne sont pas compatibles avec Google Kubernetes Engine.
  • Vous ne pouvez pas effectuer les opérations suivantes à l'aide de Google Cloud Console :

    • Créer ou modifier un équilibreur de charge réseau dont la règle de transfert utilise le protocole L3_DEFAULT.
    • Créer ou modifier un équilibreur de charge réseau dont le protocole de service de backend est défini sur UNSPECIFIED.
    • Configurer une règle de suivi des connexions pour un service de backend.

    Utilisez plutôt l'outil de ligne de commande gcloud ou l'API REST.

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

Étape suivante