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

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

Sélection du backend et suivi des connexions

La sélection du backend et le suivi des connexions fonctionnent ensemble pour équilibrer plusieurs connexions sur différents backends et pour acheminer tous les paquets de chaque connexion vers le même backend. Pour ce faire, 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 un tableau 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 suivant le processus suivant :

• Paquet TCP avec l'indicateur SYN :

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

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

• Tous les autres paquets : l'équilibreur de charge vérifie si le paquet correspond à une entrée existante dans la table de suivi des connexions. La précision du hachage de paquet utilisé pour vérifier s'il existe 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 savoir combien de temps une entrée de tableau de suivi des connexions persiste et dans quelles conditions, consultez l'étape Gérer les entrées du tableau 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 l'enregistrement de cette connexion dans un tableau de suivi des connexions.

2.1 Identifier les backends éligibles

Les backends éligibles sont les backends qui peuvent recevoir de nouvelles connexions. Le tableau suivant définit l'ensemble des backends éligibles selon que vous avez configuré ou non une stratégie de reprise après sinistre.

Stratégie de basculement	Backends éligibles
	Lorsqu'aucune règle de basculement n'est configurée, 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 non opérationnels, l'ensemble des backends éligibles est constitué de tous les backends.
	Lorsqu'une règle de basculement est configurée, l'équilibreur de charge utilise les informations de vérification de l'état l'é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 : S'il n'y a aucun backend principal opérationnel, les backends éligibles sont tous les backends de secours opérationnels. S'il n'y a pas de backends de secours opérationnels, 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 se composent de 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 secours), l'ensemble des backends éligibles dépend exclusivement de la configuration de la stratégie de basculement : Si la règle de basculement est configurée pour supprimer les nouvelles connexions lorsque tous les backends principaux et de secours sont non opérationnels, l'ensemble des backends éligibles est vide. Par conséquent, l'équilibreur de charge supprime les paquets pour les nouvelles connexions. Si la règle de basculement n'est pas configurée pour abandonner les nouvelles connexions lorsque tous les backends principaux et de basculement sont non opérationnels, les backends éligibles sont tous les backends principaux non opérationnels.

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

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

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

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

• Fonctionnement de ZONAL_AFFINITY_STAY_WITHIN_ZONE

• Fonctionnement de ZONAL_AFFINITY_SPILL_CROSS_ZONE et du ratio de basculement

2.3 Sélectionnez un backend éligible

L'équilibreur de charge conserve les hachages des backends éligibles, chaque hachage de backend étant mappé à un cercle unité.

Lors du traitement d'un paquet pour une connexion qui ne figure pas dans la table de suivi des connexions, l'équilibreur de charge calcule un hachage des caractéristiques du paquet et mappe ce hachage au même cercle unité, en sélectionnant un backend éligible sur la circonférence du cercle. L'ensemble des caractéristiques des paquets utilisées pour calculer le hachage des paquets est défini par le paramètre d'affinité de session. 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 provenant d'une adresse IP source sont mappées sur le même backend éligible.

• Si aucune affinité de session n'est explicitement configurée, l'affinité de session NONE est définie 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 du mappage, même si le nombre de backends éligibles change.

  • L'équilibreur de charge sélectionne toujours le même backend éligible pour une connexion et, plus généralement, sélectionne 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, si l'ensemble des backends éligibles ne change pas.

  • Si un backend éligible est ajouté ou supprimé, le hachage cohérent vise à minimiser la perturbation des mappages vers les autres backends éligibles. Autrement dit, la plupart des connexions qui sont mappées vers d'autres backends éligibles continuent de l'être 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 précisément, pour toutes les connexions possibles lorsque l'affinité de session génère un hachage à cinq tuples pour la sélection du backend) :

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

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

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

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

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 en fonction des événements et des règles suivants :

• Suppression des entrées inactives : une entrée de la table de suivi des connexions est supprimée une fois la connexion inactive. Sauf si vous configurez un délai d'inactivité personnalisé, l'équilibreur de charge utilise un délai d'inactivité par défaut de 600 secondes. Pour en savoir plus, consultez 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. Il est possible qu'elle soit supprimée ultérieurement en tant qu'entrée inactive. Chaque nouvelle connexion TCP comporte toujours l'indicateur SYN et est soumise au traitement décrit à l'étape Vérifier l'existence d'une entrée dans la table de suivi des connexions.

