Présentation de l'équilibreur de charge d'application interne

Ce document présente les concepts que vous devez maîtriser pour configurer des équilibreurs de charge d'application internes.

Un équilibreur de charge d'application interne Trusted Cloud by S3NS est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services derrière une adresse IP interne. L'équilibreur de charge d'application interne répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formes Trusted Cloud , telles que Compute Engine, Google Kubernetes Engine (GKE) et Cloud Run. Pour en savoir plus, consultez la section Cas d'utilisation.

Modes de fonctionnement

Cet équilibreur de charge est disponible en mode régional et est désigné ci-après par le terme "équilibreur de charge d'application interne régional". L'équilibreur de charge est mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Il comprend des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction d'une pondération, les transformations d'en-tête basées sur les requêtes ou les réponses, etc. Le mode régional exige que les backends se trouvent dans une même région Trusted Cloud . Les clients peuvent être limités à cette région ou se trouver dans n'importe quelle région, selon que l'accès mondial est désactivé ou activé sur la règle de transfert.

Architecture et ressources

Le schéma suivant présente les ressources Trusted Cloud requises pour les équilibreurs de charge d'application internes :

Équilibreur de charge d'application interne régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge d'application interne régional de niveau Premium.

Composants de l'équilibreur de charge d'application interne
Composants de l'équilibreur de charge d'application interne régional (cliquez pour agrandir).

Les ressources suivantes sont requises pour déployer un équilibreur de charge d'application interne :

Sous-réseau proxy réservé

Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge d'application internes régionaux. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent un pool de proxys Envoy du même sous-réseau proxy réservé.

En outre :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • Les VM de backend ou les points de terminaison de tous les équilibreurs de charge d'application internes situés dans une région et sur un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP virtuelle d'un équilibreur de charge d'application interne n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en interne et décrite ci-dessous.

Règle de transfert et adresse IP

Les règles de transfert permettent d'acheminer le trafic par adresse IP, par port et par protocole, vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.

Spécification de l'adresse IP. Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Vous pouvez soit réserver une adresse IP statique qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une pour votre compte. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert et en créez une autre.

Les clients utilisent l'adresse IP et le port pour se connecter aux proxys Envoy de l'équilibreur de charge. L'adresse IP de la règle de transfert correspond à l'adresse IP de l'équilibreur de charge (parfois appelée adresse IP virtuelle ou VIP). Les clients se connectant à un équilibreur de charge doivent utiliser HTTP version 1.1 ou ultérieure. Pour obtenir la liste complète des protocoles acceptés, consultez la page Comparaison des fonctionnalités de l'équilibreur de charge.

L'adresse IP interne associée à la règle de transfert peut provenir d'un sous-réseau du même réseau et de la même région que vos backends.

Spécification du port Chaque règle de transfert d'un équilibreur de charge d'application peut référencer un port unique compris entre 1 et 65 535. Pour accepter plusieurs ports, vous devez configurer plusieurs règles de transfert. Vous pouvez configurer plusieurs règles de transfert pour utiliser la même adresse IP interne (VIP) et référencer le même proxy HTTP ou HTTPS cible tant que la combinaison globale de l'adresse IP, du port et du protocole sont uniques pour chaque règle de transfert. Vous pouvez ainsi utiliser un seul équilibreur de charge avec un mappage d'URL partagé en tant que proxy pour plusieurs applications.

Le type de règle de transfert, d'adresse IP et de schéma d'équilibrage de charge utilisé par les équilibreurs de charge d'application internes dépend du mode de l'équilibreur de charge.

Équilibreur de charge d'application interne régional
Règle de transfert

Méthode forwardingRules.insert
Adresse IP régionale

Méthode addresses.insert
Schéma d'équilibrage de charge

INTERNAL_MANAGED
Adresse IP (facultatif)

SHARED_LOADBALANCER_VIP
Routage depuis le client vers l'interface de l'équilibreur de charge

Vous pouvez activer l'accès global pour autoriser les clients de n'importe quelle région d'un VPC à accéder à votre équilibreur de charge. Les backends doivent également se trouver dans la même région que l'équilibreur de charge.

Règles de transfert et réseaux VPC

Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application internes sont associées aux réseaux VPC.

Mode d'équilibreur de charge Association de réseaux VPC
Équilibreur de charge d'application interne régional

Les adresses IPv4 internes régionales existent toujours dans les réseaux VPC. Lorsque vous créez la règle de transfert, vous devez spécifier le sous-réseau à partir duquel l'adresse IP interne est extraite. Ce sous-réseau doit se trouver dans la même région et le même réseau VPC qu'un sous-réseau proxy réservé. Il existe donc une association de réseau implicite.

Proxy cible

Un proxy HTTP ou HTTPS cible met fin aux connexions HTTP(S) des clients. Le proxy HTTP(S) consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends. Un proxy HTTPS cible utilise un certificat SSL pour s'authentifier auprès des clients.

L'équilibreur de charge conserve l'en-tête "Host" de la requête du client d'origine. L'équilibreur de charge ajoute également deux adresses IP à l'en-tête X-Forwarded-For :

  • Adresse IP du client qui se connecte à l'équilibreur de charge
  • Adresse IP de la règle de transfert de l'équilibreur de charge

Si aucun en-tête X-Forwarded-For n'est présent dans la requête entrante, ces deux adresses IP correspondent à l'intégralité de la valeur d'en-tête. Si la requête comporte un en-tête X-Forwarded-For, d'autres informations, telles que les adresses IP enregistrées par les proxys au route vers l'équilibreur de charge, sont conservées avant les deux adresses IP. L'équilibreur de charge ne vérifie aucune adresse IP antérieure aux deux dernières adresses IP de cet en-tête.

