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. Si vous devez démarrer rapidement, la plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration.
Les équilibreurs de charge, les proxys Envoy et les clients gRPC sans proxy utilisent les informations de configuration de la ressource de service de backend pour effectuer les opérations suivantes :
- Dirigez le trafic vers les bons backends, qui sont des groupes d'instances ou des groupes de points de terminaison du réseau (NEG).
- Répartissez le trafic selon un mode d'équilibrage à paramétrer pour chaque backend
- Déterminez la vérification d'état utilisée pour surveiller l'état des backends
- Spécifiez l'affinité de session.
- Déterminez si d'autres services sont activés, y compris les services suivants qui ne sont disponibles que pour certains équilibreurs de charge :
- Cloud CDN
- Stratégies de sécurité Google Cloud Armor
- Identity-Aware Proxy
Vous définissez ces valeurs lorsque vous créez un service de backend ou ajoutez un backend au service de backend.
Vous pouvez configurer un service de backend pour les équilibreurs de charge Google Cloud suivants :
- Équilibreur de charge HTTP(S) externe global
- Équilibreur de charge HTTP(S) externe global (classique)
- Équilibreur de charge HTTP(S) externe régional (bêta)
- Équilibreur de charge HTTP(S) interne
- Équilibreur de charge proxy SSL
- Équilibreur de charge proxy TCP
- Équilibreur de charge TCP/UDP interne
- Équilibreur de charge réseau basé sur un service de backend
Traffic Director utilise également les services de backend.
Le produit que vous utilisez détermine le nombre maximal de services de backend, le champ d'application d'un service de backend, le type de backends compatibles et le schéma d'équilibrage de charge du service de backend.
Produit | Nombre maximal de services de backend | Champ d'application du service de backend | Types de backends compatibles | Schéma d'équilibrage de charge |
---|---|---|---|---|
Équilibreur de charge HTTP(S) externe global | Plusieurs | Mondial | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL_MANAGED |
Équilibreur de charge HTTP(S) externe global (classique) | Plusieurs | Global1 | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL |
Équilibreur de charge HTTP(S) externe régional (bêta) | Plusieurs | Régional | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL_MANAGED |
Équilibreur de charge HTTP(S) interne | Plusieurs | Régional | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
INTERNAL_MANAGED |
Équilibreur de charge proxy SSL | 1 | Global1 | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL |
Équilibreur de charge proxy TCP | 1 | Global1 | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL |
Équilibreur de charge réseau | 1 | Régional | Le service de backend accepte les combinaisons de backend suivantes :
|
EXTERNAL |
Équilibreur de charge TCP/UDP interne | 1 | Régional, mais configurable pour être accessible à l'échelle mondiale | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
INTERNAL |
Traffic Director | Plusieurs | Mondial | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
INTERNAL_SELF_MANAGED |
- La règle de transfert et son adresse IP externe sont régionales.
- Tous les backends connectés au service de backend doivent être situés dans la même région que la règle de transfert.
API et documentation de référence gcloud
Un service de backend a un champ d'application global ou régional.
Pour plus d'informations sur les propriétés de la ressource de service de backend, consultez les documents de référence suivants :
Ressource API de service de backend global
Ressource API de service de backend régional
Page sur
gcloud compute backend-services
pour les services de backend globaux et régionaux
Backends
Un backend correspond à un ou plusieurs points de terminaison qui reçoivent le trafic d'un équilibreur de charge Google Cloud, d'un proxy Envoy configuré par Traffic Director ou d'un client gRPC sans proxy. Il existe plusieurs types de backends :
- Groupe d'instances contenant des instances de machines virtuelles (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é. Plusieurs services de backend peuvent faire référence à un groupe d'instances, mais tous les services de backend qui font référence au groupe d'instances doivent utiliser le même mode d'équilibrage.
- NEG zonal
- NEG sans serveur
- NEG Internet
- NEG de connectivité hybride
- NEG Private Service Connect
- Liaisons de services de l'Annuaire des services
En outre, vous pouvez disposer d'un backend de bucket Cloud Storage en utilisant un bucket backend au lieu d'un service de backend.
Informations complémentaires concernant l'utilisation :
- Un seul service de backend ne peut pas référencer une combinaison de groupes d'instances et de NEG zonaux.
- 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 avec quels services de backend, consultez le tableau de la section précédente.
- Pour les équilibreurs de charge HTTP(S) externes globaux uniquement, vous pouvez utiliser une combinaison de NEG zonaux (avec points de terminaison
GCE_VM_IP_PORT
) et de NEG de connectivité hybride (avec points de terminaisonNON_GCP_PRIVATE_IP_PORT
) pour configurer un Équilibrage de charge hybride. - Vous ne pouvez pas supprimer un groupe d'instances ou un NEG backend 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é pour communiquer avec les backends. Vous ne pouvez spécifier qu'un seul protocole par service de backend. Vous ne pouvez pas définir de protocole secondaire à utiliser comme solution de secours.
Les protocoles valides dépendent du type d'équilibreur de charge ou de l'utilisation ou non de Traffic Director.
Produit | Schéma d'équilibrage de charge | Options de protocole du service de backend |
---|---|---|
Équilibreur de charge HTTP(S) externe global | EXTERNAL_MANAGED | HTTP, HTTPS, HTTP/2 |
Équilibreur de charge HTTP(S) externe global (classique) | EXTERNAL | HTTP, HTTPS, HTTP/2 |
Équilibreur de charge HTTP(S) externe régional (bêta) | EXTERNAL_MANAGED | HTTP, HTTPS, HTTP/2 |
Équilibreur de charge proxy SSL | EXTERNAL | SSL |
Équilibreur de charge proxy TCP | EXTERNAL | TCP |
Équilibreur de charge HTTP(S) interne | INTERNAL_MANAGED | HTTP, HTTPS, HTTP/2 |
Équilibreur de charge réseau | EXTERNAL | TCP, UDP ou UNSPECIFIED |
Équilibreur de charge TCP/UDP interne | INTERNAL | TCP ou UDP |
Traffic Director | INTERNAL_SELF_MANAGED | HTTP, HTTPS, HTTP/2, gRPC, TCP |
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 plus d'informations sur ce sujet, consultez la section Chiffrement vers les backends.
Groupes d'instances
Cette section explique comment les groupes d'instances fonctionnent avec le service de backend.
VM backend et adresses IP externes
Les VM 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. GFE communique avec les VM de backend ou les points de terminaison à l'aide d'une combinaison d'identifiants pour le réseau VPC du backend et de l'adresse IP interne du point de terminaison ou de la VM. Les adresses IP internes doivent être associées à l'interface réseau principale (nic0) du backend. La communication entre les GFE et des VM de backend ou des points de terminaison est facilitée via des routes spéciales.
- Pour les équilibreurs de charge HTTP(S) externes régionaux, les clients utilisent l'adresse IP et le port de l'équilibreur de charge pour se connecter aux proxys Envoy de l'équilibreur de charge (provisionnés dans un sous-réseau proxy réservé). Les VM de backend ou les points de terminaison de tous les équilibreurs de charge HTTP(S) externes régionaux d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
- Pour les équilibreurs de charge réseau, les paquets sont d'abord acheminés vers l'adresse IP externe de l'équilibreur de charge réseau. L'équilibreur de charge utilise ensuite un hachage cohérent pour acheminer les paquets vers les VM de backend.
- Les VM backend ne nécessitent pas d'adresses IP externes.
Ports nommés
Sur le backend, l'équilibreur de charge transfère le trafic vers les numéros de port qu'écoutent vos instances backend (instances Compute Engine). Vous configurez le numéro de port dans le groupe d'instances et vous y faites référence dans la configuration du service de backend.
Si le port nommé d'un groupe d'instances correspond au --port-name
dans la configuration du service de backend, le service de backend utilise ce numéro de port pour communiquer avec les VM du groupe d'instances.
Le numéro de port du backend est appelé port nommé, car il s'agit d'une paire nom/valeur. Dans le groupe d'instances, vous définissez le nom et la valeur de la clé pour le port.
Par exemple, vous pouvez définir le port nommé sur un groupe d'instances avec le nom my-service-name
et le port 8888
:
gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \ --named-ports=my-service-name:8888
Vous faites ensuite référence au port nommé dans la configuration du service de backend, avec --port-name
sur le service de backend défini sur my-service-name
:
gcloud compute backend-services update my-backend-service \ --port-name=my-service-name
Si vous utilisez plusieurs numéros de port pour un port nommé (par exemple, http:80,http:8080
), ils doivent tous correspondre à la même application. En effet, le trafic est équilibré entre tous les ports ayant le même nom de port. Par exemple, vous ne pouvez pas créer de port nommé avec les valeurs 80
et 443
. Cela ne fonctionne pas, car le port 80 n'est généralement pas compatible avec TLS.
Pour savoir comment créer des ports nommés, consultez les instructions suivantes :
- Groupes d'instances non gérés : Utiliser des ports nommés
- Groupes d'instances gérés : Attribuer des ports nommés à des groupes d'instances gérés
Veuillez noter les points suivants :
Chaque service de backend s'abonne à un nom de port unique. Chacun de ses groupes d'instances de backend doit avoir au moins un port nommé pour ce nom.
Un service de backend peut utiliser un numéro de port différent lors de la communication avec des VM appartenant à différents groupes d'instances si chacun de ces groupes spécifie un numéro de port différent pour le même nom de port. Cependant, tous les ports doivent représenter la même application. Par exemple,
http:80,http:8080
fonctionne, maishttp:80,http:443
ne fonctionne pas.Le numéro de port résolu utilisé par 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. Un équilibreur de charge écoute l'interface sur un ou plusieurs numéros de port que vous configurez dans la règle de transfert de l'équilibreur de charge. Les instances backend peuvent écouter sur différents numéros de port.
Les ports nommés ne sont pas utilisés dans les cas suivants :
- Pour les backends NEG zonaux ou NEG Internet, car ces NEG définissent les ports en se basant sur un mécanisme différent, à savoir les points de terminaison.
- Pour les backends NEG sans serveur, car ces NEG ne disposent pas de points de terminaison.
- Pour les équilibreurs de charge TCP/UDP internes, car il s'agit d'équilibreurs de charge à stratégie directe, et non de proxys. De plus, leur service de backend ne s'abonne pas à un port nommé.
- Pour les équilibreurs de charge réseau, car un équilibreur de charge réseau est un équilibreur de charge à stratégie directe et non un proxy, et son service de backend ne s'abonne pas à un port nommé.
Pour plus d'informations sur les ports nommés, consultez 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 VM 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 VM participe à plusieurs équilibreurs de charge, vous devez utiliser le même groupe d'instances comme backend pour chacun des services de backend.
Pour les équilibreurs de charge proxy, lorsque vous souhaitez équilibrer le trafic sur différents ports, spécifiez les ports nommés requis pour un groupe d'instances et demandez à chaque service de backend de s'abonner à un port nommé unique.
Vous pouvez utiliser le même groupe d'instances qu'un backend pour plusieurs services de backend. Dans ce cas, les backends doivent utiliser des modes d'équilibrage compatibles. Compatible signifie que les modes d'équilibrage doivent être les mêmes ou une combinaison de
CONNECTION
etRATE
. Les combinaisons incompatibles sont les suivantes :CONNECTION
avecUTILIZATION
RATE
avecUTILIZATION
Prenons l'exemple suivant :
- Vous disposez de deux services de backend :
external-https-backend-service
pour un équilibreur de charge HTTP(S) externe etinternal-tcp-backend-service
pour un équilibreur de charge TCP/UDP interne. - Vous utilisez un groupe d'instances appelé
instance-group-a
dansinternal-tcp-backend-service
. - Dans
internal-tcp-backend-service
, vous devez appliquer le mode d'équilibrageCONNECTION
, car les équilibreurs de charge TCP/UDP internes n'acceptent que le mode d'équilibrageCONNECTION
. - Vous pouvez également utiliser
instance-group-a
dansexternal-https-backend-service
si vous appliquez le mode d'équilibrageRATE
dansexternal-https-backend-service
. - Vous ne pouvez pas également utiliser
instance-group-a
dansexternal-https-backend-service
avec le mode d'équilibrageUTILIZATION
.
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 service de backend restant.
- Ajoutez à nouveau le groupe d'instances comme backend des autres services de backend, s'ils acceptent le nouveau mode d'équilibrage.
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 employez 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 vous exploitez la métrique d'autoscaling Utilisation du processeur, ou une métrique Cloud Monitoring qui n'est pas liée à la capacité de diffusion de l'équilibreur de charge. Ces métriques d'autoscaling peuvent éviter l'irrégularité d'un scaling.
Groupes de points de terminaison du réseau zonaux
Les points de terminaison du réseau représentent les services en fonction de leur adresse IP ou d'une combinaison adresse IP/port, plutôt que de se référer à une VM d'un groupe d'instances. Un groupe de points de terminaison du réseau (NEG) est un regroupement logique de points de terminaison du réseau.
Les groupes de points de terminaison du réseau (NEG) zonaux sont des ressources zonales qui représentent des collections d'adresses IP ou de combinaisons adresses IP/port pour les ressources Google Cloud faisant partie d'un même sous-réseau.
Deux types de points de terminaison du réseau sont disponibles pour les NEG zonaux :
- Les points de terminaison
GCE_VM_IP
- Les points de terminaison
GCE_VM_IP_PORT
Pour en savoir plus, consultez la page Présentation des NEG zonaux.
Un service de backend dont les backends sont des NEG zonaux distribue le trafic entre les applications ou les conteneurs exécutés au sein des VM.
Les groupes de points de terminaison du réseau (NEG) zonaux utilisant des points de terminaison GCE_VM_IP_PORT
peuvent servir de backends pour les types d'équilibreurs de charge suivants :
- Équilibreur de charge HTTP(S) externe global
- Équilibreur de charge HTTP(S) externe global (classique)
- Équilibreur de charge HTTP(S) externe régional
- Équilibreur de charge HTTP(S) interne
- Équilibreur de charge proxy SSL
- Équilibreur de charge proxy TCP
Traffic Director est également compatible avec les backends de NEG zonaux utilisant les points de terminaison GCE_VM_IP_PORT
.
Les groupes de points de terminaison du réseau (NEG) zonaux utilisant des points de terminaison GCE_VM_IP
ne peuvent servir de backends que pour l'équilibrage de charge TCP/UDP interne.
Les NEG zonaux ne sont pas compatibles avec l'équilibrage de charge 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 globales qui définissent des backend externes. Un backend externe est un backend hébergé sur une infrastructure sur site ou sur une infrastructure 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 et443
pour HTTPS) - Une adresse IP publique et un port facultatif, par exemple
203.0.113.8:80
ou203.0.113.8:443
(ports par défaut :80
pour HTTP et443
pour HTTPS)
Seul l'équilibreur de charge HTTP(S) externe global (classique) est compatible avec les backends NEG Internet. Les équilibreurs de charge HTTP(S) externes globaux et les équilibreurs de charge HTTP(S) externes régionaux ne sont pas compatibles avec les backends NEG Internet. Traffic Director accepte les NEG Internet avec des noms de domaine complets.
Pour plus d'informations, consultez la page Présentation des groupes de points de terminaison du réseau Internet.
Groupes de points de terminaison du réseau sans serveur
Un groupe de points de terminaison du réseau (NEG) spécifie un groupe de points de terminaison backend pour un équilibreur de charge. Un NEG sans serveur est un backend qui pointe vers un service Cloud Run, App Engine, Cloud Functions ou API Gateway.
Un NEG sans serveur peut représenter l'un des éléments suivants:
- Un service Cloud Run ou un groupe de services.
- Une fonction Cloud Functions ou un groupe de fonctions.
- Une application App Engine (standard ou Flex), un service spécifique au sein d'une application, une version spécifique d'une application ou un groupe de services.
- Un service API Gateway qui permet d'accéder à vos services via une API REST cohérente entre tous les services, indépendamment de leur mise en œuvre. Cette fonctionnalité est en version Bêta.
Pour configurer un NEG sans serveur pour les applications sans serveur qui partagent un format d'URL commun, utilisez un masque d'URL. Un masque d'URL est un modèle de votre schéma d'URL (par exemple, example.com/<service>
). Le NEG sans serveur utilisera ce modèle pour extraire le nom <service>
de l'URL de requête entrante et acheminer la requête vers le service Cloud Run, Cloud Functions ou App Engine correspondant (qui porte ce même nom).
Pour en savoir plus, y compris sur les équilibreurs de charge compatibles avec les NEG sans serveur, consultez la section Présentation des groupes de points de terminaison du réseau sans serveur.
Liaisons de service
Une liaison de service est un backend qui établit une connexion entre un service de backend dans Traffic Director et un service enregistré dans l'Annuaire des services. Un service de backend peut référencer plusieurs liaisons de service. Un service de backend avec une liaison de service ne peut référencer aucun autre type de backend.
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 définit la manière dont l'équilibreur de charge mesure l'état de préparation des backends susceptibles de recevoir les requêtes ou connexions ultérieures.
- Une capacité cible définit le nombre maximal de connexions cible, un taux maximal cible ou une utilisation du processeur maximale cible.
- Un scaler de capacité ajuste 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 ou de Traffic Director 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. Notez que vous ne pouvez pas spécifier de mode d'équilibrage lorsque vous utilisez des NEG sans serveur ou des NEG Internet en tant que backends pour un équilibreur de charge.
Pour l'équilibreur de charge HTTP(S) externe global (classique), le mode d'équilibrage permet de sélectionner le backend le plus adapté (groupe d'instances ou NEG). Le trafic est ensuite distribué à tour de rôle entre les instances ou les points de terminaison du backend.
Pour les équilibreurs de charge HTTP(S) externes globaux, les équilibreurs de charge HTTP(S) externes régionaux et les équilibreurs de charge HTTP(S) internes, l'équilibrage de charge est réparti sur deux niveaux. Le mode d'équilibrage détermine la pondération/la fraction du trafic à envoyer à chaque backend (groupe d'instances ou NEG ).
Ensuite, la règle d'équilibrage de charge (LocalityLbPolicy
) détermine la manière dont le trafic est distribué aux instances ou aux points de terminaison au sein du groupe. La capacité cible max-utilization
ne peut être spécifiée que par groupe d'instances et ne peut pas être appliquée à une VM spécifique du groupe.
Mode d'équilibrage | Schémas d'équilibrage de charge compatibles | Protocoles de services de backend compatibles1 | Backends compatibles2 | Produits applicables |
---|---|---|---|---|
CONNECTION |
EXTERNAL INTERNAL |
SSL, TCP, UDP |
Soit des groupes d'instances, soit des NEG zonaux, si compatibles. |
|
RATE |
EXTERNAL EXTERNAL_MANAGED INTERNAL_MANAGED INTERNAL_SELF_MANAGED |
HTTP, HTTPS, HTTP2, gRPC | Groupes d'instances ou NEG zonaux |
|
UTILIZATION |
EXTERNAL EXTERNAL_MANAGED INTERNAL_MANAGED INTERNAL_SELF_MANAGED |
Aucune restriction particulière | Groupes d'instances uniquement. Les NEG zonaux n'acceptent pas le mode d'utilisation. |
|
Si l'utilisation moyenne de toutes les VM 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 zonaux gérés dans différentes zones et des groupes d'instances zonaux 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 sur la commande gcloud 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. Pour d'autres, en fonction du backend utilisé, vous pouvez modifier le mode d'équilibrage, car plusieurs modes sont disponibles pour ces services backend.
Équilibreur de charge | Backends | Modes d'équilibrage disponibles |
---|---|---|
|
Groupes d'instances | RATE ou UTILIZATION |
NEG zonaux (points de terminaison GCE_VM_IP_PORT ) |
RATE |
|
Équilibreur de charge HTTP(S) interne | Groupes d'instances | RATE ou UTILIZATION |
NEG zonaux (points de terminaison GCE_VM_IP_PORT ) |
RATE |
|
Équilibreur de charge proxy TCP | Groupes d'instances | CONNECTION ou UTILIZATION |
NEG zonaux (points de terminaison GCE_VM_IP_PORT ) |
CONNECTION |
|
Équilibreur de charge proxy SSL | Groupes d'instances | CONNECTION ou UTILIZATION |
NEG zonaux (points de terminaison GCE_VM_IP_PORT ) |
CONNECTION |
|
Équilibreur de charge réseau | Groupes d'instances | CONNECTION |
Équilibreur de charge TCP/UDP interne | Groupes d'instances | CONNECTION |
NEG zonaux (points de terminaison GCE_VM_IP ) |
CONNECTION |
Capacité cible
Chaque mode d'équilibrage possède une capacité cible correspondante, qui définit l'une des valeurs maximales cibles suivantes :
- Nombre de connexions
- Tarif
- Utilisation du processeur
Pour chaque mode d'équilibrage, la capacité cible n'est pas un disjoncteur. Un équilibreur de charge peut dépasser la valeur maximale dans certaines conditions ; par exemple, si tous les points de terminaison ou VM de backend atteignent cette valeur.
Mode d'équilibrage des connexions
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 et des équilibreurs de charge réseau, vous devez utiliser l'un des paramètres suivants pour spécifier un nombre maximal cible de connexions :
max-connections-per-instance
(par VM) : nombre moyen cible de connexions pour une seule VM.max-connections-per-endpoint
(par point de terminaison dans un NEG zonal) : nombre moyen cible de connexions pour un seul point de terminaison.max-connections
(par NEG zonal et pour les groupes d'instances zonaux) : nombre moyen cible de connexions pour l'ensemble du NEG ou du groupe d'instances. Pour les groupes d'instances gérés régionaux, utilisez plutôtmax-connections-per-instance
.
Le tableau suivant montre comment le paramètre de capacité cible définit les éléments suivants :
- Capacité cible pour l'ensemble du backend
- Capacité cible attendue pour chaque instance ou point de terminaison
Type de backend | Capacité cible | ||
---|---|---|---|
Si vous indiquez | Capacité entière du backend | Capacité attendue par instance ou par point de terminaison | |
Groupe d'instancesN instances,H opérationnelles |
max-connections-per-instance=X
|
X × N
|
(X × N)/H
|
NEG zonalN points de terminaisonH opérationnels
|
max-connections-per-endpoint=X
|
X × N
|
(X × N)/H
|
Groupes d'instances (à l'exception des groupes d'instances gérés régionaux) H instances opérationnelles
|
max-connections=Y
|
Y
|
Y/H
|
Comme indiqué, les paramètres max-connections-per-instance
et max-connections-per-endpoint
sont des proxys permettant de calculer un nombre maximal cible de connexions pour l'ensemble du groupe d'instances ou du NEG zonal :
- Dans un groupe d'instances avec
N
instances, la définition demax-connections-per-instance=X
a la même signification que la définition demax-connections=X × N
. - Dans un NEG zonal avec
N
points de terminaison, la définition demax-connections-per-endpoint=X
a la même signification que la définition demax-connections=X × N
.
Mode d'équilibrage de fréquence
Avec le mode d'équilibrage RATE
, vous devez définir la capacité cible à l'aide de l'un des paramètres suivants :
max-rate-per-instance
(par VM) : spécifiez un taux de requêtes HTTP moyen cible pour une seule VM.max-rate-per-endpoint
(par point de terminaison dans un NEG zonal) : spécifiez un taux de requêtes HTTP moyen cible pour un seul point de terminaison.max-rate
(par NEG zonal et pour les groupes d'instances zonaux) : spécifiez un taux de requêtes HTTP moyen cible pour l'ensemble du NEG ou du groupe d'instances. Pour les groupes d'instances gérés régionaux, utilisez plutôtmax-rate-per-instance
.
Le tableau suivant montre comment le paramètre de capacité cible définit les éléments suivants :
- Capacité cible pour l'ensemble du backend
- Capacité cible attendue pour chaque instance ou point de terminaison
Type de backend | Capacité cible | ||
---|---|---|---|
Si vous indiquez | Capacité entière du backend | Capacité attendue par instance ou par point de terminaison | |
Groupe d'instancesN instances,H opérationnelles |
max-rate-per-instance=X
|
X × N
|
(X × N)/H
|
NEG zonalN points de terminaisonH opérationnels
|
max-rate-per-endpoint=X
|
X × N
|
(X × N)/H
|
Groupes d'instances (à l'exception des groupes d'instances gérés régionaux) H instances opérationnelles
|
max-rate=Y
|
Y
|
Y/H
|
Comme indiqué, les paramètres max-rate-per-instance
et max-rate-per-endpoint
sont des proxys permettant de calculer un taux maximal cible de requêtes HTTP pour l'ensemble du groupe d'instances ou du NEG zonal :
- Dans un groupe d'instances avec
N
instances, la définition demax-rate-per-instance=X
a la même signification que la définition demax-rate=X × N
. - Dans un NEG zonal avec
N
points de terminaison, la définition demax-rate-per-endpoint=X
a la même signification que la définition demax-rate=X × N
.
Mode d'équilibrage de l'utilisation
Le mode d'équilibrage UTILIZATION
n'a pas de capacité cible obligatoire. Vous disposez d'un certain nombre d'options qui dépendent du type de backend, comme résumé dans le tableau de la section suivante.
La capacité cible max-utilization
ne peut être spécifiée que par groupe d'instances et ne peut pas être appliquée à une VM spécifique du groupe.
Le mode d'équilibrage UTILIZATION
n'a pas de capacité cible obligatoire. Lorsque vous utilisez Google Cloud Console pour ajouter un groupe d'instances backend à un service de backend, Google Cloud Console définit la valeur de max-utilization
sur 0,8 (80 %) si le mode d'équilibrage UTILIZATION
est sélectionné. En plus de max-utilization
, le mode d'équilibrage UTILIZATION
accepte des capacités cibles plus complexes, comme résumé dans le tableau de la section suivante.
Modes d'équilibrage compatibles et paramètres de capacité cible
Ce tableau récapitule tous les modes d'équilibrage possibles pour un équilibreur de charge et un type de backend donnés. Il présente également les paramètres de capacité disponibles ou obligatoires que vous devez spécifier avec le mode d'équilibrage.
Équilibreur de charge | Type de backend | Mode d'équilibrage | Capacité cible |
---|---|---|---|
|
Groupe d'instances | RATE |
Vous devez spécifier l'une des valeurs suivantes :
|
UTILIZATION |
Vous pouvez éventuellement spécifier l'un des éléments suivants :
|
||
NEG zonal (GCP_VM_IP_PORT ) |
RATE |
Vous devez spécifier l'une des valeurs suivantes :
|
|
Équilibreur de charge TCP/UDP interne | Groupe d'instances | CONNECTION |
Vous ne pouvez pas spécifier de nombre maximal cible de connexions. |
NEG zonaux (GCP_VM_IP ) |
CONNECTION |
Vous ne pouvez pas spécifier de nombre maximal cible de connexions. | |
Équilibreur de charge réseau TCP/UDP externe | Groupe d'instances | CONNECTION |
Vous ne pouvez pas spécifier de nombre maximal cible de connexions. |
|
Groupe d'instances | CONNECTION |
Vous devez spécifier l'une des valeurs suivantes :
|
UTILIZATION |
Vous pouvez éventuellement spécifier l'un des éléments suivants :
|
||
NEG zonal (GCP_VM_IP_PORT ) |
CONNECTION |
Vous devez spécifier l'une des valeurs suivantes :
|
Scaler de capacité
Vous pouvez éventuellement ajuster le scaler de capacité de façon à réduire la capacité cible (utilisation maximale, taux maximal ou connexions maximales) sans la modifier. Le scaler de capacité est compatible avec tous les équilibreurs de charge qui acceptent une capacité cible. Les seules exceptions sont l'équilibreur de charge réseau et l'équilibreur de charge TCP/UDP interne.
Par défaut, la valeur du scaler de capacité est 1.0
(100 %). Vous pouvez définir le scaler de capacité sur l'une des valeurs suivantes :
- exactement
0.0
, ce qui empêche toute nouvelle connexion - une valeur comprise entre
0.1
(10 %) et1.0
(100 %)
Les exemples suivants montrent comment fonctionne le scaler de capacité en conformité avec le paramètre de capacité cible.
Si le mode d'équilibrage est
RATE
, le taux maximal est défini sur 80 RPS et le scaler de capacité est1.0
, la capacité cible effective est également de 80 RPS.Si le mode d'équilibrage est
RATE
, l'utilisation maximale est définie sur 80 RPS et le scaler de capacité est0.5
, la capacité cible effective est de 40 RPS (0.5 times 80
).Si le mode d'équilibrage est
RATE
, l'utilisation maximale est définie sur 80 RPS et le scaler de capacité est0.0
, la capacité cible effective est de zéro. Un scaler de capacité égal à zéro mettra le backend hors service.
Trafic Director et distribution du trafic
Traffic Director utilise également les ressources de services de backend. Plus précisément, il exploite 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 en fonction du mode d'équilibrage du backend. Ensuite, Traffic Director répartit le trafic en fonction d'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 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.
Sous-paramètre du backend
Le sous-paramètre de backend est une fonctionnalité facultative qui améliore les performances et l'évolutivité en attribuant un sous-ensemble de backends à chacune des instances de proxy.
Le sous-paramètre de backend est compatible avec les éléments suivants :
- Équilibrage de charge HTTP(S) interne
- Équilibrage de charge TCP/UDP interne
Sous-paramètre de backend pour l'équilibreur de charge HTTP(S) interne
Pour les équilibreurs de charge HTTP(S) internes, le sous-paramètre de backend n'attribue automatiquement qu'un sous-paramètre de backends du service de backend régional à chaque instance de proxy.
Par défaut, chaque instance de proxy de l'équilibreur de charge HTTP(S) interne ouvre des connexions à tous les backends d'un service. Lorsque le nombre d'instances de proxy et de backends sont des connexions de grande ouverture à tous les backends, des problèmes de performances peuvent survenir. En activant le sous-paramètre, chaque proxy ouvre uniquement les connexions à un sous-ensemble des backends, ce qui réduit le nombre de connexions qui restent ouvertes à chaque backend. La réduction du nombre de connexions ouvertes simultanément pour chaque backend peut améliorer les performances des backends et des proxys.
Le schéma suivant montre un équilibreur de charge avec deux proxys. Sans sous-paramètre de backend, le trafic des deux proxys est distribué à tous les backends du service de backend 1. Si le sous-paramètre de backend est activé, le trafic de chaque proxy est distribué à un sous-ensemble de backends. Le trafic du proxy 1 est distribué aux backends 1 et 2, et le trafic du proxy 2 est distribué aux backends 3 et 4.
Vous pouvez également affiner le trafic d'équilibrage de charge vers les backends en définissant la règle localityLbPolicy
.
Pour en savoir plus, consultez la section Règles de trafic.
Pour en savoir plus sur la configuration du sous-paramètre du backend pour les équilibreurs de charge HTTP(S) internes, consultez la page Configurer le sous-paramètre du backend.
Mises en garde liées au sous-paramètre du backend pour l'équilibreur de charge HTTP(S) interne
- Bien que le sous-paramètre de backend soit conçu pour garantir que toutes les instances backend restent bien utilisées, il peut introduire un biais dans la quantité de trafic que chaque backend reçoit. Il est recommandé de définir
localityLbPolicy
surLEAST_REQUEST
pour les services de backend sensibles à l'équilibrage de la charge de backend. - L'activation, puis la désactivation du sous-paramètre entraîne l'interruption des connexions existantes.
- Le sous-paramètre de backend nécessite que l'affinité de session soit
NONE
(hachage à cinq tuples). D'autres options d'affinité de session ne peuvent être utilisées que si le sous-paramètre de backend est désactivé. Les valeurs par défaut des options--subsetting-policy
et--session-affinity
sont toutes deuxNONE
, et une seule d'entre elles peut être définie sur une valeur différente.
Sous-paramètre de backend pour l'équilibreur de charge TCP/UDP interne
Le sous-paramètre de backend des équilibreurs de charge TCP/UDP internes vous permet de faire évoluer votre équilibreur de charge TCP/UDP interne de façon à accepter un plus grand nombre d'instances de VM de backend par service de backend interne.
Pour en savoir plus sur la façon dont le sous-paramètre affecte cette limite, consultez la section Services de backend de la page "Quotas et limites des ressources d'équilibrage de charge".
Par défaut, le sous-paramètre est désactivé, ce qui limite le service de backend à distribuer jusqu'à 250 instances backend ou points de terminaison. Si votre service de backend doit accepter plus de 250 backends, vous pouvez activer le sous-paramètre. Lorsque le sous-paramètre est activé, un sous-ensemble d'instances backend est sélectionné pour chaque connexion client.
Le schéma suivant illustre un modèle de réduction de la capacité qui montre la différence entre ces deux modes de fonctionnement.
Sans sous-paramètre, l'ensemble complet de backends opérationnels est mieux utilisé et les nouvelles connexions clientes sont distribués entre tous les backends opérationnels selon la répartition du trafic. Le sous-paramètre impose des restrictions d'équilibrage de charge, mais autorise l'équilibreur de charge à accepter plus de 250 backends.
Pour obtenir des instructions de configuration, consultez la section Sous-paramètre.
Mises en garde liées au sous-paramètre du backend pour l'équilibreur de charge TCP/UDP interne
- Lorsque le sous-paramètre est activé, tous les backends ne reçoivent pas le trafic d'un expéditeur donné, même si le nombre de backends est faible.
- Pour connaître le nombre maximal d'instances backend lorsque le sous-paramètre est activé, consultez la page Quotas.
- Seule l'affinité de session à cinq tuples est compatible avec le sous-paramètre.
- La mise en miroir de paquets n'est pas compatible avec le sous-paramètre.
- L'activation, puis la désactivation du sous-paramètre entraîne l'interruption des connexions existantes.
- Si les clients sur site doivent accéder à un équilibreur de charge TCP/UDP interne, le sous-paramètre peut considérablement réduire le nombre de backends recevant des connexions à partir de vos clients sur site. En effet, la région du tunnel Cloud VPN ou du rattachement de VLAN Cloud Interconnect détermine le sous-ensemble des backends de l'équilibreur de charge. Tous les points de terminaison Cloud VPN et Cloud Interconnect d'une région spécifique utilisent le même sous-ensemble. Différents sous-ensembles sont utilisés dans différentes régions.
Tarifs des sous-paramètres de backend
L'utilisation du sous-paramètre de backend est gratuite. Pour plus d'informations, consultez la page Tous les tarifs de mise en réseau.
Affinité de session
Certaines applications nécessitent que plusieurs requêtes provenant d'un utilisateur donné soit dirigées vers le même backend ou point de terminaison. Ces applications incluent des serveurs avec état utilisés pour la diffusion d'annonces, les jeux ou les services avec une forte mise en cache interne. L'inconvénient de l'affinité de session est que votre charge peut être moins bien distribuée.
L'affinité de session fonctionne de la façon la plus optimale possible pour fournir des requêtes au même backend qui a diffusé la requête initiale. Par défaut, l'affinité de session est désactivée (--session-affinity=NONE
). Si l'affinité de session n'est pas activée, les équilibreurs de charge distribuent les nouvelles requêtes en fonction d'un hachage à cinq tuples, comme suit :
- Adresse IP source du paquet
- Port source du paquet (s'il est présent dans l'en-tête du paquet)
- Adresse IP de destination du paquet
- Port de destination du paquet (s'il est présent dans l'en-tête du paquet)
- Protocole du paquet
Pour les équilibreurs de charge directs, si une instance ou un point de terminaison backend est opérationnel, les requêtes suivantes sont envoyées à la même VM ou au même point de terminaison backend.
Pour les équilibreurs de charge basés sur un proxy, si une instance ou un point de terminaison backend est opérationnel et n'est pas au maximum de sa capacité, les requêtes suivantes sont dirigées vers la même VM ou le même point de terminaison backend. Le mode d'équilibrage détermine quand le backend est au maximum de sa capacité.
Le tableau suivant présente les options d'affinité de session :
Produit | Options d'affinité de session |
---|---|
Les paramètres d'affinité de session ne sont appliqués que si la règle d'équilibrage de charge de localité (
Pour les équilibreurs de charge HTTP(S) externes globaux, ne configurez pas l'affinité de session si vous utilisez la répartition du trafic pondérée. Sinon, la configuration de la répartition du trafic pondérée est prioritaire. |
|
Équilibreur de charge HTTP(S) externe global (classique) |
|
Équilibreur de charge HTTP(S) interne |
Les paramètres d'affinité de session ne sont appliqués que si la règle d'équilibrage de charge de localité (
|
Équilibreur de charge TCP/UDP interne |
|
Équilibreur de charge réseau1 |
|
|
|
Traffic Director |
|
1 Ce tableau répertorie les options d'affinité de session compatibles avec les équilibreurs de charge réseau basés sur un service de backend.
Les équilibreurs de charge réseau basés sur un pool cible n'utilisent pas de services de backend. Vous définissez plutôt l'affinité de session pour les équilibreurs de charge réseau via le paramètre sessionAffinity
dans les pools cibles.
Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :
Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session 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 de la vérification d'état 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'équilibrageUTILIZATION
n'est pas recommandée. En effet, les changements d'utilisation de l'instance peuvent amener le service d'équilibrage de charge à diriger les nouvelles requêtes ou connexions vers des VM backend moins utilisées. Cette action rompt l'affinité de session. Utilisez plutôt le mode d'équilibrageRATE
ouCONNECTION
afin de réduire les risques de rupture de l'affinité de session.Lorsque l'affinité de session est activée pour les équilibreurs de charge, ceux-ci s'équilibrent bien dès lors qu'il existe une répartition relativement importante de sessions uniques. Le terme relativement importante désigne au moins plusieurs fois le nombre d'instances backend dans le groupe d'instances. Lorsque vous testez un équilibreur de charge avec un petit nombre de sessions, le trafic n'est pas réparti de manière uniforme.
Pour les équilibreurs de charge HTTP(S) externes et internes, l'affinité de session peut être interrompue lorsque le point de terminaison ou l'instance dépasse la limite maximale de son mode d'équilibrage. Prenons l'exemple suivant :
- Un équilibreur de charge dispose d'un NEG et de trois points de terminaison.
- Chaque point de terminaison a une capacité cible de 1 RPS.
- Le mode d'équilibrage est
RATE
. - Actuellement, chaque point de terminaison traite respectivement 1,1, 0,8 et 1,6 RPS.
- Lorsqu'une requête HTTP avec affinité pour le dernier point de terminaison arrive sur l'équilibreur de charge, l'affinité de session revendique le point de terminaison qui traite à 1,6 RPS.
- La nouvelle requête peut être dirigée vers le point de terminaison du milieu avec 0,8 RPS.
Pour plus d'informations sur l'équilibrage de charge réseau et l'affinité de session, consultez la page Présentation de l'équilibrage de charge réseau TCP/UDP externe.
Pour plus d'informations sur l'équilibrage de charge TCP/UDP interne et l'affinité de session, consultez la page Présentation de l'équilibrage de charge TCP/UDP interne.
Lorsque les services gRPC sans proxy sont configurés, Traffic Director n'est pas compatible avec l'affinité de session.
Les valeurs par défaut des options
--session-affinity
et--subsetting-policy
sontNONE
, et une seule d'entre elles peut être définie sur une valeur différente.
Les sections suivantes décrivent les différents types d'affinité de session.
Affinité basée sur les adresses IP client, aucune destination
L'affinité basée sur les adresses IP client, aucune destination dirige les requêtes en provenance de la même adresse IP source du client vers la même instance backend. L'affinité basée sur les adresses IP client, aucune destination est une option pour les équilibreurs de charge TCP/UDP internes.
Lorsque vous utilisez l'affinité basée sur les adresses IP client, aucune destination, gardez à l'esprit les points suivants :
L'affinité basée sur les adresses IP client, aucune destination est un hachage à un tuple composé de l'adresse IP source du client.
Si un client passe d'un réseau à un autre, son adresse IP change, ce qui entraîne une rupture d'affinité.
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 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é basée sur les adresses 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é.
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 les mêmes VM ou points de terminaison backend.
- Pour les équilibreurs de charge HTTP(S) externes globaux, ce cookie est nommé
GCLB
. - Pour les équilibreurs de charge HTTP(S) externes régionaux, 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 les adresses IP 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 les adresses IP 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, 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. Par exemple, lorsqu'un client change son adresse IP dans le cas d'un appareil mobile passant d'un réseau à un autre.
Lorsqu'un équilibreur de charge crée un cookie pour l'affinité basée sur les cookies générés, il définit l'attribut path
du cookie sur /
. Si l'outil de mise en correspondance des chemins d'accès du mappage d'URL comporte plusieurs services de backend pour un nom d'hôte, tous les services de backend partagent le 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.
Les produits suivants peuvent utiliser l'affinité basée sur les cookies générés :
- Équilibreur de charge HTTP(S) externe global*
- Équilibreur de charge HTTP(S) externe global (classique)
- Équilibreur de charge HTTP(S) externe régional*
- Équilibreur de charge HTTP(S) interne
- Traffic Director
LocalityLbPolicy
) est définie sur RING_HASH
ou MAGLEV
.
Affinité basée sur le champ d'en-tête
Traffic Director et un équilibreur de charge HTTP(S) interne peuvent utiliser l'affinité basée sur le champ d'en-tête lorsque les deux conditions suivantes sont remplies :
- La règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV.
- La valeur
consistentHash
du service de backend spécifie le nom de l'en-tête HTTP (httpHeaderName
).
Les produits suivants peuvent utiliser l'affinité de champ d'en-tête :
- Équilibreur de charge HTTP(S) externe global*
- Équilibreur de charge HTTP(S) externe régional*
- Équilibreur de charge HTTP(S) interne
- Traffic Director
LocalityLbPolicy
) est définie sur RING_HASH
ou MAGLEV
.
Affinité basée sur les cookies HTTP
Traffic Director et un équilibreur de charge HTTP(S) interne peuvent utiliser l'affinité basée sur les cookies HTTP lorsque les deux conditions suivantes sont remplies :
- La règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV.
- 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 VM ou points de terminaison backend d'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
.
Les produits suivants peuvent utiliser l'affinité basée sur les cookies HTTP :
- Équilibreur de charge HTTP(S) externe global*
- Équilibreur de charge HTTP(S) externe régional*
- Équilibreur de charge HTTP(S) interne
- Traffic Director
LocalityLbPolicy
) est définie sur RING_HASH
ou MAGLEV
.
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 NEG zonal ou le groupe d'instances backend 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 NEG zonal ou groupe d'instances backend, 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 VM ou un point de terminaison backend d'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 en savoir plus sur le comportement de l'équilibreur lorsque tous ses backends échouent aux vérifications de l'état.
- Lorsque le mode d'équilibrage
UTILIZATION
est activé pour les groupes d'instances 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'équilibrageRATE
ouCONNECTION
, 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. Cela peut rompre l'affinité de 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 vers le mode d'équilibrageRATE
ouCONNECTION
, en fonction de l'équilibreur de charge que vous avez choisi.
Délai avant expiration du service de backend
La plupart des équilibreurs de charge Google Cloud disposent d'un délai avant expiration de service de backend. La valeur par défaut est de 30 secondes. La plage complète des valeurs de délai avant expiration autorisées est de 1 à 2 147 483 647 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 avant expiration du 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 relance 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 que la requête envoyée au backend n'est pas une requête HTTP GET, l'équilibreur de charge ne la relance pas. Si le backend ne répond pas du tout, l'équilibreur de charge renvoie une réponse HTTP
5xx
au client. Pour modifier le délai alloué aux backends pour qu'ils répondent aux requêtes, modifiez le délai d'expiration.Pour le trafic HTTP, la durée maximale pour que le client termine d'envoyer sa requête est égale au délai avant expiration du service de backend. Si des réponses HTTP
408
avecjsonPayload.statusDetail
client_timed_out
apparaissent, cela signifie que la progression était insuffisante lors de l'envoi par proxy de la requête du client ou de la réponse du backend. Si le problème est dû à des clients rencontrant des problèmes de performances, vous pouvez résoudre ce problème en augmentant le délai avant expiration du service de backend.Si la connexion HTTP est mise à niveau vers un WebSocket, le délai avant 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 plus de détails sur le délai avant expiration du service de backend pour chaque équilibreur de charge, consultez les sections suivantes :
- Pour les équilibreurs de charge HTTP(S) externes globaux et les équilibreurs de charge HTTP(S) externes régionaux, consultez la section Délais d'expiration et nouvelles tentatives.
- Pour les équilibreurs de charge HTTP(S) internes, consultez la section Délais d'expiration et nouvelles tentatives.
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 accorder plus ou moins de temps avant la suppression de la connexion, modifiez le délai d'expiration. Ce délai d'inactivité est également utilisé pour les connexions WebSocket.
Pour les équilibreurs de charge TCP/UDP internes et les équilibreurs de charge réseau, vous pouvez définir la valeur du délai avant expiration du service de backend à l'aide de
gcloud
ou de l'API, mais la valeur est ignorée. Le délai avant expiration du service de backend n'a aucune signification pour ces équilibreurs de charge directs.Pour Traffic Director, le champ de délai avant expiration du service de backend (spécifié à l'aide de
timeoutSec
) n'est pas disponible avec les services gRPC sans proxy. Pour ces services, configurez le délai avant expiration du service de backend à l'aide du champmaxStreamDuration
. En effet, gRPC n'est pas compatible avec la sémantique detimeoutSec
qui spécifie le délai d'attente nécessaire au renvoi d'une réponse complète par le backend une fois la requête envoyée. Le délai avant expiration de gRPC spécifie le délai d'attente entre le début du flux et la fin du traitement de la réponse, y compris toutes les tentatives.
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 qui utilisent un NEG sans serveur ou un NEG Internet en tant que backend ne doivent pas 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 Google Cloud CLI ou de l'API, vous devez référencer une vérification d'état existante. Reportez-vous au guide sur les équilibreurs de charge de la page Présentation des vérifications d'état pour en savoir plus sur le type et le champ d'application requis pour la vérification d'état.
Pour en savoir plus, consultez les documents suivants :
- Présentation des vérifications d'état
- Créer des vérifications d'état
- Vérification de l'état de
gcloud
- Vérification de l'état de l'API REST
Fonctionnalités supplémentaires activées sur la ressource du service de backend
Certaines fonctionnalités facultatives de Google Cloud (telles que Cloud CDN et Google Cloud Armor) sont disponibles pour les services de backend utilisés par des équilibreurs de charge HTTP(S) externes globaux. Google Cloud Armor est également compatible avec les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP.
Pour en savoir plus, consultez :
- Présentation de l'équilibrage de charge HTTP(S)
- Cloud CDN
- Présentation des stratégies de sécurité Google Cloud Armor
Fonctionnalités de gestion du trafic
Les fonctionnalités suivantes ne sont disponibles que pour certains produits :
- Règles d'équilibrage de charge
(
localityLbPolicy
) à l'exception de ROUND_ROBIN. - Ruptures de circuit, à l'exception du champ
maxRequests
- Détection des anomalies
Ces fonctionnalités sont compatibles avec les équilibreurs de charge suivants :
- Équilibreur de charge HTTP(S) externe global (la rupture de circuit n'est pas compatible)
- Équilibreur de charge HTTP(S) externe régional
- Équilibreur de charge HTTP(S) interne
- Traffic Director (mais pas compatible avec les services gRPC sans proxy)
É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 :
- Créer des en-têtes personnalisés
- Créer un équilibreur de charge HTTP(S)
- Informations conceptuelles sur l'équilibrage de charge HTTP(S)
- Activer le drainage de connexion
- Chiffrement en transit dans Google Cloud