• Drainage de connexion 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 lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de basculement. Pour en savoir plus, consultez Drainage de connexion en cas de basculement.

• Persistance des connexions sur les backends non opérationnels : les entrées de la table de suivi des connexions peuvent être supprimées si un backend devient non opérationnel. Ce comportement dépend des facteurs décrits dans Persistance des connexions sur les backends non opérationnels.

  • Lorsqu'une entrée de table de suivi des connexions est supprimée, car un backend précédemment sélectionné passe de l'état opérationnel à l'état non opérationnel, les paquets suivants pour la connexion sont traités comme s'ils appartenaient à une nouvelle connexion. Après avoir sélectionné un nouveau backend éligible pour les paquets suivants, l'équilibreur de charge crée une entrée de remplacement dans la table de suivi des connexions.

  • Une entrée de table de suivi des connexions de remplacement se comporte exactement comme n'importe quelle autre entrée de table de suivi des connexions et est soumise aux événements et aux règles de cette étape.

  • Si le backend précédemment sélectionné redevient opérationnel après avoir été non opérationnel, la modification de la vérification de l'état seule n'entraîne pas la suppression de l'entrée de la table de suivi des connexions de remplacement. Une exception se produit lorsqu'au moins un backend de secours est configuré et que le paramètre "Drainage de connexion lors du basculement" est désactivé. Si le changement d'état du vérification de l'état de l'état d'un backend précédemment sélectionné coïncide avec l'ensemble des backends éligibles passant des backends principaux aux backends de secours, les entrées de la table de suivi des connexions sont supprimées.

• Drainage de connexion pour les backends supprimés, arrêtés ou supprimés : si le drainage de connexion pour les backends supprimés, arrêtés ou supprimés est activé, les entrées du tableau de suivi des connexions sont supprimées après un délai de drainage de connexion configurable. Le compte à rebours du délai d'inactivité commence lorsque la commande de suppression, d'arrêt ou de suppression d'un backend est reçue. Si le drainage de connexion pour les backends supprimés, arrêtés ou supprimés est désactivé, les entrées de la table de suivi des connexions sont supprimées lorsque la commande de suppression, d'arrêt ou de suppression 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 interne définit le hachage de paquet pour la sélection du backend et, en fonction du mode de suivi des connexions, le hachage de paquet pour le suivi des connexions.

Vous configurez l'affinité de session sur le service de backend, et non sur chaque groupe d'instances ou NEG de backend. 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 internes 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
Hachage à cinq tuples (adresse IP source, port source, protocole, adresse IP de destination et port de destination) pour les paquets non fragmentés incluant 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^1 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 à un tuple (composé uniquement de l'adresse IP source)	CLIENT_IP_NO_DESTINATION

¹ : 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 identique au comportement lorsque CLIENT_IP_PORT_PROTO est défini.

Affinité de session et équilibreur de charge comme saut suivant

Lorsqu'un équilibreur de charge réseau passthrough interne est le prochain saut d'une route statique, l'adresse IP de destination n'est pas limitée à l'adresse IP de la règle de transfert de l'équilibreur de charge. En revanche, l'adresse IP de destination du paquet peut être n'importe quelle adresse IP qui correspond à la plage de destination de la route statique.

La sélection d'un backend éligible dépend du calcul d'un hachage des caractéristiques des paquets. À l'exception de l'affinité de session CLIENT_IP_NO_DESTINATION (hachage à un tuple), le hachage dépend en partie de l'adresse IP de destination du paquet.

Si l'ensemble des backends éligibles ne change pas, l'équilibreur de charge sélectionne le même backend pour toutes les nouvelles connexions possibles qui présentent des caractéristiques de paquet identiques, telles que définies par l'affinité de session. Si vous avez besoin que la même VM de backend traite tous les paquets d'un client, en fonction uniquement de l'adresse IP source, quelles que soient les adresses IP de destination, utilisez l'affinité de session CLIENT_IP_NO_DESTINATION.

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 comment l'équilibreur de charge crée des entrées dans sa table de suivi des connexions. Les équilibreurs de charge réseau passthrough internes suivent les connexions pour tous les protocoles qu'ils acceptent et pour toutes les options d'affinité de session.

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 à cinq tuples ou un hachage à trois tuples des caractéristiques des paquets, selon que les informations sur les ports 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 de l'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 informations :

• Les hachages de paquets utilisés pour la sélection du backend
• 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 paquets pour la sélection du backend	Hachage des paquets pour le suivi des connexions
		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) OU 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é et tous les autres protocoles : suivi des connexions activé, hachage à trois tuples	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté et tous les autres protocoles : suivi des connexions activé, hachage à trois tuples
