Distribution des requêtes pour les équilibreurs de charge d'application externes

Ce document explique en détail comment les équilibreurs de charge d'application externes gèrent les connexions, acheminent le trafic et maintiennent l'affinité de session.

Fonctionnement des connexions

Les équilibreurs de charge d'application externes deTrusted Cloud(globaux et régionaux) simplifient le routage à l'aide de proxys distribués (GFE) ou de sous-réseaux gérés par Envoy. Grâce à des délais d'attente configurables, à la terminaison TLS et à la sécurité intégrée, ils garantissent une diffusion d'applications conforme et évolutive dans le monde entier ou au niveau régional.

Connexions à l'équilibreur de charge d'application externe régional

L'équilibreur de charge d'application externe régional est un service géré mis en œuvre sur le proxy Envoy. L'équilibreur de charge d'application externe régional utilise un sous-réseau partagé appelé sous-réseau proxy réservé pour provisionner un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy dans un réseau et une région spécifiques partagent ce sous-réseau.

Les clients utilisent l'adresse IP et le port de l'équilibreur de charge pour se connecter à cet équilibreur de charge. Les requêtes des clients sont dirigées vers le sous-réseau proxy réservé situé dans la même région que le client. L'équilibreur de charge interrompt les requêtes des clients, puis ouvre de nouvelles connexions entre le sous-réseau proxy réservé et vos backends. Par conséquent, les paquets envoyés à partir de l'équilibreur de charge ont des adresses IP sources du sous-réseau proxy réservé.

Selon la configuration du service de backend, le protocole utilisé par les proxys Envoy pour se connecter aux backends peut être HTTP, HTTPS ou HTTP/2. Dans le cas de HTTP ou HTTPS, la version HTTP est HTTP 1.1. Le message HTTP keepalive est activé par défaut, comme indiqué dans la spécification HTTP 1.1. Le proxy Envoy définit à la fois le délai avant expiration du message keepalive HTTP client et le délai avant expiration du message keepalive du backend sur une valeur par défaut de 600 secondes chacun. Vous pouvez mettre à jour le délai avant expiration du message keepalive HTTP client, mais la valeur du délai avant expiration du message keepalive du backend est fixe. Vous pouvez configurer le délai avant expiration de la requête/réponse en définissant le délai avant expiration du service de backend. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

Communication entre les clients et l'équilibreur de charge

• Les clients peuvent communiquer avec l'équilibreur de charge via le protocole HTTP 1.1 ou HTTP/2.
• Lorsque HTTPS est utilisé, les clients modernes utilisent par défaut HTTP/2. Ce fonctionnement est contrôlé au niveau du client et non au niveau de l'équilibreur de charge HTTPS.
• Vous ne pouvez pas désactiver HTTP/2 en modifiant la configuration sur l'équilibreur de charge. Toutefois, vous pouvez configurer certains clients pour qu'ils utilisent HTTP 1.1 au lieu de HTTP/2. Par exemple, avec curl, définissez le paramètre --http1.1.
• Les équilibreurs de charge d'application externes acceptent la réponse HTTP/1.1 100 Continue.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert d'équilibreur de charge d'application externe dans chaque mode, consultez la page Fonctionnalités de l'équilibreur de charge.

Adresses IP sources des paquets client

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externeTrusted Cloud de l'équilibreur de charge. En d'autres termes, il existe deux connexions TCP :

Pour les équilibreurs de charge d'application externes régionaux :

• Connexion 1, du client d'origine vers l'équilibreur de charge (sous-réseau proxy réservé) :

  • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par une passerelle NAT ou un proxy de transfert).
  • Adresse IP de destination : adresse IP de votre équilibreur de charge.

• Connexion 2, de l'équilibreur de charge (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :

  • Adresse IP source : adresse IP du sous-réseau proxy réservé partagée entre tous les équilibreurs de charge basés sur Envoy déployés dans la même région et sur le même réseau que l'équilibreur de charge.

  • Adresse IP de destination : adresse IP interne de la VM de backend ou du conteneur dans le réseau VPC.

Chemins de routage spéciaux

Trusted Cloud utilise des routes spéciales non définies dans votre réseau VPC pour acheminer les paquets pour les types de trafic suivants :

