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 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.
| 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 :
|
EXTERNAL_MANAGED |
| Équilibreur de charge d'application classique | Plusieurs | Monde‡ | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL# |
| Équilibreur de charge d'application externe régional | Plusieurs | Régional | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL_MANAGED |
| Équilibreur de charge d'application interne interrégional | Plusieurs | Monde | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
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 :
|
INTERNAL_MANAGED |
| Équilibreur de charge réseau proxy externe global | 1 | Monde‡ | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
EXTERNAL_MANAGED |
| Équilibreur de charge réseau proxy classique | 1 | Monde‡ | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
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 :
|
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 :
|
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 :
|
INTERNAL_MANAGED |
| Équilibreur de charge réseau passthrough externe | 1 | Régionales | Le service de backend accepte l'une des combinaisons de backend suivantes :
|
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 :
|
INTERNAL |
| Cloud Service Mesh | Plusieurs | Monde | Chaque service de backend accepte l'une des combinaisons de backend suivantes :
|
INTERNAL_SELF_MANAGED |
GCE_VM_IP_PORT.
- 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.
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 en suivant 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 l'équilibreur 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 identique à 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 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 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
nic0de la VM. - Pour les points de terminaison
GCE_VM_IP_PORTd'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 backends de groupe d'instances, l'adresse IPv4 interne est toujours l'adresse IPv4 interne principale qui correspond à l'interface
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
nic0de la VM, etnic0doit se trouver dans le même réseau que l'équilibreur de charge. - Pour les points de terminaison
GCE_VM_IP_PORTd'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 backends de groupe d'instances, l'adresse IPv4 interne est toujours l'adresse IPv4 interne principale correspondant à l'interface
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
nic0de la VM. - Pour les points de terminaison
GCE_VM_IPd'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.
- Pour les backends de groupe d'instances, les paquets sont toujours transmis à l'interface
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
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 Cloudvous oblige à n'utiliser qu'un seul de ces groupes d'instances à la fois comme backend d'un service de backend 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 modes d'équilibrage compatibles (par exemple,
CONNECTIONetRATE).Les combinaisons de modes d'équilibrage incompatibles sont les suivantes :
CONNECTIONavecUTILIZATIONRATEavecUTILIZATIONCUSTOM_METRICSavecUTILIZATIONCUSTOM_METRICSavecRATECUSTOM_METRICSavecCONNECTION
Prenons l'exemple suivant :
- Vous disposez de deux services de backend :
external-https-backend-servicepour un équilibreur de charge d'application externe etinternal-tcp-backend-servicepour un équilibreur de charge réseau passthrough interne. - Vous utilisez un groupe d'instances appelé
instance-group-adansinternal-tcp-backend-service. - Dans
internal-tcp-backend-service, vous devez appliquer le mode d'équilibrageCONNECTION, car les équilibreurs de charge réseau passthrough internes ne sont compatibles qu'avec le mode d'équilibrageCONNECTION. - Vous pouvez également utiliser
instance-group-adansexternal-https-backend-servicesi vous appliquez le mode d'équilibrageRATEdansexternal-https-backend-service. - Vous ne pouvez pas également utiliser
instance-group-adansexternal-https-backend-serviceavec 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 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 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 adresse IP et port pour les ressources Google 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.
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 (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.
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 terminaisonNON_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.
| 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 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 |
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.
Répartition 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 Cloud Service Mesh sont en mesure de gérer du trafic supplémentaire ou s'ils fonctionnent à charge maximale.
Google Cloud propose quatre modes d'équilibrage :
CONNECTION: détermine la répartition de la charge en fonction du nombre total de connexions que le backend peut gérer.RATE: nombre cible maximal de requêtes par seconde (RPS). La valeur RPS cible maximale peut être dépassée si tous les backends ont une capacité égale ou supérieure.UTILIZATION: détermine la répartition de la charge en fonction de l'utilisation des instances dans un groupe d'instances.CUSTOM_METRICS: détermine la répartition de la charge en fonction des métriques personnalisées définies par l'utilisateur.
Modes d'équilibrage disponibles pour chaque équilibreur de charge
Vous définissez le mode d'équilibrage lorsque vous ajoutez un backend au service de backend. Les modes d'équilibrage disponibles pour un équilibreur de charge dépendent du type d'équilibreur de charge et du type de backends.
Les équilibreurs de charge réseau passthrough nécessitent le mode d'équilibrage CONNECTION, mais ne permettent pas de définir une capacité cible.
Les équilibreurs de charge d'application sont compatibles avec les modes d'équilibrage RATE, UTILIZATION ou CUSTOM_METRICS pour les backends de groupe d'instances, et les modes d'équilibrage RATE ou CUSTOM_METRICS pour les NEG zonaux (points de terminaison GCE_VM_IP_PORT) et les NEG hybrides (points de terminaison NON_GCP_PRIVATE_IP_PORT). Pour tout autre type de backend compatible, le mode d'équilibrage doit être omis.
Pour les équilibreurs de charge d'application classiques, une région est sélectionnée en fonction de l'emplacement du client et de la disponibilité de la région selon la capacité cible du mode d'équilibrage de charge. Ensuite, dans une région, la capacité cible du mode d'équilibrage permet de calculer les proportions du nombre de requêtes à envoyer à chaque backend de la région. Les requêtes ou les connexions sont ensuite distribuées à tour de rôle entre les instances ou les points de terminaison du backend.
Pour les équilibreurs de charge d'application externes globaux, une région est sélectionnée en fonction de l'emplacement du client et de la disponibilité de la région selon la capacité cible du mode d'équilibrage de charge. Dans une région, la capacité cible du mode d'équilibrage est utilisée pour calculer les proportions du nombre de requêtes à envoyer à chaque backend (groupe d'instances ou NEG) de la région. Vous pouvez utiliser la règle d'équilibrage de charge de service (
serviceLbPolicy) et le paramètre de backend préféré pour contrôler la sélection de backends spécifiques au sein d'une région. De plus, au sein de chaque groupe d'instances ou NEG, 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 du groupe.
- Pour les équilibreurs de charge d'application internes multirégionaux , les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, la capacité cible du mode d'équilibrage est utilisée pour calculer les proportions du nombre de requêtes à envoyer à chaque backend (groupe d'instances ou NEG) dans la région. Au sein de chaque groupe d'instances ou NEG, 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 du groupe. Seul l'équilibreur de charge d'application interne interrégional est compatible avec l'utilisation de la règle d'équilibrage de charge de service (serviceLbPolicy) et des paramètres de backend préféré pour influencer la sélection des tous les backends spécifiques d'une région.
Les équilibreurs de charge réseau proxy sont compatibles avec les modes d'équilibrage CONNECTION ou UTILIZATION pour les backends de groupe d'instances de VM, le mode d'équilibrage CONNECTION pour les NEG zonaux avec des points de terminaison GCE_VM_IP_PORT et le mode d'équilibrage CONNECTION pour les NEG hybrides (points de terminaison NON_GCP_PRIVATE_IP_PORT). Pour tout autre type de backend compatible, le mode d'équilibrage doit être omis.
Pour les équilibreurs de charge réseau proxy externes mondiaux, une région est sélectionnée en fonction de l'emplacement du client et de la disponibilité de la région selon la capacité cible du mode d'équilibrage de charge. Dans une région, la capacité cible du mode d'équilibrage est utilisée pour calculer les proportions du nombre de requêtes à envoyer à chaque backend (groupe d'instances ou NEG) de la région. Vous pouvez utiliser la règle d'équilibrage de charge de service (
serviceLbPolicy) et le paramètre de backend préféré pour contrôler la sélection de backends spécifiques au sein d'une région. De plus, au sein de chaque groupe d'instances ou NEG, 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 du groupe.Pour les équilibreurs de charge réseau proxy internes interrégionaux, la région configurée est sélectionnée en premier. Dans une région, la capacité cible du mode d'équilibrage est utilisée pour calculer les proportions du nombre de requêtes à envoyer à chaque backend (groupe d'instances ou NEG) de la région. Vous pouvez utiliser la règle d'équilibrage de charge de service (
serviceLbPolicy) et le paramètre de backend préféré pour contrôler la sélection de backends spécifiques au sein d'une région. De plus, au sein de chaque groupe d'instances ou NEG, 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 du groupe.Pour les équilibreurs de charge réseau proxy classiques, une région est sélectionnée en fonction de l'emplacement du client et de la disponibilité de la région selon la capacité cible du mode d'équilibrage de charge. Ensuite, dans une région, la capacité cible du mode d'équilibrage de charge est utilisée pour calculer les proportions du nombre de requêtes ou de connexions à envoyer à chaque backend (groupe d'instances ou NEG) de la région. Une fois que l'équilibreur de charge a sélectionné un backend, les requêtes ou les connexions sont distribuées à tour de rôle entre les instances de VM ou les points de terminaison réseau au sein de chaque backend.
- Pour les équilibreurs de charge réseau proxy régionaux internes et externes, la capacité cible du mode d'équilibrage de charge est utilisée pour calculer les proportions du nombre de requêtes à envoyer à chaque backend (groupe d'instances ou NEG). Au sein de chaque groupe d'instances ou NEG, 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 du groupe.
Le tableau suivant récapitule les modes d'équilibrage de charge disponibles pour chaque combinaison d'équilibreur de charge et de backend.
| Équilibreur de charge | Backends | Modes d'équilibrage disponibles |
|---|---|---|
| Équilibreur de charge d'application | Groupes d'instances | RATE, UTILIZATION ou CUSTOM_METRICS |
NEG zonaux (points de terminaison GCE_VM_IP_PORT) |
RATE ou CUSTOM_METRICS |
|
NEG hybrides (points de terminaison NON_GCP_PRIVATE_IP_PORT) |
RATE ou CUSTOM_METRICS |
|
|
Équilibreur de charge réseau proxy
|
Groupes d'instances | CONNECTION ou UTILIZATION |
NEG zonaux (points de terminaison GCE_VM_IP_PORT) |
CONNECTION |
|
NEG hybrides (points de terminaison |
CONNECTION |
|
| Équilibreur de charge réseau passthrough | Groupes d'instances | CONNECTION |
NEG zonaux (points de terminaison GCE_VM_IP) |
CONNECTION |
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 gérés régionaux, des groupes d'instances gérés zonaux 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.
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 ouvertes. À l'exception des équilibreurs de charge réseau passthrough internes et des équilibreurs de charge réseau passthrough externes, 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 de VM ou du NEG zonal :
- Dans un groupe d'instances de VM avec
Ninstances, la définition demax-connections-per-instance=Xa la même signification que la définition demax-connections=X × N. - Dans un NEG zonal avec
Npoints de terminaison, la définition demax-connections-per-endpoint=Xa 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
Ninstances, la définition demax-rate-per-instance=Xa la même signification que la définition demax-rate=X × N. - Dans un NEG zonal avec
Npoints de terminaison, la définition demax-rate-per-endpoint=Xa 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 la console Google Cloud pour ajouter un groupe d'instances backend à un service de backend, la consoleGoogle Cloud 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.
Mode d'équilibrage des métriques personnalisées
Le mode d'équilibrage CUSTOM_METRICS vous permet de définir vos propres métriques personnalisées qui peuvent être utilisées pour déterminer comment la charge est répartie. Les métriques personnalisées vous permettent de configurer le comportement de distribution du trafic de votre équilibreur de charge en fonction de métriques spécifiques à vos exigences en termes d'application ou d'infrastructure, plutôt que des métriques standards d'utilisation ou basées sur le taux deGoogle Cloud.
Pour en savoir plus, consultez Métriques personnalisées pour les équilibreurs de charge d'application.
Modifier le mode d'équilibrage d'un équilibreur de charge
Pour certains équilibreurs de charge ou configurations d'équilibreur de charge, vous ne pouvez pas modifier le mode d'équilibrage, car le service de backend n'accepte qu'un seul mode d'équilibrage possible : Pour d'autres, en fonction du backend utilisé, vous pouvez modifier le mode d'équilibrage, car plusieurs modes sont disponibles pour ces services backend.
Pour savoir quels modes d'équilibrage sont compatibles avec chaque équilibreur de charge, consultez la page Tableau : Modes d'équilibrage disponibles pour chaque équilibreur de charge.
Modes d'équilibrage et paramètres de capacité cible
Pour les produits qui prennent en charge une spécification de capacité cible, la capacité cible n'est pas un disjoncteur. Lorsqu'une zone donnée atteint la capacité cible maximale configurée, les nouvelles requêtes ou connexions sont distribuées vers d'autres zones qui ne traitent pas de requêtes ni de connexions à la capacité cible. Si toutes les zones ont atteint leur capacité cible, les nouvelles requêtes ou connexions sont distribuées par surremplissage.
Équilibreurs de charge d'application et Cloud Service Mesh
Ce tableau liste les combinaisons de mode d'équilibrage et de capacité cible disponibles pour les équilibreurs de charge d'application et Cloud Service Mesh.
| Type de backend | Mode d'équilibrage | Spécification de la capacité cible |
|---|---|---|
Groupes d'instances
|
RATE |
Vous devez spécifier l'une des valeurs suivantes :
|
UTILIZATION |
Vous pouvez éventuellement spécifier l'un des éléments suivants :
|
|
CUSTOM_METRICS |
Vous pouvez éventuellement spécifier l'un des éléments suivants :
max-utilization par backend n'est pas accepté. |
|
|
NEG zonaux
NEG hybrides
|
RATE |
Vous devez spécifier l'une des valeurs suivantes :
|
CUSTOM_METRICS |
Vous pouvez éventuellement spécifier l'un des éléments suivants :
max-utilization par backend n'est pas accepté. |
Équilibreurs de charge réseau proxy
Ce tableau liste les combinaisons de mode d'équilibrage et de capacité cible disponibles pour les équilibreurs de charge réseau proxy.
| Type de backend | Mode d'équilibrage | Spécification de la capacité cible |
|---|---|---|
Groupes 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 zonaux
NEG hybrides
|
CONNECTION |
Vous devez spécifier l'une des valeurs suivantes :
|
Équilibreurs de charge réseau passthrough
Ce tableau liste les combinaisons de mode d'équilibrage et de capacité cible disponibles pour les équilibreurs de charge réseau passthrough.
| Type de backend | Mode d'équilibrage | Spécification de la capacité cible |
|---|---|---|
Groupes d'instances
|
CONNECTION |
Vous ne pouvez pas spécifier de nombre maximal cible de connexions. |
NEG zonaux
|
CONNECTION |
Vous ne pouvez pas spécifier de nombre maximal cible de connexions. |
Scaler de capacité
Utilisez le scaler de capacité pour ajuster la capacité cible (utilisation maximale, taux maximal ou connexions maximales) sans la modifier.
Pour obtenir la documentation de référence sur Google Cloud , consultez les pages suivantes :
- Google Cloud CLI : capacity-scaler
- API
Vous pouvez ajuster le scaler de capacité de façon à procéder au scaling de la capacité cible effective sans modifier explicitement l'un des paramètres --max-*.
Vous pouvez définir le scaler de capacité sur l'une des valeurs suivantes :
- La valeur par défaut est
1, ce qui signifie que le groupe diffuse jusqu'à 100 % de sa capacité configurée (selonbalancingMode). - Une valeur de
0signifie que le groupe est complètement drainé, ce qui offre 0 % de sa capacité disponible. Vous ne pouvez pas configurer une valeur de0lorsqu'un seul backend est associé au service de backend. - 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 paramètremax-rateest défini sur80RPS et le scaler de capacité est1.0, la capacité disponible est également de80RPS.Si le mode d'équilibrage est
RATE, le paramètremax-rateest défini sur80RPS et le scaler de capacité est0.5, la capacité disponible est de40RPS (0.5 times 80).Si le mode d'équilibrage est
RATE, le paramètremax-rateest défini sur80RPS et le scaler de capacité est0.0, la capacité disponible est de zéro (0).
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 avec une règle d'équilibrage de charge de service.
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 de localité d'équilibrage de charge. 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: algorithmeO(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_DESTINATIONn'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ègleRING_HASH. Maglev n'est pas aussi stable queRING_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 standardX-Load-Balancing-Endpoint-Weightpour 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 ouUNAVAILABLE_WEIGHT. Sinon, l'équilibrage de charge restera à pondération égale.WEIGHTED_MAGLEVn'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 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 elle reste à la valeur par défaut de 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).
Cloud Service Mesh et distribution du trafic
Cloud Service Mesh utilise également les ressources de service de backend. Plus précisément, Cloud Service Mesh utilise des services de backend dont le schéma d'équilibrage de charge est INTERNAL_SELF_MANAGED. Pour un service de backend interne autogéré, la distribution du trafic est basée sur la combinaison d'un mode d'équilibrage de charge et d'une règle d'équilibrage de charge. Le service de backend dirige le trafic vers un backend en fonction du mode d'équilibrage du backend. Ensuite, Cloud Service Mesh 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 en savoir plus sur Cloud Service Mesh, consultez Concepts de Cloud Service Mesh.
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
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.
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 de backend pour les équilibreurs de charge d'application internes, consultez la page Configurer le sous-paramètre de 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
localityLbPolicysurLEAST_REQUESTpour 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-policyet--session-affinitysont 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 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 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 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-paramètre de backend est gratuite. 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, les modifications des pondérations de backend (y compris l'activation ou la désactivation de l'équilibrage pondéré) ou les modifications de l'utilisation maximale du backend, 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 les équilibreurs de charge basés sur un proxy, tant que le nombre d'instances backend ou de points de terminaison opérationnels reste constant, et que l'instance backend ou le point de terminaison sélectionné précédemment n'est pas saturé, les requêtes ou connexions suivantes sont envoyées à la même VM de backend ou même point de terminaison. La capacité cible du mode d'équilibrage détermine à quel moment le backend est saturé.
Le tableau suivant présente les options d'affinité de session compatibles avec chaque produit :
| Produit | Options d'affinité de session |
|---|---|
Sachez également que :
|
|
| Équilibreur de charge d'application classique |
|
Sachez également que :
|
|
| Équilibreur de charge réseau passthrough interne |
Pour plus d'informations sur l'équilibreur de charge réseau passthrough interne et l'affinité de session, consultez Distribution du trafic pour l'équilibreur de charge réseau passthrough interne. |
| Équilibreur de charge réseau passthrough externe* |
Pour plus d'informations sur l'équilibreur de charge réseau passthrough externe et l'affinité de session, consultez Distribution du trafic pour les équilibreurs de charge réseau passthrough externes. |
|
|
| Cloud Service Mesh |
|
* Ce tableau répertorie les options d'affinité de session compatibles avec les équilibreurs de charge réseau passthrough externes basés sur un service de backend.
Les équilibreurs de charge réseau passthrough externes basés sur un pool cible n'utilisent pas de services de backend. Définissez plutôt l'affinité de session pour les équilibreurs de charge réseau passthrough externes 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, à l'exception de l'affinité de session avec état basée sur les cookies, est conçue pour se rompre chaque fois que le nombre de backends actifs et opérationnels change. Pour en savoir plus, consultez la section Perte d'affinité de session.
Les valeurs par défaut des options
--session-affinityet--subsetting-policysontNONE, et une seule d'entre elles peut être définie sur une valeur différente.
Types d'affinité de session
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é de session Adresse IP client, aucune destination (CLIENT_IP_NO_DESTINATION) est un hachage à un tuple basé uniquement sur l'adresse IP source de chaque paquet reçu. Cette affinité de session n'est disponible que pour les équilibreurs de charge réseau passthrough internes.
Cette option peut être utile dans les situations où vous avez besoin que la même VM de backend traite tous les paquets d'un client, en fonction uniquement de l'adresse IP source du paquet, sans tenir compte de l'adresse IP de destination du paquet. Ces situations se produisent généralement lorsqu'un équilibreur de charge réseau passthrough interne est un saut suivant pour une route statique. Pour en savoir plus, consultez Affinité de session et équilibreurs de charge réseau passthrough internes comme sauts suivants.
Affinité basée sur les adresses IP client
L'affinité de session Adresse IP client (CLIENT_IP) est un hachage à deux tuples créé à partir des adresses IP source et de destination du paquet. L'affinité de session basée sur les adresses IP client est disponible pour tous les équilibreurs de charge Google Cloud qui utilisent des services de backend.
Les équilibreurs de charge réseau passthrough externes appellent l'option d'affinité de session Adresse IP client, adresse IP de destination.
Lorsque vous utilisez l'affinité basée sur les adresses IP client, gardez à l'esprit les points suivants :
L'adresse IP de destination du paquet n'est identique à celle de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
Les paquets qui sont routés vers un équilibreur de charge réseau passthrough interne de saut suivant par une route statique ont des adresses IP de destination qui ne correspondent pas à l'adresse IP de la règle de transfert de l'équilibreur de charge. Pour en savoir plus, consultez Affinité de session et équilibreurs de charge réseau passthrough internes comme saut suivant.
L'adresse IP source du paquet peut ne pas correspondre à une adresse IP associée au client d'origine si le paquet est traité par un système NAT ou proxy intermédiaire avant d'être distribué à un équilibreur de charge Google Cloud . Dans les situations où de nombreux clients partagent la même adresse IP source effective, certaines VM de backend peuvent recevoir plus de connexions ou de requêtes que d'autres.
Affinité basée sur les cookies générés
Lorsque vous utilisez l'affinité basée sur les cookies générés, l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale.
Le nom du cookie généré varie en fonction du type d'équilibreur de charge. Les produits suivants sont compatibles avec les cookies générés :
| Produit | Nom du cookie |
|---|---|
| Équilibreurs de charge d'application externes globaux | GCLB |
| Équilibreurs de charge d'application classiques | GCLB |
| Équilibreurs de charge d'application externes régionaux | GCILB |
| Équilibreurs de charge d'application internes interrégionaux | GCILB |
| Équilibreurs de charge d'application internes régionaux | GCILB |
| Cloud Service Mesh | GCILB |
L'attribut de chemin d'accès du cookie généré est toujours une barre oblique (/). Il s'applique donc à tous les services de backend du même mappage d'URL, à condition que les autres services de backend utilisent également l'affinité de cookie générée.
Vous pouvez configurer la valeur TTL (Time To Live) du cookie entre 0 et 1,209,600 secondes (incluses) à l'aide du paramètre de service de backend affinityCookieTtlSec.
Si affinityCookieTtlSec n'est pas spécifié, la valeur TTL par défaut est 0.
Lorsque le client inclut le cookie d'affinité de session généré dans l'en-tête de requête Cookie des requêtes HTTP, l'équilibreur de charge dirige ces requêtes vers la même instance ou le même point de terminaison backend, tant que le cookie d'affinité de session reste valide. Pour ce faire, la valeur du cookie est mappée sur un index qui fait référence à une instance de backend ou à un point de terminaison spécifique, et les exigences d'affinité de session du cookie généré sont respectées.
Pour utiliser l'affinité basée sur les cookies générés, configurez les paramètres suivants pour le mode d'équilibrage et localityLbPolicy :
- Pour les groupes d'instances de backend, utilisez le mode d'équilibrage
RATE. - Pour le
localityLbPolicydu service de backend, utilisezRING_HASHouMAGLEV. Si vous ne définissez pas explicitementlocalityLbPolicy, l'équilibreur de charge utiliseMAGLEVcomme valeur par défaut implicite.
Pour en savoir plus, consultez Perte d'affinité de session.
Affinité basée sur le champ d'en-tête
Avec l'affinité basée sur le champ d'en-tête, les requêtes sont acheminées vers les backends en fonction de la valeur de l'en-tête HTTP dans le champ consistentHash.httpHeaderName du service de backend. Pour distribuer les requêtes sur tous les backends disponibles, chaque client doit utiliser une valeur d'en-tête HTTP différente.
Les équilibreurs de charge suivants utilisent l'affinité de champ d'en-tête :
- Cloud Service Mesh
- Équilibreur de charge d'application interne interrégional
- Équilibreur de charge d'application externe global
- Équilibreur de charge d'application externe régional
- Équilibreur de charge d'application interne régional
L'affinité du champ d'en-tête est prise en charge lorsque les conditions suivantes sont remplies :
- La règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV.
- La valeur
consistentHashdu service de backend spécifie le nom de l'en-tête HTTP (httpHeaderName).
Pour connaître les produits compatibles avec l'affinité basée sur le champ d'en-tête, consultez la page Tableau : Paramètres d'affinité de session compatibles.
Affinité basée sur les cookies HTTP
Lorsque vous utilisez l'affinité basée sur les cookies HTTP, l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale. Vous spécifiez le nom, le chemin d'accès et la valeur TTL (Time To Live) du cookie.
Les produits suivants sont compatibles avec l'affinité basée sur les cookies HTTP :
- Tous les équilibreurs de charge d'application
- Cloud Service Mesh
Vous pouvez configurer les valeurs TTL du cookie en utilisant des secondes, des fractions de seconde (en nanosecondes) ou les deux (secondes et fractions de seconde en nanosecondes) à l'aide des paramètres et des valeurs valides du service de backend suivants :
consistentHash.httpCookie.ttl.secondspeut être défini sur une valeur comprise entre0et315576000000(inclus).consistentHash.httpCookie.ttl.nanospeut être défini sur une valeur comprise entre0et999999999(inclus). Comme les unités sont exprimées en nanosecondes,999999999signifie.999999999secondes.
Si consistentHash.httpCookie.ttl.seconds et consistentHash.httpCookie.ttl.nanos ne sont pas spécifiés, la valeur du paramètre de service de backend affinityCookieTtlSec est utilisée à la place. Si affinityCookieTtlSec n'est pas spécifié, la valeur TTL par défaut est 0.
Lorsque le client inclut le cookie d'affinité de session HTTP dans l'en-tête de requête Cookie des requêtes HTTP, l'équilibreur de charge dirige ces requêtes vers la même instance ou le même point de terminaison de backend, tant que le cookie d'affinité de session reste valide. Pour ce faire, la valeur du cookie est mappée sur un index qui fait référence à une instance de backend ou à un point de terminaison spécifique, et les exigences d'affinité de session du cookie généré sont respectées.
Pour utiliser l'affinité basée sur les cookies HTTP, configurez les paramètres suivants pour le mode d'équilibrage et localityLbPolicy :
- Pour les groupes d'instances de backend, utilisez le mode d'équilibrage
RATE. - Pour le
localityLbPolicydu service de backend, utilisezRING_HASHouMAGLEV. Si vous ne définissez pas explicitementlocalityLbPolicy, l'équilibreur de charge utiliseMAGLEVcomme valeur par défaut implicite.
Pour en savoir plus, consultez Perte d'affinité de session.
Affinité de session avec état basée sur les cookies
Lorsque vous utilisez l'affinité avec état basée sur les cookies, l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale.
Vous spécifiez le nom, le chemin d'accès et la valeur TTL (Time To Live) du cookie.
Tous les équilibreurs de charge d'application, à l'exception des équilibreurs de charge d'application classiques, sont compatibles avec l'affinité basée sur les cookies avec état.
Vous pouvez configurer les valeurs TTL du cookie en utilisant des secondes, des fractions de seconde (en nanosecondes) ou les deux (secondes et fractions de seconde en nanosecondes).
La durée représentée par strongSessionAffinityCookie.ttl ne peut pas être définie sur une valeur représentant plus de deux semaines (1 209 600 secondes).
La valeur du cookie identifie une instance ou un point de terminaison de backend sélectionné en encodant l'instance ou le point de terminaison sélectionné dans la valeur elle-même. Tant que le cookie est valide, si le client inclut le cookie d'affinité de session dans l'en-tête de requête Cookie des requêtes HTTP ultérieures, l'équilibreur de charge dirige ces requêtes vers l'instance ou le point de terminaison de backend sélectionnés.
Contrairement aux autres méthodes d'affinité de session :
L'affinité avec état basée sur les cookies ne présente aucune exigence spécifique concernant le mode d'équilibrage ni la règle de localité d'équilibrage de charge (
localityLbPolicy).L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoscaling ajoute une instance à un groupe d'instances géré.
L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoscaling supprime une instance d'un groupe d'instances géré, sauf si l'instance sélectionnée est supprimée.
L'affinité avec état basée sur les cookies n'est pas affectée lorsque l'autoréparation supprime une instance d'un groupe d'instances géré, sauf si l'instance sélectionnée est supprimée.
Pour en savoir plus, consultez Perte d'affinité de session.
Signification d'une valeur TTL nulle pour les affinités basées sur les cookies
Toutes les affinités de session basées sur les cookies, telles que l'affinité basée sur les cookies générés, l'affinité basée sur les cookies HTTP et l'affinité basée sur les cookies avec état, ont un attribut TTL.
Une TTL de zéro seconde signifie que l'équilibreur de charge n'attribue pas d'attribut Expires au cookie. Dans ce cas, le client traite le cookie comme un cookie de session. La définition d'une session varie en fonction du client :
Certains clients, comme les navigateurs Web, conservent le cookie pendant toute la session de navigation. Cela signifie que le cookie persiste pour plusieurs requêtes jusqu'à ce que l'application soit fermée.
D'autres clients traitent une session comme une seule requête HTTP et suppriment le cookie immédiatement après.
Perdre l'affinité de session
Toutes les options d'affinité de session pour les équilibreurs de charge d'application et les équilibreurs de charge réseau proxy nécessitent les éléments suivants :
L'instance ou le point de terminaison de backend sélectionnés doivent rester configurés en tant que backend. L'affinité de session peut être rompue lorsque l'un des événements suivants se produit :
Vous supprimez l'instance sélectionnée de son groupe d'instances.
L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime l'instance sélectionnée de son groupe d'instances géré.
Vous supprimez le point de terminaison sélectionné de son NEG.
Vous supprimez du service de backend le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionnés.
L'instance ou le point de terminaison de backend sélectionnés doivent rester opérationnels. L'affinité de session peut cesser lorsque l'instance ou le point de terminaison sélectionnés échouent aux vérifications de l'état.
Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques, les équilibreurs de charge réseau proxy externes globaux et les équilibreurs de charge réseau proxy classiques, l'affinité de session peut être rompue si un autre Google Front End (GFE) de première couche est utilisé pour les requêtes ou connexions ultérieures après la modification du chemin de routage. Un autre GFE de première couche peut être sélectionné si le chemin de routage d'un client sur Internet vers Google change entre les requêtes ou les connexions.
À l'exception de l'affinité de session basée sur les cookies avec état, toutes les options d'affinité de session pour les équilibreurs de charge d'application et les équilibreurs de charge réseau proxy présentent les exigences supplémentaires suivantes :
Le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné ne doit pas être complet, comme défini par sa capacité cible. (Pour les groupes d'instances gérés régionaux, le composant zonal du groupe d'instances contenant l'instance sélectionnée ne doit pas être complet.) L'affinité de session peut être interrompue lorsque le groupe d'instances ou le NEG est plein et que d'autres groupes d'instances ou NEG ne le sont pas. Étant donné que la capacité peut changer de manière imprévisible lorsque vous utilisez le mode d'équilibrage
UTILIZATION, vous devez utiliser le mode d'équilibrageRATEouCONNECTIONpour minimiser les situations où l'affinité de session peut être rompue.Le nombre total d'instances ou de points de terminaison de backend configurés doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend configurés change, et l'affinité de session peut être interrompue :
Ajouter des instances ou des points de terminaison :
- Vous ajoutez des instances à un groupe d'instances existant sur le service de backend.
- L'autoscaling de groupe d'instances géré ajoute des instances à un groupe d'instances géré sur le service de backend.
- Vous ajoutez des points de terminaison à un NEG existant sur le service de backend.
- Vous ajoutez des groupes d'instances ou des NEG non vides au service de backend.
Supprimer une instance ou un point de terminaison (pas seulement l'instance ou le point de terminaison sélectionné) :
- Vous supprimez une instance d'un backend de groupe d'instances.
- L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime toute instance d'un backend de groupe d'instances géré.
- Vous supprimez un point de terminaison d'un backend NEG.
- Supprimez tout groupe d'instances ou NEG backend existant et non vide du service de backend.
Le nombre total d'instances ou de points de terminaison de backend opérationnels doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend opérationnels change, et l'affinité de session peut être rompue :
- Une instance ou un point de terminaison réussit sa vérification de l'état l'état et passe de l'état "Non opérationnel" à l'état "Opérationnel".
- Une instance ou un point de terminaison échoue à la vérification de l'état de l'état et passe de l'état "opérationnel" à l'état "non opérationnel" ou "délai avant expiration".
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, 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 réseau passthrough interne et passthrough externes,vous pouvez définir la valeur du délai avant expiration du service de backend à l'aide de
gcloudou 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 champmaxStreamDuration. En effet, gRPC n'est pas compatible avec la sémantique detimeoutSecqui 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 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.
Google Cloud Armor
Si vous utilisez l'un des équilibreurs de charge suivants, vous pouvez ajouter une protection supplémentaire à vos applications en activant Google 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électionner une stratégie de sécurité Google Cloud Armor existante.
- Accepter la configuration d'une stratégie de sécurité Google 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 Google 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 Google 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-servicespour 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 :