CLIENT_IP_PROTO	Tous les protocoles : hachage à trois tuples	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté et tous les autres protocoles : suivi des connexions activé, hachage à trois tuples	Tous les protocoles : suivi des connexions activé, hachage à trois tuples
CLIENT_IP	Tous les protocoles : hachage à deux tuples	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté et tous les autres protocoles : suivi des connexions activé, hachage à trois tuples	Tous les protocoles : suivi des connexions activé, hachage à deux tuples
CLIENT_IP_NO_DESTINATION	Tous les protocoles : hachage à un tuple	TCP et UDP non fragmenté : suivi des connexions activé, hachage à cinq tuples UDP fragmenté et tous les autres protocoles : suivi des connexions activé, hachage à trois tuples	Tous les protocoles : suivi des connexions activé, hachage à un tuple

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

L'option Persistance des connexions sur les backends non opérationnels permet de déterminer si les connexions existantes persistent sur une VM de backend ou un point de terminaison précédemment sélectionnés après que le backend n'est plus opérationnel, à condition que le backend reste dans un groupe d'instances ou un NEG à équilibrage de charge.

Les options de persistance de connexion suivantes sont disponibles :

• DEFAULT_FOR_PROTOCOL (par défaut)
• NEVER_PERSIST
• ALWAYS_PERSIST

Le tableau suivant récapitule si les connexions persistent en fonction des backends non opérationnels, selon l'option de persistance des connexions, l'affinité de session, le mode de suivi des connexions et le protocole.

Persistance de connexion sur les backends non opérationnels	Comportement de la persistance des connexions 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 : 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 N'utilisez cette option que pour les cas d'utilisation avancée.	TCP, UDP : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)	Configuration impossible

Lorsque la persistance des connexions sur les backends non opérationnels s'applique au trafic, chaque connexion persiste tant qu'une entrée de table de suivi des connexions correspondante existe. Pour en savoir plus, consultez l'étape Gérer les entrées du tableau de suivi des connexions.

Pour savoir comment modifier le comportement de la persistance des connexions, consultez la page 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 de connexion par hachage à 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)
• Lorsque vous utilisez le mode de suivi PER_SESSION, et l'affinité de session est soit NONE, soit CLIENT_IP_PORT_PROTO.