Si vous exécutez un proxy en guise de serveur backend, ce proxy ajoute généralement plus d'informations à l'en-tête X-Forwarded-For. Votre logiciel devra peut-être en tenir compte. Les requêtes proxy de l'équilibreur de charge proviennent d'une adresse IP du sous-réseau proxy réservé, et votre proxy sur l'instance backend peut enregistrer cette adresse, ainsi que l'adresse IP de l'instance backend.

Selon le type de trafic que votre application doit gérer, vous pouvez configurer un équilibreur de charge avec un proxy HTTP cible ou HTTPS cible.

Le tableau suivant présente les API de proxy cibles requises par les équilibreurs de charge d'application internes :

Mode d'équilibreur de charge Proxy cible
Équilibreur de charge d'application interne régional

Certificats SSL

Les équilibreurs de charge d'application internes utilisant des proxys HTTPS cibles nécessitent des clés privées et des certificats SSL dans la configuration de l'équilibreur de charge.

Les équilibreurs de charge d'application internes régionaux sont compatibles avec les certificats SSL Compute Engine autogérés.

Mappages d'URL

Le proxy HTTP(S) cible utilise des mappages d'URL pour déterminer le routage en fonction d'attributs HTTP (chemin de requête, cookies ou en-têtes, par exemple). En s'appuyant sur le routage choisi, le proxy transmet les requêtes des clients à des services de backend régionaux spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires à effectuer, telles que la réécriture d'en-têtes, l'envoi de redirections à des clients et la configuration de règles de délais avant expiration, entre autres.

Le tableau suivant spécifie le type de mappage d'URL requis par les équilibreurs de charge d'application externes dans chaque mode.

Mode d'équilibreur de charge Type de mappage d'URL
Équilibreur de charge d'application interne régional regionUrlMaps

Service de backend

