Présentation des services de backend

Un service de backend définit la manière dont Cloud Load Balancing répartit le trafic. La configuration du service de backend contient un ensemble de valeurs, telles que le protocole utilisé pour se connecter aux backends, divers paramètres de répartition et de gestion des sessions, les vérifications d'état et les délais avant expiration. Ces paramètres permettent de contrôler précisément le comportement de votre équilibreur de charge. La plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration si vous devez commencer rapidement.

Vous pouvez configurer un service de backend 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

Traffic Director utilise également les services de backend. 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 :

  • Pour diriger le trafic vers les bons backends, qui sont des groupes d'instances ou des groupes de points de terminaison réseau (NEG). Notez qu'un équilibreur de charge HTTP(S) externe peut être configuré pour utiliser un bucket de backend au lieu d'un service de backend. Pour plus d'informations sur l'utilisation de buckets de backend avec les équilibreurs de charge HTTP(S) externes, consultez la page Configurer un équilibreur de charge avec des buckets de backend.
  • Pour répartir le trafic selon un mode d'équilibrage à paramétrer pour chaque backend
  • Pour déterminer la vérification de l'état qui surveille l'état des backends
  • Pour spécifier l'affinité de session
  • Pour déterminer si Cloud CDN est activé (équilibreurs de charge HTTP(S) externes uniquement)
  • Pour déterminer si les règles de sécurité de Google Cloud Armor sont activées (équilibreurs de charge HTTP(S) externes uniquement)
  • Pour déterminer si Identity-Aware Proxy est activé (équilibreurs de charge HTTP(S) externes uniquement)

Vous définissez certaines valeurs lorsque vous créez un service de backend. Vous définissez d'autres valeurs lorsque vous ajoutez un backend à un service de backend.

Un service de backend a une portée mondiale ou régionale.

Pour plus d'informations sur les propriétés de la ressource de service de backend, consultez les documents de référence suivants :

Le nombre maximal de services de backend par équilibreur de charge, le niveau d'accès d'un service de backend, le type de backend que chaque service peut utiliser et le schéma d'équilibrage de charge d'un service de backend dépendent tous du type d'équilibreur de charge :

Type d'équilibreur de charge Nombre maximal de services de backend Niveau d'accès du service backend Types de backends compatibles Schéma d'équilibrage de charge
Équilibrage de charge HTTP(S) externe Plusieurs Mondial1 Chaque service de backend accepte les combinaisons de backend suivantes :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré, ou
  • Tous les NEG zonaux : un ou plusieurs NEG zonaux, ou
  • Un NEG Internet
 EXTERNAL
Équilibrage de charge HTTP(S) interne Plusieurs Disques Chaque service de backend accepte les combinaisons de backend suivantes :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré, ou
  • Tous les NEG zonaux : un ou plusieurs NEG zonaux
 INTERNAL_MANAGED
Équilibrage de charge proxy SSL 1 Mondial1 Le service de backend accepte les combinaisons de backend suivantes :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré, ou
  • Tous les NEG zonaux : un ou plusieurs NEG zonaux, ou
  • Un NEG Internet
 EXTERNAL
Équilibrage de charge proxy TCP 1 Mondial1 Le service de backend accepte les combinaisons de backend suivantes :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré, ou
  • Tous les NEG zonaux : un ou plusieurs NEG zonaux, ou
  • Un NEG Internet
 EXTERNAL
Équilibrage de charge TCP/UDP interne 1 Régional, mais peut être configuré pour être accessible à l'échelle mondiale Le service de backend accepte la combinaison de backend suivante :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré
 INTERNAL
Traffic Director Plusieurs Monde Chaque service de backend accepte les combinaisons de backend suivantes :
  • Tous les backends de groupe d'instances : un ou plusieurs backends de groupe d'instances géré ou non, ou une combinaison de backends de groupe d'instances géré et non géré, ou
  • Tous les NEG zonaux : un ou plusieurs NEG zonaux
 INTERNAL_SELF_MANAGED

1 Les services de backend utilisés par l'équilibrage de charge HTTP(S), l'équilibrage de charge proxy SSL et l'équilibrage de charge proxy TCP ont toujours une portée mondiale, aussi bien au niveau du réseau standard que premium. Cependant, les restrictions suivantes s'appliquent au niveau standard :

Backends

Un backend est une ressource à laquelle un équilibreur de charge Google Cloud distribue le trafic. Chaque service backend est associé à un ou plusieurs backends compatibles. Il existe trois types de backends :

  • Un groupe d'instances contenant des instances de machine virtuelle (VM). Un groupe d'instances peut être un groupe d'instances géré, avec ou sans autoscaling, ou il peut s'agir d'un groupe d'instances non géré. Il est possible qu'un groupe d'instances soit référencé par plusieurs services de backend, mais tous les services de backend qui référencent le groupe d'instances doivent utiliser le même mode d'équilibrage.
  • Un NEG zonal
  • Un NEG Internet

