Comprendre les services de backend

Un service de backend est une ressource dont les champs contiennent des valeurs de configuration pour les services d'équilibrage de charge Google Cloud suivants :

Équilibrage de charge HTTP(S) externe
Équilibrage de charge HTTP(S) interne
Équilibrage de charge proxy SSL
Équilibrage de charge proxy TCP
Équilibrage de charge TCP/UDP interne

L'équilibrage de charge réseau n'utilise pas de service de backend.

Les équilibreurs de charge utilisent les informations de configuration de la ressource du service de backend pour les opérations suivantes :

Diriger le trafic vers les bons backends, qui sont des groupes d'instances ou des groupes de points de terminaison du réseau
Répartir le trafic selon un mode d'équilibrage défini dans le service de backend pour chaque backend
Surveiller l'état du backend à l'aide de la vérification de l'état désignée dans le service de backend
Conserver l'affinité de session

Architecture

Le nombre de services de backend par équilibreur de charge dépend du type d'équilibreur de charge :

Type d'équilibreur de charge	Nombre de services de backend
Équilibrage de charge HTTP(S) externe	Plusieurs
Équilibrage de charge HTTP(S) interne	Plusieurs
Équilibrage de charge proxy SSL	1
Équilibrage de charge proxy TCP	1
Équilibrage de charge TCP/UDP interne	1

Chaque service de backend contient un ou plusieurs backends.