Lorsque l'équilibreur de charge utilise un suivi de connexion par 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 effectuer une nouvelle tentative de connexion, laissant ainsi l'équilibreur de charge sélectionner un autre backend éligible. (Les paquets TCP SYN sont traités comme de nouvelles connexions lors de l'étape Identifier les backends éligibles.)

Délai d'inactivité

Une entrée de table de suivi des connexions est supprimée une fois que la connexion est inactive pendant une certaine période. Sauf si vous configurez un délai d'inactivité personnalisé, l'équilibreur de charge utilise une valeur par défaut de 600 secondes (10 minutes).

Le tableau suivant indique les valeurs de délai d'inactivité minimales et maximales configurables pour différentes combinaisons de paramètres d'affinité de session et de mode de suivi des connexions.

Affinité de session	Mode de suivi des connexions	Délai d'inactivité par défaut	Délai d'inactivité minimal configurable	Délai d'inactivité maximal configurable
Tout tuple de connexion	PER_CONNECTION	600 secondes	60 secondes	600 secondes
1 tuple (CLIENT_IP_NO_DESTINATION) 2-tuple (CLIENT_IP) Trois tuples (CLIENT_IP_PROTO)	PER_SESSION	600 secondes	60 secondes	57 600 secondes
Cinq tuples (NONE, CLIENT_IP_PORT_PROTO)	PER_SESSION	600 secondes	60 secondes	600 secondes

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

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

Le drainage de connexion fournit une durée minimale configurable pendant laquelle les connexions existantes peuvent persister 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 de backend (y compris l'abandon d'une instance dans un groupe d'instances géré de backend)
• Une VM est arrêtée ou supprimée (y compris les actions automatiques telles que les mises à jour progressives ou la réduction de la taille 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, arrêtés ou effacés est désactivé. Pour en savoir plus, consultez Activer le drainage de connexion.

Basculement

Le basculement vous permet d'influencer l'ensemble des backends éligibles pour les nouvelles connexions en classant chaque groupe d'instances de backend ou NEG comme principal ou de basculement.

Par défaut, lorsque vous ajoutez un groupe d'instances ou un NEG à un service de backend, les VM ou points de terminaison membres sont des backends principaux, et le groupe d'instances ou le NEG est un groupe de backends principaux. Le basculement vous permet d'ajouter un groupe de backends de basculement (groupe d'instances ou NEG) dont les VM ou points de terminaison membres sont des backends de basculement :

• Pour le basculement, un service de backend doit comporter au moins un groupe de backend principal et au moins un groupe de backend de secours.
• Vous pouvez ajouter jusqu'à 50 groupes de backend principaux et 50 groupes de backend de basculement à un service de backend.

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

• État de fonctionnement de chaque backend
• Le taux de basculement que vous avez configuré
• Paramètre Supprimer le trafic si les backends ne sont pas opérationnels

Stratégie de basculement

Lorsqu'un service de backend comporte au moins un groupe de backend principal et au moins un groupe de backend de secours, vous pouvez ajuster les paramètres suivants dans sa stratégie de basculement :

• 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 Supprimer 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 indique 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 configuré détermine quand l'ensemble des backends éligibles bascule entre les backends principaux et de basculement. Le taux peut être un nombre compris entre 0.0 et 1.0 (inclus). Si vous n'indiquez pas de taux de basculement, Google Cloud 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

L'option Drainage de connexion lors du basculement contrôle si une connexion existante persiste sur une VM de backend ou un point de terminaison précédemment sélectionnés lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de secours.

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

Option de drainage de connexion en cas de basculement	Comportement lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de basculement
Activés (par défaut)	Tous les protocoles : les connexions persistent tant qu'une entrée de table de suivi des connexions correspondante existe, 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.
Désactivé	Tous les protocoles : les connexions ne persistent pas lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de basculement.

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

• Application de correctifs sur les VM de backend : Avant l'application de correctifs, vous pouvez configurer les backends principaux opérationnels pour qu'ils échouent aux vérifications d'état. Les backends éligibles peuvent ainsi devenir des backends de basculement opérationnels. En désactivant le drainage de connexion lors du basculement et de la restauration, 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 envoie à 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 des backends éligibles ne comporte pas plus d'une VM ou d'un point de terminaison membre, la désactivation du drainage de connexion en cas de basculement et de rétablissement réduit le risque d'incohérences de données.

Pour savoir comment désactiver le drainage de connexion lors du basculement et de la restauration, consultez Désactiver le drainage de connexion lors du basculement et de la restauration.

Bonnes pratiques et conseils

Vous pouvez optimiser l'équilibreur de charge réseau passthrough interne en suivant ces consignes opérationnelles. Les sections suivantes fournissent 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.

Gestion de la fragmentation UDP

Les équilibreurs de charge réseau passthrough internes 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 non-Google Cloud et l'équipement réseau sur site peuvent transférer les fragments UDP à leur arrivée, retarder les paquets UDP fragmentés jusqu'à ce que tous les fragments soient arrivés, ou supprimer les paquets UDP fragmentés. Pour en savoir plus, consultez la documentation du fournisseur réseau ou de l'équipement réseau.

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

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

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

Tester à partir d'un seul client

Lorsque vous testez un équilibreur de charge réseau passthrough interne à 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 de la section 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 souvent que prévu. 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 interne à 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 traitées par l'équilibreur de charge. Les paquets sortants dont l'adresse IP de destination correspond à celle de 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 et tester un équilibreur de charge réseau passthrough interne qui utilise le basculement, consultez la page Configurer le basculement pour les équilibreurs de charge réseau à stratégie interne.
• Pour configurer et tester un équilibreur de charge réseau passthrough interne, consultez la page Configurer un équilibreur de charge réseau à stratégie interne.