Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

Les équilibreurs de charge réseau passthrough distribuent le trafic entrant entre les instances backend disponibles. Ce document explique comment l'équilibreur de charge sélectionne les backends, suit les connexions et gère l'affinité de session, l'équilibrage de charge pondéré et le basculement.

Comprendre comment toutes ces fonctionnalités fonctionnent ensemble vous aide à optimiser votre configuration d'équilibrage de charge pour des performances fiables et une utilisation efficace des ressources. Ces mécanismes sont essentiels pour les applications qui nécessitent la persistance de session, car ils leur permettent de maintenir un comportement cohérent pour chaque interaction utilisateur.

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, vous devez adopter 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 une table de suivi des connexions.

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

1. Rechercher une entrée dans la table de suivi des connexions

L'équilibreur de charge détermine si un paquet à équilibrage de charge appartient à une nouvelle connexion ou à une connexion existante en procédant comme suit :

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 l'une des options d'affinité de session à cinq tuples (NONE ou CLIENT_IP_PORT_PROTO) est utilisée.

Le suivi des connexions n'est pas compatible : si la combinaison de protocole et d'affinité de session n'est pas compatible avec le suivi des connexions, passez à l'étape Identifier les backends éligibles. Pour en savoir plus sur les protocoles dont les connexions peuvent être suivies, consultez le tableau de la section Mode de suivi des connexions.

Tous les autres paquets : l'équilibreur de charge vérifie si le paquet correspond à une entrée existante de la table de suivi des connexions. La précision du hachage de paquet utilisé pour vérifier l'existence d'une entrée dans 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 en savoir plus, 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 persistance d'une entrée de table de suivi des connexions et sur les conditions dans lesquelles elle persiste, consultez l'étape Gérer les entrées de table de suivi des connexions.

2. Étapes de sélection du backend

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

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 une table de suivi des connexions.

2.1 Identifier les backends éligibles

Les backends éligibles sont les backends susceptibles de recevoir de nouvelles connexions. Le tableau suivant définit l'ensemble des backends éligibles selon que l'équilibreur de charge utilise le basculement et que l'équilibrage de charge pondéré est activé.

Basculement	Équilibrage de charge pondéré	Backends éligibles
		Lorsque les fonctionnalités de basculement et d'équilibrage de charge pondéré sont désactivées, tous les backends configurés sont des backends principaux. L'ensemble des backends éligibles est défini comme suit : 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 considérés comme non opérationnels, l'ensemble des backends éligibles se compose de tous les backends.
		Lorsque la fonctionnalité d'équilibrage de charge de basculement est désactivée et que la fonctionnalité d'équilibrage de charge pondéré est activée, les backends éligibles sont ceux qui proviennent du premier des ensembles suivants qui n'est pas vide : Tous les backends opérationnels dont la pondération est non nulle Tous les backends non opérationnels dont la pondération est non nulle Tous les backends opérationnels avec une pondération nulle Tous les backends non opérationnels de pondération nulle
		Lorsque la fonctionnalité d'équilibrage de charge avec basculement est activée et que la fonctionnalité d'équilibrage de charge pondéré est désactivée, l'équilibreur de charge utilise les informations de vérification d'état et la configuration de la règle de basculement pour définir l'ensemble des backends éligibles : Lorsqu'au moins un backend (principal ou de basculement) est opérationnel, les backends éligibles sont ceux qui proviennent du premier des ensembles suivants qui n'est pas vide : Si aucun backend principal n'est opérationnel, les backends éligibles sont tous les backends de basculement opérationnels. S'il n'y a pas de backend de basculement opérationnel, les backends éligibles sont tous les backends principaux opérationnels. Si le taux de basculement est défini sur `0.0` (valeur par défaut), les backends éligibles sont tous les backends principaux opérationnels. Si le ratio entre le nombre de backends principaux opérationnels et le nombre total de backends principaux est supérieur ou égal au taux de basculement configuré, les backends éligibles sont tous les backends principaux opérationnels. Les backends éligibles sont tous les backends de secours opérationnels. Lorsqu'il n'y a pas de backends opérationnels (principaux et de basculement), l'ensemble des backends éligibles dépend exclusivement de la configuration de la règle de basculement : Si la règle de basculement est configurée pour supprimer les nouvelles connexions lorsque tous les backends principaux et de basculement ne sont pas opérationnels, l'ensemble des backends éligibles est vide. Par conséquent, l'équilibreur de charge supprime les paquets des nouvelles connexions. Si la règle de basculement n'est pas configurée pour supprimer les nouvelles connexions lorsque tous les backends principaux et de basculement ne sont pas opérationnels, les backends éligibles sont tous les backends principaux non opérationnels.
		Lorsque les fonctionnalités de basculement et d'équilibrage de charge pondéré sont toutes deux activées, l'équilibreur de charge utilise les informations de pondération, les informations de vérification de l'état'état et la configuration de la règle de basculement pour définir l'ensemble des backends éligibles : Lorsqu'au moins un backend avec un poids non nul (principal ou de secours) est opérationnel, les backends éligibles sont ceux qui proviennent du premier des ensembles suivants qui n'est pas vide : Si l'ensemble des backends principaux opérationnels dont la pondération est non nulle est vide, les backends éligibles sont tous les backends de basculement opérationnels dont la pondération est non nulle. Si l'ensemble des backends de basculement opérationnels dont la pondération est non nulle est vide, les backends éligibles sont tous les backends principaux opérationnels dont la pondération est non nulle. Si le taux de basculement est défini sur `0.0` (valeur par défaut), les backends éligibles sont tous les backends principaux opérationnels dont la pondération est non nulle. Si le ratio entre le nombre de backends principaux opérationnels dont la pondération n'est pas nulle et le nombre total de backends principaux est supérieur ou égal au taux de basculement configuré, les backends éligibles sont tous les backends principaux opérationnels dont la pondération n'est pas nulle. Les backends éligibles sont tous les backends de secours opérationnels dont la pondération est non nulle. Lorsqu'il n'y a aucun backend opérationnel avec un poids non nul (principal et de secours), l'ensemble des backends éligibles dépend de la configuration de la règle de basculement : Si la règle de basculement est configurée pour supprimer les nouvelles connexions lorsqu'il n'y a pas de backends principaux et de basculement opérationnels dont la pondération n'est pas nulle, l'ensemble des backends éligibles est vide. Par conséquent, l'équilibreur de charge supprime les paquets des nouvelles connexions. Si la règle de basculement n'est pas configurée pour supprimer les nouvelles connexions lorsqu'il n'y a pas de backends principaux et de basculement opérationnels dont la pondération est différente de zéro, les backends éligibles sont ceux qui proviennent du premier des ensembles suivants qui n'est pas vide : Tous les backends principaux non opérationnels dont la pondération est non nulle Tous les backends de basculement non opérationnels dont la pondération est non nulle Tous les backends principaux opérationnels de pondération nulle Tous les backends de secours opérationnels avec une pondération nulle Tous les backends principaux non opérationnels de pondération nulle Tous les backends de basculement non opérationnels avec une pondération nulle