Pour un service de backend donné, tous les backends doivent être soit des groupes d'instances, soit des groupes de points de terminaison du réseau. Vous pouvez associer un même service de backend à différents types de groupes d'instances (par exemple, des groupes d'instances gérés et non gérés), mais pas à la fois à des groupes d'instances et à des groupes de points de terminaison du réseau.

Paramètres du service de backend

Chaque service de backend dispose des paramètres configurables suivants :

Affinité de session (facultatif). Généralement, les équilibreurs de charge distribuent les requêtes entre les instances disponibles à l'aide d'un algorithme de hachage. En utilisation normale, le hachage repose sur l'adresse IP source, l'adresse IP de destination, le port source, le port de destination et le protocole (on parle de hachage à cinq tuples). L'affinité de session ajuste les éléments inclus dans le hachage et tente d'envoyer toutes les requêtes d'un même client à la même instance de machine virtuelle.
Délai avant expiration du service de backend. Cette valeur est interprétée de différentes manières selon le type d'équilibreur de charge et le protocole utilisés :
- Pour un équilibreur de charge HTTP(S), il s'agit du délai avant expiration d'une requête/réponse, sauf pour les connexions mises à niveau pour utiliser le protocole WebSocket.
- Lorsque vous envoyez le trafic WebSocket à un équilibreur de charge HTTP(S), le délai avant expiration du service de backend est interprété comme la durée maximale pendant laquelle un WebSocket peut rester ouvert, qu'il soit actif ou inactif.
- Pour un équilibreur de charge proxy TCP ou proxy SSL, le délai avant expiration du service de backend est interprété comme un délai d'inactivité pour l'ensemble du trafic.
- Pour un équilibreur de charge TCP/UDP interne, le paramètre de délai avant expiration du service de backend est ignoré.
Vérification de l'état. Le vérificateur d'état interroge les instances associées au service de backend à des intervalles configurés. Les instances qui réussissent la vérification d'état peuvent recevoir de nouvelles requêtes. Les instances non opérationnelles n'en reçoivent pas tant qu'elles ne sont pas redevenues conformes.

Consultez la ressource d'API des services de backend ou le guide de l'utilisateur de l'outil de ligne de commande gcloud pour obtenir la description des propriétés disponibles dans les services de backend.

Backends

Vous pouvez ajouter plusieurs backends à un seul service de backend. Chaque backend est une ressource vers laquelle un équilibreur de charge Google Cloud répartit le trafic. Trois types de ressources différents peuvent être utilisés comme backends :

Un groupe d'instances contenant des instances de machines virtuelles. Il peut s'agir d'un groupe d'instances géré avec ou sans autoscaling ou d'un groupe d'instances non géré. Vous devez ajouter un backend et lui attribuer un groupe d'instances. Créez le groupe d'instances avant de l'ajouter au backend.
Un groupe de points de terminaison du réseau (NEG, Network Endpoint Group) contenant des points de terminaison du réseau.
Un bucket backend.

Pour un service de backend donné, les backends doivent tous être des groupes d'instances ou, si cela est possible, des NEG ou des buckets backend. Vous ne pouvez pas utiliser différents types de backends avec le même service de backend. De plus :

Les backends des équilibreurs de charge TCP/UDP internes n'acceptent que les backends de type "groupe d'instances".
Si un équilibreur de charge HTTP(S) possède deux services de backend (ou plus), vous pouvez utiliser des groupes d'instances comme backends pour un service de backend et des NEG comme backends pour l'autre service de backend.

Backends et adresses IP externes

Les VM de backend n'ont pas besoin d'adresses IP externes :

Pour les équilibreurs de charge HTTP(S), proxy SSL et proxy TCP : les clients communiquent avec un Google Front End (GFE) au moyen de l'adresse IP externe de votre équilibreur de charge. Le GFE communique avec les VM de backend en utilisant les adresses IP internes de leur interface réseau principale. Étant donné que le GFE est un proxy, les VM de backend proprement dites n'ont pas besoin d'adresses IP externes.
Pour les équilibreurs de charge réseau : ceux-ci acheminent les paquets à l'aide de la traduction d'adresses réseau (NAT, Network Address Translation) bidirectionnelle. Lorsque les VM de backend envoient des réponses aux clients, elles utilisent l'adresse IP externe de la règle de transfert de l'équilibreur de charge comme adresse IP source.
Pour les équilibreurs de charge internes : les VM de backend pour un équilibreur de charge interne n'ont pas besoin d'adresses IP externes.

Distribution du trafic

Les valeurs des champs suivants dans la ressource de services de backend déterminent certains aspects du comportement du backend :

Un mode d'équilibrage qui indique au système d'équilibrage de charge comment déterminer quand le backend est pleinement utilisé. Si tous les backends du service de backend d'une région sont pleinement utilisés, les nouvelles requêtes sont automatiquement acheminées vers la région la plus proche pouvant encore traiter des requêtes. Le mode d'équilibrage peut reposer sur les connexions, l'utilisation du backend ou les requêtes par seconde (taux).
Un paramètre de capacité. La capacité est un contrôle supplémentaire qui interagit avec le paramètre de mode d'équilibrage. Par exemple, si vous souhaitez normalement que vos instances s'exécutent avec une utilisation maximale du backend de 80 %, vous devez définir le mode d'équilibrage sur l'utilisation du backend et la capacité sur 80 %. Si vous souhaitez diviser de moitié l'utilisation de l'instance, vous pouvez laisser la capacité à 80 % de l'utilisation du backend et définir le scaler de capacité sur 0,5. Pour drainer le service de backend, définissez le scaler de capacité sur 0 et laissez la capacité telle quelle.Pour en savoir plus sur la capacité et l'utilisation du backend, consultez la page Effectuer un scaling basé sur l'utilisation du processeur ou la capacité de diffusion de l'équilibrage de charge.

Veuillez noter les points suivants :

Si l'utilisation moyenne de toutes les instances dans les groupes d'instances backend associés au même service de backend est inférieure à 10 %, GCP pourra préférer des zones spécifiques. Cela peut se produire lorsque vous utilisez des groupes d'instances régionaux gérés, des groupes d'instances zonaux gérés et des groupes d'instances zonaux non gérés. Ce déséquilibre zonal disparaît automatiquement à mesure que du trafic est envoyé à l'équilibreur de charge. Les services de backend des autres régions n'ont pas d'incidence sur ce comportement.

Traffic Director utilise également les ressources de services de backend. Plus précisément, Traffic Director utilise des services de backend dont le schéma d'équilibrage de charge est INTERNAL_SELF_MANAGED. Pour un service de backend interne autogéré, la distribution du trafic est réalisée à l'aide de la combinaison d'un mode d'équilibrage de charge et d'une règle d'équilibrage de charge. Le service de backend dirige 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é, Traffic Director distribue le trafic selon une règle d'équilibrage de charge.

Les services de backend internes autogérés sont compatibles avec les modes d'équilibrage suivants :

UTILIZATION, si tous les backends sont des groupes d'instances ;
RATE, si tous les backends sont des groupes d'instances ou des NEG.

Si vous choisissez le mode d'équilibrage RATE, vous devez spécifier un taux maximal par backend, instance ou point de terminaison.

Protocole de communication avec les backends

Lorsque vous créez un service de backend, vous devez spécifier le protocole utilisé pour la communication avec ses backends. Un service de backend ne peut se servir que d'un seul protocole. Vous ne pouvez pas spécifier de protocole secondaire en guise de protocole de remplacement.

Les protocoles disponibles sont les suivants :

HTTP
HTTPS
HTTP/2
SSL
TCP
UDP

Le type d'équilibreur de charge que vous créez, y compris son schéma d'équilibrage de charge, détermine les protocoles valides. Reportez-vous à la documentation de chaque type d'équilibreur de charge afin d'obtenir plus d'informations sur les protocoles pouvant être utilisés pour ses services de backend.

Le protocole HTTP/2, utilisé pour communiquer avec les backends, est également disponible pour l'équilibrage de charge avec l'objet "Entrée".

La modification du protocole d'un service de backend rend les backends inaccessibles via les équilibreurs de charge pendant quelques minutes.

Groupes d'instances

Services de backend et groupes d'instances gérés avec autoscaling

Les groupes d'instances gérés avec autoscaling sont utiles si vous avez besoin de plusieurs machines, toutes configurées de la même façon, et si vous souhaitez ajouter ou supprimer automatiquement des instances en fonction des besoins.

Le pourcentage d'autoscaling fonctionne avec le mode d'équilibrage du service de backend. Par exemple, supposons que vous définissiez le mode d'équilibrage sur une utilisation du backend de 80 % en laissant le scaler de capacité sur 100 %, et que vous définissiez l'objectif d'utilisation de l'équilibrage de charge sur 80 % dans l'autoscaler. Lorsque l'utilisation du backend du groupe dépasse 64 % (soit 80 % de 80 %), l'autoscaler instancie de nouvelles instances à partir du modèle jusqu'à ce que l'utilisation descende à environ 64 %. Si l'utilisation globale passe en dessous de 64 %, l'autoscaler supprime les instances jusqu'à ce que l'utilisation revienne à 64 %.

Avant que les nouvelles instances ne soient considérées comme faisant partie du groupe, elles connaissent une période de transition. Le trafic peut alors dépasser les 80 % d'utilisation du backend du service de backend pendant cette période, ce qui entraîne l'acheminement du trafic excédentaire vers le prochain service de backend disponible. Une fois les instances disponibles, le nouveau trafic est acheminé vers elles. En outre, si le nombre d'instances atteint le maximum autorisé par les paramètres de l'autoscaler, celui-ci cesse d'ajouter des instances quel que soit le pourcentage d'utilisation.Dans ce cas, le trafic supplémentaire fait l'objet d'un équilibrage de charge vers la prochaine région disponible.

Configurer des groupes d'instances gérés avec autoscaling

Pour configurer des groupes d'instances gérés avec autoscaling, procédez comme suit :

Créez un modèle d'instance pour votre groupe d'instances.
Créez un groupe d'instances géré et attribuez-lui le modèle.
Activez l'autoscaling en fonction de la capacité de diffusion de l'équilibrage de charge.

Restrictions et conseils concernant les groupes d'instances

Étant donné que Cloud Load Balancing offre une grande flexibilité dans la manière de configurer l'équilibrage de charge, il est possible de créer des configurations qui fonctionnent mal. Gardez à l'esprit les restrictions et conseils suivants lorsque vous créez des groupes d'instances à utiliser avec l'équilibrage de charge.

N'associez pas une même instance de VM à plusieurs groupes d'instances.
Ne supprimez pas un groupe d'instances utilisé par un serveur de backend.
Pour simplifier votre configuration, évitez d'ajouter le même groupe d'instances à deux backends différents. Si vous souhaitez tout de même que deux backends partagent le même groupe, tenez compte des points suivants :
- Les deux backends doivent utiliser le même mode d'équilibrage, UTILIZATION ou RATE.
- Vous pouvez combiner les paramètres maxRatePerInstance et maxRatePerGroup. Il est possible de définir un backend de sorte qu'il utilise maxRatePerInstance et l'autre de sorte qu'il utilise maxRatePerGroup.
- Si votre groupe d'instances utilise deux ports ou plus pour chaque backend, vous devez spécifier des noms de ports différents dans le groupe d'instances.
Toutes les instances d'un groupe d'instances géré ou non géré doivent se trouver sur le même réseau VPC et, le cas échéant, sur le même sous-réseau.
Si vous utilisez un groupe d'instances géré avec autoscaling, n'utilisez pas le mode d'équilibrage maxRate dans le service de backend. Vous pouvez utiliser le mode maxUtilization ou le mode maxRatePerInstance.
Ne définissez pas un groupe d'instances géré avec autoscaling comme cible de deux équilibreurs de charge différents.
Lors du redimensionnement d'un groupe d'instances géré, la taille maximale du groupe doit être inférieure ou égale à la taille du sous-réseau.

Groupes de points de terminaison du réseau

Un point de terminaison du réseau est la combinaison d'une adresse IP et d'un port, spécifiée de l'une des deux façons suivantes :

En spécifiant une paire IP address:port, telle que 10.0.1.1:80.
En spécifiant seulement une adresse IP de point de terminaison du réseau. Le port par défaut du NEG est automatiquement utilisé comme port de la paire IP address:port.

Les points de terminaison du réseau représentent les services en fonction de leur adresse IP et de leur port, plutôt que de se référer à une VM spécifique. Un groupe de points de terminaison du réseau (NEG) est un regroupement logique de points de terminaison du réseau.

Un service de backend dont les backends sont des groupes de points de terminaison du réseau distribue le trafic entre les applications ou les conteneurs exécutés au sein des instances de VM. Pour en savoir plus, consultez la page Concepts relatifs aux groupes de points de terminaison du réseau dans le cadre de l'équilibrage de charge.

Affinité de session

Sans l'affinité de session, les équilibreurs de charge distribuent les nouvelles requêtes en fonction du mode d'équilibrage du NEG ou du groupe d'instances backend. Certaines applications, telles que les serveurs avec état utilisés pour la diffusion d'annonces, les jeux ou les services avec une mise en cache interne importante, nécessitent que plusieurs requêtes d'un même utilisateur soient dirigées vers la même instance.

L'affinité de session permet d'identifier le trafic TCP provenant d'un même client en fonction de paramètres tels que l'adresse IP du client ou la valeur d'un cookie, en dirigeant ces requêtes vers la même instance backend si le backend est opérationnel et a de la capacité disponible (selon son mode d'équilibrage).

