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. Pour vous aider à démarrer, la plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration. Un service de backend a un champ d'application global ourégional.

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
• Désignez les services de backend globaux et régionaux comme services dans les applications App Hub.

Vous définissez ces valeurs lorsque vous créez un service de backend ou ajoutez un backend au service de backend.

Remarque : Si vous utilisez l'équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique, et que vos backends diffusent du contenu statique, envisagez d'utiliser des buckets backend au lieu de services de backend. Consultez Buckets backend pour l'équilibreur de charge d'application externe mondial ou Buckets backend pour l'équilibreur de charge d'application classique.

Le tableau suivant récapitule les équilibreurs de charge qui utilisent des 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. Le schéma d'équilibrage de charge est un identifiant que Google utilise pour classer les règles de transfert et les services de backend. Chaque produit d'équilibrage de charge utilise un schéma d'équilibrage de charge pour ses règles de transfert et ses services de backend. Certains schémas sont partagés entre les produits.

Tableau : Services de backend et types de backends compatibles

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 d'application externe global	Plusieurs	Monde	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† Tous les NEG sans serveur : une ou plusieurs ressources App Engine, Cloud Run ou Cloud Run Functions Un NEG Internet global pour un backend externe NEG Private Service Connect : API Google : un seul NEG Private Service Connect Services gérés : un ou plusieurs NEG Private Service Connect	EXTERNAL_MANAGED
Équilibreur de charge d'application classique	Plusieurs	Monde^‡	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† Tous les NEG sans serveur : une ou plusieurs ressources App Engine, Cloud Run ou Cloud Run Functions, ou Un NEG Internet global pour un backend externe	EXTERNAL^#
Équilibreur de charge d'application externe régional	Plusieurs	Régional	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† Un seul NEG sans serveur (pour Cloud Run ou Cloud Run Functions 2e génération uniquement) Un seul NEG Private Service Connect Tous les NEG Internet régionaux pour un backend externe	EXTERNAL_MANAGED
Équilibreur de charge d'application interne interrégional	Plusieurs	Monde	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† Un seul NEG sans serveur (pour Cloud Run ou Cloud Run Functions 2e génération uniquement) NEG Private Service Connect : API Google : un seul NEG Private Service Connect Services gérés : un ou plusieurs NEG Private Service Connect	INTERNAL_MANAGED
Équilibreur de charge d'application interne régional	Plusieurs	Régional	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† Un seul NEG sans serveur (pour Cloud Run ou Cloud Run Functions 2e génération uniquement) Un seul NEG Private Service Connect Tous les NEG Internet régionaux pour un backend externe	INTERNAL_MANAGED
Équilibreur de charge réseau proxy externe global	1	Monde^‡	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^† NEG Private Service Connect : API Google : un seul NEG Private Service Connect Services gérés : un ou plusieurs NEG Private Service Connect	EXTERNAL_MANAGED
Équilibreur de charge réseau proxy classique	1	Monde^‡	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT^†	EXTERNAL
Équilibreur de charge réseau proxy externe régional	1	Régionales	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT Tous les NEG Internet régionaux pour un backend externe Un seul NEG Private Service Connect	EXTERNAL_MANAGED
Équilibreur de charge réseau proxy interne régional	1	Régionales	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT Tous les NEG Internet régionaux pour un backend externe Un seul NEG Private Service Connect	INTERNAL_MANAGED
Équilibreur de charge réseau proxy interne interrégional	Plusieurs	Monde	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés ^* Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT^* Tous les NEG de connectivité hybride : un ou plusieurs NEG de type NON_GCP_PRIVATE_IP_PORT Une combinaison de NEG zonaux et hybrides : NEG de type GCE_VM_IP_PORT et NON_GCP_PRIVATE_IP_PORT NEG Private Service Connect : API Google : un seul NEG Private Service Connect Services gérés : un ou plusieurs NEG Private Service Connect	INTERNAL_MANAGED
Équilibreur de charge réseau passthrough externe	1	Régionales	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP	EXTERNAL
Équilibreur de charge réseau passthrough interne	1	Régional, mais configurable pour être accessible à l'échelle mondiale	Le service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP Un NEG de mappage de port	INTERNAL
Cloud Service Mesh	Plusieurs	Monde	Chaque service de backend accepte l'une des combinaisons de backend suivantes  : Tous les backends de groupe d'instances : un ou plusieurs backends de groupes d'instances gérés ou non, ou une combinaison de backends de groupes d'instances gérés et non gérés Tous les NEG zonaux : un ou plusieurs NEG zonaux de type GCE_VM_IP_PORT ou NON_GCP_PRIVATE_IP_PORT Un NEG Internet de type INTERNET_FQDN_PORT Une ou plusieurs liaisons de service	INTERNAL_SELF_MANAGED

^* Compatible avec les groupes d'instances et les backends NEG zonaux IPv4 et IPv6 (double pile). Les NEG zonaux sont compatibles avec la double pile uniquement sur les points de terminaison de type GCE_VM_IP_PORT.

^† Pour les déploiements GKE, les backends NEG mixtes ne sont compatibles qu'avec les NEG autonomes.

^‡ Les services de backend utilisés par les équilibreurs de charge d'application classiques et les équilibreurs de charge réseau proxy classiques ont toujours un champ d'application global, qu'ils soient du niveau de réseau Standard ou Premium. Cependant, les restrictions suivantes s'appliquent au niveau Standard :

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

^# Il est possible d'associer des services de backend EXTERNAL_MANAGED à des règles de transfert EXTERNAL. Toutefois, les services de backend EXTERNAL ne peuvent pas être associés à des règles de transfert EXTERNAL_MANAGED. Pour profiter des nouvelles fonctionnalités disponibles uniquement avec l'équilibreur de charge d'application externe mondial, nous vous recommandons de migrer vos ressources EXTERNAL existantes vers EXTERNAL_MANAGED à l'aide de la procédure de migration décrite dans Migrer des ressources de l'équilibreur de charge d'application classique vers l'équilibreur de charge d'application externe mondial.

Nommer les équilibreurs de charge

Pour les équilibreurs de charge réseau proxy et les équilibreurs de charge réseau passthrough, le nom de l'équilibreur de charge est toujours le même que celui du service de backend. Le comportement de chaque interface Google Cloud est le suivant :

• Google Cloud console. Si vous créez un équilibreur de charge réseau proxy ou un équilibreur de charge réseau passthrough à l'aide de la console Google Cloud , le service de backend reçoit automatiquement le même nom que celui que vous avez saisi pour l'équilibreur de charge.
• Google Cloud CLI ou API. Si vous créez un équilibreur de charge réseau proxy ou un équilibreur de charge réseau direct à l'aide de gcloud CLI ou de l'API, vous saisissez le nom de votre choix lors de la création du service de backend. Le nom de ce service de backend est ensuite reflété dans la console Google Cloud en tant que nom de l'équilibreur de charge.

Pour en savoir plus sur la façon dont les équilibreurs de charge d'application sont nommés, consultez Présentation des mappages d'URL : nommage des équilibreurs de charge.

Backends