2.2 Sélectionner un backend éligible

L'équilibreur de charge gère les hachages des backends éligibles, chaque hachage de backend étant mappé à un cercle unitaire. L'équilibrage de charge pondéré modifie la façon dont les backends éligibles sont mappés au cercle, de sorte que les backends ayant des pondérations plus élevées sont plus susceptibles d'être sélectionnés, proportionnellement à leur pondération.

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 de paquet utilisées pour calculer le hachage de paquet est défini par le paramètre d'affinité de session. Par exemple, lorsque l'affinité de session sélectionnée génère un hachage de sélection de backend à deux ou trois tuples, toutes les connexions TCP d'une adresse IP source sont mappées au même backend éligible.

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

Le hachage cohérent garantit que l'équilibreur de charge attribue les nouvelles connexions aux backends éligibles de manière à minimiser les perturbations de mappage, même si le nombre de backends éligibles ou leurs pondérations changent.
- L'équilibreur de charge sélectionne toujours le même backend éligible pour une connexion et, plus généralement, toujours le même backend éligible pour tous les paquets ayant des caractéristiques identiques, telles que définies par le paramètre d'affinité de session, dans les situations suivantes :
  - Si l'équilibrage de charge pondéré n'est pas configuré, lorsque l'ensemble de backends éligibles ne change pas.
  - Si l'équilibrage de charge pondéré est configuré, lorsque l'ensemble des backends éligibles ne change pas et que la pondération de chaque backend éligible reste constante.