• Pour les vérifications d'état, à l'exception des vérifications d'état Envoy distribuées. Pour en savoir plus, consultez la section Chemins d'accès pour les vérifications d'état.

Trusted Cloud utilise des routes de sous-réseau pour les sous-réseaux proxy réservés afin de rediriger les paquets pour les types de trafic suivants :

• Lorsque vous utilisez des vérifications d'état Envoy distribuées.

Pour les équilibreurs de charge d'application externes régionaux, Trusted Cloud utilise des proxys Envoy Open Source pour interrompre les requêtes des clients adressées à l'équilibreur de charge. L'équilibreur de charge interrompt la session TCP et ouvre une nouvelle session TCP depuis le sous-réseau proxy réservé de la région vers votre backend. Les routes définies au sein de votre réseau VPC facilitent la communication entre les proxys Envoy et vos backends, et inversement.

terminaison TLS

Le tableau suivant récapitule la manière dont la terminaison TLS est gérée par les équilibreurs de charge d'application externes.

Mode d'équilibreur de charge	terminaison TLS
Équilibreur de charge d'application externe régional	TLS est interrompu sur les proxys Envoy situés dans un sous-réseau proxy réservé dans une région choisie par l'utilisateur. Utilisez ce mode d'équilibreur de charge si vous avez besoin d'exercer un contrôle géographique sur la région où le protocole TLS est interrompu.

Délais d'expiration et nouvelles tentatives

Les équilibreurs de charge d'application externes sont compatibles avec les types de délais d'expiration suivants pour le trafic HTTP ou HTTPS :

Type de délai d'expiration et description	Valeurs par défaut	Valeurs de délai avant expiration personnalisées acceptées
		Délai avant expiration du service de backend1 Un délai avant expiration de la requête et de la réponse Représente la durée maximale autorisée entre le moment où l'équilibreur de charge envoie le premier octet d'une requête au backend et le moment où celui-ci renvoie le dernier octet de la réponse HTTP à l'équilibreur de charge. Si le backend n'a pas renvoyé la réponse HTTP entière à l'équilibreur de charge dans ce délai, les données de réponse restantes sont supprimées.	Pour tous les autres types de backends sur un service de backend : 30 secondes
Délai d'expiration du message keepalive HTTP client Durée maximale d'inactivité de la connexion TCP entre un client et le proxy de l'équilibreur de charge. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.) Pour les équilibreurs de charge d'application externes régionaux, le proxy de l'équilibreur de charge correspond au logiciel Envoy.	610 secondes
Délai avant expiration du message keepalive HTTP du backend Durée maximale d'inactivité de la connexion TCP entre le proxy de l'équilibreur de charge et un backend. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.) Pour les équilibreurs de charge d'application externes régionaux, le proxy de l'équilibreur de charge correspond au logiciel Envoy.	Pour les services de backend : 10 minutes (600 secondes)

Délai avant expiration du service de backend

Le délai avant expiration du service backend configurable représente la durée maximale pendant laquelle l'équilibreur de charges attend que de votre backend traite une requête HTTP et renvoie la réponse HTTP correspondante. À l'exception des NEG sans serveur, la valeur par défaut du délai avant expiration du service de backend est de 30 secondes.

Par exemple, si vous souhaitez télécharger un fichier de 500 Mo et que la valeur du délai avant expiration du service de backend est de 90 secondes, l'équilibreur de charge s'attend à ce que le backend fournisse l'intégralité du fichier de 500 Mo dans un délai de 90 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il soit insuffisant pour envoyer une réponse HTTP complète. Dans ce cas, si l'équilibreur de charge a au moins reçu des en-têtes de réponse HTTP du backend, il renvoie les en-têtes de réponse complets et tout ce qu'il a pu tirer du corps de réponse dans le délai avant expiration du service de backend.

Nous vous recommandons de définir le délai avant expiration du service de backend sur la durée la plus longue attendue par votre backend pour traiter une réponse HTTP. Si le logiciel exécuté sur votre backend a besoin de plus de temps pour traiter une requête HTTP et renvoyer sa réponse complète, nous vous recommandons d'augmenter le délai avant expiration du service de backend. Par exemple, nous vous recommandons d'augmenter le délai avant expiration si vous voyez des réponses avec le code d'état HTTP 408 et des erreurs jsonPayload.statusDetail client_timed_out.