Un backend correspond à un ou plusieurs points de terminaison qui reçoivent le trafic d'un Google Cloudéquilibreur de charge, d'un proxy Envoy configuré par Cloud Service Mesh 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é (MIG), avec ou sans autoscaling, ou il peut s'agir d'un groupe d'instances non géré. Plusieurs service 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 des modes d'équilibrage compatibles. Pour en savoir plus, consultez Restrictions et conseils pour les groupes d'instances dans ce document.
• NEG zonal
• NEG sans serveur
• NEG Private Service Connect
• NEG Internet
• NEG de connectivité hybride
• NEG de mappage de port
• Liaisons de services de l'Annuaire des services

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.

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 d'application externes globaux et les équilibreurs de charge réseau proxy externes : les clients communiquent avec un GFE (Google Front End) qui héberge l'adresse IP externe de votre équilibreur de charge. Les GFE communiquent avec les VM ou points de terminaison de backend en envoyant des paquets à une adresse interne créée en joignant un identifiant pour le réseau VPC du backend à l'adresse IPv4 interne 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 backends de groupe d'instances, l'adresse IPv4 interne est toujours l'adresse IPv4 interne principale qui correspond à l'interface nic0 de la VM.
  • Pour les points de terminaison GCE_VM_IP_PORT d'un NEG zonal, vous pouvez spécifier l'adresse IP du point de terminaison comme adresse IPv4 principale associée à l'interface réseau d'une VM, ou toute adresse IPv4 d'une plage d'adresses IP d'alias associée à n'importe quelle interface réseau d'une VM.

• Pour les équilibreurs de charge d'application externes régionaux : les clients communiquent avec un proxy Envoy qui héberge l'adresse IP externe de votre équilibreur de charge. Les proxys Envoy communiquent avec les VM ou points de terminaison de backend en envoyant des paquets à une adresse interne créée en joignant un identifiant pour le réseau VPC du backend avec l'adresse IPv4 interne du backend.

  • Pour les backends de groupe d'instances, l'adresse IPv4 interne est toujours l'adresse IPv4 interne principale correspondant à l'interface nic0 de la VM, et nic0 doit se trouver dans le même réseau que l'équilibreur de charge.
  • Pour les points de terminaison GCE_VM_IP_PORT d'un NEG zonal, vous pouvez spécifier l'adresse IP du point de terminaison comme adresse IPv4 principale associée à l'interface réseau d'une VM, ou toute adresse IPv4 d'une plage d'adresses IP d'alias associée à n'importe quelle interface réseau d'une VM., à condition que l'interface réseau et l'équilibreur de charge se trouvent sur le même réseau.

• Pour les équilibreurs de charge réseau passthrough externes, les clients communiquent directement avec les backends via l'infrastructure d'équilibrage de charge passthrough Maglev de Google. Les paquets sont acheminés et transmis aux backends avec les adresses IP source et de destination d'origine conservées. Les backends répondent aux clients à l'aide du retour direct du serveur. Les méthodes utilisées pour sélectionner un backend et pour suivre les connexions sont configurables.

  • Pour les backends de groupe d'instances, les paquets sont toujours transmis à l'interface nic0 de la VM.
  • Pour les points de terminaison GCE_VM_IP d'un NEG zonal, les paquets sont distribués à l'interface réseau de la VM qui se trouve dans le sous-réseau associé au NEG.

Ports nommés

L'attribut port nommé du service de backend ne s'applique qu'aux équilibreurs de charge basés sur un proxy (équilibreurs de charge d'application et équilibreurs de charge réseau proxy) utilisant des backends de groupe d'instances. Le port nommé définit le port de destination utilisé pour la connexion TCP entre le proxy (GFE ou Envoy) et l'instance de backend.

Les ports nommés sont configurés comme suit :

• Sur chaque backend de groupe d'instances, vous devez configurer un ou plusieurs ports nommés à l'aide de paires clé/valeur. La clé représente un nom de port descriptif que vous choisissez et la valeur représente le numéro de port que vous attribuez au nom. Le mappage des noms à des numéros est effectué individuellement pour chaque backend de groupe d'instances.

• Sur le service de backend, vous spécifiez un seul port nommé en utilisant uniquement le nom de port (--port-name).

Sur la base d'un backend de groupe d'instances, le service de backend traduit le nom du port en numéro de port. Lorsque le port nommé d'un groupe d'instances correspond au --port-name du service de backend, le service de backend utilise ce numéro de port pour communiquer avec les VM du groupe d'instances.

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

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.

Le numéro de port résolu qu'utilise le service de backend de l'équilibreur de charge proxy 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 proxy écoute les connexions TCP envoyées à l'adresse IP et au port de destination de ses règles de transfert. Étant donné que le proxy ouvre une deuxième connexion TCP à ses backends, le port de destination de la deuxième connexion TCP peut être différent.

Les ports nommés ne s'appliquent qu'aux backends de groupes d'instances. Les NEG zonaux avec des points de terminaison GCE_VM_IP_PORT, les NEG hybrides avec des points de terminaison NON_GCP_PRIVATE_IP_PORT et les NEG Internet définissent des ports à l'aide d'un mécanisme différent, à savoir les points de terminaison eux-mêmes. Les NEG sans serveur référencent les services Google et les NEG PSC référencent les rattachements de service à l'aide d'abstractions qui n'impliquent pas de spécifier un port de destination.

Les équilibreurs de charge réseau passthrough internes et passthrough externes n'utilisent pas de ports nommés. En effet, il s'agit d'équilibreurs de charge passthrough qui acheminent directement les connexions vers les backends au lieu de créer de nouvelles connexions. Les paquets sont transmis aux backends préservant l'adresse IP de destination et le port de la règle de transfert de l'équilibreur de charge.

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

Restrictions et conseils concernant les groupes d'instances

Tenez compte des points suivants lorsque vous utilisez des backends de groupe d'instances :

• Une instance de VM ne peut appartenir qu'à un seul groupe d'instances à équilibrage de charge. Par exemple, une VM peut appartenir à deux groupes d'instances non gérés, ou à un groupe d'instances géré et à un groupe d'instances non géré. Lorsqu'une VM est membre de deux groupes d'instances ou plus, un seul de ces groupes peut être référencé par un ou plusieurs services de backend d'équilibreur de charge.

• Un même groupe d'instances peut être utilisé par plusieurs services de backend. Chaque mappage entre un groupe d'instances et un service de backend peut utiliser un mode d'équilibrage différent, à l'exception des combinaisons de modes d'équilibrage incompatibles.

  • Voici les combinaisons de modes d'équilibrage incompatibles :

    • Le mode d'équilibrage UTILIZATION est incompatible avec tous les autres modes d'équilibrage. Si un groupe d'instances est un backend de plusieurs services de backend, il doit utiliser le mode d'équilibrage UTILIZATION sur chaque service de backend.

    • Le mode d'équilibrage CUSTOM_METRICS est incompatible avec tous les autres modes d'équilibrage. Si un groupe d'instances est un backend de plusieurs services de backend, il doit utiliser le mode d'équilibrage CUSTOM_METRICS sur chaque service de backend.

  • En raison des combinaisons de modes d'équilibrage incompatibles, si un groupe d'instances utilise le mode d'équilibrage UTILIZATION ou CUSTOM_METRICS comme backend pour au moins un service de backend, le même groupe d'instances ne peut pas être utilisé comme backend pour un équilibreur de charge réseau passthrough, car les équilibreurs de charge réseau passthrough nécessitent le mode d'équilibrage CONNECTION.

• Il n'existe pas de commande unique permettant de modifier le mode d'équilibrage du même groupe d'instances sur plusieurs services de backend. Pour modifier le mode d'équilibrage d'un groupe d'instances qui est le backend de deux services de backend ou plus, vous pouvez utiliser la technique suivante :

  • Supprimez le groupe d'instances en tant que backend de tous les services de backend, sauf un.
  • Modifiez le mode d'équilibrage du groupe d'instances pour le service de backend restant.
  • Ajoutez à nouveau le groupe d'instances en tant que backend aux autres services de backend.

