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 de Google Cloud 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 Google 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

Vous pouvez configurer un équilibreur de charge d'application interne dans les modes suivants :

• Équilibreur de charge d'application interne interrégional. Il s'agit d'un équilibreur de charge multirégional mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Le mode interrégional vous permet d'équilibrer la charge du trafic sur les services de backend distribués à l'échelle mondiale, y compris la gestion du trafic qui garantit que celui-ci est dirigé vers le backend le plus proche. Cet équilibreur de charge permet également la haute disponibilité. Le positionnement des backends dans plusieurs régions permet d'éviter les défaillances dans une seule région. Si les backends d'une région sont indisponibles, le trafic peut basculer vers une autre région.

• Équilibreur de charge d'application interne régional Il s'agit d'un équilibreur de charge régional mis en œuvre en tant que service géré sur le proxy Envoy Open Source. Le mode régional garantit que tous les clients et backends proviennent d'une région spécifiée, ce qui s'avère utile lorsque vous avez besoin d'une conformité régionale. Cet équilibreur de charge est activé avec des fonctionnalités avancées de contrôle du trafic s'appuyant sur les paramètres HTTP(S). Une fois l'équilibreur de charge configuré, il alloue automatiquement des proxys Envoy pour satisfaire vos besoins en termes de trafic.

  Le tableau suivant décrit les principales différences entre les modes régional et interrégional :

  Sélection	Équilibreur de charge d'application interne interrégional	Équilibreur de charge d'application interne régional
  Adresse IP virtuelle de l'équilibreur de charge.	Allouée depuis un sous-réseau dans une région Google Cloud spécifique. Les adresses IP virtuelles de plusieurs régions peuvent partager le même service de backend global. Vous pouvez configurer l'équilibrage de charge global basé sur le DNS à l'aide de règles de routage DNS pour acheminer les requêtes des clients vers l'adresse IP virtuelle la plus proche.	Allouée depuis un sous-réseau dans une région Google Cloud spécifique.
  Accès des clients	Toujours accessible mondialement. Les clients de n'importe quelle région Google Cloud d'un VPC peuvent envoyer du trafic vers l'équilibreur de charge.	Par défaut, non accessible mondialement. Vous pouvez éventuellement activer l'accès mondial.
  Backends à équilibrage de charge	Backends globaux. L'équilibreur de charge peut envoyer du trafic vers des backends dans n'importe quelle région.	Backends régionaux. L'équilibreur de charge ne peut envoyer du trafic qu'aux backends situés dans la même région que le proxy de l'équilibreur de charge.
  Haute disponibilité et basculement	Basculement automatique vers des backends opérationnels dans la même région ou dans des régions différentes.	Basculement automatique vers des backends opérationnels dans la même région.

Identifier le mode

console Cloud

1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

   Accéder à la page "Équilibrage de charge"

2. Dans l'onglet Équilibreurs de charge, vous pouvez voir le type, le protocole et la région de l'équilibreur de charge. Si la région est vide, l'équilibreur de charge est en mode interrégional. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

   Mode d'équilibreur de charge	Type d'équilibreur de charge	Type d'accès	Région
   Équilibreur de charge d'application interne régional	Application	Interne	Spécifie une région
   Équilibreur de charge d'application interne interrégional	Application	Interne

gcloud

1. Pour déterminer le mode d'un équilibreur de charge, exécutez la commande suivante :

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   Dans le résultat de la commande, vérifiez le schéma d'équilibrage de charge, la région et le niveau de réseau. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

   Mode d'équilibreur de charge	Schéma d'équilibrage de charge	Règle de transfert
   Équilibreur de charge d'application interne interrégional	INTERNAL_MANAGED	Mondial
   Équilibreur de charge d'application interne régional	INTERNAL_MANAGED	Régional

Important : Une fois que vous avez créé un équilibreur de charge, vous ne pouvez plus modifier son mode. Vous devez supprimer l'équilibreur de charge et en créer un autre.

Architecture et ressources

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

Interrégional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge d'application interne interrégional de niveau Premium au sein du même réseau VPC. Chaque règle de transfert globale utilise une adresse IP régionale que les clients utilisent pour se connecter.

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

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 régional (cliquez pour agrandir)

Chaque équilibreur de charge d'application interne utilise les ressources de configuration Google Cloud suivantes.

Sous-réseau proxy réservé

Dans le diagramme ci-dessus, 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.

Le tableau suivant décrit les différences entre les sous-réseaux proxy réservés en mode régional et interrégional :