L'affinité de session n'a pas beaucoup d'effet sur le trafic UDP, car une session pour UDP consiste en une seule requête et une seule réponse.

L'affinité de session peut cesser si l'instance devient non opérationnelle ou surchargée. Vous ne devez donc pas supposer que l'affinité sera parfaite.

Pour l'équilibrage de charge HTTP(S), l'affinité de session fonctionne mieux avec le mode d'équilibrage RATE.

Les différents équilibreurs de charge acceptent diverses options d'affinité de session, comme résumé dans le tableau suivant :

Équilibreur de charge	Options d'affinité de session
• Interne	• Aucune • IP client • Protocole et IP client • Port, protocole et IP client
• Proxy TCP • Proxy SSL	• Aucune • IP client
• HTTP(S)	• Aucune • IP client • Cookie généré
• Réseau	L'équilibrage de charge au niveau du réseau n'utilise pas les services de backend. À la place, vous définissez l'affinité de session pour les équilibreurs de charge réseau via des pools cibles. Consultez le paramètre `sessionAffinity` dans Pools cibles.

Les sections suivantes décrivent deux types courants d'affinité de session.

Utiliser l'affinité basée sur les adresses IP client

L'affinité basée sur les adresses IP client dirige les requêtes provenant d'une adresse IP client donnée vers la même instance backend en fonction d'un hachage de cette adresse IP. Chaque équilibreur de charge Google Cloud faisant appel à des services de backend peut utiliser l'affinité basée sur les adresses IP client.

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