Voici quelques bonnes pratiques qui vous offrent des options plus flexibles :

• Évitez d'utiliser le même groupe d'instances comme backend pour plusieurs services de backend. Utilisez plutôt plusieurs NEG.

  • Contrairement aux groupes d'instances, une VM peut avoir un point de terminaison dans plusieurs NEG à équilibrage de charge.

  • Par exemple, si une VM doit simultanément être un backend d'un équilibreur de charge réseau passthrough et d'un équilibreur de charge réseau proxy ou d'un équilibreur de charge d'application, utilisez plusieurs NEG à équilibrage de charge. Placez un point de terminaison de VM dans un NEG unique compatible avec chaque type d'équilibreur de charge. Associez ensuite chaque NEG au service de backend d'équilibreur de charge correspondant.

• N'ajoutez pas de groupe d'instances géré avec autoscaling à plusieurs services de backend lorsque vous utilisez la métrique d'autoscaling Utilisation de l'équilibrage de charge HTTP. Deux services de backend ou plus référençant le même groupe d'instances géré avec autoscaling peuvent se contredire, sauf si la métrique d'autoscaling n'est pas liée à l'activité de l'équilibreur de charge.

Groupes zonaux de points de terminaison du réseau

Les points de terminaison du réseau représentent les services en fonction de leur adresse IP ou d'une combinaison adresse IP et de 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 NEG zonaux sont des ressources zonales qui représentent des collections d'adresses IP ou de combinaisons adresses IP/port pour les ressourcesGoogle Cloud faisant partie d'un même sous-réseau.

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.

Deux types de points de terminaison du réseau sont disponibles pour les NEG zonaux :

• Les points de terminaison GCE_VM_IP (compatibles uniquement avec les équilibreurs de charge réseau passthrough internes et les équilibreurs de charge réseau passthrough externes basés sur un service de backend).
• Les points de terminaison GCE_VM_IP_PORT

Pour connaître les produits compatibles avec les backends de NEG zonaux, consultez la page Tableau : services de backend et types de backends compatibles.

Pour en savoir plus, consultez la page Présentation des NEG zonaux.

Groupes de points de terminaison du réseau Internet

Les NEG Internet sont des ressources 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'un nom d'hôte ou d'une adresse IP, et d'un port facultatif. Deux types de points de terminaison du réseau sont disponibles pour les NEG Internet : INTERNET_FQDN_PORT et INTERNET_IP_PORT.

Les NEG Internet sont disponibles dans deux champs d'application : global et régional. Pour savoir quels produits sont compatibles avec les backends NEG Internet dans chaque champ d'application, consultez la page Tableau : services de backend et types de backends compatibles.

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 une ressource Cloud Run, App Engine, Cloud Run Functions ou API Gateway.

Un NEG sans serveur peut représenter l'un des éléments suivants :

• Une ressource Cloud Run ou un groupe de ressources.
• Une fonction ou un groupe de fonctions Cloud Run (anciennement Cloud Run Functions 2e génération).
• Une fonction Cloud Run Functions (1re génération) ou un groupe de fonctions
• Une application de l'environnement standard App Engine ou de l'environnement flexible App Engine, 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.

Important : Pour que les ressources d'un groupe de ressources soient placées dans le même NEG sans serveur, elles doivent disposer d'un format d'URL commun.

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 Run Functions ou App Engine correspondant (qui porte ce même nom).

Pour savoir quels équilibreurs de charge sont compatibles avec les backends NEG sans serveur, consultez la page Tableau : services de backend et types de backend compatibles.

Pour en savoir plus sur les NEG sans serveur, consultez la page 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 Cloud Service Mesh 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.

Backends mixtes

Les considérations d'utilisation suivantes s'appliquent lorsque vous ajoutez différents types de backends à un seul service de backend :

• Un seul service de backend ne peut pas utiliser simultanément des groupes d'instances et des 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 certains équilibreurs de charge proxy, 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 terminaison NON_GCP_PRIVATE_IP_PORT) pour configurer un équilibrage de charge hybride. Pour afficher les équilibreurs de charge dotés de cette fonctionnalité, consultez la page Tableau : Services de backend et types de backends compatibles.

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 Cloud Service Mesh.

Tableau : Protocole de communication avec les backends

Produit	Options de protocole du service de backend
Équilibreur de charge d'application	HTTP, HTTPS, HTTP/2
Équilibreur de charge réseau proxy	TCP ou SSL Les équilibreurs de charge réseau proxy régionaux ne sont compatibles qu'avec TCP.
Équilibreur de charge réseau passthrough	TCP, UDP, ou UNSPECIFIED
Cloud Service Mesh	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.

Règle de sélection des adresses IP

Ce champ s'applique aux équilibreurs de charge proxy. Vous devez utiliser la règle de sélection d'adresse IP pour spécifier le type de trafic envoyé depuis le service de backend vers vos backends.

Lorsque vous sélectionnez la règle de sélection d'adresse IP, assurez-vous que vos backends sont compatibles avec le type de trafic sélectionné. Pour en savoir plus, consultez le tableau : services de backend et types de backends compatibles.

La règle de sélection d'adresse IP est utilisée lorsque vous souhaitez convertir le service de backend de votre équilibreur de charge pour qu'il soit compatible avec un autre type de trafic. Pour en savoir plus, consultez Convertir des backends à pile unique en backends à double pile.

Vous pouvez spécifier les valeurs suivantes pour la règle de sélection des adresses IP :