Un service de backend fournit des informations de configuration à l'équilibreur de charge afin qu'il puisse diriger les requêtes vers ses backends (par exemple, des groupes d'instances Compute Engine ou des groupes de points de terminaison du réseau (NEG)). Pour en savoir plus sur les services de backend, consultez la présentation des services de backend.

Champ d'application du service de backend

Le tableau suivant indique la ressource et le champ d'application du service de backend utilisés par les équilibreurs de charge d'application internes :

Mode d'équilibreur de charge Ressources du service de backend
Équilibreur de charge d'application interne régional regionBackendServices

Protocole de communication avec les backends

Les services de backend pour les équilibreurs de charge d'application doivent utiliser l'un des protocoles suivants pour envoyer des requêtes aux backends :

  • HTTP, qui utilise HTTP/1.1 et aucun protocole TLS
  • HTTPS, qui utilise HTTP/1.1 et TLS
  • HTTP/2, qui utilise HTTP/2 et TLS (HTTP/2 sans chiffrement n'est pas accepté)
  • H2C, qui utilise HTTP/2 sur TCP. Le protocole TLS n'est pas requis. H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

L'équilibreur de charge n'utilise que le protocole de service de backend que vous spécifiez pour communiquer avec ses backends. S'il ne parvient pas à communiquer avec les backends à l'aide du protocole de service de backend spécifié, l'équilibreur de charge ne recourt pas à un autre protocole.

Le protocole du service de backend ne doit pas nécessairement correspondre au protocole utilisé par les clients pour communiquer avec l'équilibreur de charge. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge à l'aide du protocole HTTP/2, mais l'équilibreur de charge peut communiquer avec les backends à l'aide du protocole HTTP/1.1 (HTTP ou HTTPS).

Backends

Un équilibreur de charge d'application externe régional est compatible avec les types de backends suivants :

  • Groupes d'instances
  • NEG zonaux
  • NEG Internet
  • NEG hybrides

Backends et réseaux VPC

Les restrictions concernant l'emplacement des backends dépendent du type de backend.

  • Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent être situés dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un autre réseau VPC dans le même projet que le service de backend. La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC du backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN ou de rattachements de VLAN Cloud Interconnect.

    Définition du réseau de backend

    • Pour les NEG zonaux et hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
    • Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
    • Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini pour correspondre au réseau VPC de l'interface nic0 de la première VM ajoutée au groupe d'instances.

    Exigences du réseau de backend

    Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :

    • Le réseau VPC du backend doit correspondre exactement à celui de la règle de transfert.

    • Le réseau VPC du backend doit être connecté à celui de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer les échanges de routes de sous-réseau pour permettre la communication entre le sous-réseau proxy réservé dans le réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison de backend.

  • Pour tous les autres types de backend, tous les backends doivent se trouver dans le même réseau VPC et dans la même région.

Backends et interfaces réseau

Si vous utilisez des backends de groupe d'instances, les paquets sont toujours distribués à nic0. Si vous souhaitez envoyer des paquets à des interfaces non nic0 (vNIC ou interfaces réseau dynamiques), utilisez plutôt des backends de NEG.

Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.

Sous-paramètre du backend

Le sous-paramètre de backend est une fonctionnalité facultative compatible avec les équilibreurs de charge d'application internes régionaux 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 désactivé par défaut. Pour en savoir plus sur l'activation de cette fonctionnalité, consultez la page Sous-paramètre de backend pour les équilibreurs de charge d'application internes régionaux.

Vérifications d'état

Chaque service de backend spécifie une vérification d'état qui vérifie régulièrement que les backends sont disponibles et aptes à recevoir une connexion de l'équilibreur de charge. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter. Les vérifications d'état ne vérifient pas si l'application elle-même fonctionne.

Pour les vérifications d'état, vous devez créer une règle de pare-feu autorisant le trafic entrant qui permet aux vérifications d'état d'atteindre vos instances backend. En règle générale, les vérifications d'état proviennent du mécanisme de vérification d'état centralisé de Google. Toutefois, pour les NEG hybrides, les vérifications d'état proviennent du sous-réseau proxy réservé. Pour en savoir plus, consultez Vérifications de l'état Envoy distribuées.

Protocole de vérification d'état

Bien que ce ne soit pas obligatoire et pas toujours possible, il est recommandé d'utiliser une vérification de l'état d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état HTTP/2 permet de tester plus précisément la connectivité HTTP/2 aux backends. En revanche, les équilibreurs de charge d'application internes qui utilisent des backends NEG hybrides ne sont pas compatibles avec les vérifications d'état gRPC. Pour obtenir la liste des protocoles de vérification de l'état compatibles, consultez les fonctionnalités d'équilibrage de charge dans la section Vérifications d'état.

Le tableau suivant spécifie le champ d'application des vérifications d'état compatibles avec les équilibreurs de charge d'application internes :

Mode d'équilibreur de charge Type de vérification d'état
Équilibreur de charge d'application interne régional regionHealthChecks

Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :

Règles de pare-feu

Un équilibreur de charge d'application interne nécessite les règles de pare-feu suivantes:

  • Une règle d'autorisation d'entrée qui autorise le trafic provenant des plages de vérification de l'état d'état centrales de Google. Pour en savoir plus sur les plages d'adresses IP de vérification de l'état d'état spécifiques et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.
  • Une règle d'autorisation d'entrée qui autorise le trafic provenant du sous-réseau proxy réservé

Il existe certaines exceptions aux exigences des règles de pare-feu pour ces plages :

  • Il n'est pas nécessaire d'autoriser le trafic provenant des plages de vérification de l'état de l'état de Google pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez autoriser le trafic provenant des plages de vérification de l'état de l'état Google pour les NEG zonaux.
  • Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge qui utilisent des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est traduit par la NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez NEG régionaux : utiliser une passerelle Cloud NAT.

Accès des clients

Les clients peuvent se trouver sur le même réseau ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC.

Pour les équilibreurs de charge d'application internes régionaux, les clients doivent se trouver dans la même région que l'équilibreur de charge par défaut. Vous pouvez activer l'accès global pour autoriser les clients de n'importe quelle région d'un VPC à accéder à votre équilibreur de charge.

Le tableau suivant récapitule l'accès des clients pour les équilibreurs de charge d'application internes régionaux :

Accès mondial désactivé Accès mondial activé
Les clients doivent se trouver dans la même région que l'équilibreur de charge. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC. Les clients peuvent se trouver dans n'importe quelle région. Ils doivent toujours se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.
Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements doivent se trouver dans la même région que l'équilibreur de charge. Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements peuvent se trouver dans n'importe quelle région.

Assistance GKE

GKE utilise des équilibreurs de charge d'application internes de différentes manières :

  • Les passerelles internes créées à l'aide du contrôleur GKE Gateway peuvent utiliser n'importe quel mode d'équilibreur de charge d'application interne. Vous contrôlez le mode de l'équilibreur de charge en choisissant une GatewayClass. Le contrôleur GKE Gateway utilise toujours des backends NEG zonaux GCE_VM_IP_PORT.

  • Les entrées internes créées à l'aide du contrôleur GKE Ingress sont toujours des équilibreurs de charge d'application internes régionaux. Le contrôleur GKE Ingress utilise toujours des backends de NEG zonaux GCE_VM_IP_PORT.

Architectures de VPC partagé

Les équilibreurs de charge d'application internes sont compatibles avec les réseaux qui utilisent un VPC partagé. Un VPC partagé permet à des organisations de connecter des ressources provenant de différents projets à un réseau VPC commun, afin de pouvoir communiquer entre elles de manière sécurisée et efficace à l'aide d'adresses IP internes de ce réseau. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.

Il existe plusieurs façons de configurer un équilibreur de charge d'application interne dans un réseau VPC partagé. Quel que soit le type de déploiement, tous les composants de l'équilibreur de charge doivent appartenir à la même organisation.

Sous-réseaux et adresse IP Composants d'interface Composants backend

Créez le réseau et les sous-réseaux (y compris le sous-réseau proxy réservé) requis dans le projet hôte de VPC partagé.

L'adresse IP interne de l'équilibreur de charge peut être définie dans le projet hôte ou dans un projet de service, mais elle doit utiliser un sous-réseau dans le réseau VPC partagé souhaité dans le projet hôte. L'adresse elle-même provient de la plage d'adresses IP principale du sous-réseau référencé.

 L'adresse IP interne régionale, la règle de transfert, le proxy HTTP(S) cible et le mappage d'URL associé doivent être définis dans le même projet. Ce projet peut être un projet hôte ou un projet de service. Vous pouvez effectuer l'une des actions suivantes :
  • Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans le même projet de service que les composants d'interface.
  • Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans autant de projets de service que nécessaire. Un seul mappage d'URL peut référencer des services de backend sur différents projets. Ce type de déploiement est appelé référence de services inter-projets.

Chaque service de backend doit être défini dans le même projet que les backends auxquels il fait référence. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.

Bien que vous puissiez créer tous les composants et les backends d'équilibrage de charge dans le projet hôte de VPC partagé, ce type de déploiement ne sépare pas les responsabilités d'administration réseau et de développement de services.

Tous les composants et les backends de l'équilibreur de charge dans un projet de service

Le schéma d'architecture suivant illustre un déploiement de VPC partagé standard dans lequel tous les composants et les backends de l'équilibreur de charge se trouvent dans un projet de service. Ce type de déploiement est compatible avec tous les équilibreurs de charge d'application.

L'équilibreur de charge utilise les adresses IP et les sous-réseaux du projet hôte. Les clients peuvent accéder à un équilibreur de charge d'application interne s'ils se trouvent dans le même réseau VPC partagé et la même région que l'équilibreur de charge. Les clients peuvent se situer dans le projet hôte, dans un projet de service associé ou dans n'importe quel réseau connecté.

Équilibreur de charge d'application interne sur un réseau VPC partagé.
Équilibreur de charge d'application interne sur un réseau VPC partagé (cliquez pour agrandir).

Backends sans serveur dans un environnement VPC partagé

Pour un équilibreur de charge d'application interne qui utilise un backend de NEG sans serveur, le service de sauvegarde Cloud Run doit se trouver dans le même projet de service que le service de backend et le NEG sans serveur. Les composants d'interface de l'équilibreur de charge (règle de transfert, proxy cible, mappage d'URL) peuvent être créés dans le projet hôte, dans le même projet de service que les composants backend ou dans tout autre projet de service du même environnement VPC partagé.

Référence de services inter-projets

La référence de services inter-projets est un modèle de déploiement dans lequel l'interface et le mappage d'URL de l'équilibreur de charge se trouvent dans un projet, tandis que le service de backend et les backends de l'équilibreur de charge se trouvent dans un autre projet.

Le référencement de services inter-projets permet aux organisations de configurer un équilibreur de charge central et d'acheminer le trafic vers des centaines de services répartis sur plusieurs projets différents. Vous pouvez gérer toutes les règles et stratégies de routage du trafic de manière centralisée dans un mappage d'URL. Vous pouvez également associer l'équilibreur de charge à un seul ensemble de noms d'hôte et de certificats SSL. Par conséquent, vous pouvez optimiser le nombre d'équilibreurs de charge nécessaires au déploiement de votre application et réduire les coûts de gestion, d'exploitation et de quota.

En disposant de projets différents pour chacune de vos équipes fonctionnelles, vous pouvez également assurer la séparation des rôles au sein de votre organisation. Les propriétaires de service peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes réseau peuvent provisionner et gérer des équilibreurs de charge dans un autre projet, et les deux peuvent être connectées à l'aide du référencement de services inter-projets.

Les propriétaires de services peuvent conserver leur autonomie quant à l'exposition de leurs services et contrôler quels utilisateurs peuvent y accéder à l'aide de l'équilibreur de charge. Ce procédé fait appel à un rôle IAM spécial appelé Rôle "Utilisateur des services d'équilibreur de charge Compute" (roles/compute.loadBalancerServiceUser).

Pour les équilibreurs de charge d'application internes, le référencement des services inter-projets n'est compatible qu'avec les environnements VPC partagés.

Pour apprendre à configurer un VPC partagé pour un équilibreur de charge d'application interne, avec et sans référence de services inter-projets, consultez la page Configurer un équilibreur de charge d'application interne avec un VPC partagé.

Remarques sur l'utilisation du référencement des services inter-projets

  • Vous ne pouvez pas référencer de service de backend multiprojet si le service de backend comporte des backends NEG Internet régionaux. Tous les autres types de backends sont acceptés.
  • Trusted Cloud ne fait pas de distinction entre les ressources (par exemple, les services de backend) utilisant le même nom sur plusieurs projets. Par conséquent, lorsque vous utilisez le référencement de services multiprojet, nous vous recommandons d'utiliser des noms de service de backend uniques pour tous les projets de votre organisation.

Exemple 1 : interface et backend de l'équilibreur de charge dans des projets de service différents

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet de service A, et le mappage d'URL référence un service de backend dans le projet de service B.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibrage de charge du projet de service A nécessitent un accès aux services de backend du projet de service B. Les administrateurs du projet de service B attribuent le rôle Utilisateur des services de l'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet de service A qui souhaitent référencer le service de backend dans le projet de service B.

Interface et mappage d'URL de l'équilibreur de charge dans le projet de service.
Interface et backend de l'équilibreur de charge dans différents projets de service (cliquez pour agrandir).

Exemple 2 : interface de l'équilibreur de charge dans le projet hôte et backends dans les projets de service

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet hôte, et les services de backend (et les backends) sont créés dans les projets de service.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibreur de charge du projet hôte requièrent un accès aux services de backend dans le projet de service. Les administrateurs de projets de service accordent le rôle Utilisateur des services de l'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet hôte A qui souhaitent référencer le service de backend dans le projet de service.

Interface et mappage d'URL de l'équilibreur de charge dans le projet hôte.
Interface et mappage d'URL de l'équilibreur de charge dans le projet hôte (cliquez pour agrandir).

Délais d'expiration et nouvelles tentatives

Les équilibreurs de charge d'application internes sont compatibles avec les types de délais d'expiration suivants:

Type de délai d'expiration et description Valeurs par défaut Valeurs personnalisées acceptées
Délai avant expiration du service de backend

Un délai avant expiration de la requête et de la réponse Représente la durée maximale autorisée entre le moment où l'équilibreur de charge envoie le premier octet d'une requête au backend et le moment où celui-ci renvoie le dernier octet de la réponse HTTP à l'équilibreur de charge. Si le backend n'a pas renvoyé la réponse HTTP entière à l'équilibreur de charge dans ce délai, les données de réponse restantes sont supprimées.
  • Pour les NEG sans serveur sur un service de backend : 60 minutes
  • Pour tous les autres types de backends sur un service de backend: 30 secondes
Délai d'expiration du message keepalive HTTP client

Durée maximale d'inactivité de la connexion TCP entre un client et le proxy Envoy géré de l'équilibreur de charge. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.)

 610 secondes
