Comprendre les services 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 Platform suivants :

  • Équilibrage de charge HTTP(S)
  • Équilibrage de charge proxy SSL
  • Équilibrage de charge proxy TCP
  • Équilibrage de charge TCP/UDP interne
  • Équilibrage de charge HTTP(S) interne (bêta)

Un service de backend dirige le trafic vers des backends, qui sont des groupes d'instances ou des groupes de points de terminaison du réseau.

Le service de backend remplit diverses fonctions, par exemple :

  • Diriger le trafic en fonction d'un mode d'équilibrage, lequel est défini dans le service de backend pour chaque backend
  • Surveiller l'état des backends en fonction d'une vérification de l'état
  • Maintenir 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) Plusieurs
Équilibrage de charge SSL 1
Équilibrage de charge proxy TCP 1
Équilibrage de charge TCP/UDP interne 1
Équilibrage de charge HTTP(S) interne Plusieurs

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 à jour 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 API du service 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 si vous faites appel à des services de backend.

Backends

Chaque backend est une ressource vers laquelle un équilibreur de charge GCP distribue le trafic. Deux types différents de ressources peuvent être utilisés comme backends :

Pour un service de backend donné, les backends doivent tous être des groupes d'instances ou, si cela est possible, des NEG. Vous ne pouvez pas utiliser à la fois des groupes d'instances et des NEG comme backends sur 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 processeur 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 processeur de 80 %, vous devez définir le mode d'équilibrage sur l'utilisation du processeur 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 processeur 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 processeur, consultez la page Effectuer un scaling basé sur l'utilisation du processeur ou SUR la capacité de diffusion de l'équilibrage de charge.

Veuillez noter les points suivants :

  • Si l'utilisation moyenne du processeur de toutes les instances dans les groupes d'instances backend associés au même service de backend est inférieure à 10 %, GCP peut 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 auto-gé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 auto-gé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".

Services de backend et régions

L'équilibrage de charge HTTP(S) est un service mondial. Vous pouvez avoir plusieurs services de backend dans une région, et vous pouvez attribuer des services de backend à plusieurs régions, tous desservis par le même équilibreur de charge global. Le trafic est alloué aux services de backend de la manière suivante :

  1. Lorsqu'une requête utilisateur arrive, le service d'équilibrage de charge détermine son origine approximative à partir de l'adresse IP source.
  2. Le service d'équilibrage de charge connaît les emplacements des instances détenues par le service de backend, leur capacité globale et leur utilisation actuelle globale.
  3. Si les instances les plus proches de l'utilisateur ont de la capacité disponible, la requête est transmise à l'ensemble d'instances le plus proche.
  4. Les requêtes envoyées vers la région donnée sont distribuées de manière équitable entre l'ensemble des instances et des services de backend disponibles dans cette région. Toutefois, pour des charges très faibles, la distribution peut sembler non équitable.
  5. Si aucune instance opérationnelle d'une région donnée n'a de capacité disponible, l'équilibreur de charge envoie la requête à la région la plus proche avec de la capacité disponible.

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 processeur 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 processeur 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 80 % d'utilisation du processeur 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 quelle 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 :

  1. Créez un modèle d'instance pour votre groupe d'instances.
  2. Créez un groupe d'instances géré et attribuez-lui le modèle.
  3. 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 faire appel au mode maxUtilization ou 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 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 des groupes de points de terminaison du réseau dans 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
• IP client et protocole
• IP client, port et protocole
• 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 sur la page 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 GCP 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 :

  1. Dans la console Google Cloud Platform, accédez à la section Configuration du backend de la page de l'équilibreur de charge.
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
  5. Dans la boîte de dialogue Modifier le service backend, sélectionnez Client IP dans le menu déroulant Affinité de session.
    Cette action active l'affinité de session basée sur les adresse 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.
  6. Cliquez sur le bouton Mettre à jour du service de backend.
  7. 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.