Le délai avant expiration du service de backend accepte des valeurs comprises entre 1 et 2,147,483,647 secondes. Cependant, les valeurs plus élevées ne sont pas des options pratiques de configuration.Trusted Cloud ne garantit pas non plus qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de compter sur une connexion TCP pour être ouverte pendant de longues périodes.

Pour configurer le délai avant expiration du service de backend, utilisez l'une des méthodes suivantes :

Les délais avant expiration de la connexion WebSocket ne sont pas toujours les mêmes que ceux du service de backend. Les délais avant expiration de la connexion WebSocket dépendent du type d'équilibreur de charge :

Mode d'équilibreur de charge	Valeurs par défaut	Description du délai avant expiration pour les WebSockets
Équilibreur de charge d'application externe régional	Délai avant expiration du service de backend : 30 secondes	Les connexions WebSocket actives n'utilisent pas le délai avant expiration du service de backend de l'équilibreur de charge. Les connexions WebSocket inactives sont fermées au terme du délai avant expiration du service de backend. Trusted Cloud redémarre ou modifie périodiquement le nombre de tâches logicielles Envoy servies. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que les tâches de redémarrage ou d'arrêt d'Envoy interrompent les connexions TCP.

Les équilibreurs de charge d'application externes régionaux utilisent le paramètre routeActions.timeout configuré des mappages d'URL et ignorent le délai avant expiration du service de backend. Lorsque routeActions.timeout n'est pas configuré, la valeur du délai avant expiration du service de backend est utilisée. Lorsque routeActions.timeout est fourni, le délai avant expiration du service de backend est ignoré et la valeur de routeActions.timeout est utilisée comme délai avant expiration de la requête et de la réponse.

Délai d'expiration du message keepalive HTTP client

Le délai d'expiration du message keepalive HTTP client représente la durée maximale pendant laquelle une connexion TCP peut être inactive entre le client en aval et l'un des types de proxys suivants :

• Pour un équilibreur de charge d'application externe régional : un proxy Envoy

Le délai avant expiration du message keepalive HTTP du client représente le délai d'inactivité TCP pour les connexions TCP sous-jacentes. Le délai avant expiration du message keepalive HTTP client ne s'applique pas aux WebSockets.

La valeur par défaut du délai avant expiration du message keepalive HTTP client est de 610 secondes. Pour les équilibreurs de charge d'application externes globaux et régionaux, vous pouvez configurer le délai avant expiration du message keepalive HTTP du client avec une valeur comprise entre 5 et 1 200 secondes.

Pour configurer le délai d'expiration du message HTTP du client, utilisez l'une des méthodes suivantes :

Le délai d'expiration du message keepalive HTTP client de l'équilibreur de charge doit être supérieur au délai d'expiration du message keepalive HTTP (TCP inactif) utilisé par les clients ou les proxys en aval. Si un client en aval possède un délai avant expiration du message keepalive HTTP (TCP inactif) supérieur à celui de l'équilibreur de charge, il est possible qu'une condition de concurrence se produise. Du point de vue d'un client en aval, une connexion TCP établie est autorisée à être inactive plus longtemps que l'équilibreur de charge ne le permet. Cela signifie que le client en aval peut envoyer des paquets après que l'équilibreur de charge considère la connexion TCP comme fermée. Dans ce cas, l'équilibreur de charge répond par un paquet de réinitialisation TCP (RST).

Lorsque le délai avant expiration du message keepalive HTTP du client est écoulé, le GFE ou le proxy Envoy envoie un message TCP FIN au client pour fermer la connexion en douceur.

Délai avant expiration du message keepalive HTTP du backend

Les équilibreurs de charge d'application externes sont des proxys qui utilisent au moins deux connexions TCP :

• Pour un équilibreur de charge d'application externe régional, une première connexion TCP existe entre le client (en aval) et un proxy Envoy. Le proxy Envoy ouvre ensuite une deuxième connexion TCP à vos backends.