L'adresse IP client vue par l'équilibreur de charge peut ne pas correspondre au client d'origine si elle est protégée par la fonctionnalité NAT ou envoie des requêtes via un proxy. Les requêtes effectuées via NAT ou un proxy utilisent l'adresse IP du routeur NAT ou du proxy comme adresse IP client. Cela peut entraîner un regroupement inutile du trafic entrant sur les mêmes instances backend.
Si un client passe d'un réseau à un autre, son adresse IP change, ce qui entraîne une rupture d'affinité.

Console

Pour définir l'affinité basée sur les adresses IP client :

Dans Google Cloud Console, accédez à la section Configuration du backend de la page "Équilibrage de charge".
Accéder à la page Équilibrage de charge
Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
Sélectionnez Configuration du backend.
Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
Dans la boîte de dialogue Modifier le service de backend, sélectionnez Client IP dans le menu déroulant Affinité de session.
Cette action active l'affinité de session basée sur les adresses IP client. Le champ Valeur TTL du cookie d'affinité est grisé, car il n'a aucun sens pour l'affinité basée sur les adresses IP client.
Cliquez sur le bouton Mettre à jour du service de backend.
Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud

Si vous souhaitez définir l'affinité de session pour un nouveau service de backend, vous pouvez exécuter la commande create. Pour un service de backend existant, exécutez la commande update. L'exemple suivant illustre l'utilisation de la commande update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip

API

Consultez la documentation de référence de l'API sur les services de backend.

Utiliser l'affinité basée sur les cookies générés

Lorsque vous définissez l'affinité basée sur les cookies générés, l'équilibreur de charge émet un cookie lors de la première requête. Pour chaque requête suivante présentant le même cookie, l'équilibreur de charge dirige celle-ci vers la même VM backend ou le même point de terminaison.

Pour les équilibreurs de charge HTTP(S) externes, ce cookie est nommé GCLB.
Pour les équilibreurs de charge HTTP(S) internes et Traffic Director, ce cookie est nommé GCILB.

L'affinité basée sur les cookies permet à un équilibreur de charge d'identifier un client plus précisément qu'avec l'affinité basée sur l'adresse IP du client. Exemple :

Grâce à l'affinité basée sur les cookies, l'équilibreur de charge peut identifier de manière unique deux systèmes clients (ou plus) partageant la même adresse IP source. Lorsqu'il utilise l'affinité basée sur l'adresse IP du client, l'équilibreur de charge traite toutes les connexions provenant de la même adresse IP source comme si elles provenaient du même système client.
Si un client change d'adresse IP, par exemple dans le cas d'un appareil mobile passant d'un réseau à un autre, l'affinité basée sur les cookies permet à l'équilibreur de charge de reconnaître les connexions ultérieures de ce client, plutôt que de traiter celles-ci comme si elles étaient nouvelles.

Lorsqu'un équilibreur de charge crée un cookie pour utiliser une affinité basée sur les cookies générés, il définit l'attribut path du cookie sur /. Si le mappage d'URL de l'équilibreur de charge comporte un outil de mise en correspondance des chemins d'accès qui spécifie plusieurs services de backend pour un nom d'hôte donné, tous les services de backend qui utilisent l'affinité de session basée sur les cookies partagent un même cookie de session.

La durée de vie du cookie HTTP généré par l'équilibreur de charge est configurable. Vous pouvez la définir sur 0 (par défaut), ce qui signifie que le cookie n'est qu'un cookie de session. Vous pouvez également la définir de sorte qu'elle soit comprise entre 1 et 86400 secondes (24 heures) inclus.

Console

Pour définir l'affinité basée sur les cookies générés :

Dans Google Cloud Console, vous pouvez modifier l'affinité basée sur les cookies générés dans la section Configuration du backend de la page de l'équilibreur de charge HTTP(S).
Accéder à la page Équilibrage de charge
Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
Sélectionnez Configuration du backend.
Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
Dans le menu déroulant Affinité de session, cliquez sur Generated cookie pour sélectionner l'affinité basée sur les cookies générés.
Dans le champ Valeur TTL du cookie d'affinité, définissez la durée de vie du cookie en secondes.
Cliquez sur le bouton Mettre à jour du service de backend.
Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud

Activez l'affinité basée sur les cookies générés en définissant --session-affinity sur generated_cookie et en définissant --affinity-cookie-ttl sur la durée de vie du cookie en secondes. Si vous souhaitez la définir pour un nouveau service de backend, vous pouvez exécuter la commande create. Pour un service de backend existant, exécutez la commande update. L'exemple suivant illustre l'utilisation de la commande update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400

API

Consultez la documentation de référence de l'API sur les services de backend.

Désactiver l'affinité de session

