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, nous avons mis en place 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 le processus de sélection du backend et de suivi des connexions.

1. Rechercher une entrée dans la table de suivi des connexions pour utiliser un backend précédemment sélectionné

Pour une connexion existante, l'équilibreur de charge utilise la table de suivi des connexions pour identifier le backend précédemment sélectionné pour cette connexion.

L'équilibreur de charge tente de faire correspondre chaque paquet à équilibrage de charge à une entrée de sa table de suivi des connexions en suivant le processus suivant :

• Si le paquet est un 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. Dans le 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 vous utilisez l'une des options d'affinité de session à cinq tuples (NONE ou CLIENT_IP_PORT_PROTO).

• Si l'affinité de session configurée ne prend pas en charge le suivi des connexions pour le protocole du paquet, passez à l'étape Identifier les backends éligibles. Pour savoir quels protocoles peuvent être suivis, consultez le tableau de la section Mode de suivi des connexions.

• Pour 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. Le tuple de connexion (ensemble de caractéristiques de paquets) utilisé pour comparer le paquet aux entrées existantes de 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 savoir quel tuple de connexion est utilisé pour le suivi des connexions, 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 table de suivi des connexions est conservée et dans quelles conditions, consultez l'étape Créer une entrée de table de suivi des connexions.

2. Sélectionner un backend éligible pour une nouvelle connexion

Pour une nouvelle connexion, l'équilibreur de charge utilise l'algorithme de 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

Cette étape modélise les backends susceptibles de recevoir de nouvelles connexions, en tenant compte de l'état, de la configuration de l'équilibrage de charge pondéré et de la stratégie de basculement.

Le tableau suivant décrit comment la règle de basculement et l'équilibrage de charge pondéré influencent les backends éligibles.

Aucune règle de basculement, équilibrage de charge pondéré désactivé

L'ensemble des backends éligibles dépend uniquement des vérifications de l'état :

• 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 se compose de tous les backends.

Aucune règle de basculement, équilibrage de charge pondéré activé

L'ensemble des backends éligibles dépend à la fois des vérifications de l'état et des pondérations. Il se compose du premier des éléments 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 et dont la pondération est nulle
• Tous les backends non opérationnels et de pondération nulle

Règle de basculement configurée, équilibrage de charge pondéré désactivé

L'ensemble des backends éligibles dépend de la configuration des vérifications d'état et de la stratégie de reprise après sinistre :

• Lorsqu'au moins un backend est opérationnel, l'ensemble des backends éligibles est défini comme suit, en utilisant la première condition vraie de cette liste ordonnée :

  • 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 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, l'ensemble des backends éligibles est défini comme suit :

  • Si la règle de basculement de l'équilibreur de charge est configurée pour supprimer les nouvelles connexions lorsqu'aucun backend n'est opérationnel, l'ensemble des backends éligibles est vide. L'équilibreur de charge abandonne les paquets pour les nouvelles connexions.
  • Si la règle de basculement de l'équilibreur de charge n'est pas configurée pour supprimer les nouvelles connexions lorsqu'aucun backend n'est opérationnel, les vérifications de l'état ne sont pas pertinentes. Les backends éligibles sont tous les backends principaux.

Stratégie de basculement configurée, équilibrage de charge pondéré activé

L'ensemble des backends éligibles dépend de la configuration des vérifications de l'état, des pondérations et de la règle de basculement :

• Lorsqu'au moins un backend est opérationnel et a un poids non nul, l'ensemble des backends éligibles est défini comme suit, en utilisant la première condition qui est vraie dans cette liste ordonnée :

  • S'il n'y a pas de backends principaux opérationnels avec une pondération non nulle, les backends éligibles sont tous les backends de secours opérationnels avec une pondération non nulle.
  • S'il n'existe aucun backend de secours opérationnel dont la pondération est non nulle, 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 n'est pas nulle.
  • 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 ratio de basculement configuré, les backends éligibles sont tous les backends principaux opérationnels avec une pondération non nulle.
  • Les backends éligibles sont tous les backends de secours opérationnels et dont la pondération est non nulle.