Délai avant expiration du message keepalive HTTP du backend

Durée maximale d'inactivité de la connexion TCP entre le proxy Envoy géré de l'équilibreur de charge et un backend. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.)

 10 minutes (600 secondes)

Délai avant expiration du service de backend

Le délai avant expiration du service backend configurable représente la durée maximale pendant laquelle l'équilibreur de charges attend que de votre backend traite une requête HTTP et renvoie la réponse HTTP correspondante. À l'exception des NEG sans serveur, la valeur par défaut du délai avant expiration du service de backend est de 30 secondes.

Par exemple, si vous souhaitez télécharger un fichier de 500 Mo et que la valeur du délai avant expiration du service de backend est de 90 secondes, l'équilibreur de charge s'attend à ce que le backend fournisse l'intégralité du fichier de 500 Mo dans un délai de 90 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il soit insuffisant pour envoyer une réponse HTTP complète. Dans ce cas, si l'équilibreur de charge a au moins reçu des en-têtes de réponse HTTP du backend, il renvoie les en-têtes de réponse complets et tout ce qu'il a pu tirer du corps de réponse dans le délai avant expiration du service de backend.

Nous vous recommandons de définir le délai avant expiration du service de backend sur la durée la plus longue attendue par votre backend pour traiter une réponse HTTP. Si le logiciel exécuté sur votre backend a besoin de plus de temps pour traiter une requête HTTP et renvoyer sa réponse complète, nous vous recommandons d'augmenter le délai avant expiration du service de backend.