Vous ne pouvez pas utiliser différents types de backends avec le même service de backend. Par exemple, un seul service de backend ne peut pas référencer une combinaison de groupes d'instances et de NEG zonaux. Cependant, vous pouvez utiliser une combinaison de différents types de groupes d'instances sur le même service de backend. Par exemple, un seul service de backend peut référencer une combinaison de groupes d'instances gérés et non gérés. Pour obtenir des informations complètes et savoir quels backends sont compatibles quels services de backend, consultez le tableau de la section précédente.

Vous ne pouvez pas supprimer un groupe d'instances de backend ni un NEG associé à un service de backend. Avant de supprimer un groupe d'instances ou un NEG, vous devez d'abord le supprimer en tant que backend de tous les services de backend qui le référencent.

Protocole de communication avec les backends

Lorsque vous créez un service de backend, vous devez spécifier le protocole utilisé par l'équilibreur de charge pour la communication avec les backends. Vous ne pouvez spécifier qu'un seul protocole par service de backend et pas de protocole secondaire à utiliser comme solution de secours.

Les protocoles disponibles sont les suivants :

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

Les protocoles valides dépendent du type d'équilibreur de charge. Pour plus d'informations, consulter la page Fonctionnalités d'équilibrage de charge.

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

Chiffrement entre l'équilibreur de charge et les backends

Pour l'équilibrage de charge HTTP(S), l'équilibrage de charge proxy TCP et l'équilibrage de charge proxy SSL, Google chiffre automatiquement le trafic entre les serveurs GFE (Google Front End) et vos backends, au sein de Google Cloud. Pour les backends extérieurs à Google Cloud, tels que les points de terminaison au sein d'un groupe de points de terminaison du réseau Internet, le trafic n'est chiffré automatiquement qu'au sein du réseau Google.

  • En plus de ce chiffrement au niveau du réseau, vous pouvez choisir d'utiliser un protocole sécurisé, tel que SSL, HTTPS ou HTTP/2 (via TLS), comme protocole de service de backend.
  • Nous vous recommandons vivement d'utiliser le protocole HTTPS ou HTTP/2 pour la connexion à des backends extérieurs à Google Cloud, car la communication avec le backend peut transiter par l'Internet public.
  • Lorsque vous utilisez SSL, HTTPS ou HTTP/2 comme protocole de service de backend, vous devez installer des clés privées et des certificats, puis configurer le logiciel exécuté sur vos backends pour fonctionner comme un serveur SSL ou HTTPS.

Lorsqu'un GFE se connecte à vos backends via un protocole de service de backend sécurisé, il s'agit du client SSL ou HTTPS.

  • Dans le cadre de connexions aux backends au sein de Google Cloud, les GFE acceptent tous les certificats présenté par vos backends, qu'ils soient autosignés ou signés par une autorité de certification. Dans ce cas, les GFE n'effectuent pas de validation de certificat lors de la connexion à des backends via un protocole de service de backend sécurisé.
  • Dans le cadre de connexions à des backends situés sur l'Internet public via un NEG Internet, le certificat doit être signé par une autorité de certification publique et respecter les exigences de validation

Pour plus d'informations sur le chiffrement de Google, consultez la page Chiffrement en transit dans Google Cloud.

Groupes d'instances

Cette section explique comment les groupes d'instances fonctionnent avec le service de backend.

VM de back-end et adresses IP externes

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

  • Pour les équilibreurs de charge HTTP(S) externes, les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP : les clients communiquent avec un GFE à l'aide de l'adresse IP externe de votre équilibreur de charge. Le GFE communique avec les machines virtuelles ou les points de terminaison à l'aide des 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 HTTP(S) internes et les équilibreurs de charge TCP/UDP internes : les machines virtuelles de backend des équilibreurs de charge internes ne nécessitent pas d'adresses IP externes.

Ports nommés

Les groupes d'instances de backend connectés à l'un de ces types d'équilibreurs de charge doivent avoir un port nommé correspondant à celui auquel le service de backend de l'équilibreur de charge s'abonne :

  • Équilibrage de charge HTTP(S) interne
  • Équilibrage de charge HTTP(S)
  • Équilibrage de charge proxy SSL
  • Équilibrage de charge proxy TCP

Chaque groupe d'instances peut avoir plusieurs ports nommés. Un port nommé fait correspondre un nom de service à un numéro de port. Si le port nommé d'un groupe d'instances correspond à celui auquel les services de backend s'abonnent, il sert à définir le numéro de port que le service de backend utilise pour la communication avec les machines virtuelles membres du groupe.