Mode d'équilibreur de charge	Valeur de l'option --purpose du sous-réseau proxy réservé
Équilibreur de charge d'application interne interrégional	GLOBAL_MANAGED_PROXY Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux L'équilibreur de charge interrégional basé sur Envoy doit disposer d'un sous-réseau proxy réservé dans chaque région où il est configuré. Les proxys d'équilibreur de charge interrégionaux dans la même région et le même réseau partagent le même sous-réseau proxy réservé.
Équilibreur de charge d'application interne régional	REGIONAL_MANAGED_PROXY Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent le 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.

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 que vous pouvez utiliser, soit laisser Cloud Load Balancing en attribuer une pour vous. 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 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.

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(S) 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 tableau suivant montre les différences entre les règles de transfert entre les modes régional et interrégional :

Mode d'équilibreur de charge	Règle de transfert, adresse IP et sous-réseau proxy réservé --purpose	Routage depuis le client vers l'interface de l'équilibreur de charge
Équilibreur de charge d'application interne interrégional	Règle de transfert globale Adresses IP régionales Schéma d'équilibrage de charge : INTERNAL_MANAGED Sous-réseau proxy réservé --purpose : GLOBAL_MANAGED_PROXY Adresse IP --purpose : SHARED_LOADBALANCER_VIP	L'accès global est activé par défaut pour permettre aux clients de n'importe quelle région d'un VPC d'accéder à votre équilibreur de charge. Les backends peuvent se trouver dans plusieurs régions.
Équilibreur de charge d'application interne régional	Règle de transfert régionale Adresse IP régionale Schéma d'équilibrage de charge : INTERNAL_MANAGED Sous-réseau proxy réservé --purpose : REGIONAL_MANAGED_PROXY Adresse IP --purpose : SHARED_LOADBALANCER_VIP	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.

Proxy cible

Un proxy HTTP(S) 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 dans chaque mode :

Proxy cible	Équilibreur de charge d'application interne interrégional	Équilibreur de charge d'application interne régional
HTTP	Global targetHttpProxies	regionTargetHttpProxies
HTTPS	Global targetHttpsProxies	regionTargetHttpsProxies

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.

Le tableau suivant spécifie le type de certificats SSL requis par les équilibreurs de charge d'application internes dans chaque mode :

Mode d'équilibreur de charge	Type de certificat SSL
Équilibreur de charge d'application interne régional	Certificats SSL régionaux Compute Engine Certificats autogérés régionaux et certificats gérés par Google du gestionnaire de certificats. Les types de certificats gérés par Google suivants sont compatibles avec le gestionnaire de certificats : Certificats régionaux gérés par Google avec une autorisation DNS par projet. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google. Certificats régionaux gérés par Google avec Certificate Authority Service privé. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google avec le service d'autorité de certification. Les certificats gérés par Google avec une autorisation d'équilibreur de charge ne sont pas acceptés.
Équilibreur de charge d'application interne interrégional	Certificats autogérés et certificats gérés par Google du gestionnaire de certificats. Les types de certificats gérés par Google suivants sont compatibles avec le gestionnaire de certificats : Autorisation DNS avec DNS public. Pour en savoir plus, consultez la page Créer un certificat géré par Google avec une autorisation DNS. Certificate Authority Service privé. Pour plus d'informations, consultez la section Créer un certificat géré par Google et émis par votre instance de service CA. Les certificats gérés par Google avec une autorisation d'équilibreur de charge ne sont pas acceptés. Les certificats SSL Compute Engine ne sont pas accepté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 interrégional	Mappages d'URL générales
Équilibreur de charge d'application interne régional	Mappages d'URL régionaux

Service de backend

Un service de backend répartit les requêtes entre les backends opérationnels : groupes d'instances contenant des VM Compute Engine, Cloud Run ou NEG contenant des conteneurs GKE.

Les services de backend sont compatibles avec les protocoles HTTP, HTTPS et HTTP/2. Le protocole HTTP/2 n'est compatible qu'avec TLS. Les clients et les backends n'ont pas besoin d'utiliser le même protocole de requête. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge à l'aide du protocole HTTP/2, et l'équilibreur de charge peut transférer ces requêtes aux backends en utilisant le protocole HTTP/1.1.

Le tableau suivant spécifie le type de service de backend requis par les équilibreurs de charge d'application internes dans chaque mode :

Mode d'équilibreur de charge	Type de service de backend
Équilibreur de charge d'application interne interrégional	Services de backend globaux
Équilibreur de charge d'application interne régional	Services de backend régionaux

Le tableau suivant spécifie les fonctionnalités de backend compatibles avec les équilibreurs de charge d'application internes dans chaque mode.