Vous pouvez désactiver l'affinité de session en mettant à jour le service de backend et en définissant l'affinité de session sur none, ou vous pouvez modifier le service de backend et définir l'affinité de session none dans un éditeur de texte. Vous pouvez également exécuter l'une ou l'autre des commandes mentionnées ci-dessous pour modifier la durée de vie des cookies.

Console

Pour désactiver l'affinité de session :

Dans Google Cloud Console, vous pouvez désactiver l'affinité de session dans la section Configuration du backend de la page "Équilibrage de charge".
Accéder à la page Équilibrage de charge
Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
Sélectionnez Configuration du backend.
Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
Dans le menu déroulant Affinité de session, sélectionnez None pour désactiver l'affinité de session.
Cliquez sur le bouton Mettre à jour du service de backend.
Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud

Pour désactiver l'affinité de session, exécutez la commande suivante :

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API

Consultez la documentation de référence de l'API sur les services de backend.

Perdre l'affinité de session

Quel que soit le type d'affinité choisi, un client peut perdre l'affinité avec l'instance dans les cas suivants :

Le groupe d'instances n'a plus de capacité disponible, et le trafic doit être acheminé vers une autre zone. Dans ce cas, le trafic provenant de sessions existantes peut être envoyé à la nouvelle zone, mettant ainsi fin à l'affinité. Pour éviter cela, assurez-vous que vos groupes d'instances disposent d'une capacité suffisante pour gérer tous les utilisateurs locaux.
L'autoscaling ajoute des instances au groupe d'instances ou en supprime. Dans les deux cas, le service de backend réalloue la charge, et la cible peut être déplacée. Pour y remédier, assurez-vous que le nombre minimal d'instances provisionnées par l'autoscaling est suffisant pour gérer la charge attendue, puis réservez l'autoscaling aux augmentations de charge inattendues.
L'instance cible échoue lors de la vérification de l'état. L'affinité est perdue, car la session est déplacée vers une instance opérationnelle.
Le mode d'équilibrage est défini sur l'utilisation du backend, ce qui peut entraîner le changement des capacités calculées dans les différentes zones, envoyant ainsi du trafic vers une autre zone de la région. Cette situation est plus probable de se produire en cas de trafic faible, lorsque la capacité calculée est moins stable.
Lorsque les backends se trouvent dans plusieurs régions cloud et que le routage client est conçu de sorte que la première requête et les suivantes envoyées lors d'une connexion sortent de différentes zones géographiques, vous risquez de perdre l'affinité de session. En effet, les requêtes supplémentaires peuvent être acheminées vers une autre région cloud déterminée par son nouvel emplacement de sortie.

Configurer le paramètre de délai avant expiration

Pour les connexions plus longues au service de backend à partir de l'équilibreur de charge, configurez un paramètre de délai avant expiration supérieur à la valeur par défaut (30 secondes).

Console

Pour configurer le paramètre de délai avant expiration :

Dans Google Cloud Console, vous pouvez modifier le paramètre de délai avant expiration dans la section Configuration du backend de la page de l'équilibreur de charge HTTP(S).
Accéder à la page Équilibrage de charge
Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
Sélectionnez Configuration du backend.
Sélectionnez l'icône Modifier (en forme de crayon) du service de backend.
Sur la ligne correspondant aux paramètres Protocole, Port et Délai avant expiration, sélectionnez l'icône Modifier (en forme de crayon).
Saisissez un nouveau paramètre de délai avant expiration, exprimé en secondes.
Cliquez sur le bouton Mettre à jour du service de backend.
Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud

Pour modifier le paramètre de délai avant expiration avec l'outil de ligne de commande gcloud, exécutez la commande "gcloud compute backend-services update". Ajoutez "--help" à la commande pour obtenir des informations détaillées.

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]

API

Consultez la documentation de référence de l'API REST sur les services de backend.

Ports nommés

Pour les équilibreurs de charge HTTP(S) internes, HTTP(S) externes, proxy SSL et proxy TCP, un port nommé doit être associé aux services de backend si leurs backends sont des groupes d'instances. Le port nommé informe l'équilibreur de charge qu'il doit utiliser ce port nommé configuré dans le groupe d'instances backend, qui le convertit en numéro de port. Il s'agit du port utilisé par l'équilibreur de charge pour se connecter aux VM de backend, et il peut être différent du port utilisé par les clients pour contacter l'équilibreur de charge proprement dit.