Par exemple, vous pouvez définir le port nommé sur un groupe d'instances tel qu'indiqué dans l'exemple ci-dessous, où le nom du service est my-service-name et le port est 8888 :

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Vous devez ensuite définir le port nommé du service de backend sur my-service-name :

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Remarques :

  • Chaque service de backend s'abonne à un nom de port unique. Par conséquent, chacun de ses groupes d'instances de backend doit avoir au moins un port nommé pour ce nom.

  • Il est possible pour un service de backend d'utiliser un numéro de port différent lors de la communication avec des machines virtuelles appartenant à différents groupes d'instances si chacun de ces groupes spécifie un numéro de port unique pour le même nom de port.

  • Le numéro de port résolu qu'utilise le service de backend ne doit pas nécessairement correspondre au numéro de port utilisé par les règles de transfert de l'équilibreur de charge.

Les ports nommés ne sont pas utilisés dans les cas suivantes :

  • Pour les backends de NEG zonaux ou de NEG Internet, car les NEG définissent les ports en se basant sur un mécanisme différent, à savoir les points de terminaison -mêmes.
  • Pour les équilibreurs de charge TCP/UDP internes, car un équilibreur de charge TCP/UDP interne est un composant intermédiaire, pas un proxy. Son service de backend ne s'abonne donc pas à un port nommé.

Pour plus d'informations sur les ports nommés, consulter les pages sur les commandes gcloud compute instance-groups managed set-named-ports et gcloud compute instance-groups unmanaged set-named-ports dans la documentation du SDK.

Restrictions et conseils concernant les groupes d'instances

Gardez à l'esprit les restrictions et conseils suivants lorsque vous créez des groupes d'instances pour vos équilibreurs de charge :

  • N'associez pas une même instance de VM à plusieurs groupes d'instances à équilibrage de charge. Si une machine virtuelle appartient à deux groupes d'instances non gérés ou plus, ou à un groupe d'instances géré et un ou plusieurs groupes d'instances non gérés, Google Cloud vous oblige à n'utiliser qu'un seul de ces groupes d'instances à la fois comme backend d'un service particulier.

    Si vous avez besoin qu'une machine virtuelle participe à plusieurs équilibreurs de charge, vous devez utiliser le même groupe d'instances comme backend pour chacun des services de backend. Pour équilibrer le trafic vers différents ports, créez les ports nommés requis pour un groupe d'instances et demandez à chaque service de backend de s'abonner à un port nommé unique.

  • Il est possible d'utiliser le même groupe d'instances comme backend pour plusieurs services de backend. Dans cette situation, ces services de backend doivent tous utiliser le même mode d'équilibrage.

    Il s'agit d'une configuration complexe qui n'est pas toujours possible. Par exemple, un même groupe d'instances ne peut pas servir de backend à un service de backend pour un équilibreur de charge TCP/UDP interne et pour un équilibreur de charge HTTP(S) externe. Un équilibreur de charge TCP/UDP interne fait appel à des services de backend dont les backends doivent utiliser le mode d'équilibrage CONNECTION, tandis qu'un équilibreur de charge HTTP(S) externe utilise des services de backend dont les backends sont compatibles avec les modes RATE ou UTILIZATION. Étant donné qu'aucun mode d'équilibrage n'est commun aux deux, un même groupe d'instances ne peut pas servir de backend aux deux types d'équilibreur de charge.

    • Si votre groupe d'instances est associé à plusieurs services de backend, chacun de ces services peut référencer le même port nommé ou un port nommé différent sur le groupe d'instances.

  • Nous vous recommandons de ne pas ajouter de groupe d'instances géré avec autoscaling à plusieurs services de backend. Cela pourrait entraîner un scaling imprévisible et inutile pour les instances du groupe, en particulier si vous utilisez la métrique d'autoscaling Utilisation de l'équilibrage de charge HTTP.

    • Bien qu'il ne soit pas recommandé, ce scénario peut fonctionner si la métrique que vous utilisez pour l'autoscaling du groupe d'instances géré est l'utilisation du processeur ou une métrique Cloud Monitoring qui n'est pas liée à la capacité de diffusion de l'équilibreur de charge. En effet, l'une de ces métriques d'autoscaling peut éviter l'irrégularité d'un scaling basé sur la métrique d'utilisation de l'équilibrage de charge HTTP.

Groupes zonaux de points de terminaison du réseau

Un service de backend dont les backends sont des groupes de points de terminaison de réseau zonal (NEG) distribue le trafic entre les applications ou les conteneurs exécutés au sein des machines virtuelles.

Un point de terminaison de réseau zonal 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 référencer une VM spécifique. Un groupe de points de terminaison du réseau est un regroupement logique de points de terminaison du réseau.

Pour plus d'informations, consultez la page Présentation des groupes de points de terminaison de réseau dans l'équilibrage de charge.

Groupes de points de terminaison du réseau Internet

Les NEG Internet sont des ressources mondiales qui sont hébergées au sein d'une infrastructure sur site ou fournie par des tiers.