Le délai avant expiration du service de backend accepte des valeurs comprises entre 1 et 2,147,483,647 secondes. Cependant, les valeurs plus élevées ne sont pas des options pratiques de configuration.Trusted Cloud ne garantit pas non plus qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de compter sur une connexion TCP pour être ouverte pendant de longues périodes.

Pour les connexions WebSocket utilisées avec les équilibreurs de charge d'application internes, les connexions WebSocket actives ne suivent pas le délai avant expiration du service de backend. Les connexions WebSocket inactives sont fermées au terme du délai avant expiration du service de backend.

Trusted Cloud redémarre ou modifie périodiquement le nombre de tâches logicielles Envoy servies. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que les tâches de redémarrage ou de remplacement d'Envoy interrompent les connexions TCP.

Pour configurer le délai avant expiration du service de backend, utilisez l'une des méthodes suivantes :

Console

Modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.

gcloud

Utilisez la commande gcloud compute backend-services update pour modifier le paramètre --timeout de la ressource du service de backend.

API

Modifiez le paramètre timeoutSec pour la ressource regionBackendServices.

Délai d'expiration du message keepalive HTTP client

Le délai avant expiration du message keepalive HTTP du client représente la durée maximale pendant laquelle une connexion TCP peut être inactive entre le client (en aval) et un proxy Envoy. La valeur par défaut du délai avant expiration du message keepalive HTTP client est de 610 secondes. Vous pouvez configurer le délai avant expiration avec une valeur comprise entre 5 et 1 200 secondes.

Un délai avant expiration du message keepalive HTTP est également appelé délai d'inactivité TCP.

Le délai d'expiration du message keepalive HTTP client de l'équilibreur de charge doit être supérieur au délai d'expiration du message keepalive HTTP (TCP inactif) utilisé par les clients ou les proxys en aval. Si un client en aval possède un délai avant expiration du message keepalive HTTP (TCP inactif) supérieur à celui de l'équilibreur de charge, il est possible qu'une condition de concurrence se produise. Du point de vue d'un client en aval, une connexion TCP établie est autorisée à être inactive plus longtemps que l'équilibreur de charge ne le permet. Cela signifie que le client en aval peut envoyer des paquets après que l'équilibreur de charge considère la connexion TCP comme fermée. Dans ce cas, l'équilibreur de charge répond par un paquet de réinitialisation TCP (RST).

Lorsque le délai avant expiration du message keepalive HTTP du client est écoulé, le GFE ou le proxy Envoy envoie un message TCP FIN au client pour fermer la connexion en douceur.

Délai avant expiration du message keepalive HTTP du backend

Les équilibreurs de charge d'application internes sont des proxys qui utilisent une première connexion TCP entre le client (en aval) et un proxy Envoy, et une deuxième connexion TCP entre le proxy Envoy et vos backends.

les connexions TCP secondaires de l'équilibreur de charge peuvent ne pas être fermées après chaque requête ; elles peuvent rester ouvertes pour gérer plusieurs requêtes et réponses HTTP. Le délai avant expiration du message keepalive HTTP du backend définit le délai d'inactivité TCP entre l'équilibreur de charge et vos backends. Le délai avant expiration du message keepalive HTTP du backend ne s'applique pas aux WebSockets.

Le délai avant expiration du message keepalive du backend est fixé à 10 minutes (600 secondes) et ne peut pas être modifié. Cela permet de s'assurer que l'équilibreur de charge maintient les connexions inactives pendant au moins 10 minutes. Passé ce délai, l'équilibreur de charge peut envoyer des paquets de fin de connexion au backend à tout moment.

Le délai d'expiration du message keepalive du backend de l'équilibreur de charge doit être inférieur au délai d'expiration du message keepalive utilisé par les logiciels exécutés sur vos backends. Cela évite une condition de concurrence où le système d'exploitation de vos backends peut fermer les connexions TCP avec une réinitialisation TCP (RST). Étant donné que le délai avant expiration du message keepalive du backend pour l'équilibreur de charge n'est pas configurable, vous devez configurer votre logiciel backend de sorte que sa valeur de délai avant expiration de message keepalive HTTP (TCP inactive) soit supérieure à 600 secondes.