- Si un backend éligible est ajouté, supprimé ou si sa pondération est modifiée, le hachage cohérent vise à minimiser la perturbation des mappages vers les autres backends éligibles. En d'autres termes, la plupart des connexions qui sont mappées vers d'autres backends éligibles continuent d'être mappées vers le même backend éligible.
De plus, le hachage cohérent garantit que l'équilibreur de charge répartit les nouvelles connexions entre les backends éligibles de la manière la plus équitable possible. Pour tous les hachages de paquets possibles, tels que définis par le paramètre d'affinité de session configuré (et plus spécifiquement, pour toutes les connexions possibles lorsque l'affinité de session génère un hachage à 5 tuples pour la sélection du backend) :
- Si l'équilibrage de charge pondéré n'est pas configuré, environ 1/N hachages de paquets possibles sont mappés à chaque backend éligible, où N correspond au nombre de backends éligibles.
- Si l'équilibrage de charge pondéré est configuré, le ratio des hachages de paquets possibles qui correspondent à chaque backend éligible est d'environ : la pondération d'un backend éligible divisée par la somme de toutes les pondérations des backends éligibles.
Les deux exemples suivants montrent comment l'équilibrage de charge pondéré affecte les probabilités de sélection de chaque backend éligible :
- Si le service de backend comporte deux backends éligibles (le premier avec un poids de 1 et le second avec un poids de 4), le premier backend éligible a une probabilité de sélection de 20% (1/(1+4)) et le second backend éligible a une probabilité de sélection de 80% (4/(1+4)).
- Si le service de backend comporte trois backends éligibles (le backend éligible a ayant une pondération de 0, le backend éligible b ayant une pondération de 2 et le backend éligible c ayant une pondération de 6), le backend a a une probabilité de sélection de 0 % (0&div;(0+2+6)), le backend b a une probabilité de sélection de 25 % (2&div;(0+2+6)) et le backend c a une probabilité de sélection de 75 % (6&div;(0+2+6)).

2.3 Créer une entrée dans la 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 si l'affinité de session configurée est compatible avec le suivi des connexions pour le protocole du paquet.

Si la combinaison de protocole et d'affinité de session n'est pas compatible avec le suivi des connexions, ignorez cette étape.
Si l'affinité de session configurée est compatible avec le suivi des connexions pour le protocole du paquet, l'entrée de la table de suivi des connexions qui est créée mappe les caractéristiques du paquet 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.

Pour en savoir plus sur les protocoles dont les connexions peuvent être suivies en fonction de vos choix de configuration, et sur les caractéristiques des paquets utilisées pour le hachage dans la table de suivi des connexions, consultez le tableau de la section Mode de suivi des connexions.

3. Gérer les entrées de la table de suivi des connexions

L'équilibreur de charge gère les entrées de la table de suivi des connexions, si la combinaison du protocole et de l'affinité de session est compatible avec le suivi des connexions, selon les événements et règles suivants :

Les entrées inactives sont supprimées : une entrée de la table de suivi des connexions est supprimée après 60 secondes si aucun nouveau paquet entrant n'est traité par un Maglev. Pour en savoir plus, consultez Délai d'inactivité.

Connexions TCP fermées : les entrées de la table de suivi des connexions pour les connexions TCP ne sont pas supprimées lorsqu'une connexion TCP est fermée avec un paquet FIN ou RST. Elles pourront être supprimées ultérieurement en tant qu'entrées inactives. Chaque nouvelle connexion TCP comporte toujours l'indicateur SYN et est soumise au traitement décrit à l'étape Rechercher une entrée dans la table de suivi des connexions.
Lorsque les connexions ne persistent pas lors du basculement : lorsqu'au moins un backend de basculement est configuré et que le paramètre de drainage de connexion lors du basculement est désactivé, l'équilibreur de charge supprime toutes les entrées de la table de suivi des connexions après que l'ensemble des backends éligibles bascule entre les backends principaux et de basculement, sous réserve des règles suivantes :
- L'équilibreur de charge ne supprime pas de manière proactive les entrées de la table de suivi des connexions au moment où l'ensemble des backends éligibles bascule entre les backends principaux et de secours. À la place, l'équilibreur de charge supprime chaque entrée de la table de suivi des connexions lorsqu'un paquet suivant arrive pour la connexion, à condition que l'ensemble des backends éligibles n'ait pas été rétabli.
- Si l'ensemble des backends éligibles bascule entre les backends principaux et de basculement (par exemple, du backend principal au backend de basculement, puis de nouveau au backend principal) et qu'aucun paquet de la connexion n'est arrivé entre les événements de basculement, l'entrée de la table de suivi des connexions est conservée, sauf si une autre raison ou un autre événement supprime l'entrée de la table de suivi des connexions.
Pour en savoir plus, consultez Drainage de connexion lors du basculement.
Lorsque les connexions ne persistent pas sur les backends non opérationnels : lorsque la persistance des connexions sur les backends non opérationnels est désactivée pour le protocole du paquet, l'équilibreur de charge supprime les entrées de la table de suivi des connexions sur les backends non opérationnels selon les règles suivantes :
- L'équilibreur de charge ne supprime pas de manière proactive les entrées de la table de suivi des connexions vers un backend précédemment sélectionné au moment où le backend devient non opérationnel. Au lieu de cela, l'équilibreur de charge supprime une entrée de la table de suivi des connexions lorsqu'un prochain paquet pour la connexion arrive, à condition que le backend précédemment sélectionné reste non opérationnel. Les paquets suivants pour la connexion sont traités comme une nouvelle connexion, car l'équilibreur de charge sélectionne un nouveau backend éligible et crée une nouvelle entrée dans la table de suivi des connexions.
- Si un backend précédemment sélectionné passe de l'état "opérationnel" à l'état "non opérationnel", puis revient à l'état "opérationnel", et qu'aucun paquet pour la connexion n'est arrivé pendant que le backend précédemment sélectionné était non opérationnel, l'entrée de la table de suivi des connexions est conservée, sauf si une autre raison ou un autre événement supprime l'entrée de la table de suivi des connexions.
Drainage de connexion pour les backends supprimés, arrêtés ou effacés : si le drainage de connexion pour les backends supprimés, arrêtés ou effacés est activé, les entrées de la table de suivi des connexions sont supprimées après un délai avant expiration du drainage de connexion configurable. Le décompte du délai avant expiration commence lorsque la commande de suppression (abandon), d'arrêt ou de suppression d'un backend est reçue (y compris les commandes de suppression résultant de la réduction de la capacité d'un groupe d'instances géré). Si le drainage de connexion pour les backends supprimés ou arrêtés est désactivé, les entrées de la table de suivi des connexions sont supprimées lorsque la commande de suppression ou d'arrêt d'un backend est reçue. Pour en savoir plus, consultez Activer le drainage de connexion.

Affinité de session

Le paramètre d'affinité de session d'un équilibreur de charge réseau passthrough externe régional définit le hachage de paquets pour la sélection du backend et, en fonction du mode de suivi des connexions, le hachage de paquets pour le suivi des connexions.

Vous configurez l'affinité de session sur le service de backend, et non sur chaque groupe d'instances backend ou NEG. L'affinité de session détermine les en-têtes IP et de couche 4 utilisés pour calculer un hachage des caractéristiques des paquets. Le hachage des caractéristiques des paquets est utilisé dans les étapes de sélection du backend.

Les équilibreurs de charge réseau passthrough externes régionaux sont compatibles avec les paramètres d'affinité de session suivants.

Méthode de hachage pour la sélection du backend Paramètre d'affinité de session

Méthode de hachage pour la sélection du backend	Paramètre d'affinité de session
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 les paquets non fragmentés qui incluent des informations de port (paquets TCP et paquets UDP non fragmentés) OU Hachage à trois tuples (composé de l'adresse IP source, de l'adresse IP de destination et du protocole) pour les paquets UDP fragmentés et les paquets de tous les autres protocoles	`NONE`¹ OU `CLIENT_IP_PORT_PROTO`
Hachage à trois tuples (composé de l'adresse IP source, de l'adresse IP de destination et du protocole)	`CLIENT_IP_PROTO`
Hachage à deux tuples (composé de l'adresse IP source et de l'adresse IP de destination)	`CLIENT_IP`

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 les paquets non fragmentés qui incluent des informations de port (paquets TCP et paquets UDP non fragmentés)

Hachage à trois tuples (composé de l'adresse IP source, de l'adresse IP de destination et du protocole) pour les paquets UDP fragmentés et les paquets de tous les autres protocoles

NONE¹
OU
CLIENT_IP_PORT_PROTO

Hachage à trois tuples
(composé de l'adresse IP source, de l'adresse IP de destination et du protocole) CLIENT_IP_PROTO

Hachage à deux tuples
(composé de l'adresse IP source et de l'adresse IP de destination) CLIENT_IP

¹ L'affinité de session NONE n'indique pas qu'il n'y a pas d'affinité de session. Cela signifie que l'affinité de session est effectuée avec un hachage à cinq tuples ou à trois tuples des caractéristiques des paquets, ce qui est fonctionnellement le même comportement que lorsque CLIENT_IP_PORT_PROTO est défini.

Règle de suivi de connexion

Cette section décrit les paramètres de la règle de suivi des connexions de l'équilibreur de charge :

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

Mode de suivi des connexions

Cette section décrit quand et comment l'équilibreur de charge crée des entrées dans sa table de suivi des connexions. Les équilibreurs de charge réseau passthrough externes régionaux sont compatibles avec le suivi des connexions en fonction du protocole et de l'affinité de session :

Les connexions TCP sont toujours suivies, pour toutes les options d'affinité de session.
Les connexions UDP, ESP et GRE peuvent être suivies pour toutes les options d'affinité de session, à l'exception de NONE. Pour l'affinité de session NONE, ces protocoles ne sont pas traçables par connexion.
Tous les autres protocoles, tels que ICMP et ICMPv6, ne sont pas compatibles avec le suivi des connexions, pour toutes les options d'affinité de session.

Lorsque le suivi des connexions est possible, le mode de suivi des connexions, le protocole et l'affinité de session déterminent l'ensemble des caractéristiques des paquets qui sont utilisées pour créer le hachage des paquets dans chaque entrée de la table de suivi des connexions.

Le mode de suivi des connexions peut être l'un des suivants :

PER_CONNECTION : il s'agit du mode de suivi des connexions par défaut, qui est aussi le plus précis. Chaque connexion est définie comme un hachage à 5 tuples ou à 3 tuples des caractéristiques du paquet, selon que les informations de port sont présentes ou non dans le paquet. Les paquets non fragmentés qui incluent des informations de 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 moins précis utilise un hachage qui correspond au hachage d'affinité de session. En fonction de l'affinité de session choisie, le mode de suivi PER_SESSION peut traiter plusieurs connexions distinctes comme une seule connexion à des fins de suivi des connexions. Cela réduit la fréquence à laquelle une connexion est considérée comme nouvelle et soumise aux étapes de sélection du backend.

Le tableau suivant récapitule :

Les hachages de paquets utilisés pour la sélection du backend
Les hachages de paquets utilisés pour le suivi des connexions, en fonction du mode de suivi des connexions, du protocole et de l'affinité de session.

Affinité de session	Hachage de paquet pour la sélection du backend	Hachage de paquets pour le suivi des connexions
Affinité de session	Hachage de paquet pour la sélection du backend	Lorsque vous utilisez le mode de suivi `PER_CONNECTION` (par défaut)	Lorsque vous utilisez le mode de suivi `PER_SESSION`
`NONE` (par défaut)	TCP et UDP non fragmenté : hachage à cinq tuples UDP fragmenté et tous les autres protocoles : hachage à trois tuples	TCP : suivi des connexions activé, hachage à cinq tuples Tous les autres protocoles : suivi des connexions désactivé	TCP : suivi des connexions activé, hachage à cinq tuples Tous les autres protocoles : suivi des connexions désactivé
`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 activé, hachage à cinq tuples UDP fragmenté, ESP et GRE : suivi des connexions activé, hachage à trois tuples Tous les autres protocoles : suivi des connexions désactivé	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté, ESP et GRE : suivi des connexions activé, hachage à trois tuples Tous les autres protocoles : suivi des connexions désactivé
`CLIENT_IP_PROTO`	Tous les protocoles : hachage à trois tuples	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté, ESP et GRE : suivi des connexions activé, hachage à trois tuples Tous les autres protocoles : suivi des connexions désactivé	TCP, UDP, ESP, GRE : suivi des connexions activé, hachage à trois tuples Tous les autres protocoles : suivi des connexions désactivé
`CLIENT_IP`	Tous les protocoles : hachage à deux tuples	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté, ESP et GRE : suivi des connexions activé, hachage à trois tuples Tous les autres protocoles : suivi des connexions désactivé	TCP, UDP, ESP, GRE : suivi des connexions activé, hachage à deux tuples Tous les autres protocoles : suivi des connexions désactivé

Pour savoir comment modifier le mode de suivi des connexions, consultez Configurer une règle de suivi des connexions.

Persistance des connexions sur les backends non opérationnels

L'option Persistance des connexions sur les backends non opérationnels permet de déterminer si les connexions existantes peuvent persister sur une VM de backend précédemment sélectionnée si celle-ci devient non opérationnelle. La persistance des connexions sur les backends non opérationnels nécessite que la VM de backend reste membre d'un groupe d'instances ou d'un NEG à équilibrage de charge, et que la combinaison du protocole et de l'affinité de session soit compatible avec le suivi des connexions.

Les options de persistance de connexion suivantes sont disponibles :

DEFAULT_FOR_PROTOCOL (par défaut)
NEVER_PERSIST
ALWAYS_PERSIST

Le tableau suivant décrit le comportement de la persistance de connexion sur les backends non opérationnels en fonction de l'option de persistance de connexion sur les backends non opérationnels, du mode de suivi des connexions, de l'affinité de session et du protocole.

Persistance de connexion sur les backends non opérationnels	Comportement de la persistance des connexions sur les backends non opérationnels
Persistance de connexion sur les backends non opérationnels	Lorsque vous utilisez le mode de suivi `PER_CONNECTION` (par défaut)	Lorsque vous utilisez le mode de suivi `PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP (toutes les affinités de session) : les connexions persistent sur les backends non opérationnels, sous réserve des autres événements et règles de l'étape Gérer les entrées de la table de suivi des connexions. Tous les autres protocoles : les connexions ne persistent pas sur les backends non opérationnels	TCP (affinités de session `NONE` et `CLIENT_IP_PORT_PROTO`) : les connexions persistent sur les backends non opérationnels, sous réserve des autres événements et règles de l'étape Gérer les entrées de la table de suivi des connexions. TCP (toutes les autres affinités de session) et tous les autres protocoles : les connexions ne persistent pas sur les backends non opérationnels
`NEVER_PERSIST`	Tous les protocoles : les connexions ne persistent pas sur les backends non opérationnels
`ALWAYS_PERSIST` N'utilisez cette option que pour les cas d'utilisation avancée.	*TCP (toutes les affinités de session) ; ESP, GRE, UDP (toutes les affinités de session sauf* `NONE`) : les connexions persistent sur les backends non opérationnels, sous réserve des autres événements et règles de l'étape Gérer les entrées de la table de suivi des connexions. ESP, GRE, UDP (affinité de session `NONE`)** : non applicable, car ces protocoles ne sont pas compatibles avec le suivi des connexions	Configuration impossible

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

Comportement de la persistance de connexion TCP sur les backends non opérationnels

L'équilibreur de charge utilise le suivi des connexions à cinq tuples pour les connexions TCP dans les situations suivantes :

Lorsque vous utilisez le mode de suivi PER_CONNECTION (toutes les affinités de session) ou
Lorsque vous utilisez le mode de suivi PER_SESSION, et que l'affinité de session est NONE ou CLIENT_IP_PORT_PROTO.

Lorsque l'équilibreur de charge utilise un suivi des connexions avec hachage à cinq tuples pour les connexions TCP, gardez à l'esprit les comportements suivants :

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 réessayer avec une nouvelle connexion, ce qui permet à l'équilibreur de charge de sélectionner un autre backend éligible. (Les paquets TCP SYN sont traités comme de nouvelles connexions à l'étape Identifier les backends éligibles.)