les connexions TCP secondaires de l'équilibreur de charge peuvent ne pas être fermées après chaque requête ; elles peuvent rester ouvertes pour gérer plusieurs requêtes et réponses HTTP. Le délai avant expiration du message keepalive HTTP du backend définit le délai d'inactivité TCP entre l'équilibreur de charge et vos backends. Le délai avant expiration du message keepalive HTTP du backend ne s'applique pas aux WebSockets.

Le délai avant expiration du message keepalive du backend est fixé à 10 minutes (600 secondes) et ne peut pas être modifié. Cela permet de s'assurer que l'équilibreur de charge maintient les connexions inactives pendant au moins 10 minutes. Passé ce délai, l'équilibreur de charge peut envoyer des paquets de fin de connexion au backend à tout moment.

Le délai d'expiration du message keepalive du backend de l'équilibreur de charge doit être inférieur au délai d'expiration du message keepalive utilisé par les logiciels exécutés sur vos backends. Cela évite une condition de concurrence où le système d'exploitation de vos backends peut fermer les connexions TCP avec une réinitialisation TCP (RST). Étant donné que le délai avant expiration du message keepalive du backend pour l'équilibreur de charge n'est pas configurable, vous devez configurer votre logiciel backend de sorte que sa valeur de délai avant expiration de message keepalive HTTP (TCP inactive) soit supérieure à 600 secondes.

Lorsque le délai avant expiration du message keepalive HTTP du backend expire, le GFE ou le proxy Envoy envoie un message TCP FIN à la VM de backend pour fermer correctement la connexion.

Le tableau suivant répertorie les modifications à effectuer pour modifier les valeurs du délai d'expiration du message keepalive pour les logiciels de serveur Web courants.

Logiciel de serveur Web	Paramètre	Paramètre par défaut	Réglage recommandé
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Tentatives

La compatibilité de la logique de nouvelle tentative dépend du mode de l'équilibreur de charge d'application externe.

Mode d'équilibreur de charge

Logique de nouvelle tentative

Équilibreur de charge d'application externe régional

Configurable à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de nouvelles tentatives par défaut (numRetries) est de 1. Le nombre maximal de nouvelles tentatives pouvant être configurées à l'aide de la stratégie de nouvelle tentative est de 25. La valeur maximale configurable de perTryTimeout est de 24 heures. Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) qui aboutissent à des réponses HTTP 502, 503 ou 504 sont relancées. une fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative. Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale.

Le protocole WebSocket est compatible avec GKE Ingress.

Traitement des requêtes et réponses illégales

Il existe différentes raisons pour lesquelles l'équilibreur de charge peut être amené à empêcher des requêtes client ou des réponses du backend d'atteindre, respectivement, le backend ou le client. Certaines raisons sont strictement liées à la conformité avec le protocole HTTP/1.1. D'autres visent à éviter de transmettre des données inattendues en provenance ou à destination des backends. Aucune vérification ne peut être désactivée.

L'équilibreur de charge bloque les requêtes dans les cas de figure suivants pour assurer la conformité avec le protocole HTTP/1.1 :

• Il ne peut pas analyser la première ligne de la requête.
• Le délimiteur : manque dans un en-tête.
• Les en-têtes ou la première ligne contiennent des caractères non valides.
• La longueur du contenu n'est pas un nombre valide, ou il existe plusieurs en-têtes de longueur de contenu.
• Il existe plusieurs clés de codage de transfert ou des valeurs de codage de transfert non reconnues.
• La requête présente un corps non découpé en blocs et aucune longueur de contenu n'est spécifiée.
• Les blocs de corps ne peuvent pas être analysés. C'est le seul cas de figure où certaines données parviennent au backend. L'équilibreur de charge ferme les connexions au client et au backend lorsqu'il reçoit un bloc impossible à analyser.

Gestion des requêtes

L'équilibreur de charge bloque la requête si l'une des conditions suivantes est remplie :

• La taille totale des en-têtes et de l'URL de la requête dépasse la taille d'en-tête de requête maximale autorisée pour les équilibreurs de charge d'application externes.
• La requête présente un corps bien que la méthode de la requête l'interdise.
• La requête contient un en-tête Upgrade et cet en-tête Upgrade n'est pas utilisé pour activer les connexions WebSocket.
• La version de HTTP est inconnue.