Un NEG Internet est la combinaison d'une adresse IP, ou d'un nom d'hôte, et d'un port facultatif :

  • Un nom de domaine complet pouvant être résolu publiquement et un port facultatif, par exemple backend.example.com:443 (ports par défaut : 80 pour HTTP et 443 pour HTTPS)
  • Une adresse IP publique et un port facultatif, par exemple 203.0.113.8:80 ou 203.0.113.8:443 (ports par défaut : 80 pour HTTP et 443 pour HTTPS)

Un service de backend d'un équilibreur de charge HTTP(S) externe dont le backend est un groupe de points de terminaison de réseau Internet distribue le trafic vers une destination en dehors de Google Cloud.

Pour plus d'informations, consultez la page Présentation du groupe de points de terminaison du réseau Internet.

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 permet à l'équilibreur de charge de déterminer les backends susceptibles de recevoir les requêtes ou connexions ultérieures.
  • Une capacité cible, qui définit le nombre maximal de connexions cible, un taux maximal cible ou une utilisation du processeur maximale cible.
  • Un scaler de capacité, qui permet d'ajuster la capacité globale disponible sans modifier la capacité cible.

Mode d'équilibrage

Le mode d'équilibrage détermine si les backends d'un équilibreur de charge sont en mesure de gérer du trafic supplémentaire ou s'ils fonctionnent à charge maximale. Google Cloud propose trois modes d'équilibrage :

  • CONNECTION
  • RATE
  • UTILIZATION

Les options du mode d'équilibrage dépendent du schéma d'équilibrage de charge et du protocole du service de backend, ainsi que du type des backends connectés au service de backend.

Vous définissez le mode d'équilibrage lorsque vous ajoutez un backend au service de backend.

Mode d'équilibrage Schémas d'équilibrage de charge compatibles Protocoles de service de backend compatibles Types de backends compatibles Produits applicables
CONNECTION EXTERNAL
INTERNAL		 Les options de protocole SSL, TCP, UDP
sont limitées par le type d'équilibreur de charge. Par exemple, l'équilibrage de charge TCP/UDP interne n'utilise que le protocole TCP ou UDP. 		Soit des groupes d'instances, soit des NEG zonaux, si compatibles.
Par exemple, l'équilibrage de charge TCP/UDP interne n'accepte pas les NEG zonaux.
  • Équilibrage de charge proxy SSL
  • Équilibrage de charge proxy TCP
  • Équilibrage de charge TCP/UDP interne
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED		 HTTP, HTTPS, HTTP2 Groupes d'instances ou NEG zonaux
  • Équilibrage de charge HTTP(S) externe
  • Équilibrage de charge HTTP(S) interne
  • Traffic Director
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED		 Tout protocole Groupes d'instances uniquement. Les NEG zonaux n'acceptent pas le mode d'utilisation.
  • Équilibrage de charge HTTP(S) externe
  • Équilibrage de charge HTTP(S) interne
  • Équilibrage de charge proxy SSL
  • Équilibrage de charge proxy TCP
  • Traffic Director

Si l'utilisation moyenne de toutes les machines virtuelles associées à un service de backend est inférieure à 10 %, Google Cloud 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 zonales gérés dans différentes zones et des groupes d'instances zonales non gérés. Ce déséquilibre zonal se résout automatiquement à mesure que le trafic envoyé à l'équilibreur de charge augmente.

Pour plus d'informations, consultez la page de la commande gcloud beta compute backend-services add-backend.

Modifier le mode d'équilibrage d'un équilibreur de charge

Pour certains équilibreurs de charge, vous ne pouvez pas modifier le mode d'équilibrage, car le service de backend n'accepte qu'un seul mode d'équilibrage possible :

  • Les services de backend des équilibreurs de charge TCP/UDP internes n'acceptent que le mode d'équilibrage CONNECTION.
  • Les services de backend des équilibreurs de charge HTTP(S) externes dont tous les backends sont des NEG n'acceptent que le mode d'équilibrage RATE.
  • Les services de backend des équilibreurs de charge HTTP(S) internes dont tous les backends sont des NEG n'acceptent que le mode d'équilibrage RATE.
  • Les services de backend des équilibreurs de charge proxy SSL dont tous les backends sont des NEG n'acceptent que le mode d'équilibrage CONNECTION
  • Les services de backend des équilibreurs de charge proxy TCP dont tous les backends sont des NEG n'acceptent que le mode d'équilibrage CONNECTION

Pour certains équilibreurs de charge, vous pouvez modifier le mode d'équilibrage, car leurs services de backend acceptent plusieurs modes :

  • Les services de backend des équilibreurs de charge HTTP(S) externes dont tous les backends sont des groupes d'instances acceptent le mode d'équilibrage RATE ou UTILIZATION.
  • Les services de backend des équilibreurs de charge HTTP(S) internes dont tous les backends sont des groupes d'instances acceptent le mode d'équilibrage RATE ou UTILIZATION.
  • Les services de backend des équilibreurs de charge proxy SSL dont tous les backends sont des groupes d'instances acceptent le mode d'équilibrage CONNECTION ou UTILIZATION.
  • Les services de backend des équilibreurs de charge proxy TCP dont tous les backends sont des groupes d'instances acceptent le mode d'équilibrage CONNECTION ou UTILIZATION.

