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

Cette page explique comment les équilibreurs de charge réseau passthrough externes 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é une stratégie de basculement et que l'équilibrage de charge pondéré est activé ou non.

Stratégie de basculement Équilibrage de charge pondéré Backends éligibles

Lorsqu'aucune règle de basculement n'est configurée et que l'équilibrage de charge pondéré est désactivé, 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'aucune règle de basculement n'est configurée et que l'équilibrage de charge pondéré est activé, 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 avec une pondération nulle

Lorsqu'une règle de basculement est configurée et que l'équilibrage de charge pondéré est désactivé, 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 :
    1. S'il n'y a aucun backend principal opérationnel, les backends éligibles sont tous les backends de secours opérationnels.
    2. S'il n'y a pas de backends de secours opérationnels, les backends éligibles sont tous les backends principaux opérationnels.
    3. 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.
    4. 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.
    5. 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.

Lorsqu'une stratégie de basculement est configurée et que l'équilibrage de charge pondéré est activé, l'équilibreur de charge utilise les informations sur la pondération, les informations vérification de l'état'état et la configuration de la stratégie 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 :
    1. 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 secours opérationnels dont la pondération est non nulle.
    2. Si l'ensemble des backends de secours 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.
    3. 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.
    4. Si le ratio du nombre de backends principaux opérationnels avec une pondération non nulle par rapport au 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 avec une pondération non nulle.
    5. Les backends éligibles sont tous les backends de secours opérationnels dont la pondération est non nulle.
  • Lorsqu'il n'y a pas de backends opérationnels avec un poids non nul (principaux et de basculement), l'ensemble des backends éligibles dépend de la configuration de la règle de basculement :
    • Si la stratégie de basculement est configurée pour abandonner les nouvelles connexions lorsqu'il n'y a pas de backends principaux et de basculement opérationnels avec une pondération non nulle, l'ensemble des backends éligibles est vide. Par conséquent, l'équilibreur de charge supprime les paquets pour les nouvelles connexions.
    • Si la stratégie de basculement n'est pas configurée pour supprimer les nouvelles connexions lorsqu'il n'y a pas de backends principaux et de secours opérationnels dont la pondération n'est pas nulle, les backends éligibles sont ceux qui proviennent du premier des ensembles suivants qui n'est pas vide :
      1. Tous les backends principaux non opérationnels dont la pondération est non nulle
      2. Tous les backends de basculement non opérationnels avec une pondération non nulle
      3. Tous les backends principaux opérationnels avec un poids nul
      4. Tous les backends de secours opérationnels avec une pondération nulle
      5. Tous les backends principaux non opérationnels avec une pondération nulle
      6. Tous les backends de secours non opérationnels avec une pondération nulle

2.2 Sélectionnez un backend éligible

L'équilibreur de charge conserve les hachages des backends éligibles, chaque hachage de backend étant mappé à un cercle unité. 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 à leurs pondérations.

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 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 présentant 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é, l'ensemble des 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 son poids est modifié, 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 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) :

    • 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 de hachages de paquets possibles qui correspondent à chaque backend éligible est approximativement égal à la pondération d'un backend éligible divisée par la somme de toutes les pondérations de backend é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 (backend éligible a avec un poids de 0, backend éligible b avec un poids de 2 et backend éligible c avec un poids de 6), le backend a a une probabilité de sélection de 0 % (0/(0+2+6)), le backend b a une probabilité de sélection de 25 % (2/(0+2+6)) et le backend c a une probabilité de sélection de 75 % (6/(0+2+6)).

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

Après avoir sélectionné un backend, l'équilibreur de charge crée une entrée dans la table de suivi des connexions si l'affinité de session configurée est compatible avec le suivi des connexions pour le protocole du paquet.

  • Si l'affinité de session configurée n'est pas compatible avec le suivi des connexions pour le protocole du paquet, 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 savoir quels protocoles peuvent être suivis en fonction de vos choix de configuration et quelles caractéristiques de paquets sont utilisées pour le hachage dans le tableau 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 en fonction des événements et des 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 d'inactivité de la connexion. 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 externe 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 externes 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

 NONE1
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

1 : 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.

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

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 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 sauf NONE.

  • Tous les autres protocoles, tels qu'ICMP et ICMPv6, ne peuvent pas faire l'objet d'un suivi des connexions.

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 à 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)
  • 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 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 : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)
  • ESP, GRE, UDP : les connexions persistent sur les backends non opérationnels si l'affinité de session n'est pas définie sur NONE.
  • Tous les autres protocoles : non applicable, car ces protocoles ne sont pas compatibles avec le suivi des connexions
 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é

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

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.

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

Points à prendre en compte pour 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 aux 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). Cela fonctionne, car tous les backends avec un poids non nul (quel que soit l'état de la vérification de l'état'état) sont des backends éligibles 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 indiquer un poids 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 paramètre request-path ou un port de destination unique.

    • Configurez les instances ou les points de terminaison backend pour qu'ils répondent avec les informations de pondération appropriées pour chaque vérification de l'état'état.

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
  • Que vous utilisiez le basculement seul ou avec l'équilibrage de charge pondéré

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)
  • 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 non suivis par le suivi de connexion : les connexions ne persistent pas lorsque l'ensemble des backends éligibles bascule entre les backends principaux et de secours.

Pour savoir quels protocoles peuvent être suivis, consultez le tableau de la section Mode 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 avec un poids non nul 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 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 externe 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 externes basés sur un service de backend peuvent traiter à la fois les paquets UDP fragmentés et non fragmentés. Si votre application utilise des paquets UDP fragmentés, gardez à l'esprit les points suivants :

  • Les paquets UDP peuvent être fragmentés avant d'atteindre un réseau VPC Google Cloud.
  • Google Cloud Les réseaux VPC transfèrent les fragments UDP dès leur arrivée (sans attendre que tous les fragments arrivent).
  • Les réseaux 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 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 à 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 externe à 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