Lorsque le délai avant expiration du message keepalive HTTP du backend expire, le GFE ou le proxy Envoy envoie un message TCP FIN à la VM de backend pour fermer correctement la connexion.

Le tableau suivant répertorie les modifications à effectuer pour modifier les valeurs du délai d'expiration du message keepalive pour les logiciels de serveur Web courants.

Logiciel de serveur Web Paramètre Paramètre par défaut Réglage recommandé
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Tentatives

Pour configurer les nouvelles tentatives, vous pouvez utiliser une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de tentatives par défaut (numRetries) est de 1. La valeur maximale configurable de perTryTimeout est de 24 heures.

Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) qui aboutissent à des réponses HTTP 502, 503 ou 504 sont relancées. une fois.

Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative.

Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale.

Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibreur de charge d'application interne.

Accès aux réseaux connectés

Vos clients peuvent accéder à un équilibreur de charge d'application interne dans votre réseau VPC à partir d'un réseau connecté à l'aide des éléments suivants :

  • Appairage de réseaux VPC
  • Cloud VPN et Cloud Interconnect

Pour obtenir des exemples détaillés, consultez la page Équilibreurs de charge d'application internes et réseaux connectés.

Affinité de session

L'affinité de session, configurée sur le service de backend des équilibreurs de charge d'application, tente au mieux d'envoyer les requêtes d'un client donné au même backend, à condition que le nombre d'instances ou de points de terminaison de backend opérationnels reste constant et que l'instance ou le point de terminaison de backend sélectionné précédemment ne soit pas saturé. La capacité cible du mode d'équilibrage détermine à quel moment le backend est saturé.

Le tableau suivant présente les différents types d'options d'affinité de session compatibles avec les différents équilibreurs de charge d'application. Dans la section Types d'affinité de session ci-dessous, chaque type d'affinité de session est décrit plus en détail.

Tableau : Paramètres d'affinité de session compatibles
Produit Options d'affinité de session
  • Aucune (NONE)
  • Adresse IP client (CLIENT_IP)
  • Cookie généré (GENERATED_COOKIE)
  • Champ d'en-tête (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Affinité avec état basée sur les cookies (STRONG_COOKIE_AFFINITY)

Sachez également 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 les équilibreurs de charge d'application internes, ne configurez pas l'affinité de session si vous utilisez la répartition du trafic pondérée. Sinon, la configuration de la répartition du trafic pondérée est prioritaire.

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, peut 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-affinity et --subsetting-policy sont NONE, et une seule d'entre elles peut être définie sur une valeur différente.

Types d'affinité de session