Lorsque l'affinité basée sur les cookies générés est définie, l'équilibreur de charge émet un cookie nommé GCLB lors de la première requête, puis dirige chaque requête suivante ayant ce cookie vers la même instance. L'affinité basée sur les cookies permet à l'équilibreur de charge de faire la distinction entre différents clients utilisant la même adresse IP afin de les répartir plus équitablement entre les instances. Elle lui permet également de conserver l'affinité avec l'instance même lorsque l'adresse IP client change.

Le chemin du cookie est toujours /. Par conséquent, si deux services de backend sur le même nom d'hôte activent l'affinité basée sur les cookies, tous deux sont équilibrés par le même cookie.

La durée de vie du cookie HTTP généré par l'équilibreur de charge est configurable. Elle peut être définie sur 0 (par défaut), ce qui signifie que le cookie n'est qu'un cookie de session, ou elle peut être comprise entre 1 et 86400 secondes (24 heures).

Console


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

  1. Dans la console Google Cloud Platform, vous pouvez modifier l'affinité basée sur les cookies générés dans la section Configuration du backend sur la page de l'équilibreur de charge HTTP(S).
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
  5. Sélectionnez Generated cookie dans le menu déroulant Affinité de session pour sélectionner l'affinité basée sur les cookies générés.
  6. Dans le champ Valeur TTL du cookie d'affinité, définissez la durée de vie du cookie en secondes.
  7. Cliquez sur le bouton Mettre à jour du service de backend.
  8. 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 définir l'affinité basée sur les cookies générés pour un nouveau service de backend, exécutez 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

Pour désactiver l'affinité de session, mettez à jour le service de backend et définissez l'affinité de session sur none, ou modifiez le service de backend et définissez l'affinité de session sur 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 :

  1. Dans la console Google Cloud Platform, vous pouvez désactiver l'affinité de session dans la section Configuration du backend sur la page de l'équilibreur de charge.
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend.
  5. Sélectionnez None dans le menu déroulant Affinité de session pour désactiver l'affinité de session.
  6. Cliquez sur le bouton Mettre à jour du service de backend.
  7. 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


OU

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 processeur, 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. Cela 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 :

  1. Dans la console Google Cloud Platform, vous pouvez modifier le paramètre de délai avant expiration dans la section Configuration du backend sur la page de l'équilibreur de charge HTTP(S).
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sélectionnez l'icône Modifier (en forme de crayon) du service de backend.
  5. Sur la ligne correspondant aux paramètres Protocole, Port et Délai avant expiration, sélectionnez l'icône Modifier (en forme de crayon).
  6. Saisissez un nouveau paramètre de délai avant expiration, exprimé en secondes.
  7. Cliquez sur le bouton Mettre à jour du service de backend.
  8. 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 proxies), 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. Une vérification de l'état s'exécute en permanence, et ses résultats permettent de déterminer quelles instances doivent 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.

Bonnes pratiques concernant les vérifications d'état

Lors de la configuration d'une vérification de l'état, il est recommandé de vérifier l'état et de diffuser le trafic sur le même port. Toutefois, il est possible d'effectuer les vérifications d'état sur un port tout en diffusant le trafic sur un autre. Si vous utilisez deux ports différents, assurez-vous que les services et les règles de pare-feu exécutés sur les instances sont configurés de manière appropriée. Si vous effectuez les vérifications d'état et diffusez le trafic sur le même port, mais que vous décidez de changer de port à un certain moment, veillez à mettre à jour le service de backend et la vérification de l'état.

Les services de backend qui ne sont pas référencés par une règle de transfert valide ne feront pas l'objet d'une vérification d'état, et leur état ne sera pas indiqué.

Créer des vérifications d'état

Vous devez créer une vérification de l'état avant de créer un service de backend. Nous vous recommandons de la créer pour le même protocole que le trafic dont vous équilibrez la charge.

Console

Dans la console, vous pouvez créer une vérification de l'état lorsque vous créez votre service de backend.

gcloud

Si vous souhaitez créer une vérification de l'état à l'aide des commandes gcloud, consultez la page Vérification de l'état.

API

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

Créer un service de backend

Console