Règle de sélection des adresses IP	Description
IPv4 uniquement	N'envoyez le trafic IPv4 qu'aux backends du service de backend, quel que soit le trafic entre le client et le GFE. Seules les vérifications de l'état IPv4 sont utilisées pour vérifier l'état des backends.
Préférer IPv6	Privilégiez la connexion IPv6 du backend à la connexion IPv4 (à condition qu'il existe un backend opérationnel avec des adresses IPv6). Les vérifications d'état surveillent régulièrement les connexions IPv6 et IPv4 des backends. Le GFE tente d'abord de se connecter à IPv6. Si la connexion IPv6 est interrompue ou lente, le GFE utilise des visiteurs heureux pour se connecter à IPv4. Même si l'une des connexions IPv6 ou IPv4 n'est pas opérationnelle, le backend est toujours considéré comme opérationnel et le GFE peut tester les deux connexions, après quoi les visiteurs heureux choisissent celle à utiliser.
IPv6 uniquement	N'envoyez le trafic IPv6 qu'aux backends du service de backend, quel que soit le trafic entre le client et le proxy. Seules les vérifications de l'état IPv6 sont utilisées pour vérifier l'état des backends. Il n'y a aucune validation pour vérifier si le type de trafic de backend correspond à la règle de sélection d'adresse IP. Par exemple, si vous avez des backends IPv4 uniquement et que vous sélectionnez Only IPv6 comme règle de sélection des adresses IP, la configuration entraîne des backends non opérationnels, car le trafic ne parvient pas à atteindre ces backends et le code de réponse HTTP 503 est renvoyé aux clients.

Chiffrement entre l'équilibreur de charge et les backends

Pour plus d'informations sur le chiffrement entre l'équilibreur de charge et les backends, consultez la page Chiffrement vers les backends.

Mode d'équilibrage, capacité cible et scaler de capacité

Pour les équilibreurs de charge d'application, Cloud Service Mesh et les équilibreurs de charge réseau proxy, le mode d'équilibrage, la capacité cible et le facteur de capacité sont des paramètres que vous fournissez lorsque vous ajoutez un backend compatible à un service de backend. Les équilibreurs de charge utilisent ces paramètres pour gérer la distribution des nouvelles requêtes ou connexions vers les zones contenant des backends compatibles :

• Le mode d'équilibrage définit la manière dont l'équilibreur de charge mesure la capacité. Google Cloud dispose des modes d'équilibrage suivants :
  • CONNECTION : définit la capacité en fonction du nombre de nouvelles connexions TCP.
  • RATE : définit la capacité en fonction du taux de nouvelles requêtes HTTP.
  • IN-FLIGHT (Aperçu) : définit la capacité en fonction du nombre de requêtes HTTP en cours au lieu du taux de requêtes HTTP. Utilisez ce mode d'équilibrage au lieu de RATE si les requêtes mettent plus d'une seconde à s'exécuter.
  • UTILIZATION : définit la capacité en fonction de l'utilisation approximative du processeur des VM dans une zone d'un groupe d'instances.
  • CUSTOM_METRICS : définit la capacité en fonction des métriques personnalisées définies par l'utilisateur.
• La capacité cible définit le nombre de capacité cible.
  • La capacité cible n'est pas un disjoncteur.
  • Lorsque l'utilisation de la capacité atteint la capacité cible, l'équilibreur de charge redirige les nouvelles requêtes ou connexions vers une autre zone si les backends sont configurés dans au moins deux zones.
  • Les équilibreurs de charge d'application externes globaux, les équilibreurs de charge réseau proxy externes globaux, les équilibreurs de charge d'application internes interrégionaux et les équilibreurs de charge réseau proxy internes interrégionaux utilisent également la capacité pour diriger les requêtes vers des zones de différentes régions, si vous avez configuré des backends dans plusieurs régions.
  • Lorsque toutes les zones ont atteint la capacité cible, les nouvelles requêtes ou connexions sont réparties par surremplissage proportionnel.
• Le scaler de capacité permet de mettre à l'échelle la capacité cible manuellement. Voici les valeurs du scaler de capacité :
  • 0 : indique que le backend est complètement drainé. Vous ne pouvez pas utiliser la valeur 0 si un service de backend ne comporte qu'un seul backend.
  • 0.1 (10 %) – 1.0 (100 %) : indique le pourcentage de capacité du backend utilisé.

Les équilibreurs de charge réseau passthrough utilisent symboliquement le mode d'équilibrage CONNECTION, mais ne sont pas compatibles avec une capacité cible ni un scaler de capacité. Pour en savoir plus sur la façon dont les équilibreurs de charge réseau passthrough distribuent les nouvelles connexions, consultez les pages suivantes :

• Distribution du trafic pour les équilibreurs de charge réseau passthrough internes
• Distribution du trafic pour les équilibreurs de charge réseau passthrough externes

Backends compatibles

Pour les équilibreurs de charge d'application, Cloud Service Mesh et les équilibreurs de charge réseau proxy, les types de backends suivants sont compatibles avec les paramètres de mode d'équilibrage, de capacité cible et de facteur de capacité :

• Backends de groupes d'instances
• NEG zonaux avec des points de terminaison GCE_VM_IP_PORT
• NEG de connectivité hybride zonale

Les NEG Internet, les NEG sans serveur et les NEG Private Service Connect ne sont pas compatibles avec les paramètres de mode d'équilibrage, de capacité cible et de facteur de capacité.

Modes d'équilibrage pour les équilibreurs de charge d'application et Cloud Service Mesh

Les modes d'équilibrage disponibles pour les backends Application Load Balancer et Cloud Service Mesh dépendent du type de backend compatible et d'un paramètre de durée du trafic (aperçu).

Paramètre de durée du trafic

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour les backends Application Load Balancer et Cloud Service Mesh, vous pouvez éventuellement spécifier un paramètre de durée du trafic. Ce paramètre est propre au mappage entre un backend compatible et un service de backend. Le paramètre de durée du trafic a deux valeurs valides :

• SHORT : recommandé pour les requêtes HTTP auxquelles les backends répondent en moins d'une seconde. Si vous ne spécifiez pas explicitement de durée du trafic, l'équilibreur de charge fonctionne comme si vous aviez spécifié SHORT.
• LONG : recommandé pour les requêtes HTTP pour lesquelles le backend a besoin de plus d'une seconde pour générer des réponses.

Pour définir explicitement la durée du trafic lorsque vous ajoutez un backend à un service de backend, procédez comme suit :

• Exécutez la commande gcloud compute backend-services add-backend avec l'option --traffic-duration.
• Créez ou mettez à jour un service de backend avec l'attribut trafficDuration.

Modes d'équilibrage pour une courte durée du trafic

Lorsque le paramètre de durée du trafic n'est pas spécifié ou est défini sur SHORT(aperçu), les modes d'équilibrage disponibles pour les backends Application Load Balancer et Cloud Service Mesh dépendent du type de backend compatible.

Tableau : Modes d'équilibrage pour les backends d'équilibreur de charge d'application et de Cloud Service Mesh utilisant le paramètre de courte durée du trafic

Backend compatible	Mode d'équilibrage
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Groupes d'instances
NEG zonaux avec des points de terminaison GCE_VM_IP_PORT
NEG de connectivité hybride zonaux

Modes d'équilibrage pour les longues durées de trafic

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Lorsque le paramètre de durée du trafic est défini sur LONG, les modes d'équilibrage disponibles pour les backends Application Load Balancer et Cloud Service Mesh dépendent du type de backend compatible.

Tableau : Modes d'équilibrage pour les backends d'équilibreur de charge d'application et de Cloud Service Mesh utilisant le paramètre de longue durée du trafic

Backend compatible	Mode d'équilibrage
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Groupes d'instances
NEG zonaux avec des points de terminaison GCE_VM_IP_PORT
NEG de connectivité hybride zonaux

Modes d'équilibrage pour les équilibreurs de charge réseau proxy

Les modes d'équilibrage disponibles pour les backends d'équilibreur de charge réseau proxy dépendent du type de backend compatible.

Tableau : Modes d'équilibrage pour les équilibreurs de charge réseau proxy

Backend compatible	Mode d'équilibrage
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Groupes d'instances
NEG zonaux avec des points de terminaison GCE_VM_IP_PORT
NEG de connectivité hybride zonaux

Spécifications de la capacité cible

Les spécifications de capacité cible concernent les backends d'équilibreur de charge d'application, de Cloud Service Mesh et d'équilibreur de charge réseau proxy qui sont compatibles avec les paramètres mode d'équilibrage, capacité cible et scaler de capacité.

Les spécifications de capacité cible ne sont pas pertinentes pour les équilibreurs de charge réseau passthrough.

Mode d'équilibrage des connexions

Les backends d'équilibreur de charge réseau proxy peuvent utiliser le mode d'équilibrage CONNECTION avec l'un des paramètres de capacité cible requis suivants :

Paramètres de capacité cible pour le mode d'équilibrage CONNECTION

Paramètre de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-connections Connexions TCP cibles par zone de backend
max-connections-per-instance Nombre cible de connexions TCP par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer les connexions TCP cibles par zone de backend.
max-connections-per-endpoint Nombre cible de connexions TCP par point de terminaison NEG. Cloud Load Balancing utilise ce paramètre pour calculer les connexions TCP cibles par zone de backend.

Utiliser le paramètre max-connections

Lorsque vous spécifiez le paramètre max-connections, la valeur que vous fournissez définit la capacité d'une zone entière.

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-connections sur X, la capacité cible zonale est X.
  • Le nombre moyen de connexions par instance est de X / h.

• Les groupes d'instances gérés régionaux ne sont pas compatibles avec le paramètre max-connections, car ils sont constitués de plusieurs zones. Utilisez plutôt le paramètre max-connections-per-instance.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-connections sur X, la capacité cible zonale est X.
  • Le nombre moyen de connexions par point de terminaison est de X / h.

Utiliser le paramètre max-connections-per-instance ou max-connections-per-endpoint

Lorsque vous spécifiez le paramètre max-connections-per-instance ou max-connections-per-endpoint, l'équilibreur de charge utilise la valeur que vous fournissez pour calculer une capacité par zone :

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-connections-per-instance sur X, la capacité cible zonale est N * X. Cela équivaut à définir max-connections sur N * X.
  • Le nombre moyen de connexions par instance est de (N * X) / h.

• Pour un groupe d'instances géré régional, si vous définissez max-connections-per-instance sur X, Google Cloud calcule une capacité cible par zone pour chaque zone du groupe d'instances. Dans chaque zone, s'il y a K instances au total et h instances opérationnelles (où h≤ K), les calculs sont les suivants :

  • La capacité cible de la zone est de K * X.
  • Le nombre moyen de connexions par instance dans la zone est de (K * X) / h.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-connections-per-endpoint sur X, la capacité cible zonale est N * X. Cela équivaut à définir max-connections sur N * X.
  • Le nombre moyen de connexions par point de terminaison est de (N * X) / h.

Mode d'équilibrage de fréquence

Les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic non spécifié ou court (aperçu) peuvent utiliser le mode d'équilibrage RATE avec l'un des paramètres de capacité cible requis suivants :

Tableau : Paramètres de capacité cible pour le mode d'équilibrage RATE

Paramètre de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-rate Taux de requêtes HTTP cible par zone de backend
max-rate-per-instance Taux de requêtes HTTP cible par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le taux de requêtes HTTP cibles par zone de backend.
max-rate-per-endpoint Taux de requêtes HTTP cible par point de terminaison NEG. Cloud Load Balancing utilise ce paramètre pour calculer le taux de requêtes HTTP cibles par zone de backend.

Utiliser le paramètre max-rate

Lorsque vous spécifiez le paramètre max-rate, la valeur que vous fournissez définit la capacité d'une zone entière.

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-rate sur X, la capacité cible zonale est de X requêtes par seconde.
  • Le nombre moyen de requêtes par seconde et par instance est de X / h.

• Les groupes d'instances gérés régionaux ne sont pas compatibles avec le paramètre max-rate, car ils sont constitués de plusieurs zones. Utilisez plutôt le paramètre max-rate-per-instance.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-rate sur X, la capacité cible zonale est de X requêtes par seconde.
  • Le nombre moyen de requêtes par seconde et par point de terminaison est de X / h.

Utiliser le paramètre max-rate-per-instance ou max-rate-per-endpoint

Lorsque vous spécifiez le paramètre max-rate-per-instance ou max-rate-per-endpoint, l'équilibreur de charge utilise la valeur que vous fournissez pour calculer une capacité par zone :

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-rate-per-instance sur X, la capacité cible zonale est de N * X requêtes par seconde. Cela équivaut à définir max-rate sur N * X.
  • Le nombre moyen de requêtes par seconde et par instance est de (N * X) / h.

• Pour un groupe d'instances géré régional, si vous définissez max-rate-per-instance sur X, Google Cloud calcule une capacité cible par zone pour chaque zone du groupe d'instances. Dans chaque zone, s'il y a K instances au total et h instances opérationnelles (où h≤ K), les calculs sont les suivants :

  • La capacité cible de la zone est de K * X requêtes par seconde.
  • Le nombre moyen de requêtes par seconde et par instance dans la zone est de (K * X) / h.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-rate-per-endpoint sur X, la capacité cible zonale est de N * X requêtes par seconde. Cela équivaut à définir max-rate sur N * X.
  • Le nombre moyen de requêtes par seconde et par point de terminaison est de (N * X) / h.

Mode d'équilibrage en vol

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic élevé peuvent utiliser le mode d'équilibrage IN_FLIGHT avec l'un des paramètres de capacité cible requis suivants :

Tableau : Paramètres de capacité cible pour le mode d'équilibrage IN_FLIGHT

Paramètre de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-in-flight-requests Nombre cible de requêtes HTTP en cours par zone de backend
max-in-flight-requests-per-instance Nombre cible de requêtes HTTP en cours par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le nombre cible de requêtes HTTP en cours par zone de backend.
max-in-flight-requests-per-endpoint Nombre cible de requêtes HTTP en cours par point de terminaison NEG. L'équilibrage de charge utilise ce paramètre pour calculer le nombre cible de requêtes HTTP en cours par zone de backend.

Utiliser le paramètre max-in-flight-requests

Lorsque vous spécifiez le paramètre max-in-flight-requests, la valeur que vous fournissez définit la capacité d'une zone entière.

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-in-flight-requests sur X, la capacité cible zonale est de X requêtes HTTP en cours.
  • Le nombre moyen de requêtes HTTP en cours par instance est de X / h.

• Les groupes d'instances gérés régionaux ne sont pas compatibles avec le paramètre max-in-flight-requests, car ils sont constitués de plusieurs zones. Utilisez plutôt le paramètre max-in-flight-requests-per-instance.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-in-flight-requests sur X, la capacité cible zonale est de X requêtes HTTP en cours.
  • Le nombre moyen de requêtes HTTP en cours par point de terminaison est de X / h.

Utiliser les paramètres max-in-flight-requests-per-instance ou max-in-flight-requests-per-endpoint

Lorsque vous spécifiez le paramètre max-in-flight-requests-per-instance ou max-in-flight-requests-per-endpoint, l'équilibreur de charge utilise la valeur que vous fournissez pour calculer une capacité par zone :

• Pour un groupe d'instances zonal avec N instances au total et h instances saines (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-in-flight-requests-per-instance sur X, la capacité cible zonale est de N * X requêtes HTTP en cours. Cela équivaut à définir max-in-flight-requests sur N * X.
  • Le nombre moyen de requêtes HTTP en cours par instance est de (N * X) / h.

• Pour un groupe d'instances géré régional, si vous définissez max-in-flight-requests-per-instance sur X, Google Cloud calcule une capacité cible par zone pour chaque zone du groupe d'instances. Dans chaque zone, s'il y a K instances au total et h instances opérationnelles (où h≤ K), les calculs sont les suivants :

  • La capacité cible de la zone est de K * X requêtes HTTP en cours.
  • Le nombre moyen de requêtes HTTP en cours par instance dans la zone est de (K * X) / h.

• Pour un NEG zonal avec N points de terminaison au total et h points de terminaison opérationnels (où h ≤ N), les calculs sont les suivants :

  • Si vous définissez max-in-flight-requests-per-endpoint sur X, la capacité cible zonale est de N * X requêtes HTTP en cours. Cela équivaut à définir max-in-flight-requests sur N * X.
  • Le nombre moyen de requêtes HTTP en cours par point de terminaison est de (N * X) / h.

Mode d'équilibrage de l'utilisation

Les backends de groupe d'instances d'équilibreur de charge d'application, de Cloud Service Mesh et d'équilibreur de charge réseau proxy peuvent utiliser le mode d'équilibrage UTILIZATION. Les backends de NEG ne sont pas compatibles avec ce mode d'équilibrage.

Le mode d'équilibrage UTILIZATION dépend de l'utilisation du processeur de la VM, ainsi que d'autres facteurs. Lorsque ces facteurs fluctuent, l'équilibreur de charge peut calculer l'utilisation de manière à ce que certaines VM reçoivent plus de requêtes ou de connexions que d'autres. Par conséquent, tenez compte des points suivants :

• N'utilisez le mode d'équilibrage UTILIZATION que lorsque l'affinité de session est définie sur NONE. Si votre service de backend utilise une affinité de session différente de NONE, utilisez plutôt les modes d'équilibrage RATE, IN-FLIGHT ou CONNECTION.

• Si l'utilisation moyenne des VM dans tous les groupes d'instances est inférieure à 10 %, certains équilibreurs de charge préfèrent répartir les nouvelles requêtes ou connexions sur des zones spécifiques. Cette préférence zonale devient moins fréquente lorsque le taux de requêtes ou le nombre de connexions augmentent.

Le mode d'équilibrage UTILIZATION n'a pas de paramètre de capacité cible obligatoire, mais vous pouvez éventuellement définir une capacité cible à l'aide de l'un des paramètres de capacité cible ou des combinaisons de paramètres de capacité cible décrits dans les sections suivantes.

Paramètres de capacité cible d'utilisation pour les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic non spécifié ou courte

Les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic non spécifié ou court (aperçu) peuvent utiliser le mode d'équilibrage UTILIZATION avec l'un des paramètres de capacité cible suivants ou une combinaison de paramètres :

Tableau : Paramètres de capacité cible du mode d'équilibrage UTILIZATION et combinaisons de paramètres pour les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic non spécifié ou courte

Paramètre ou combinaison de paramètres de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-utilization Utilisation cible par zone de backend
max-rate Taux de requêtes HTTP cible par zone de backend
max-rate et max-utilization La cible est la première à être atteinte dans la zone du backend : Utilisation cible de la zone Taux de requêtes HTTP cibles de la zone
max-rate-per-instance Taux de requêtes HTTP cible par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le taux de requêtes HTTP cibles par zone de backend.
max-rate-per-instance et max-utilization La cible est la première à être atteinte dans la zone backend : Utilisation cible de la zone Taux de requêtes HTTP cible de la zone (calculé à partir du taux de requêtes HTTP cible par instance de VM des VM de la zone)

Pour en savoir plus sur les paramètres de capacité cible max-rate et max-rate-per-instance, consultez la section Mode d'équilibrage du taux de ce document.

Paramètres de capacité cible d'utilisation pour les backends Application Load Balancer et Cloud Service Mesh avec un paramètre de longue durée du trafic

Les backends d'équilibreur de charge d'application et de Cloud Service Mesh avec un paramètre de durée du trafic long (version bêta) peuvent utiliser le mode d'équilibrage UTILIZATION avec l'un des paramètres de capacité cible suivants ou une combinaison de paramètres :

Tableau : Paramètres de capacité cible du mode d'équilibrage UTILIZATION et combinaisons de paramètres pour les backends Application Load Balancer et Cloud Service Mesh avec un paramètre de longue durée du trafic (aperçu)

Paramètre ou combinaison de paramètres de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-utilization Utilisation cible par zone de backend
max-in-flight-requests Nombre cible de requêtes HTTP en cours par zone de backend
max-in-flight-requests et max-utilization La cible est la première à être atteinte dans la zone du backend : Utilisation cible de la zone Nombre cible de requêtes HTTP en cours dans la zone
max-in-flight-requests-per-instance Nombre cible de requêtes HTTP en cours par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le nombre cible de requêtes HTTP en cours par zone de backend.
max-in-flight-requests-per-instance et max-utilization La cible est la première à être atteinte dans la zone backend : Utilisation cible de la zone Nombre cible de requêtes HTTP en cours pour la zone (calculé à partir du nombre cible de requêtes HTTP en cours par instance de VM des VM de la zone)

Pour en savoir plus sur les paramètres de capacité cible max-in-flight-requests et max-in-flight-requests-per-instance, consultez la section Mode d'équilibrage en cours de ce document.

Paramètres de capacité cible d'utilisation pour les équilibreurs de charge réseau proxy

Les backends de groupes d'instances des équilibreurs de charge réseau proxy peuvent utiliser le mode d'équilibrage UTILIZATION avec l'un des paramètres de capacité cible suivants ou une combinaison de ces paramètres.

Tableau : Paramètres et combinaisons de paramètres de capacité cible du mode d'équilibrage UTILIZATION pour les backends d'équilibreur de charge réseau proxy

Paramètre ou combinaison de paramètres de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
max-utilization Utilisation cible par zone de backend
max-connections Connexions TCP cibles par zone de backend
max-connections et max-utilization La cible est la première à être atteinte dans la zone du backend : Utilisation cible de la zone Connexions TCP cibles de la zone
max-connections-per-instance Nombre cible de connexions TCP par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer les connexions TCP cibles par zone de backend.
max-connections-per-instance et max-utilization La cible est la première à être atteinte dans la zone backend : Utilisation cible de la zone Connexions TCP cibles de la zone (calculées à partir des connexions TCP cibles par instance de VM des VM de la zone)

Pour en savoir plus sur les paramètres de capacité cible max-connections et max-connections-per-instance, consultez la section Mode d'équilibrage des connexions dans ce document.

Mode d'équilibrage des métriques personnalisées

Les backends d'équilibreur de charge d'application et d'équilibreur de charge réseau proxy peuvent utiliser le mode d'équilibrage CUSTOM_METRICS. Les métriques personnalisées vous permettent de définir une capacité cible en fonction des données d'application ou d'infrastructure qui vous intéressent le plus. Pour en savoir plus, consultez Métriques personnalisées pour les équilibreurs de charge d'application.

Le mode d'équilibrage CUSTOM_METRICS n'a pas de paramètre de capacité cible obligatoire, mais vous pouvez éventuellement définir une capacité cible à l'aide de l'un des paramètres de capacité cible ou des combinaisons de paramètres de capacité cible décrits dans les sections suivantes.

Paramètres de capacité cible des métriques personnalisées pour les backends d'équilibreur de charge d'application avec un paramètre de durée du trafic non spécifié ou court

Les backends d'équilibreur de charge d'application avec un paramètre de durée du trafic non spécifié ou court (aperçu) peuvent utiliser le mode d'équilibrage CUSTOM_METRICS avec l'un des paramètres de capacité cible suivants ou une combinaison de paramètres :

Tableau : Paramètres de capacité cible du mode d'équilibrage CUSTOM_METRICS et combinaisons de paramètres pour les backends d'équilibreur de charge d'application avec un paramètre de durée du trafic non spécifié ou courte

Paramètre ou combinaison de paramètres de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
backends[].customMetrics[].maxUtilization Utilisation de métriques personnalisées cibles par zone de backend
max-rate Taux de requêtes HTTP cible par zone de backend
max-rate et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Taux de requêtes HTTP cibles de la zone
max-rate-per-instance Taux de requêtes HTTP cible par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le taux de requêtes HTTP cibles par zone de backend.
max-rate-per-instance et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Taux de requêtes HTTP cible de la zone (calculé à partir du taux de requêtes HTTP cible par instance de VM des VM de la zone)
max-rate-per-endpoint Taux de requêtes HTTP cible par point de terminaison NEG. Cloud Load Balancing utilise ce paramètre pour calculer le taux de requêtes HTTP cibles par zone de backend.
max-rate-per-endpoint et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Taux de requêtes HTTP cible de la zone (calculé à partir du taux de requêtes HTTP cible par point de terminaison NEG des points de terminaison de la zone)

Pour en savoir plus sur les paramètres de capacité cible max-rate, max-rate-per-instance et max-rate-per-endpoint, consultez la section Mode d'équilibrage RATE de ce document.

Paramètres de capacité cible des métriques personnalisées pour les backends d'équilibreur de charge d'application avec un paramètre de longue durée du trafic

Les backends d'équilibreur de charge d'application avec un paramètre de durée du trafic long peuvent utiliser le mode d'équilibrage CUSTOM_METRICS avec l'un des paramètres de capacité cible suivants ou une combinaison de ces paramètres :

Tableau : Paramètres de capacité cible du mode d'équilibrage CUSTOM_METRICS et combinaisons de paramètres pour les backends de l'équilibreur de charge d'application avec un paramètre de longue durée du trafic (aperçu)

Paramètre ou combinaison de paramètres de capacité cible	Backend compatible
	Groupes d'instances zonaux (gérés ou non)	Groupes d'instances gérés régionaux	NEG zonaux avec des points de terminaison GCE_VM_IP_PORT	NEG de connectivité hybride zonaux
backends[].customMetrics[].maxUtilization Utilisation de métriques personnalisées cibles par zone de backend
max-in-flight-requests Nombre cible de requêtes HTTP en cours par zone de backend
max-in-flight-requests et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Nombre cible de requêtes HTTP en cours dans la zone
max-in-flight-requests-per-instance Nombre cible de requêtes HTTP en cours par instance de VM. Cloud Load Balancing utilise ce paramètre pour calculer le nombre cible de requêtes HTTP en cours par zone de backend.
max-in-flight-requests-per-instance et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Nombre cible de requêtes HTTP en cours pour la zone (calculé à partir du nombre cible de requêtes HTTP en cours par instance de VM des VM de la zone)
max-in-flight-requests-per-endpoint Nombre cible de requêtes HTTP en cours par point de terminaison NEG. L'équilibrage de charge utilise ce paramètre pour calculer le nombre cible de requêtes HTTP en cours par zone de backend.
max-in-flight-requests-per-endpoint et backends[].customMetrics[].maxUtilization La cible est la première à être atteinte dans la zone backend : Utilisation de la métrique personnalisée cible de la zone Nombre cible de requêtes HTTP en cours pour la zone (calculé à partir du nombre cible de requêtes HTTP en cours par point de terminaison NEG des points de terminaison de la zone)

Pour en savoir plus sur les paramètres de capacité cible max-in-flight-requests, max-in-flight-requests-per-instance et max-flight-requests-per-endpoint, consultez la section Mode d'équilibrage en cours.

Règle d'équilibrage de charge de service

Une règle d'équilibrage de charge de service (serviceLbPolicy) est une ressource associée au service de backend de l'équilibreur de charge. Elle vous permet de personnaliser les paramètres permettant de contrôler la répartition du trafic entre les backends associés à un service de backend :

• Personnalisez l'algorithme d'équilibrage de charge utilisé pour déterminer la façon dont le trafic est réparti entre les régions ou les zones.
• Activez le drainage de capacité automatique pour que l'équilibreur de charge puisse drainer rapidement le trafic des backends non opérationnels.

De plus, vous pouvez désigner des backends spécifiques en tant que backends préférés. Ces backends doivent être utilisés pour faire face à la capacité (c'est-à-dire la capacité cible spécifiée par le mode d'équilibrage du backend) avant que les requêtes ne soient envoyées aux backends restants.

Pour en savoir plus, consultez Optimisations avancées de l'équilibrage de charge.

Règle d'équilibrage de charge de la localité

Pour un service de backend, la répartition du trafic est basée sur un mode d'équilibrage et sur une règle de localité d'équilibrage de charge. Le mode d'équilibrage détermine la fraction du trafic à envoyer à chaque backend (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine ensuite la manière dont le trafic est distribué entre les instances ou les points de terminaison de chaque zone. Pour les groupes d'instances gérés régionaux, la règle de localité s'applique à chaque zone constitutive.

La règle d'équilibrage de charge de la localité est configurée par service de backend. Les paramètres suivants sont disponibles :

• ROUND_ROBIN (par défaut) : il s'agit du paramètre par défaut de la règle d'équilibrage de charge de la localité. L'équilibreur de charge sélectionne un backend opérationnel à tour de rôle.

• WEIGHTED_ROUND_ROBIN : l'équilibreur de charge utilise des métriques personnalisées définies par l'utilisateur pour sélectionner l'instance ou le point de terminaison optimal dans le backend pour traiter la requête.

• LEAST_REQUEST : algorithme O(1) dans lequel l'équilibreur de charge sélectionne deux hôtes opérationnels aléatoires et choisit celui avec le moins de requêtes actives.

• RING_HASH : cet algorithme implémente un hachage cohérent pour les backends. L'algorithme a la propriété que l'ajout ou la suppression d'un hôte d'un ensemble de N hôtes n'affecte que 1/N des requêtes.

• RANDOM : l'équilibreur de charge sélectionne un hôte opérationnel aléatoire.

• ORIGINAL_DESTINATION : l'équilibreur de charge sélectionne un backend en fonction des métadonnées de la connexion client. Les connexions sont ouvertes à l'adresse IP de destination d'origine spécifiée dans la requête client entrante, avant que la requête ne soit redirigée vers l'équilibreur de charge.

  ORIGINAL_DESTINATION n'est pas compatible avec les équilibreurs de charge d'application externes globaux et régionaux.

• MAGLEV : implémente un hachage cohérent pour les backends et peut être utilisé en remplacement de la règle RING_HASH. Maglev n'est pas aussi stable que RING_HASH, mais permet de créer des recherches de tables et de sélectionner des hôtes plus rapidement. Pour en savoir plus sur Maglev, consultez le livre blanc Maglev.

• WEIGHTED_MAGLEV : implémente l'équilibrage de charge pondéré par instance à l'aide des pondérations signalées par les vérifications de l'état. Si cette stratégie est utilisée, le service de backend doit configurer une vérification de l'état HTTP non héritée, et les réponses de vérification de l'état doivent contenir le champ d'en-tête de réponse HTTP non standard, X-Load-Balancing-Endpoint-Weight, pour spécifier les pondérations par instance. Les décisions d'équilibrage de charge sont prises en fonction des pondérations par instance indiquées dans les dernières réponses de vérification de l'état'état traitées, à condition que chaque instance indique une pondération valide ou UNAVAILABLE_WEIGHT. Sinon, l'équilibrage de charge restera à pondération égale.

  WEIGHTED_MAGLEV n'est compatible qu'avec les équilibreurs de charge réseau passthrough externes. Pour obtenir un exemple, consultez Configurer l'équilibrage de charge pondéré pour les équilibreurs de charge réseau passthrough externes.

La configuration d'une règle de localité d'équilibrage de charge n'est possible que sur les services de backend utilisés avec les équilibreurs de charge suivants :

• Équilibreur de charge d'application externe global
• Équilibreur de charge d'application externe régional
• Équilibreur de charge d'application interne interrégional
• Équilibreur de charge d'application interne régional
• Équilibreur de charge réseau proxy externe global
• Équilibreur de charge réseau proxy externe régional
• Équilibreur de charge réseau proxy interne interrégional
• Équilibreur de charge réseau proxy interne régional
• Équilibreur de charge réseau passthrough externe

Notez que la valeur effective par défaut de la règle d'équilibrage de charge de localité (localityLbPolicy) change en fonction de vos paramètres d'affinité de session. Si l'affinité de session n'est pas configurée (c'est-à-dire, si l'affinité de session reste à la valeur par défaut NONE), la valeur par défaut de localityLbPolicy est ROUND_ROBIN. Si l'affinité de session est définie sur une valeur autre que NONE, la valeur par défaut de localityLbPolicy est MAGLEV.

Pour configurer une règle de localisation d'équilibrage de charge, vous pouvez utiliser la consoleGoogle Cloud , gcloud (--locality-lb-policy) ou l'API (localityLbPolicy).

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 :

• Équilibreur de charge d'application interne régional
• Équilibreur de charge réseau passthrough interne

Sous-paramètre de backend pour les équilibreurs de charge d'application internes régionaux

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

L'équilibreur de charge d'application interne interrégional n'est pas compatible avec le sous-paramètre de backend.

Pour les équilibreurs de charge d'application internes régionaux, 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 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.

Comparaison d'un équilibreur de charge d'application interne sans et avec le sous-paramètre de backend (cliquez pour agrandir).

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 d'application 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 d'application 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 sur LEAST_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 deux NONE, 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 réseau passthrough

Le sous-paramètre de backend des équilibreurs de charge réseau passthrough internes vous permet de faire évoluer votre équilibreur de charge réseau passthrough interne à charge à 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 Services de backend dans "Quotas et limites".

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.

Comparaison d'un équilibreur de charge réseau passthrough interne avec et sans sous-paramètre.

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 réseau passthrough 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 passthrough 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-ensemble de backend est sans frais. Pour plus d'informations, consultez la page Tous les tarifs de mise en réseau.

Affinité de session

L'affinité de session vous permet de contrôler la manière dont l'équilibreur de charge sélectionne les backends pour les nouvelles connexions de manière prévisible tant que le nombre de backends opérationnels reste constant. Cela est utile pour les applications qui nécessitent que plusieurs requêtes d'un utilisateur donné soient 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.

Les équilibreurs de chargeGoogle 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 de l'état d'état du backend, l'ajout ou la suppression de backends, la modification des pondérations de backend (y compris l'activation ou la désactivation de l'équilibrage pondéré) ou des modifications de leur utilisation maximale selon les mesures effectuées par le mode d'équilibrage, peuvent rompre l'affinité de session.

L'équilibrage de charge avec affinité de session fonctionne bien lorsqu'il existe une distribution raisonnablement importante de connexions uniques. Une taille raisonnablement importante signifie au moins plusieurs fois le nombre de backends. Le test d'un équilibreur de charge avec un petit nombre de connexions n'offre pas une représentation précise de la distribution des connexions client entre les backends.

Par défaut, tous les équilibreurs de charge Google Cloud sélectionnent les backends à l'aide d'un hachage à cinq tuples (--session-affinity=NONE), 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 en savoir plus sur l'affinité de session pour les équilibreurs de charge réseau passthrough, consultez les documents suivants :

• Distribution du trafic pour les équilibreurs de charge réseau passthrough externes
• Distribution du trafic pour les équilibreurs de charge réseau passthrough internes

Pour en savoir plus sur l'affinité de session pour les équilibreurs de charge d'application, consultez les documents suivants :

• Affinité de session pour les équilibreurs de charge d'application externes
• Affinité de session pour les équilibreurs de charge d'application internes

Pour en savoir plus sur l'affinité de session pour les équilibreurs de charge réseau proxy, consultez les documents suivants :

• Affinité de session pour les équilibreurs de charge réseau proxy externes
• Affinité de session pour les équilibreurs de charge réseau proxy internes

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 d'application externes et 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 ou de réponse pour le trafic HTTP(S).

  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 d'application externes globaux et les équilibreurs de charge d'application externes régionaux , consultez Délais d'expiration et nouvelles tentatives.
  • Pour les équilibreurs de charge d'application internes, consultez Délais d'expiration et nouvelles tentatives.

• Pour les équilibreurs de charge réseau proxy externes et internes, le délai avant expiration du service de backend configuré correspond à la durée pendant laquelle l'équilibreur de charge maintient la connexion TCP ouverte en l'absence de données transmises par le client ou le backend. Passé ce délai sans transmission de données, le proxy ferme la connexion.

  • Valeur par défaut : 30 secondes
  • Plage configurable : de 1 à 2 147 483 647 secondes

• Pour les équilibreurs de charge réseau passthrough internes et externes, 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 Cloud Service Mesh, 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 champ maxStreamDuration. En effet, gRPC n'est pas compatible avec la sémantique de timeoutSec 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 de l'état. Les services de backend utilisant un NEG sans serveur ou un NEG Internet global en tant que backend ne doivent pas référencer une vérification de l'état.

Lorsque vous créez un équilibreur de charge à l'aide de la console Google Cloud , vous pouvez créer la vérification de l'état'état, si nécessaire, lors de la création de l'équilibreur de charge, mais vous pouvez également référencer une vérification de l'état de l'é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

Les fonctionnalités facultatives suivantes sont compatibles avec certains services de backend.

Cloud CDN

Cloud CDN utilise le réseau périphérique mondial de Google pour diffuser les contenus au plus près des utilisateurs, ce qui accélère vos sites Web et vos applications. Cloud CDN est activé sur les services de backend utilisés par les équilibreurs de charge d'application externes globaux. L'équilibreur de charge fournit les adresses IP d'interface et les ports qui reçoivent les requêtes, ainsi que les backends qui y répondent.

Pour en savoir plus, consultez la documentation Cloud CDN.

Cloud CDN n'est pas compatible avec IAP. Ils ne peuvent pas être activés sur le même service de backend.

Cloud Armor

Si vous utilisez l'un des équilibreurs de charge suivants, vous pouvez ajouter une protection supplémentaire à vos applications en activant Cloud Armor sur le service de backend lors de la création de l'équilibreur de charge :

• Équilibreur de charge d'application externe global
• Équilibreur de charge d'application classique
• Équilibreur de charge réseau proxy externe global
• Équilibreur de charge réseau proxy classique

Si vous utilisez la console Google Cloud , vous pouvez effectuer l'une des opérations suivantes :

• Sélectionnez une stratégie de sécurité Cloud Armor existante.
• Accepter la configuration d'une stratégie de sécurité Cloud Armor par défaut, visant une limitation du débit, avec nom, nombre de requêtes, intervalle, clé et paramètres de limitation du débit personnalisables. Si vous utilisez Cloud Armor avec un service de proxy en amont, tel qu'un fournisseur CDN, une adresse IP à en-tête XFF doit être définie pour le paramètre Enforce_on_key.
• Choisir de désactiver la protection Cloud Armor en sélectionnant Aucun.

IAP

IAP vous permet d'établir une couche d'autorisation centrale pour les applications accessibles via HTTPS. Vous pouvez donc adopter un modèle de contrôle des accès au niveau des applications au lieu d'utiliser des pare-feu au niveau du réseau. IAP est compatible avec certains équilibreurs de charge d'application.

IAP n'est pas compatible avec Cloud CDN. Ils ne peuvent pas être activés sur le même service de backend.

Fonctionnalités de gestion avancée du trafic

Pour en savoir plus sur les fonctionnalités avancées de gestion du trafic configurées sur les services de backend et les mappages d'URL associés aux équilibreurs de charge, consultez les pages suivantes :

• Présentation de la gestion du trafic pour les équilibreurs de charge d'application internes
• Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes mondiaux
• Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux

API et documentation de référence gcloud

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

Étapes suivantes

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

• Créer des en-têtes personnalisés
• Créer un équilibreur de charge d'application externe
• Présentation de l'équilibreur de charge d'application externe
• Activer le drainage de connexion
• Chiffrement en transit dans Google Cloud

Pour des vidéos similaires :

• Configurer des services de backend pour les équilibreurs de charge d'application externes globaux