• Lorsqu'il n'y a pas de backends opérationnels avec un poids non nul, l'ensemble des backends éligibles est défini comme suit :

  • Si la règle de basculement de l'équilibreur de charge est configurée pour supprimer les nouvelles connexions lorsqu'aucun backend n'est opérationnel, l'ensemble des backends éligibles est vide. L'équilibreur de charge abandonne les paquets pour les nouvelles connexions.

  • Si la stratégie de basculement de l'équilibreur de charge n'est pas configurée pour abandonner les nouvelles connexions lorsqu'aucun backend n'est opérationnel, l'ensemble des backends éligibles est le premier des ensembles suivants qui n'est pas vide :

    • Tous les backends principaux non opérationnels et dont la pondération est non nulle
    • Tous les backends de secours non opérationnels et dont la pondération est non nulle
    • Tous les backends principaux opérationnels et de pondération nulle
    • Tous les backends de secours opérationnels et dont la pondération est nulle
    • Tous les backends principaux non opérationnels et de pondération nulle
    • Tous les backends de basculement non opérationnels et de pondération nulle

2.2 Sélectionner un backend éligible

L'équilibreur de charge utilise le hachage cohérent pour sélectionner un backend éligible. L'équilibreur de charge conserve les hachages des backends éligibles, mappés sur 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.

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

• Les deux exemples suivants montrent comment l'équilibrage de charge pondéré affecte la sélection d'un 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)).

• L'équilibreur de charge attribue de nouvelles connexions aux backends éligibles de la manière la plus cohérente possible, même si le nombre de backends éligibles ou leurs pondérations changent. Les avantages suivants du hachage cohérent montrent comment l'équilibreur de charge sélectionne les backends éligibles pour les nouvelles connexions possibles qui n'ont pas d'entrées dans la table de suivi des connexions :

  • 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, dans les situations suivantes :

    • Si l'équilibrage de charge pondéré n'est pas configuré, lorsque 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.

  • L'équilibreur de charge distribue les nouvelles connexions possibles entre les backends éligibles de la manière la plus équitable possible :

    • Si l'équilibrage de charge pondéré n'est pas configuré, environ 1/N nouvelles connexions possibles sont mappées à chaque backend éligible, où N correspond au nombre de backends éligibles.

    • Si l'équilibrage de charge pondéré est configuré, le ratio de nouvelles connexions possibles qui sont mappées à chaque backend éligible est approximativement le suivant : la pondération d'un backend éligible divisée par la somme de toutes les pondérations de backend éligibles.

    • Si un backend éligible est ajouté, supprimé ou voit son poids 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.

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 ne prend pas en charge 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 de connexion 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 paquet sont utilisées pour le hachage, consultez la section Mode de suivi des connexions.

L'équilibreur de charge supprime les entrées de la table de suivi des connexions selon les règles suivantes :

• 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é.

• Les entrées de la table de suivi des connexions ne sont pas supprimées lorsqu'une connexion TCP est fermée avec un paquet FIN ou RST. Toute nouvelle connexion TCP comporte toujours l'indicateur SYN et est traitée comme décrit dans l'étape Rechercher une entrée dans la table de suivi des connexions.

• Si une règle de basculement est configurée et que le paramètre "Drainage de connexion lors du basculement et de la restauration" est désactivé, l'équilibreur de charge supprime toutes les entrées de la table de suivi des connexions lorsque les backends éligibles passent des backends principaux aux backends de basculement (basculement) ou des backends de basculement aux backends principaux (restauration). Pour en savoir plus, consultez Drainage de connexion lors du basculement et de la restauration.

• 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 du mode de suivi des connexions, du protocole et du paramètre de persistance des connexions sur les backends non opérationnels. Pour en savoir plus, consultez Persistance des connexions sur les backends non opérationnels.

• Les entrées du tableau de suivi des connexions sont supprimées après le délai avant expiration du drainage de connexion qui se produit à la suite d'un événement tel que la suppression d'une VM de backend ou le retrait d'une VM de backend d'un groupe d'instances ou d'un NEG. Pour en savoir plus, consultez Activer le drainage de connexion.

Affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux backends de l'équilibreur de charge. Les équilibreurs de charge réseau passthrough externes utilisent l'affinité de session pour sélectionner un backend parmi un ensemble de backends éligibles, comme décrit dans les étapes Identifier les backends éligibles et Sélectionner un backend éligible de la section Sélection du backend et suivi des connexions. Vous configurez l'affinité de session sur le service de backend, et non sur chaque groupe d'instances backend ou NEG.

Les équilibreurs de charge réseau passthrough externes sont compatibles avec les paramètres d'affinité de session suivants. Chaque paramètre d'affinité de session utilise le hachage cohérent pour sélectionner un backend éligible. Le paramètre d'affinité de session détermine les champs des en-têtes IP et TCP/UDP utilisés pour calculer le hachage.

Pour savoir comment les différents paramètres d'affinité de session affectent les méthodes de sélection du backend et de suivi des connexions, consultez le tableau de la section Mode de suivi des connexions.

Règle de suivi de connexion

Cette section décrit les paramètres qui contrôlent le comportement de suivi des connexions des équilibreurs de charge réseau passthrough externes. Une règle de suivi des connexions inclut les paramètres suivants :

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

Mode de suivi des connexions

Lorsque le suivi des connexions est possible, la table de suivi des connexions de l'équilibreur de charge mappe les tuples de connexion aux backends précédemment sélectionnés dans une table de hachage. L'ensemble des caractéristiques de paquet qui composent chaque tuple de connexion dépend du mode de suivi des connexions et de l'affinité de session.

Les équilibreurs de charge réseau passthrough externes sont compatibles avec le suivi des connexions en fonction des options de protocole et d'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.

Le mode de suivi des connexions fait référence à la précision de chaque tuple de connexion dans la table de suivi des connexions de l'équilibreur de charge. Le tuple de connexion peut être à cinq tuples ou à trois tuples (mode PER_CONNECTION), ou il peut correspondre au paramètre d'affinité de session (mode PER_SESSION).

• PER_CONNECTION : il s'agit du mode de suivi des connexions par défaut. Ce mode de suivi des connexions utilise un hachage à cinq tuples ou à trois tuples. Les paquets non fragmentés qui incluent des informations sur le 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 utilise un hachage composé des mêmes caractéristiques de paquet que le hachage de l'affinité de session. Selon l'affinité de session choisie, PER_SESSION peut entraîner des connexions qui correspondent plus fréquemment à une entrée de table de suivi des connexions existante, ce qui réduit la fréquence à laquelle un backend doit être sélectionné par le hachage d'affinité de session.

Le tableau suivant récapitule comment le mode de suivi des connexions et l'affinité de session fonctionnent ensemble pour acheminer tous les paquets de chaque connexion vers le même backend.

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

Persistance des connexions sur les backends non opérationnels