Délai d'inactivité

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

Drainage de connexion pour les backends retirés, arrêtés ou supprimés

Le drainage de connexion fournit une durée minimale configurable pendant laquelle les connexions existantes persistent dans la table de suivi des connexions de l'équilibreur de charge lorsque l'un des événements suivants se produit :

Une instance de machine virtuelle (VM) est supprimée d'un groupe d'instances backend (y compris l'abandon d'une instance dans un groupe d'instances géré backend).
Une VM est arrêtée ou supprimée (cela inclut 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 lorsque les backends sont supprimés ou arrêtés est désactivé. Pour en savoir plus, consultez la section Activer le drainage de connexion.

Équilibrage de charge pondéré

L'équilibrage de charge pondéré influence les backends éligibles dans les étapes de sélection du backend. Chaque VM ou point de terminaison de backend signale sa pondération à l'équilibreur de charge à l'aide d'une vérification d'état HTTP et d'un en-tête de réponse personnalisé. Pour utiliser l'équilibrage de charge pondéré, vous devez configurer les éléments suivants sur le service de backend de l'équilibreur de charge :

La règle de localité (localityLbPolicy) doit être définie sur WEIGHTED_MAGLEV.
La vérification de l'état doit être une vérification de l'état HTTP qui envoie un en-tête de réponse spécial :
- Le nom du champ de l'en-tête de réponse doit être X-Load-Balancing-Endpoint-Weight.
- Les valeurs des champs de l'en-tête de réponse peuvent être comprises entre 0 et 1000 (inclus).

Pour en savoir plus, consultez Configurer l'équilibrage de charge pondéré.

Remarques concernant l'équilibrage de charge pondéré

L'équilibrage de charge pondéré est utile dans les scénarios suivants, qui permettent à un backend de continuer à traiter ses connexions existantes :

L'équilibrage de charge pondéré permet à un backend qui traite des connexions de longue durée ou des connexions impliquant de grandes quantités de données d'indiquer à l'équilibreur de charge de réduire le nombre de nouvelles connexions qu'il reçoit.
L'équilibrage de charge pondéré permet à un backend surchargé ou en cours de maintenance de se retirer des backends éligibles pour les nouvelles connexions. Pour ce faire, le backend surchargé envoie l'en-tête de réponse X-Load-Balancing-Endpoint-Weight: 0 (et peut continuer à réussir ou à échouer la vérification de l'état'équilibreur de charge). Cette approche est efficace, car tous les backends de pondération non nulle (quel que soit l'état de la vérification de l'état d'état) sont des backends éligibles plus préférables à l'étape Identifier les backends éligibles.

Tenez compte des points suivants lorsque vous utilisez l'équilibrage de charge :

Si les backends éligibles modifient fréquemment leurs pondérations, l'équilibrage de charge pondéré peut nuire à l'affinité de session. Pour en savoir plus, consultez l'étape Sélectionner un backend éligible.
Si vous utilisez le même groupe d'instances ou NEG comme backend de deux services de backend d'équilibreur de charge ou plus, vous pouvez signaler une pondération unique pour chaque service de backend en utilisant la stratégie suivante :
- Utilisez une vérification de l'état HTTP unique pour chaque service de backend. Chaque vérification de l'état peut utiliser un port de destination ou un paramètre request-path unique.
- Configurez les instances backend ou les points de terminaison pour qu'ils répondent avec les informations de pondération appropriées pour chaque vérification de l'état'état.

Basculement

La fonctionnalité de basculement vous permet d'influencer l'ensemble des backends éligibles en classant les groupes d'instances backend ou les NEG et leurs points de terminaison comme suit :

Les backends principaux sont des VM ou des points de terminaison dans un groupe d'instances ou un NEG configuré comme groupe de backends principaux.
Les backends de basculement sont des VM ou des points de terminaison d'un groupe d'instances ou d'un NEG configuré en tant que groupe de backends de basculement.

Par défaut, lorsque vous ajoutez un groupe d'instances ou un NEG à un service de backend, il s'agit d'un groupe de backend principal. Vous pouvez ajouter jusqu'à 50 groupes de backend principaux et 50 groupes de backend de basculement à un service de backend.

Pour activer la fonctionnalité de basculement, vous devez configurer le service de backend de l'équilibreur de charge avec les deux éléments suivants :

Au moins un groupe de backend principal non vide
Au moins un groupe de backend de basculement non vide

Lorsque le basculement est activé, les facteurs suivants déterminent l'ensemble des backends éligibles :

État de santé de chaque backend
Taux de basculement dans la règle de basculement
Le paramètre Supprimer le trafic si les backends ne sont pas opérationnels dans la règle de basculement
Si vous utilisez le basculement seul ou conjointement avec l'équilibrage de charge pondéré

Stratégie de basculement

Vous pouvez ajuster les paramètres suivants dans la stratégie de basculement d'un service de backend. La stratégie de basculement n'est pertinente que si le basculement est activé.

Taux de basculement : nombre compris entre 0.0 et 1.0, inclus.
Abandonner le trafic si les backends ne sont pas opérationnels : valeur booléenne qui détermine le comportement de dernier recours de l'équilibreur de charge. Le taux de basculement et le paramètre Abandonner le trafic si les backends sont non opérationnels fonctionnent avec d'autres facteurs pour contrôler l'ensemble des backends éligibles.
Drainage de connexion en cas de basculement : valeur booléenne qui détermine si les connexions persistent sur les backends précédemment sélectionnés lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de secours.

Taux de basculement

Le ratio de basculement détermine quand l'ensemble de backends éligibles bascule entre les backends principaux et les backends de basculement. Le ratio peut être un nombre compris entre 0.0 et 1.0 (inclus). Si vous n'indiquez pas de taux de basculement, Cloud de Confiance utilise une valeur par défaut de 0.0. Nous vous recommandons de définir votre taux de basculement en vous servant d'un nombre qui fonctionne pour votre cas d'utilisation plutôt que d'utiliser cette valeur par défaut.

Drainage de connexion en basculement

Le drainage de connexion lors du basculement détermine si une connexion existante persiste sur une VM ou un point de terminaison de backend précédemment sélectionné lorsque l'ensemble de backends éligibles bascule entre les backends principaux et les backends de basculement.

Le drainage de connexion lors du basculement est activé par défaut. Le tableau suivant récapitule la persistance des connexions en fonction de l'option de drainage de connexion lors du basculement et du protocole :

Option "Drainage de connexion en basculement"	Comportement lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de basculement
Activés (par défaut)	Protocoles avec suivi des connexions : les connexions persistent tant qu'une entrée correspondante existe dans la table de suivi des connexions, lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de secours. Pour en savoir plus, consultez l'étape Gérer les entrées de la table de suivi des connexions. Protocoles dont les connexions ne peuvent pas être suivies : les connexions ne sont pas conservées lorsque l'ensemble des backends éligibles bascule entre les backends principaux et les backends de basculement. Pour en savoir plus sur les protocoles dont les connexions peuvent être suivies, consultez le tableau de la section Mode de suivi des connexions.
Désactivé	Tous les protocoles : les connexions ne sont pas conservées lorsque l'ensemble des backends éligibles bascule entre les backends principaux et les backends de basculement.

Option "Drainage de connexion en basculement"

Comportement lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de basculement

Activés (par défaut)

Protocoles avec suivi des connexions : les connexions persistent tant qu'une entrée correspondante existe dans la table de suivi des connexions, lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de secours. Pour en savoir plus, consultez l'étape Gérer les entrées de la table de suivi des connexions.
Protocoles dont les connexions ne peuvent pas être suivies : les connexions ne sont pas conservées lorsque l'ensemble des backends éligibles bascule entre les backends principaux et les backends de basculement.

Pour en savoir plus sur les protocoles dont les connexions peuvent être suivies, consultez le tableau de la section Mode de suivi des connexions.

Désactivé

Tous les protocoles : les connexions ne sont pas conservées lorsque l'ensemble des backends éligibles bascule entre les backends principaux et les backends de basculement.

La désactivation du drainage de connexion lors du basculement est utile dans les situations suivantes :

Application de correctifs sur les VM de backend : Avant d'appliquer des correctifs, vous pouvez configurer les backends principaux opérationnels dont le poids est différent de zéro pour qu'ils échouent aux vérifications d'état, ou vous pouvez définir leur poids sur zéro. Ainsi, les backends éligibles peuvent être des backends de basculement opérationnels avec un poids non nul. En désactivant le drainage de connexion lors du basculement, l'équilibreur de charge supprime les entrées de la table de suivi des connexions, applique les étapes de sélection du backend aux paquets suivants et les transmet à un autre backend éligible. Le backend différent ferme ensuite la connexion avec une réinitialisation TCP, afin que les VM clientes puissent établir rapidement une nouvelle connexion à l'équilibreur de charge.
Nécessité de n'utiliser qu'une seule VM de backend pour garantir la cohérence des données : Si vous devez vous assurer que l'ensemble de backends éligibles ne comporte pas plus d'une VM ou d'un point de terminaison membre, la désactivation du drainage de connexion lors du basculement réduit le risque d'incohérences des données.

Pour savoir comment désactiver le drainage de connexion lors du basculement, consultez Définir une règle de basculement.

Bonnes pratiques et conseils

Vous pouvez optimiser un équilibreur de charge réseau passthrough externe régional en suivant ces consignes opérationnelles. Les sections suivantes décrivent les exigences techniques pour gérer les paquets UDP fragmentés et les bonnes pratiques pour tester la répartition de la charge à partir d'un seul client.

Gérer la fragmentation UDP

Les équilibreurs de charge réseau passthrough externes régionaux 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 Cloud de Confiance.
Cloud de Confiance 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-Cloud de Confiance 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.

Tester à partir d'un seul client

Lorsque vous testez un équilibreur de charge réseau passthrough externe régional à partir d'un seul client, gardez les points suivants à l'esprit :

Si la VM cliente n'est pas un backend de l'équilibreur de charge : les nouvelles connexions sont traitées comme décrit dans les étapes Sélection du backend et suivi des connexions. À l'étape Sélectionner un backend éligible, l'équilibreur de charge crée un hachage des caractéristiques des paquets en fonction de l'affinité de session.

N'oubliez pas que toutes les options d'affinité de session reposent au moins sur l'adresse IP du client. Les connexions provenant du même client peuvent être distribuées au même backend éligible plus fréquemment que vous ne le pensez. Par conséquent, vous ne pouvez pas modéliser précisément la distribution globale des nouvelles connexions en vous connectant à un équilibreur de charge réseau passthrough externe régional à partir d'un seul client.
Si la VM cliente est également une VM de backend de l'équilibreur de charge : les nouvelles connexions ne sont pas du tout traitées par l'équilibreur de charge. Les paquets sortants dont l'adresse IP de destination correspond à la règle de transfert de l'équilibreur de charge sont acheminés localement dans l'OS invité du client en raison de la présence d'une route locale pour la règle de transfert.

Étapes suivantes

Pour configurer un équilibreur de charge réseau passthrough externe avec un service de backend pour le trafic TCP ou UDP uniquement (compatible avec le trafic IPv4 et IPv6), consultez la page Configurer un équilibreur de charge réseau passthrough externe avec un service de backend.
Pour configurer un équilibreur de charge réseau passthrough externe pour plusieurs protocoles IP (compatible avec le trafic IPv4 et IPv6), consultez la page Configurer un équilibreur de charge réseau passthrough externe pour plusieurs protocoles IP.
Pour configurer un équilibreur de charge réseau passthrough externe avec un backend de NEG zonal, consultez la page Configurer un équilibreur de charge réseau passthrough externe avec des NEG zonaux.
Pour découvrir comment passer d'un équilibreur de charge réseau passthrough externe d'un backend de pool cible vers un service de backend régional, consultez la page Migrer un équilibreur de charge réseau passthrough externe depuis un pool cible vers un service de backend.