Pour créer un service de backend :

  1. Dans la console Google Cloud Platform, vous pouvez créer un service de backend dans la section Configuration du backend sur la page de l'équilibreur de charge HTTP(S).
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Dans le menu déroulant Créer ou sélectionner des services backend et des buckets backend, sélectionnez Services de backend -> Créer un service backend.
  5. Dans le champ Nom, saisissez le nom du service de backend.
  6. (Facultatif) Saisissez une description.
  7. Sélectionnez l'icône Modifier (en forme de crayon) sur la ligne correspondant aux paramètres Protocole, Port et Délai avant expiration.
    • Choisissez un protocole (http, https ou http2).
    • Saisissez un nom (port name) pour le port nommé.
    • (Facultatif) Modifiez le paramètre Délai avant expiration par défaut.
  8. Sous Type de backend, sélectionnez la case d'option Groupe Instances.
  9. Dans la boîte de dialogue Backends, vous pouvez créer un ou plusieurs backends.
    1. Dans la boîte de dialogue Nouveau backend, sélectionnez un groupe d'instances existant dans le menu déroulant.
    2. Saisissez un ou plusieurs numéros de port, séparés par des virgules, via lesquels le backend recevra les requêtes.
      • Pour le protocole http, ce champ est défini sur 80.
      • Pour le protocole https, ce champ est défini sur 443.
      • Pour le protocole http2, ce champ est défini sur 443.
    3. Définissez le pourcentage d'utilisation maximale du processeur.
    4. (Facultatif) Définissez le nombre maximal de RPS, en laissant le champ vide pour unlimited. Définissez RPS par instance ou RPS par groupe.
    5. Définissez le pourcentage de capacité.
    6. Cliquez sur le bouton Terminé.
  10. Cochez ou décochez la case Activer Cloud CDN.
  11. Dans le menu déroulant Vérification de l'état, sélectionnez une vérification d'état existante ou créez une autre vérification d'état de la manière suivante :
    1. Définissez le nom.
    2. (Facultatif) Définissez la description.
    3. Définissez le protocole et le port. Consultez la section Vérifications d'état pour connaître les bonnes pratiques.
    4. Définissez le protocole de proxy.
    5. (Facultatif) Définissez les valeurs des champs Requête et Réponse.
    6. Sous Critères de vérification d'état, définissez les éléments suivants :
      1. Définissez l'intervalle entre deux tests, en secondes.
      2. Définissez le délai avant expiration, en secondes.
      3. Définissez le nombre de succès consécutifs (number of consecutive successes) dans le champ Seuil sanitaire.
      4. Définissez le nombre d'échecs consécutifs (number of consecutive failures) dans le champ Seuil non sanitaire.
      5. Cliquez sur Enregistrer et continuer.
    7. Cliquez sur Configurations avancées pour modifier l'affinité de session, le délai avant expiration du drainage de connexion, les en-têtes de requêtes personnalisés ou les règles de sécurité.
      1. Pour définir l'affinité de session, sélectionnez IP client ou Cookie généré. Si vous avez sélectionné *Cookie généré, définissez la valeur TTL du cookie d'affinité (en secondes).
      2. Pour définir le délai avant expiration du drainage de connexion, saisissez le nombre de secondes pendant lequel l'instance attend que les connexions en cours de transfert soient terminées.
      3. Pour créer des en-têtes de requêtes personnalisés, cliquez sur +Ajouter un en-tête, puis ajoutez le nom et la valeur de l'en-tête.
      4. Pour activer une règle de sécurité, sélectionnez-en une dans le menu déroulant.
    8. Cliquez sur le bouton Mettre à jour du service de backend.
    9. Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud


Pour créer un service de backend à l'aide de l'outil de ligne de commande gcloud, consultez la documentation du SDK Cloud.

API


Si vous souhaitez créer un service de backend à l'aide des commandes de l'API, consultez la page Services de backend.

Modifier un service de backend

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.

Console