Les ports nommés sont des paires clé/valeur représentant un nom de service et un numéro de port sur lequel un service s'exécute. La paire clé/valeur est définie sur un groupe d'instances. Lorsqu'un service de backend utilise ce groupe d'instances comme backend, il peut "s'abonner" au port nommé :

Jusqu'à cinq ports nommés (paires clé/valeur) peuvent être définis pour chaque groupe d'instances.
Chaque service de backend d'un équilibreur de charge HTTP(S), proxy SSL ou proxy TCP utilisant des backends de type groupe d'instances ne peut "s'abonner" qu'à un seul port nommé.
Lorsque vous spécifiez un port nommé pour un service de backend, tous les groupes d'instances backend doivent avoir au moins un port nommé défini qui utilise le même nom.

Les ports nommés ne peuvent pas être utilisés dans les circonstances suivantes :

Pour les backends de type NEG : les NEG définissent les ports par point de terminaison, et aucune paire clé/valeur de port nommé n'est associée à un NEG.
Pour les équilibreurs de charge TCP/UDP internes : les équilibreurs de charge TCP/UDP internes étant des équilibreurs de charge directs (pas des proxys), leurs services de backend ne permettent pas de définir un port nommé.

Vérifications d'état

Une vérification de l'état doit être associée à chaque service de backend. Celle-ci doit exister avant la création du service de backend.

Une vérification de l'état s'exécute en permanence, et ses résultats permettent de déterminer quelles instances peuvent recevoir de nouvelles requêtes.

Les instances non opérationnelles ne reçoivent pas de nouvelles requêtes et continuent d'être interrogées. Si une instance non opérationnelle réussit une vérification de l'état, elle est considérée comme saine et commence à recevoir de nouvelles connexions.

Pour en savoir plus, consultez les documents suivants :

Afficher les résultats d'une vérification de l'état des services de backend

Après avoir créé les vérifications d'état et le service de backend, vous pouvez afficher les résultats d'une vérification de l'état.

Console

Pour afficher les résultats d'une vérification de l'état sur un service de backend :

Accédez à la page de résumé de l'équilibrage de charge.
Accéder à la page Équilibrage de charge
Cliquez sur le nom d'un équilibreur de charge.
Sous Backend, pour un service de backend, affichez la colonne Opérationnel dans la table Groupe d'instances.

gcloud

Pour afficher les résultats de la dernière vérification de l'état à l'aide de l'outil de ligne de commande gcloud, exécutez la commande backend-services get-health.

gcloud compute backend-services get-health [BACKEND_SERVICE]

La commande renvoie le paramètre healthState pour toutes les instances du service de backend spécifié, avec la valeur HEALTHY ou UNHEALTHY :

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth

API

Si vous souhaitez utiliser les commandes de l'API, consultez la page Vérifications d'état.

Fonctionnalités supplémentaires activées sur la ressource du service de backend

Les fonctionnalités facultatives suivantes de Google Cloud, qui sont activées à l'aide de la ressource du service de backend, ne sont pas traitées dans ce document :

Google Cloud Armor offre une protection contre les attaques DDoS et autres grâce à des règles de sécurité.
Cloud CDN est un système de diffusion de contenu à faible latence.
Les en-têtes de requêtes définis par l'utilisateur sont des en-têtes supplémentaires que l'équilibreur de charge ajoute aux requêtes.

Autres remarques

Les modifications apportées à vos services de backend ne sont pas appliquées de manière instantanée. Leur propagation sur le réseau peut prendre plusieurs minutes.

Les équilibreurs de charge Google Cloud ne sont pas compatibles avec les fonctionnalités Traffic Director suivantes :

Ruptures de circuit
Détection des anomalies
Règles d'équilibrage de charge
Affinité de session basée sur les cookies HTTP
Affinité de session basée sur l'en-tête HTTP

Étapes suivantes

Pour obtenir de la documentation et des informations sur l'utilisation des services de backend dans l'équilibrage de charge, consultez les ressources suivantes :

Créer des en-têtes de requête définis par l'utilisateur, pour en savoir plus sur les en-têtes de requête définis par l'utilisateur
Créer un équilibreur de charge HTTP(S)
Informations conceptuelles sur l'équilibrage de charge HTTP(S)
Activer le drainage de connexion