Les paramètres de persistance de connexion contrôlent si une connexion existante persiste sur une VM de backend ou un point de terminaison sélectionné après que ce backend n'est plus opérationnel, tant que le backend reste dans le groupe de backend configuré de l'équilibreur de charge (dans un groupe d'instances ou un NEG).

Les options de persistance de connexion suivantes sont disponibles :

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

Le tableau suivant récapitule les options de persistance des connexions et indique leur comportement de persistance en fonction des différents protocoles, options d'affinité de session et modes de suivi.

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

Chaque fois qu'une connexion TCP avec un suivi à cinq tuples persiste sur un backend non opérationnel :

• Si le backend non opérationnel continue de répondre aux paquets, la connexion se poursuit jusqu'à ce qu'elle soit réinitialisée ou fermée (par le backend non opérationnel ou le client).
• Si le backend non opérationnel envoie un paquet de réinitialisation TCP (RST) ou ne répond pas aux paquets, le client peut effectuer une nouvelle tentative de connexion, laissant ainsi l'équilibreur de charge sélectionner un autre backend opérationnel. Les paquets TCP SYN sélectionnent toujours un nouveau backend opérationnel.

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

Délai d'inactivité

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

Équilibrage de charge pondéré

L'équilibrage de charge pondéré pour les équilibreurs de charge réseau passthrough externes utilise les informations de pondération signalées par une vérification d'état HTTP. L'équilibrage de charge pondéré nécessite la configuration de tous les éléments suivants :

• La règle d'équilibrage de charge de la localité du service de backend (localityLbPolicy) doit être définie sur WEIGHTED_MAGLEV.
• Le service de backend doit utiliser une vérification de l'état HTTP.
• Les réponses de vérification d'état de chaque VM ou point de terminaison de backend doivent contenir un en-tête de réponse HTTP personnalisé. Le nom du champ d'en-tête de réponse est X-Load-Balancing-Endpoint-Weight, et les valeurs de champ valides sont comprises entre 0 et 1000.

Si vous devez utiliser le même groupe d'instances ou NEG comme backend pour deux services de backend ou plus, nous vous recommandons la stratégie suivante afin que chacune des instances ou chacun des points de terminaison de backend communs puisse fournir des informations de pondération uniques pour chaque service de backend :

• Utilisez une vérification de l'état HTTP unique pour chaque service de backend. Par exemple, utilisez un paramètre de vérification de l'état request-path 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.

Lorsque vous utilisez l'équilibrage de charge pondéré, l'équilibreur de charge classe les VM ou les points de terminaison de backend, d'abord en fonction de leur pondération (supérieure ou égale à zéro), puis en fonction des vérifications de l'état. L'état de la vérification d'état est déterminé par les critères de réussite pour les vérifications d'état HTTP, HTTPS et HTTP/2.

Pour en savoir plus sur l'influence de l'équilibrage de charge pondéré sur les backends éligibles, consultez les étapes Identifier les backends éligibles et Sélectionner un backend éligible de la section Sélection du backend et suivi des connexions.

L'équilibrage de charge pondéré peut être utilisé dans les scénarios suivants:

• Si certaines connexions traitent plus de données que d'autres ou que certaines connexions existent plus longtemps que d'autres, la distribution de la charge du backend peut être inégale. En signalant une pondération par instance inférieure, une instance avec une charge élevée peut réduire sa part des nouvelles connexions, tout en conservant les connexions existantes.

• Si un backend est surchargé et que l'attribution de connexions supplémentaires peut interrompre les connexions existantes, ces backends s'attribuent zéro pondération. En signalant une pondération nulle, une instance backend cesse de traiter les nouvelles connexions, mais continue à desservir les connexions existantes.

• Si un backend draine des connexions existantes avant la maintenance, il s'attribue une pondération nulle. En signalant une pondération nulle, l'instance backend cesse de traiter les nouvelles connexions, mais continue à traiter les connexions existantes.

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

Drainage de connexion

Le drainage de connexion fournit un délai supplémentaire configurable pour que les connexions établies persistent dans le tableau de suivi des connexions de l'équilibreur de charge lorsque l'une des actions suivantes 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 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 pour les actions susmentionnées est désactivé. Pour en savoir plus sur le déclenchement et l'activation du drainage de connexion, consultez la page Activer le drainage de connexion.

Fragmentation UDP

Les équilibreurs de charge réseau passthrough externes basés sur un service de backend peuvent traiter à la fois les paquets UDP fragmentés et non fragmentés. Si votre application utilise des paquets UDP fragmentés, gardez à l'esprit les points suivants :

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

Basculement

Vous pouvez configurer un équilibreur de charge réseau passthrough externe pour répartir les connexions entre les instances de VM ou les points de terminaison des backends principaux (groupes d'instances ou NEG), puis, si nécessaire, utiliser des backends de basculement. Avec le basculement, vous disposez d'une autre méthode permettant d'augmenter la disponibilité tout en étant mieux à même de contrôler la gestion de votre charge de travail lorsque les backends principaux ne sont pas opérationnels.

Par défaut, lorsque vous ajoutez un backend à un service de backend d'un équilibreur de charge réseau passthrough externe, ce backend est un backend principal. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend de l'équilibreur de charge, ou en modifiant le service de backend ultérieurement.

Pour en savoir plus sur l'utilisation du basculement pour la sélection du backend et le suivi des connexions, consultez les étapes Identifier les backends éligibles et Créer une entrée dans le tableau de suivi des connexions de la section Sélection du backend et suivi des connexions.

Pour en savoir plus sur le fonctionnement du basculement, consultez la page Présentation du basculement pour les équilibreurs de charge réseau passthrough externes.

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