Pour modifier un service de backend existant :

  1. Dans la console Google Cloud Platform, vous pouvez modifier un service de backend dans la section Configuration du backend sur la page de l'équilibreur de charge HTTP(S).
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sous Services de backend, sélectionnez l'icône Modifier (en forme de crayon) d'un service de backend. Vous pouvez modifier les champs suivants :
    1. Sous Backends, ajoutez un nouveau backend ou sélectionnez l'icône Modifier (en forme de crayon) d'un backend existant.
    2. Sélectionnez l'icône Modifier (en forme de crayon) sur la ligne correspondant aux paramètres Protocole, Port et Délai avant expiration.
    3. Sélectionnez une vérification de l'état existante ou créez-en une en suivant les étapes précédentes de création d'une vérification d'état.
    4. Modifiez l'affinité de session et, si nécessaire, la valeur TTL du cookie d'affinité
    5. Cliquez sur Configurations avancées pour modifier le délai avant expiration du drainage de connexion.
    6. Cochez ou décochez la case Activer Cloud CDN.
  5. Cliquez sur Configurations avancées pour modifier l'affinité de session, le délai avant expiration du drainage de connexion, les en-têtes de requêtes personnalisés ou les règles de sécurité.
    1. Pour définir l'affinité de session, sélectionnez IP client ou Cookie généré. Si vous avez sélectionné *Cookie généré, définissez la valeur TTL du cookie d'affinité (en secondes).
    2. Pour définir le délai avant expiration du drainage de connexion, saisissez le nombre de secondes pendant lequel l'instance attend que les connexions en cours de transfert soient terminées.
    3. Pour créer des en-têtes de requêtes personnalisés, cliquez sur +Ajouter un en-tête, puis ajoutez le nom et la valeur de l'en-tête.
    4. Pour activer une règle de sécurité, sélectionnez-en une dans le menu déroulant.
    5. Cliquez sur le bouton Mettre à jour du service de backend.
    6. Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud


Pour modifier un service de backend à l'aide de l'outil de ligne de commande gcloud, consultez la documentation du SDK Cloud.

API


Pour modifier un service de backend avec l'API, consultez la documentation de l'API.

Ajouter des groupes d'instances à un service de backend

Pour définir les instances incluses dans un service de backend, vous devez ajouter un backend et lui attribuer un groupe d'instances. Vous devez créer le groupe d'instances avant de l'ajouter au backend.

Lorsque vous ajoutez le groupe d'instances au backend, vous devez également définir certains paramètres.

Console


Pour ajouter un groupe d'instances à un service de backend :

  1. Dans la console Google Cloud Platform, vous pouvez ajouter un groupe d'instances à un backend dans la section Configuration du backend sur la page de l'équilibreur de charge HTTP(S).
    Accéder à la page "Équilibrage de charge"
  2. Sélectionnez l'icône Modifier (en forme de crayon) de votre équilibreur de charge.
  3. Sélectionnez Configuration du backend.
  4. Sélectionnez l'icône Modifier (en forme de crayon) de la configuration du backend.
  5. Sélectionnez l'icône Modifier (en forme de crayon) d'un backend.
  6. Dans la boîte de dialogue Modifier le backend, dans le menu déroulant Groupe d'instances, sélectionnez un groupe d'instances (Instance group).
  7. Cliquez sur le bouton Terminé de la boîte de dialogue Modifier le backend.
  8. Cliquez sur le bouton Mettre à jour du service de backend.
  9. Cliquez sur le bouton Mettre à jour de l'équilibreur de charge.

gcloud


Pour ajouter un groupe d'instances à un service de backend à l'aide de l'outil de ligne de commande gcloud, consultez la documentation du SDK Cloud.

API


Pour ajouter un groupe d'instances à un service de backend avec l'API, consultez la documentation de l'API.

Ajouter des groupes de points de terminaison du réseau à un service de backend

Pour ajouter un groupe de points de terminaison du réseau à un service de backend, consultez la section Ajouter un groupe de points de terminaison du réseau à un service de backend.

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

Une fois que vous avez 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 :

  1. Accédez à la page de résumé de l'équilibrage de charge.
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur le nom d'un équilibreur de charge.
  3. 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 avec 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 affiche un 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.

Autres remarques

Les fonctionnalités suivantes de Traffic Director ne sont pas disponibles avec les équilibreurs de charge GCP :

  • 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

Étape suivante

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

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…