Mode d'équilibreur de charge	Backends compatibles sur un service de backend						Compatible avec les buckets backend	Compatible avec Google Cloud Armor	Compatible avec Cloud CDN	Compatible avec IAP	Compatible avec les extensions de service
	Groupes d'instances	NEG zonaux	NEG Internet	NEG sans serveur	NEG hybrides	NEG Private Service Connect
Équilibreur de charge d'application interne interrégional		^2		Cloud Run
Équilibreur de charge d'application interne régional		^1		Cloud Run

¹ Utilisez des points de terminaison de type GCE_VM_IP_PORT avec GKE : Utilisez des NEG zonaux autonomes ou utilisez Ingress

² Utilisez des points de terminaison de type GCE_VM_IP_PORT avec GKE : Utilisez des NEG zonaux autonomes

Remarque :

• Vous ne pouvez pas utiliser à la fois des groupes d'instances et des groupes de points de terminaison du réseau sur le même service de backend.

• Si vous partagez les mêmes groupes d'instances pour les services de backend globaux et régionaux, configurez la règle d'autoscaling du groupe d'instances de sorte qu'elle utilise plusieurs signaux.

Pour en savoir plus, consultez la page Présentation des services de backend.

Backends et réseaux VPC

Tous les backends doivent être situés sur le même réseau VPC. Il n'est pas possible de placer des backends dans différents réseaux VPC, même ceux connectés à l'aide de l'appairage de réseaux VPC. Pour en savoir plus sur la manière dont les systèmes clients des réseaux VPC appairés peuvent accéder aux équilibreurs de charge, consultez la page Équilibrage de charge d'application interne et réseaux connectés.

Sous-paramètre du backend

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Le sous-paramètre de backend est une fonctionnalité facultative compatible avec l'équilibreur de charge d'application interne régional 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 l'équilibreur de charge d'application interne.

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 la section sur les vérifications d'état Envoy distribuées dans la présentation des NEG hybrides.

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 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 d'état compatibles, consultez la section Fonctionnalités d'équilibrage de charge.

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

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

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

• Présentation des vérifications d'état
• Créer des vérifications d'état

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érifications d'état centrales de Google.
  • 35.191.0.0/16
  • 130.211.0.0/22
• 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 :

• L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification de l'état Google à la liste d'autorisation pour les NEG zonaux.
• Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge utilisant des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est converti en 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 la page NEG régionaux : utiliser Cloud NAT pour la sortie.

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 interrégionaux, l'accès mondial est activé par défaut. Les clients de n'importe quelle région d'un VPC peuvent accéder à votre équilibreur de charge.

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.

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é

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

Dans ce modèle, le mappage d'URL et l'interface de l'équilibreur de charge se trouve dans un projet hôte ou de service. Les services de backend et les backends de l'équilibreur de charge peuvent être répartis entre les projets de l'environnement VPC partagé. Les services de backend inter-projets peuvent être référencés dans un seul mappage d'URL. C'est ce que l'on appelle la référence du service inter-projets.

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

Limites connues liées au 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.
• Google 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 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 IAM 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 backend de l'équilibreur de charge dans différents projets de service

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

Dans ce type de déploiement, 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 les projets de service. Les administrateurs de projets de service accordent le rôle IAM 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

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 pouvant s'écouler entre le moment où l'équilibreur de charge envoie le premier octet de la requête HTTP à votre backend et le moment où celui-ci renvoie le dernier octet de la réponse HTTP. Si la réponse HTTP entière n'a pas été renvoyée à l'équilibreur de charge dans le délai avant expiration de la requête ou de la réponse, 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.)	10 minutes (600 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.

Vous devez 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. Vous devez augmenter le délai avant expiration du service de backend 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.

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

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 après le délai avant expiration du service de backend.

Google Cloud redémarre ou modifie périodiquement le nombre de tâches d'inférence logicielles Envoy. 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 Google Cloud : modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.
• Google Cloud CLI : 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. Le délai avant expiration du message keepalive HTTP client est fixé à 600 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).

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é. 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 d'expiration de message keepalive HTTP (TCP inactive) soit supérieure à 600 secondes.

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	Réglage 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. Le délai avant expiration par défaut pour chaque tentative (perTryTimeout) est de 30 secondes avec une valeur de perTryTimeout configurable maximale 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

Vous pouvez 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.

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 interrégional	Basculement automatique vers des backends opérationnels dans la même région ou dans d'autres régions Le trafic est réparti entre les backends opérationnels dans plusieurs régions en fonction de la répartition du trafic configurée.	Renvoie HTTP 503
É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