Si un même groupe d'instances sert de backend à plusieurs services de backend, il doit utiliser le même mode d'équilibrage pour chacun de ces services. Pour modifier le mode d'équilibrage d'un groupe d'instances servant de backend à plusieurs services de backend, procédez comme suit :

  • Supprimez le groupe d'instances de tous les services de backend, sauf un.
  • Modifiez le mode d'équilibrage du backend sur le seul service de backend restant.
  • Ajoutez à nouveau le groupe d'instances comme backend des services de backend restants, s'ils acceptent le nouveau mode d'équilibrage.

En outre, vous ne pouvez pas utiliser un même groupe d'instances en tant que backend pour certaines combinaisons de services de backend différentes. Par exemple, un même groupe d'instances ne peut servir de backend à la fois à un équilibreur de charge TCP/UDP interne qui n'accepte que le mode d'équilibrage CONNECTION et à un équilibreur de charge HTTP(S) externe compatible avec le mode d'équilibrage RATE ou UTILIZATION.

Capacité cible

Chaque mode d'équilibrage a une capacité cible correspondante, qui définit un nombre maximal de connexions cible, un taux maximal cible ou une utilisation du processeur maximale cible. Pour chaque mode d'équilibrage, la capacité cible n'est pas un disjoncteur. Un équilibreur de charge dépasse la valeur maximale dans certaines conditions ; par exemple, si toutes les machines virtuelles de backend ou les points de terminaison atteignent cette valeur.

  • Pour le mode d'équilibrage CONNECTION, la capacité cible définit un nombre maximal cible de connexions simultanées. À l'exception des équilibreurs de charge TCP/UDP internes, vous devez spécifier un nombre maximal de connexions cible à l'aide de l'une des trois méthodes suivantes : spécifier le nombre maximal de connexions pour chaque machine virtuelle à l'aide de max-connections-per-instance ou pour chaque point d'extrémité dans un NEG zonal à l'aide de max-connections-per-endpoint. Pour les NEG zonaux et pour les groupes d'instances non gérés zonaux, vous pouvez spécifier max-connections pour l'ensemble du groupe.

    Lorsque vous spécifiez max-connections-per-instance ou max-connections-per-endpoint, Google Cloud calcule la cible effective pour chaque machine virtuelle ou point de terminaison comme suit :

    • (Nombre maxi de connexions par VM * nombre total de VM) / nombre de VM opérationnelles
    • (Nombre maxi de connexions par point de terminaison * nombre total de points de terminaison) / nombre de points de terminaison opérationnels

    Lorsque vous spécifiez max-connections, Google Cloud calcule la cible effective pour chaque machine virtuelle ou point de terminaison de la manière suivante :

    • Nombre maxi de connexions / nombre de machines virtuelles opérationnelles
    • Nombre maxi de connexions / nombre de points de terminaison opérationnels

  • Pour le mode d'équilibrage RATE, la capacité cible définit un taux maximal cible de requêtes HTTP. Vous devez spécifier un taux cible à l'aide de l'une des trois méthodes suivantes : spécifier un taux maximal cible pour chaque machine virtuelle à l'aide de max-rate-per-instance ou pour chaque point de terminaison dans un NEG zonal à l'aide de max-rate-per-endpoint. Pour les NEG zonaux et pour les groupes d'instances non gérés zonaux, vous pouvez spécifier max-rate pour l'ensemble du groupe.

    Lorsque vous spécifiez max-rate-per-instance ou max-rate-per-endpoint, Google Cloud calcule le taux cible effectif pour chaque machine virtuelle ou point de terminaison comme suit :

    • taux maxi par VM * nombre total de VM / nombre de VM opérationnelles
    • taux maxi par point de terminaison * nombre total de points de terminaison / nombre de points de terminaison opérationnels

    Lorsque vous spécifiez max-rate, Google Cloud calcule le taux cible effectif pour chaque machine virtuelle ou point de terminaison de la manière suivante :

    • taux maxi / nombre maxi de VM opérationnelles
    • taux maxi / nombre maxi de points de terminaison opérationnels

  • Pour le mode d'équilibrage UTILIZATION, il n'est pas nécessaire de définir une capacité cible. Vous disposez d'un certain nombre d'options qui dépendent du type de backend, comme résumé dans le tableau suivant.

Ce tableau indique tous les modes d'équilibrage possibles pour un équilibreur de charge et un type de backend donnés. Il indique également les paramètres de capacité disponibles ou obligatoires, que vous devez spécifier conjointement avec le mode d'équilibrage.