L'affinité de session pour les équilibreurs de charge d'application internes peut être classée dans l'une des catégories suivantes :
  • Affinité de session basée sur le hachage (NONE, CLIENT_IP)
  • Affinité de session basée sur l'en-tête HTTP (HEADER_FIELD)
  • Affinité de session basée sur les cookies (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Affinité de session basée sur le hachage

Pour l'affinité de session basée sur le hachage, l'équilibreur de charge utilise l'algorithme de hachage cohérent pour sélectionner un backend éligible. Le paramètre d'affinité de session détermine les champs de l'en-tête IP utilisés pour calculer le hachage.

L'affinité de session basée sur le hachage peut être de l'un des types suivants :

Aucun

Un paramètre d'affinité de session de NONE ne signifie pas qu'il n'y a pas d'affinité de session. Cela signifie qu'aucune option d'affinité de session n'est explicitement configurée.

Le hachage est toujours effectué pour sélectionner un backend. Un paramètre d'affinité de session NONE signifie que l'équilibreur de charge utilise un hachage à cinq tuples pour sélectionner un backend. Le hachage à cinq tuples est constitué de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

La valeur par défaut de l'affinité de session est NONE.

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é basée sur les adresses IP client permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.

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 à l'adresse IP de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
  • 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 Trusted 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é de session basée sur l'en-tête HTTP

Avec l'affinité basée sur le champ d'en-tête (HEADER_FIELD), 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.

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 consistentHash du service de backend spécifie le nom de l'en-tête HTTP (httpHeaderName).

L'affinité de session basée sur les cookies peut être de l'un des types suivants :

Lorsque vous utilisez l'affinité basée sur les cookies générés (GENERATED_COOKIE), 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.

Produit Nom du cookie
Équilibreurs de charge d'application internes interrégionaux GCILB
Équilibreurs de charge d'application internes régionaux 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é basée sur les cookies générés.

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 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 localityLbPolicy du service de backend, utilisez RING_HASH ou MAGLEV. Si vous ne définissez pas explicitement localityLbPolicy, l'équilibreur de charge utilise MAGLEV comme valeur par défaut implicite.

Pour en savoir plus, consultez Perte d'affinité de session.

Lorsque vous utilisez l'affinité basée sur les cookies HTTP (HTTP_COOKIE), 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 sont compatibles avec l'affinité basée sur les cookies HTTP.

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.seconds peut être défini sur une valeur comprise entre 0 et 315576000000 (inclus).
  • consistentHash.httpCookie.ttl.nanos peut être défini sur une valeur comprise entre 0 et 999999999 (inclus). Comme les unités sont exprimées en nanosecondes, 999999999 signifie .999999999 secondes.

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 localityLbPolicy du service de backend, utilisez RING_HASH ou MAGLEV. Si vous ne définissez pas explicitement localityLbPolicy, l'équilibreur de charge utilise MAGLEV comme 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é basée sur les cookies avec état (STRONG_COOKIE_AFFINITY), l'équilibreur de charge inclut un cookie HTTP dans l'en-tête Set-Cookie en réponse à la requête HTTP initiale. Vous devez spécifier le nom, le chemin d'accès et la durée de vie (TTL) du cookie.

Les équilibreurs de charge suivants sont compatibles avec l'affinité avec état basée sur les cookies :

  • Équilibreurs de charge d'application externes régionaux
  • Équilibreurs de charge d'application internes régionaux

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 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.
À l'exception de l'affinité de session avec état basée sur les cookies, toutes les options d'affinité de session sont soumises aux 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'équilibrage RATE ou CONNECTION pour 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".

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels.

Le tableau suivant décrit le comportement de basculement dans chaque mode :

Mode d'équilibreur de charge Comportement de basculement Comportement lorsque tous les backends ne sont pas opérationnels
Équilibreur de charge d'application interne régional

Basculement automatique vers des backends opérationnels dans la même région.

Le proxy Envoy envoie le trafic aux backends opérationnels dans une région en fonction de la répartition du trafic configurée.

 Renvoie HTTP 503

Haute disponibilité et basculement interrégional

Pour les équilibreurs de charge d'application internes régionaux :

Pour atteindre une haute disponibilité, déployez plusieurs équilibreurs de charge d'application internes régionaux individuels dans les régions qui prennent le mieux en charge le trafic de votre application. Vous utilisez ensuite une règle de routage par géolocalisation Cloud DNS pour détecter si un équilibreur de charge répond lors d'une panne régionale. Une règle de géolocalisation achemine le trafic vers la région disponible la plus proche en fonction de l'origine de la requête client. La vérification de l'état est disponible par défaut pour les équilibreurs de charge d'application internes.

Assistance WebSocket

Trusted Cloud Les équilibreurs de charge HTTP(S) sont compatibles avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS comme protocole avec le backend. L'équilibreur de charge ne nécessite aucune configuration pour relayer les connexions WebSocket par proxy.

Le protocole WebSocket fournit un canal de communication full-duplex entre les clients et l'équilibreur de charge. Pour plus d'informations, consultez la norme RFC 6455.

Le protocole WebSocket fonctionne comme suit :

  1. L'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP ou HTTPS. La requête contient les en-têtes Connection: Upgrade et Upgrade: websocket, suivis d'autres en-têtes de requête pertinents liés à WebSocket.
  2. Le backend envoie une réponse WebSocket Upgrade. L'instance de backend envoie une réponse 101 switching protocol avec les en-têtes Connection: Upgrade et Upgrade: websocket, ainsi que d'autres en-têtes de réponse liés à WebSocket.
  3. L'équilibreur de charge établit un trafic bidirectionnel par proxy pendant la durée de la connexion actuelle.

Si l'instance de backend renvoie un code d'état 426 ou 502, l'équilibreur de charge ferme la connexion.

L'affinité de session pour WebSockets fonctionne de la même manière que pour toute autre requête. Pour plus d'informations, consultez la section Affinité de session.

Compatibilité HTTP/2

HTTP/2 est une révision majeure du protocole HTTP/1. Il existe deux modes de compatibilité avec HTTP/2 :

  • HTTP/2 sur TLS
  • HTTP/2 en texte clair sur TCP

HTTP/2 sur TLS

Le protocole HTTP/2 sur TLS est accepté pour les connexions entre les clients et l'équilibreur de charge d'application externe, ainsi que pour les connexions entre l'équilibreur de charge et ses backends.

L'équilibreur de charge négocie automatiquement le protocole HTTP/2 avec les clients dans le cadre du handshake TLS à l'aide de l'extension TLS ALPN. Même si un équilibreur de charge est configuré pour utiliser HTTPS, les clients modernes utilisent par défaut HTTP/2. Ce fonctionnement est contrôlé au niveau du client et non au niveau de l'équilibreur de charge.

Si un client n'est pas compatible avec le protocole HTTP/2 et que l'équilibreur de charge est configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend, l'équilibreur de charge peut toujours négocier une connexion HTTPS ou accepter des requêtes HTTP non sécurisées. Ces requêtes HTTPS ou HTTP sont ensuite transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Pour utiliser HTTP/2 sur TLS, vous devez activer TLS sur vos backends et définir le protocole du service de backend sur HTTP2. Pour en savoir plus, consultez Chiffrement entre l'équilibreur de charge et les backends.

Nombre maximal de flux simultanés HTTP/2

Le paramètre SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 décrit le nombre maximal de flux accepté par le point de terminaison (flux lancés par le point de terminaison pair). La valeur annoncée par un client HTTP/2 à un équilibreur de chargeTrusted Cloud est sans importance, car l'équilibreur de charge ne lance pas de flux vers le client.

Dans le cas où l'équilibreur de charge utilise HTTP/2 pour communiquer avec un serveur qui s'exécute sur une VM, l'équilibreur de charge respecte la valeur SETTINGS_MAX_CONCURRENT_STREAMS annoncée par le serveur. Si une valeur "zéro" est annoncée, l'équilibreur de charge ne peut pas transférer les requêtes vers le serveur, et cela peut générer des erreurs.

Limites liées à HTTP/2

  • Le protocole HTTP/2 entre l'équilibreur de charge et l'instance peut nécessiter beaucoup plus de connexions TCP à l'instance que HTTP ou HTTPS. Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP ou HTTPS, n'est pas disponible avec HTTP/2. Vous risquez par conséquent de constater des latences de backend élevées, car les connexions backend sont établies plus fréquemment.
  • Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec l'exécution du protocole WebSocket sur un seul flux d'une connexion HTTP/2 (RFC 8441).
  • Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec le serveur push.
  • Le taux d'erreur gRPC et le volume de requêtes ne sont pas visibles dans l'APITrusted Cloud ni dans la console Trusted Cloud . Si le point de terminaison gRPC renvoie une erreur, les journaux de l'équilibreur de charge et les données de surveillance signalent le code d'état HTTP 200 OK.

HTTP/2 en texte clair sur TCP (H2C)

HTTP/2 en texte clair sur TCP, également appelé H2C, vous permet d'utiliser HTTP/2 sans TLS. H2C est compatible avec les deux types de connexions suivants :

  • Connexions entre les clients et l'équilibreur de charge. Aucune configuration spéciale n'est requise.

  • Connexions entre l'équilibreur de charge et ses backends.

    Pour configurer H2C pour les connexions entre l'équilibreur de charge et ses backends, définissez le protocole du service de backend sur H2C.

La compatibilité avec H2C est également disponible pour les équilibreurs de charge créés à l'aide du contrôleur GKE Gateway et de Cloud Service Mesh.

H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

Compatibilité avec gRPC

gRPC est un framework Open Source pour les appels de procédure à distance. Il est basé sur le standard HTTP/2. Voici quelques exemples d'utilisation de gRPC :

  • Systèmes distribués à faible latence et hautement évolutifs
  • Développement de clients mobiles communiquant avec un serveur cloud
  • Conception de nouveaux protocoles devant être précis, efficaces et indépendants du langage
  • Conception à plusieurs couches pour permettre l'extension, l'authentification et la journalisation

Pour utiliser gRPC avec vos applications Trusted Cloud , vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Pour ce faire, créez un équilibreur de charge d'application avec l'une des configurations suivantes :

  • Pour un trafic non chiffré de bout en bout (sans TLS) : créez un équilibreur de charge HTTP (configuré avec un proxy HTTP cible). Vous pouvez également configurer l'équilibreur de charge pour qu'il utilise HTTP/2 pour les connexions non chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole du service de backend sur H2C.

  • Pour le trafic chiffré de bout en bout (avec TLS) : créez un équilibreur de charge HTTPS (configuré avec un proxy HTTPS cible et un certificat SSL). L'équilibreur de charge négocie le protocole HTTP/2 avec les clients dans le cadre du handshake SSL à l'aide de l'extension TLS ALPN.

    De plus, vous devez vous assurer que les backends peuvent gérer le trafic TLS et configurer l'équilibreur de charge pour qu'il utilise HTTP/2 pour les connexions chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole du service de backend sur HTTP2.

    L'équilibreur de charge peut toujours négocier le protocole HTTPS avec certains clients ou accepter des requêtes HTTP non sécurisées sur un équilibreur de charge configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend. Ces requêtes HTTP ou HTTPS sont transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Compatibilité avec TLS

Par défaut, lorsqu'il interrompt les requêtes SSL des clients, un proxy HTTPS cible n'accepte que les protocoles TLS 1.0, 1.1, 1.2 et 1.3.

Lorsque l'équilibreur de charge d'application interne utilise HTTPS comme protocole de service de backend, il peut négocier les protocoles TLS 1.2 ou 1.3 vers le backend.

Compatibilité avec le protocole TLS mutuel

Le protocole TLS mutuel (mTLS) est un protocole standard du secteur pour l'authentification mutuelle entre un client et un serveur. mTLS permet de s'assurer que le client et le serveur s'authentifient mutuellement en vérifiant que chacun détient un certificat valide émis par une autorité de certification (CA) de confiance. Contrairement au protocole TLS standard, où seul le serveur est authentifié, mTLS exige que le client et le serveur présentent des certificats, confirmant l'identité des deux parties avant l'établissement de la communication.

Tous les équilibreurs de charge d'application sont compatibles avec mTLS. Avec l'authentification mTLS, l'équilibreur de charge demande au client d'envoyer un certificat pour s'authentifier lors du handshake TLS avec l'équilibreur de charge. Vous pouvez configurer un magasin de confiance Certificate Manager que l'équilibreur de charge utilise ensuite pour valider la chaîne de confiance du certificat client.

Pour en savoir plus sur mTLS, consultez la page Authentification TLS mutuelle.

Limites

  • Rien ne garantit qu'une requête d'un client situé dans une zone de la région est envoyée à un backend situé dans la même zone que le client. L'affinité de session ne limite pas la communication entre les zones.

  • Les équilibreurs de charge d'application internes ne sont pas compatibles avec les fonctionnalités suivantes:

  • Pour utiliser des certificats Certificate Manager avec des équilibreurs de charge d'application internes, vous devez utiliser l'API ou la gcloud CLI. La consoleTrusted Cloud n'est pas compatible avec les certificats Certificate Manager.

  • Un équilibreur de charge d'application interne n'accepte le protocole HTTP/2 que via TLS.

  • Les clients se connectant à un équilibreur de charge d'application interne doivent utiliser HTTP version 1.1 ou ultérieure. Le protocole HTTP 1.0 n'est pas compatible.

  • Trusted Cloud ne vous avertit pas si votre sous-réseau proxy réservé manque d'adresses IP.

  • La règle de transfert interne utilisée par votre équilibreur de charge d'application interne doit avoir exactement un port.

  • Lorsque vous utilisez un équilibreur de charge d'application interne avec Cloud Run dans un environnement VPC partagé, les réseaux VPC autonomes dans les projets de service peuvent envoyer du trafic vers tout autre service Cloud Run déployés dans tout autre projet de service au sein d'un même environnement VPC partagé. C'est un problème connu.

  • Trusted Cloud ne garantit pas qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de compter sur une connexion TCP pour être ouverte pendant de longues périodes.

Étapes suivantes