Vous pouvez configurer un équilibreur de charge d'application interne interrégional dans plusieurs régions pour bénéficier des avantages suivants :

1. Si l'équilibreur de charge d'application interne interrégional d'une région échoue, les règles de routage DNS acheminent le trafic vers un équilibreur de charge d'application interne interrégional d'une autre région.

   L'exemple de déploiement haute disponibilité présente les éléments suivants :

   • Un équilibreur de charge d'application interrégional avec une adresse IP virtuelle (VIP) d'interface dans les régions RegionA et RegionB de votre réseau VPC. Vos clients sont situés dans la région RegionA.
   • Vous pouvez rendre l'équilibreur de charge accessible en utilisant des adresses IP virtuelles d'interface dans deux régions et utiliser des règles de routage DNS pour renvoyer l'adresse IP virtuelle optimale à vos clients. Utilisez les règles de routage de géolocalisation si vous souhaitez que vos clients utilisent l'adresse IP virtuelle la plus proche géographiquement.
   • Les règles de routage DNS peuvent détecter si une adresse IP virtuelle ne répond pas en cas de panne régionale et renvoyer à vos clients l'adresse IP virtuelle optimale, garantissant ainsi que votre application reste opérationnelle même en cas de panne régionale.

   

   Équilibreur de charge d'application interne interrégional avec un déploiement haute disponibilité (cliquez pour agrandir)

2. Si les backends d'une région spécifique sont indisponibles, le trafic de l'équilibreur de charge d'application interne interrégional bascule vers les backends d'une autre région de manière optimale.

   L'exemple de déploiement de basculement interrégional présente les éléments suivants :

   • Un équilibreur de charge d'application interne interrégional avec une adresse IP virtuelle d'interface dans la région RegionA de votre réseau VPC. Vos clients sont également situés dans la région RegionA.
   • Un service de backend global faisant référence aux backends des régions Google Cloud RegionA et RegionB.
   • Lorsque les backends de la région RegionA sont indisponibles, le trafic bascule vers la région RegionB.

   

   Équilibreur de charge d'application interne interrégional avec un déploiement de basculement interrégional (cliquez sur l'image pour l'agrandir).

Assistance WebSocket

Les équilibreurs de charge HTTP(S) de Google Cloud proposent une compatibilité intégrée avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS en tant que 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 en duplex intégral entre clients et serveurs. Une requête HTTP(S) initialise le canal. Pour en savoir plus sur le protocole, consultez la RFC 6455.

Lorsque l'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP(S) suivie d'une réponse Upgrade réussie de la part de l'instance backend, l'équilibreur de charge relaie le trafic bidirectionnel par proxy pendant la durée de la connexion en cours. Si l'instance backend ne renvoie pas de réponse Upgrade réussie, 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 en savoir plus, consultez la section Affinité de session.

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 Google Cloud, vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Procédez comme suit :

1. Configurez un équilibreur de charge HTTPS.
2. Activez HTTP/2 comme protocole à utiliser entre l'équilibreur de charge et les backends.

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.

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.

Vous devez activer le protocole TLS sur vos backends. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

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.0, 1.1, 1.2 ou 1.3 vers le backend.

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:

  • Cloud CDN
  • Google Cloud Armor
  • Buckets Cloud Storage
  • Certificats SSL gérés par Google

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

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

• Les équilibreurs de charge d'application internes ne sont pas compatibles avec Cloud Trace.

• 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é. Il s'agit d'un problème connu. Ce type d'accès sera bloqué à l'avenir.

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

• Pour configurer l'équilibrage de charge sur une configuration de VPC partagé, consultez la page Configurer un équilibreur de charge d'application interne pour un VPC partagé.
• Pour configurer l'équilibrage de charge pour vos services exécutés dans des pods GKE, consultez la page Déployer des passerelles GKE, Équilibrage de charge natif en conteneurs avec des NEG autonomes et la section Associer un équilibreur de charge d'application interne aux NEG autonomes.
• Pour configurer un équilibreur de charge d'application interne régional avec Private Service Connect, consultez la page Configurer Private Service Connect avec les contrôles de service HTTP(S) grand public.
• Pour savoir comment gérer la ressource de sous-réseau proxy réservé, consultez la page Sous-réseaux proxy réservés.
• Pour configurer le sous-paramètre de backend pour les équilibreurs de charge d'application internes régionaux, consultez la page Sous-paramètre de backend.
• Pour injecter une logique personnalisée dans le chemin d'accès aux données d'équilibrage de charge, configurez les appels d'extensions de service.