Gestion des réponses

L'équilibreur de charge bloque la réponse du backend si l'une des conditions suivantes est remplie :

• La taille totale des en-têtes de réponse dépasse la taille d'en-tête de réponse maximale autorisée pour les équilibreurs de charge d'application externes.
• La version de HTTP est inconnue.

Lors du traitement de la requête et de la réponse, l'équilibreur de charge peut supprimer ou remplacer les en-têtes hop-by-hop dans HTTP/1.1 avant de les transférer vers la destination prévue.

Distribution du trafic

Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage, qui définit une méthode mesurant la charge du backend et une capacité cible. Les équilibreurs de charge d'application externes sont compatibles avec deux modes d'équilibrage :

• RATE, pour les groupes d'instances ou les NEG, est le nombre cible maximal de requêtes par seconde (RPS). La valeur RPS cible maximale peut être dépassée si tous les backends ont une capacité égale ou supérieure.

• UTILIZATION est l'utilisation du backend des VM dans un groupe d'instances.

La manière dont le trafic est réparti entre les backends dépend du mode de l'équilibreur de charge.

Équilibreur de charge d'application externe régional

Pour les équilibreurs de charge d'application externes régionaux, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle de localité d'équilibrage de charge.

Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque groupe (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.

Lorsqu'un service de backend reçoit du trafic, il dirige tout d'abord le trafic vers un backend (groupe d'instances ou NEG) en fonction du mode d'équilibrage du backend. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.

Pour en savoir plus, consultez les ressources suivantes :

• Modes d'équilibrage
• Règle d'équilibrage de charge de la localité (documentation de l'API sur le service de backend régional)

Affinité de session

L'affinité de session, configurée sur le service de backend des équilibreurs de charge d'application, tente au mieux d'envoyer les requêtes d'un client donné au même backend, à condition que le nombre d'instances ou de points de terminaison de backend opérationnels reste constant et que l'instance ou le point de terminaison de backend sélectionné précédemment ne soit pas saturé. La capacité cible du mode d'équilibrage détermine à quel moment le backend est saturé.

Le tableau suivant présente les différents types d'options d'affinité de session compatibles avec les différents équilibreurs de charge d'application. Dans la section Types d'affinité de session ci-dessous, chaque type d'affinité de session est décrit plus en détail.

Tableau : Paramètres d'affinité de session compatibles

Produit

Options d'affinité de session

Équilibreur de charge d'application externe régional

Aucune (NONE) Adresse IP client (CLIENT_IP) Cookie généré (GENERATED_COOKIE) Champ d'en-tête (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Affinité avec état basée sur les cookies (STRONG_COOKIE_AFFINITY) Sachez également que : La valeur effective par défaut de la règle d'équilibrage de charge de localité (localityLbPolicy) change en fonction de vos paramètres d'affinité de session. Si l'affinité de session n'est pas configurée (c'est-à-dire, si l'affinité de session reste à la valeur par défaut NONE), la valeur par défaut de localityLbPolicy est ROUND_ROBIN. Si l'affinité de session est définie sur une valeur autre que NONE, la valeur par défaut de localityLbPolicy est MAGLEV.

Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :

• Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session, à l'exception de l'affinité de session avec état basée sur les cookies, peut se rompre chaque fois que le nombre de backends actifs et opérationnels change. Pour en savoir plus, consultez la section Perte d'affinité de session.

• Les valeurs par défaut des options --session-affinity et --subsetting-policy sont NONE, et une seule d'entre elles peut être définie sur une valeur différente.

Types d'affinité de session

L'affinité de session pour les équilibreurs de charge d'application externes peut être classée dans l'une des catégories suivantes :

• Affinité de session basée sur le hachage (NONE, CLIENT_IP)
• Affinité de session basée sur l'en-tête HTTP (HEADER_FIELD)
• Affinité de session basée sur les cookies (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Affinité de session basée sur le hachage

Pour l'affinité de session basée sur le hachage, l'équilibreur de charge utilise l'algorithme de hachage cohérent pour sélectionner un backend éligible. Le paramètre d'affinité de session détermine les champs de l'en-tête IP utilisés pour calculer le hachage.

L'affinité de session basée sur le hachage peut être de l'un des types suivants :

• None
• Affinité basée sur les adresses IP client

Aucun

Un paramètre d'affinité de session de NONE ne signifie pas qu'il n'y a pas d'affinité de session. Cela signifie qu'aucune option d'affinité de session n'est explicitement configurée.

Le hachage est toujours effectué pour sélectionner un backend. Un paramètre d'affinité de session NONE signifie que l'équilibreur de charge utilise un hachage à cinq tuples pour sélectionner un backend. Le hachage à cinq tuples est constitué de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

La valeur par défaut de l'affinité de session est NONE.

Affinité basée sur les adresses IP client

L'affinité de session Adresse IP client (CLIENT_IP) est un hachage à deux tuples créé à partir des adresses IP source et de destination du paquet. L'affinité basée sur les adresses IP client permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.

Lorsque vous utilisez l'affinité basée sur les adresses IP client, gardez à l'esprit les points suivants :

• L'adresse IP de destination du paquet n'est identique à celle de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
• L'adresse IP source du paquet peut ne pas correspondre à une adresse IP associée au client d'origine si le paquet est traité par un système NAT ou proxy intermédiaire avant d'être distribué à un équilibreur de charge Trusted Cloud . Dans les situations où de nombreux clients partagent la même adresse IP source effective, certaines VM de backend peuvent recevoir plus de connexions ou de requêtes que d'autres.

Affinité de session basée sur l'en-tête HTTP

Avec l'affinité basée sur le champ d'en-tête (HEADER_FIELD), les requêtes sont acheminées vers les backends en fonction de la valeur de l'en-tête HTTP dans le champ consistentHash.httpHeaderName du service de backend. Pour distribuer les requêtes sur tous les backends disponibles, chaque client doit utiliser une valeur d'en-tête HTTP différente.

L'affinité du champ d'en-tête est prise en charge lorsque les conditions suivantes sont remplies :

• La règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV.
• La valeur consistentHash du service de backend spécifie le nom de l'en-tête HTTP (httpHeaderName).

Affinité de session basée sur les cookies

L'affinité de session basée sur les cookies peut être de l'un des types suivants :

• Affinité basée sur les cookies générés
• Affinité basée sur les cookies HTTP
• Affinité de session avec état basée sur les cookies

Affinité basée sur les cookies générés

Lorsque vous utilisez l'affinité basée sur les cookies générés (GENERATED_COOKIE), l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale.

Le nom du cookie généré varie en fonction du type d'équilibreur de charge.

Produit	Nom du cookie
Équilibreurs de charge d'application externes globaux	GCLB
Équilibreurs de charge d'application classiques	GCLB
Équilibreurs de charge d'application externes régionaux	GCILB

L'attribut de chemin d'accès du cookie généré est toujours une barre oblique (/). Il s'applique donc à tous les services de backend du même mappage d'URL, à condition que les autres services de backend utilisent également l'affinité basée sur les cookies générés.

Vous pouvez configurer la valeur TTL (Time To Live) du cookie entre 0 et 1,209,600 secondes (incluses) à l'aide du paramètre de service backend affinityCookieTtlSec. Si affinityCookieTtlSec n'est pas spécifié, la valeur TTL par défaut est 0.

Lorsque le client inclut le cookie d'affinité de session généré dans l'en-tête de requête Cookie des requêtes HTTP, l'équilibreur de charge dirige ces requêtes vers la même instance ou le même point de terminaison backend, tant que le cookie d'affinité de session reste valide. Pour ce faire, la valeur du cookie est mappée sur un index qui fait référence à une instance de backend ou à un point de terminaison spécifique, et les exigences d'affinité de session du cookie généré sont respectées.

Pour utiliser l'affinité basée sur les cookies générés, configurez les paramètres suivants pour le mode d'équilibrage et localityLbPolicy :

• Pour les groupes d'instances de backend, utilisez le mode d'équilibrage RATE.
• Pour le localityLbPolicy du service de backend, utilisez RING_HASH ou MAGLEV. Si vous ne définissez pas explicitement localityLbPolicy, l'équilibreur de charge utilise MAGLEV comme valeur par défaut implicite.

Pour en savoir plus, consultez Perte d'affinité de session.

Affinité basée sur les cookies HTTP

Lorsque vous utilisez l'affinité basée sur les cookies HTTP (HTTP_COOKIE), l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale. Vous spécifiez le nom, le chemin d'accès et la valeur TTL (Time To Live) du cookie.

Tous les équilibreurs de charge d'application sont compatibles avec l'affinité basée sur les cookies HTTP.

Vous pouvez configurer les valeurs TTL du cookie en utilisant des secondes, des fractions de seconde (en nanosecondes) ou les deux (secondes et fractions de seconde en nanosecondes) à l'aide des paramètres et des valeurs valides du service de backend suivants :

• consistentHash.httpCookie.ttl.seconds peut être défini sur une valeur comprise entre 0 et 315576000000 (inclus).
• consistentHash.httpCookie.ttl.nanos peut être défini sur une valeur comprise entre 0 et 999999999 (inclus). Comme les unités sont exprimées en nanosecondes, 999999999 signifie .999999999 secondes.

Si consistentHash.httpCookie.ttl.seconds et consistentHash.httpCookie.ttl.nanos ne sont pas spécifiés, la valeur du paramètre de service de backend affinityCookieTtlSec est utilisée à la place. Si affinityCookieTtlSec n'est pas spécifié, la valeur TTL par défaut est 0.

Lorsque le client inclut le cookie d'affinité de session HTTP dans l'en-tête de requête Cookie des requêtes HTTP, l'équilibreur de charge dirige ces requêtes vers la même instance ou le même point de terminaison de backend, tant que le cookie d'affinité de session reste valide. Pour ce faire, la valeur du cookie est mappée sur un index qui fait référence à une instance de backend ou à un point de terminaison spécifique, et les exigences d'affinité de session du cookie généré sont respectées.

Pour utiliser l'affinité basée sur les cookies HTTP, configurez les paramètres suivants pour le mode d'équilibrage et localityLbPolicy :

• Pour les groupes d'instances de backend, utilisez le mode d'équilibrage RATE.
• Pour le localityLbPolicy du service de backend, utilisez RING_HASH ou MAGLEV. Si vous ne définissez pas explicitement localityLbPolicy, l'équilibreur de charge utilise MAGLEV comme valeur par défaut implicite.

Pour en savoir plus, consultez Perte d'affinité de session.

Affinité de session avec état basée sur les cookies

Lorsque vous utilisez l'affinité basée sur les cookies avec état (STRONG_COOKIE_AFFINITY), l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale. Vous devez spécifier le nom, le chemin d'accès et la valeur TTL (Time To Live) du cookie.

Les équilibreurs de charge suivants sont compatibles avec l'affinité avec état basée sur les cookies :

• Équilibreurs de charge d'application externes régionaux
• Équilibreurs de charge d'application internes régionaux

Vous pouvez configurer les valeurs TTL du cookie en utilisant des secondes, des fractions de seconde (en nanosecondes) ou les deux (secondes et fractions de seconde en nanosecondes). La durée représentée par strongSessionAffinityCookie.ttl ne peut pas être définie sur une valeur représentant plus de deux semaines (1 209 600 secondes).

La valeur du cookie identifie une instance ou un point de terminaison de backend sélectionné en encodant l'instance ou le point de terminaison sélectionné dans la valeur elle-même. Tant que le cookie est valide, si le client inclut le cookie d'affinité de session dans l'en-tête de requête Cookie des requêtes HTTP ultérieures, l'équilibreur de charge dirige ces requêtes vers l'instance ou le point de terminaison de backend sélectionnés.

Contrairement aux autres méthodes d'affinité de session :

• L'affinité avec état basée sur les cookies ne présente aucune exigence spécifique concernant le mode d'équilibrage ni la règle de localité d'équilibrage de charge (localityLbPolicy).

• L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoscaling ajoute une instance à un groupe d'instances géré.

• L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoscaling supprime une instance d'un groupe d'instances géré, sauf si l'instance sélectionnée est supprimée.

• L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoréparation supprime une instance d'un groupe d'instances géré, sauf si l'instance sélectionnée est supprimée.

Pour en savoir plus, consultez Perte d'affinité de session.

Signification d'une valeur TTL nulle pour les affinités basées sur les cookies

Toutes les affinités de session basées sur les cookies, telles que l'affinité basée sur les cookies générés, l'affinité basée sur les cookies HTTP et l'affinité basée sur les cookies avec état, ont un attribut TTL.

Une TTL de zéro seconde signifie que l'équilibreur de charge n'attribue pas d'attribut Expires au cookie. Dans ce cas, le client traite le cookie comme un cookie de session. La définition d'une session varie en fonction du client :

• Certains clients, comme les navigateurs Web, conservent le cookie pendant toute la session de navigation. Cela signifie que le cookie persiste pour plusieurs requêtes jusqu'à ce que l'application soit fermée.

• D'autres clients traitent une session comme une seule requête HTTP et suppriment le cookie immédiatement après.

Perdre l'affinité de session

Toutes les options d'affinité de session nécessitent les éléments suivants :

• L'instance ou le point de terminaison de backend sélectionnés doivent rester configurés en tant que backend. L'affinité de session peut être rompue lorsque l'un des événements suivants se produit :
  • Vous supprimez l'instance sélectionnée de son groupe d'instances.
  • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime l'instance sélectionnée de son groupe d'instances géré.
  • Vous supprimez le point de terminaison sélectionné de son NEG.
  • Vous supprimez du service de backend le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionnés.
• L'instance ou le point de terminaison de backend sélectionnés doivent rester opérationnels. L'affinité de session peut cesser lorsque l'instance ou le point de terminaison sélectionnés échouent aux vérifications de l'état.
• Pour les équilibreurs de charge d'application externes globaux et les équilibreurs de charge d'application classiques, l'affinité de session peut être rompue si un autre Google Front End (GFE) de première couche est utilisé pour les requêtes ou connexions ultérieures après la modification du chemin de routage. Un autre GFE de première couche peut être sélectionné si le chemin de routage d'un client sur Internet vers Google change entre les requêtes ou les connexions.

À l'exception de l'affinité de session avec état basée sur les cookies, toutes les options d'affinité de session sont soumises aux exigences supplémentaires suivantes :

• Le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné ne doit pas être complet, comme défini par sa capacité cible. (Pour les groupes d'instances gérés régionaux, le composant zonal du groupe d'instances contenant l'instance sélectionnée ne doit pas être complet.) L'affinité de session peut être interrompue lorsque le groupe d'instances ou le NEG est plein et que d'autres groupes d'instances ou NEG ne le sont pas. Étant donné que la capacité peut changer de manière imprévisible lorsque vous utilisez le mode d'équilibrage UTILIZATION, vous devez utiliser le mode d'équilibrage RATE ou CONNECTION pour minimiser les situations où l'affinité de session peut être rompue.

• Le nombre total d'instances ou de points de terminaison de backend configurés doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend configurés change, et l'affinité de session peut être interrompue :

  • Ajouter des instances ou des points de terminaison :

    • Vous ajoutez des instances à un groupe d'instances existant sur le service de backend.
    • L'autoscaling de groupe d'instances géré ajoute des instances à un groupe d'instances géré sur le service de backend.
    • Vous ajoutez des points de terminaison à un NEG existant sur le service de backend.
    • Vous ajoutez des groupes d'instances ou des NEG non vides au service de backend.

  • Supprimer une instance ou un point de terminaison, et pas seulement l'instance ou le point de terminaison sélectionné :

    • Vous supprimez une instance d'un backend de groupe d'instances.
    • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime toute instance d'un backend de groupe d'instances géré.
    • Vous supprimez un point de terminaison d'un backend NEG.
    • Supprimez tout groupe d'instances ou NEG backend existant et non vide du service de backend.

• Le nombre total d'instances ou de points de terminaison de backend opérationnels doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend opérationnels change, et l'affinité de session peut être rompue :

  • Une instance ou un point de terminaison réussit sa vérification de l'état l'état et passe de l'état "Non opérationnel" à l'état "Opérationnel".
  • Une instance ou un point de terminaison échoue à sa vérification de l'état'état et passe de l'état "opérationnel" à l'état "non opérationnel" ou "délai avant expiration".