Équilibreur de charge Type de backend Mode d'équilibrage Capacité cible
Équilibrage de charge TCP/UDP interne Groupe d'instances CONNECTION Vous ne pouvez pas spécifier de nombre maximal de connexions.
Équilibrage de charge proxy SSL, équilibrage de charge proxy TCP Groupe d'instances CONNECTION Vous devez spécifier l'un des éléments suivants :
1. Nombre maximal de connexions par groupe d'instances zonal
2. Nombre maximal de connexions par instance
(groupes d'instances zonaux ou régionaux)
UTILIZATION Vous pouvez éventuellement spécifier l'une des options suivantes :
1. Utilisation maximale
2. Nombre maximal de connexions par groupe d'instances zonal
3. Nombre maximal de connexions par instance
(groupes d'instances zonaux ou régionaux)
4. 1 et 2 ensemble
5. 1 et 3 ensemble
NEG zonal CONNECTION Vous devez spécifier l'un des éléments suivants :
1. Nombre maximal de connexions par NEG zonal
2. Nombre maximal de connexions par point de terminaison
Équilibrage de charge HTTP(S), équilibrage de charge HTTP(S) interne, Traffic Director Groupe d'instances RATE Vous devez spécifier l'un des éléments suivants :
1. Taux maximal par groupe d'instances zonal
2. Taux maximal par instance
(groupes d'instances zonaux ou régionaux)
UTILIZATION Vous pouvez éventuellement spécifier l'une des options suivantes :
1. Utilisation maximale
2. Taux maximal par groupe d'instances zonal
3. Taux maximal par instance
(groupes d'instances zonaux ou régionaux)
4. 1 et 2 ensemble
5. 1 et 3 ensemble
NEG zonal RATE Vous devez spécifier l'un des éléments suivants :
1. Taux maximal par NEG zonal
2. Taux maximal par point de terminaison

Scaler de capacité

Vous pouvez éventuellement ajuster le scaler de capacité pour réduire la capacité cible (utilisation maximale, taux maximal ou connexions maximales) sans modifier la capacité cible. Le scaler de capacité est compatible avec tous les équilibreurs de charge qui acceptent une capacité cible. La seule exception concerne l'équilibreur de charge TCP/UDP interne.

Par défaut, le scaler de capacité est défini sur 1.0 (100 %). Cela signifie, par exemple, que si le pourcentage d'utilisation actuel d'une instance de backend est de 80 % et que l'utilisation maximale est définie sur 80 %, le service de backend cesse d'envoyer des requêtes à cette instance :

capacity-scaler: 1 * 0.8

Vous pouvez régler le scaler de capacité à la valeur 0.0 ou bien à une valeur allant de 0.1 (10%) à 1.0 (100%). Vous ne pouvez pas configurer une valeur supérieure à 0.0 et inférieure à 0.1. Un facteur de scaling de zéro (0.0) empêche toute nouvelle connexion. Vous ne pouvez pas configurer une valeur de 0.0 lorsqu'un seul backend est associé au service de backend.

Utiliser le scaler de capacité lorsque deux services de backend partagent un backend de groupe d'instances

Dans une situation où deux services de backend utilisent le même backend de groupe d'instances, vous devez répartir la capacité du groupe d'instances entre les deux services de backend.

Par exemple, vous pouvez définir le scaler de capacité sur 0.5 pour les deux services de backend. Chaque service de backend recevra ainsi 40 % de la capacité du groupe d'instances :

capacity-scaler: 0.5 * 0.8

Lorsque chaque service de backend a utilisé 40 % de la capacité du groupe d'instances, les requêtes ne sont plus envoyées à ce groupe d'instances.

Trafic Director et distribution du trafic

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 basée sur 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 soit des groupes d'instances, soit des NEG zonaux.

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

Pour plus d'informations sur Traffic Director, consultez la page Concepts de Traffic Director.

Affinité de session

Sans affinité de session, les équilibreurs de charge distribuent les nouvelles requêtes en fonction d'un hachage à 5 tuples composé de l'adresse IP et du port source du client, de l'adresse IP et du port de destination de la règle de transfert de l'équilibreur de charge et du protocole L3 (protocole TCP pour tous les équilibreurs de charge qui utilisent des services de backend). Le mode d'équilibrage du groupe d'instances de backend ou du NEG zonal détermine quand le backend fonctionne à pleine capacité. Certaines applications - telles que les serveurs avec état utilisés par la diffusion d'annonces, les jeux ou les services avec une forte mise en cache interne - nécessitent plusieurs requêtes d'un utilisateur donné pour être dirigées vers le même backend ou point de terminaison.

L'affinité de session est disponible pour le trafic TCP, y compris les protocoles SSL, HTTP(S) et HTTP/2. Tant qu'une instance de backend ou un point de terminaison reste opérationnel et n'a pas atteint la capacité définie par son mode d'équilibrage, l'équilibreur de charge dirige les requêtes ultérieures vers la même machine virtuelle de backend ou le même point de terminaison. Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :

  • Comme le trafic UDP n'est pas compatible avec les sessions, l'affinité de session n'affecte pas ce type de trafic.

  • Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session est conçue pour rompre lorsqu'un backend a atteint ou dépassé sa capacité ou s'il n'est plus opérationnel.

  • Les équilibreurs de charge Google Cloud assurent l'affinité de session de la façon la plus optimale possible. Des facteurs tels que la modification des états du backend ou de son utilisation maximale, selon les mesures effectuées par le mode d'équilibrage, peuvent rompre l'affinité de session. L'utilisation d'une affinité de session autre que None avec le mode d'équilibrage UTILIZATION n'est pas recommandée, car les changements d'utilisation de l'instance peuvent amener le service d'équilibrage de charge à diriger les requêtes ou les connexions ultérieures vers des machines virtuelles de backend moins utilisées, ce qui rompt l'affinité de session. Utilisez plutôt le mode d'équilibrage RATE ou CONNECTION compatible avec l'équilibreur de charge que vous avez choisi, pour réduire les risques de rupture de l'affinité de session.

Le tableau suivant présente les options d'affinité de session :

Produit Options d'affinité de session
• TCP/UDP interne • Aucune
• Adresse IP client
• Adresse IP client et protocole
• Adresse IP client, protocole et port
• Proxy TCP
• Proxy SSL		 • Aucune
• Adresse IP client
• HTTP(S) externe • Aucune
• Adresse IP client
• Cookie généré
• HTTP(S) interne • Aucune
• Adresse IP client
• Cookie généré
• Champ d'en-tête
• Cookie HTTP
• 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. Reportez-vous au paramètre sessionAffinity dans Pools cibles.
• Traffic Director • Aucune
• Adresse IP client
• Cookie généré
• Champ d'en-tête
• Cookie HTTP

Les sections suivantes décrivent les différents types d'affinité de session.

Affinité basée sur les adresses IP client

L'affinité basée sur les adresses IP client dirige les requêtes en provenance d'une même adresse IP client vers une même instance de backend. 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 utilisez l'affinité IP client, gardez à l'esprit les points suivants :

  • L'affinité basée sur les adresses IP client consiste en un hachage à deux tuples composé de l'adresse IP du client et de l'adresse IP de la règle de transfert de l'équilibreur de charge que le client contacte.

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

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 :

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

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

Affinité basée sur le champ d'en-tête

Un équilibreur de charge HTTP(S) interne peut utiliser l'affinité basée sur le champ d'en-tête lorsque la règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le nom de l'en-tête HTTP. L'affinité basée sur le champ d'en-tête achemine les requêtes vers les machines virtuelles de backend ou les points de terminaison dans un NEG zonal en fonction de la valeur de l'en-tête HTTP nommé dans l'option --custom-request-header.

Pour plus d'informations sur l'équilibrage de charge HTTP(S) interne utilisant l'affinité basée sur le champ d'en-tête, consultez la page Présentation de l'équilibrage de charge HTTP(S) interne.

Un équilibreur de charge TCP/UDP interne peut utiliser l'affinité basée sur les cookies HTTP lorsque la règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le nom du cookie HTTP.

L'affinité basée sur les cookies HTTP achemine les requêtes vers les machines virtuelles de backend ou les points de terminaison dans un NEG en fonction du cookie HTTP nommé dans l'option HTTP_COOKIE. Si le client ne fournit pas de cookie, le proxy en génère un et le renvoie au client dans un en-tête Set-Cookie.

Pour plus d'informations sur l'équilibrage de charge HTTP(S) interne utilisant l'affinité basée sur les cookies HTTP, consultez la page Présentation de l'équilibrage de charge HTTP(S) interne.

Perdre l'affinité de session

Quel que soit le type d'affinité choisi, un client peut perdre son affinité avec un backend dans les situations suivantes :

  • Si le groupe d'instances de backend ou le NEG zonal manque de capacité par rapport à la capacité cible définie du mode d'équilibrage. Dans cette situation, Google Cloud dirige le trafic vers un autre groupe d'instances de backend ou un NEG zonal, qui peut se trouver dans une zone différente. Vous pouvez minimiser ce comportement en spécifiant une valeur appropriée pour la capacité cible de chaque backend en fonction de vos propres tests.
  • L'autoscaling ajoute ou supprime des instances d'un groupe d'instances géré. Lorsque cela se produit, le nombre d'instances dans le groupe change, de sorte que le service de backend recalcule les hachages pour l'affinité de session. Vous pouvez minimiser ce comportement en vous assurant que la taille minimale du groupe d'instances géré est capable de supporter une charge type. L'autoscaling ne s'effectue alors qu'en cas d'augmentation inattendue de la charge.
  • Si une machine virtuelle de backend ou un point de terminaison dans un NEG échoue aux vérifications de l'état, l'équilibreur de charge dirige le trafic vers un autre backend opérationnel. Reportez-vous à la documentation de chaque équilibreur de charge Google Cloud pour plus de détails sur le comportement de l'équilibreur de charge lorsque tous ses backends échouent aux vérifications de l'état.
  • Lorsque le mode d'équilibrage UTILIZATION est activé pour les groupes d'instances de backend, l'affinité de session se rompt en raison de changements dans l'utilisation du backend. Vous pouvez minimiser ce comportement en utilisant le mode d'équilibrage RATE ou CONNECTION, selon le type compatible avec l'équilibreur de charge.

Lorsque vous utilisez l'équilibrage de charge HTTP(S), l'équilibrage de charge proxy SSL ou l'équilibrage de charge proxy TCP, gardez à l'esprit les points supplémentaires suivants :

  • Si le chemin de routage d'un client sur Internet vers Google change entre les requêtes ou les connexions, un autre GFE peut être sélectionné comme proxy. Toutefois, cela peut rompre l'affinité de la session.
  • Lorsque vous utilisez le mode d'équilibrage UTILIZATION - en particulier sans avoir défini de capacité maximale cible - l'affinité de session est susceptible de se rompre lorsque le trafic vers l'équilibreur de charge est faible. Basculez plutôt sur le mode d'équilibrage RATE ou CONNECTION.

Délai avant expiration du service de backend

La plupart des équilibreurs de charge Google Cloud dispose d'un délai avant expiration de service de backend. La valeur par défaut est de 30 secondes.

  • Pour les équilibreurs de charge HTTP(S) externes et les équilibreurs de charge HTTP(S) internes utilisant le protocole HTTP, HTTPS ou HTTP/2, le délai d'expiration de service de backend est un délai d'expiration de requête/réponse pour le trafic HTTP(S). Il s'agit de la durée pendant laquelle l'équilibreur de charge attend qu'un backend renvoie une réponse complète à une requête. Par exemple, si la valeur par défaut du délai avant expiration du service de backend est de 30 secondes, alors les backends disposent de cette durée pour fournir une réponse complète aux requêtes. L'équilibreur de charge réessaye la requête HTTP GET une fois si le backend ferme la connexion ou expire avant d'envoyer des en-têtes de réponse à l'équilibreur de charge. Si le backend envoie des en-têtes de réponse (même si le corps de la réponse est par ailleurs incomplet) ou si la requête envoyée au backend n'est pas une requête HTTP GET, l'équilibreur de charge ne réessaye pas. Si le backend ne répond pas du tout, l'équilibreur de charge renvoie une réponse HTTP 5xx au client. Pour ces équilibreurs de charge, modifiez la valeur du délai d'expiration si vous souhaitez accorder plus ou moins de temps aux backends pour envoyer une réponse complète aux requêtes.

  • Pour les équilibreurs de charge HTTP(S) externes, si la connexion HTTP est mise à niveau vers un WebSocket, le délai d'expiration du service de backend définit la durée maximale pendant laquelle un WebSocket peut être ouvert, qu'il soit inactif ou non.

  • Pour les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP, le délai avant expiration est un délai d'inactivité. Pour ces équilibreurs de charge, modifiez la valeur du délai avant expiration si vous souhaitez accorder plus ou moins de temps avant la suppression de la connexion. Ce délai d'inactivité est également utilisé pour les connexions WebSocket.

  • Les équilibreurs de charge TCP/UDP internes ignorent la valeur du délai avant expiration du service de backend.

Vérifications d'état

Chaque service de backend dont les backends sont des groupes d'instances ou des NEG zonaux doit être associé à une vérification d'état. Les services de backend utilisant un NEG Internet comme backend n'ont pas besoin de référencer une vérification d'état.

Lorsque vous créez un équilibreur de charge à l'aide de Google Cloud Console, vous pouvez créer la vérification d'état, si nécessaire, lors de la création de l'équilibreur de charge, mais vous pouvez également référencer une vérification d'état existante.

Lorsque vous créez un service de backend basé sur un groupe d'instances ou un NEG zonal à l'aide de l'outil de ligne de commande gcloud ou de l'API, vous devez référencer une vérification d'état existante. Reportez-vous au guide sur les équilibreurs de charge dans la Présentation des vérifications d'état pour plus de détails sur le type et la portée de la vérification d'état requise.

Pour en savoir plus, consultez les documents suivants :

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

Les fonctionnalités Google Cloud facultatives suivantes sont disponibles pour les services de backend utilisés par un équilibrage de charge HTTP(S). Elles ne sont pas abordées dans ce document mais dans les pages suivantes :

  • 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.
  • IAP vous permet d'exiger une authentification auprès d'un compte Google à l'aide d'un workflow de connexion OAuth 2.0 et de contrôler l'accès à l'aide des autorisations IAM.

Autres remarques

Les fonctionnalités suivantes ne sont compatibles qu'avec les équilibreurs de charge HTTP(S) internes et Traffic Director :

  • 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 :