Présentation des groupes de points de terminaison du réseau Internet

Cloud Load Balancing prend en charge le trafic proxy vers des backends externes en dehors de Google Cloud. Pour définir un backend externe pour un équilibreur de charge, vous utilisez une ressource globale appelée groupe de points de terminaison du réseau (NEG) Internet.

Vous pouvez utiliser ce type de déploiement lorsque vous souhaitez diffuser du contenu à partir d'un backend externe, mais que vous souhaitez que votre équilibreur de charge Google Cloud soit utilisé comme interface. Vous pouvez ainsi effectuer les opérations suivantes :

utiliser l'infrastructure périphérique de Google pour interrompre vos connexions utilisateur ;
diriger les connexions vers votre backend externe ;
Avec les équilibreurs de charge mondiaux, vous pouvez utiliser Cloud CDN pour mettre en cache le contenu de votre backend externe.
diriger le trafic vers votre point de terminaison public via le backbone privé de Google, ce qui améliore la fiabilité et peut réduire la latence entre le client et le serveur.

La figure 1 montre un équilibreur de charge d'application externe avec plusieurs types de backends, parmi lesquels figure un backend externe configuré avec un NEG Internet.

Groupes de points de terminaison du réseau Internet dans le cadre de l'équilibrage de charge. — **Figure 1.** Groupes de points de terminaison du réseau Internet dans le cadre de l'équilibrage de charge (cliquez sur l'image pour l'agrandir).

Les backends NEG Internet sont compatibles avec divers équilibreurs de charge mondiaux et régionaux. Selon votre équilibreur de charge (mondial ou régional), la compatibilité des NEG Internet diffère en ce qui concerne le DNS, la vérification d'état, le nombre de points de terminaison disponibles et les comportements de routage du trafic.

Les sections suivantes expliquent comment les backends externes sont utilisés avec Cloud Load Balancing. Si vous souhaitez utiliser un backend externe avec Traffic Director, consultez la page Traffic Director avec des groupes de points de terminaison du réseau Internet.

Terminologie

Les termes suivants sont parfois utilisés de manière interchangeable, car leur signification est identique ou similaire :

backend externe : backend situé en dehors de Google Cloud et accessible sur Internet. Point de terminaison d'un NEG Internet.
origine personnalisée : identique à un backend externe. Dans CDN, origine est le terme standard de l'industrie désignant une instance de backend qui diffuse du contenu Web.
groupe de points de terminaison du réseau (NEG) Internet : ressource d'API Google Cloud que vous utilisez pour spécifier un backend externe.
point de terminaison externe : identique à un backend externe.

Ce document utilise le terme backend externe, sauf si vous faites référence à la ressource d'API NEG Internet.

Composants de l'équilibreur de charge

Cette section décrit l'architecture d'équilibrage de charge et les ressources nécessaires pour configurer un équilibreur de charge avec un backend externe. L'équilibreur de charge nécessite une configuration spéciale uniquement pour le service de backend. La configuration de frontend est identique à celle de n'importe quel autre équilibreur de charge.

Les figures suivantes illustrent les ressources Google Cloud requises pour configurer un équilibreur de charge avec un backend externe.

Mondial, externe

Cette figure illustre les ressources Google Cloud requises pour configurer un équilibreur de charge d'application externe mondial avec un backend externe.

Équilibreur de charge d'application externe global avec un backend externe. — Équilibreur de charge d'application externe global avec backend externe (cliquez pour agrandir).

Externe régional

Cette figure illustre les ressources Google Cloud requises pour configurer un équilibreur de charge d'application externe régional avec un backend externe.

Cette figure montre les ressources Google Cloud requises pour configurer un équilibreur de charge réseau proxy externe régional avec un backend externe.

Équilibreur de charge réseau proxy externe régional avec un backend externe. — Équilibreur de charge réseau proxy externe régional avec un backend externe (cliquez pour agrandir).

Régional interne

Cette figure montre les ressources Google Cloud requises pour configurer un équilibreur de charge d'application interne régional avec un backend externe.

Un équilibreur de charge d'application interne régional avec un backend externe. — Un équilibreur de charge d'application interne régional avec un backend externe (cliquez pour agrandir).

Cette figure montre les ressources Google Cloud requises pour configurer un équilibreur de charge réseau proxy interne régional avec un backend externe.

Équilibreur de charge réseau proxy interne régional avec un backend externe. — Équilibreur de charge réseau proxy interne régional avec un backend externe (cliquez pour agrandir).

Vous ne pouvez utiliser des NEG Internet qu'avec le niveau de service réseau Premium.

Configuration de l'interface

Aucune configuration de frontend spéciale n'est requise pour créer un équilibreur de charge avec un backend NEG Internet. Les règles de transfert permettent d'acheminer le trafic vers un proxy cible sur la base de l'adresse IP, du port et du protocole. Le proxy cible met ensuite fin aux connexions des clients. De plus, les équilibreurs de charge basés sur Envoy nécessitent un sous-réseau proxy réservé.

Les équilibreurs de charge d'application utilisent également des mappages d'URL pour configurer le routage basé sur l'URL des requêtes vers les services de backend appropriés.

Pour en savoir plus sur chacun de ces composants, consultez les sections d'architecture de l'équilibreur de charge correspondant :

NEG Internet

Un NEG Internet est une ressource utilisée pour définir un backend externe pour l'équilibreur de charge. Le backend externe référencé par le NEG Internet doit être accessible sur Internet. Le point de terminaison ne peut pas être accessible uniquement via Cloud VPN ou Cloud Interconnect. Si le backend externe fait référence à une API ou à un service Google, le service doit être accessible via le port TCP 80 ou 443 à l'aide du protocole HTTP, HTTPS ou HTTP/2.

Il existe deux façons de configurer le point de terminaison externe référencé par le NEG : INTERNET_FQDN_PORT ou INTERNET_IP_PORT. De plus, chacun de ces points de terminaison est disponible dans deux champs d'application : mondial ou régional.

Le tableau suivant vous permet d'examiner les différences entre les deux types de points de terminaison et leur comportement dans les champs d'application mondial et régional.

Load balancers	Type de point de terminaison	Définition du point de terminaison	Définition du champ d'application	Vérifications d'état
Équilibreur de charge d'application externe mondial Équilibreur de charge d'application classique	`INTERNET_FQDN_PORT`	Nom de domaine complet pouvant être résolu publiquement et port facultatif. Par exemple, `backend.example.com:443`¹. Le nom de domaine doit pouvoir être résolu par l'infrastructure DNS publique de Google. Un seul point de terminaison par NEG est autorisé.	Monde	Non compatible
	`INTERNET_IP_PORT`	Une adresse IP routable publiquement et un port facultatif. Par exemple, `8.8.8.8:443`¹. L'adresse IP ne peut pas être une adresse RFC 1918. Un seul point de terminaison par NEG est autorisé.	Monde	Non compatible
Équilibreur de charge d'application externe régional Équilibreur de charge d'application interne régional Équilibreur de charge réseau proxy externe régional Équilibreur de charge réseau proxy interne régional	`INTERNET_FQDN_PORT`	Nom de domaine complet pouvant être résolu publiquement et port facultatif. Par exemple, `backend.example.com:443`². Le nom de domaine doit pouvoir être résolu par Cloud DNS ou l'infrastructure DNS publique de Google. Un maximum de 256 points de terminaison par NEG est autorisé.	Régional	Vérifications d'état distribuées Envoy
	`INTERNET_IP_PORT`	Une adresse IP routable publiquement et un port facultatif. Par exemple, `8.8.8.8:443`². L'adresse IP ne peut pas être une adresse RFC 1918. Un maximum de 256 points de terminaison par NEG est autorisé.	Régional	Vérifications d'état distribuées Envoy

¹ Si vous ne spécifiez pas de port lors de l'ajout du point de terminaison, le port par défaut du NEG est utilisé. Si vous n'avez pas spécifié de port par défaut pour le NEG, le port connu de votre protocole de backend est utilisé (80 pour HTTP et 443 pour HTTPS et HTTP/2).

² Avec les NEG Internet régionaux, vous devez spécifier un port. Vous pouvez spécifier un port par défaut lors de la création du NEG ou chaque fois que vous ajoutez un point de terminaison au NEG, ou bien les deux. Si vous ne spécifiez pas de port lors de l'ajout d'un point de terminaison, le port par défaut du NEG est utilisé.

Résolution DNS pour les points de terminaison `INTERNET_FQDN_PORT` régionaux

Si votre domaine peut être résolu sur Internet, aucune autre configuration n'est nécessaire pour configurer le DNS. Toutefois, si vous utilisez des noms de domaine complets privés, vous devez configurer Cloud DNS pour faciliter la résolution DNS. Le nom doit être hébergé sur Cloud DNS ou doit pouvoir être résolu via le transfert DNS de Cloud DNS vers un DNS sur site.

Commencez par créer une zone Cloud DNS pour héberger les enregistrements DNS dans votre projet. Ajoutez-y ensuite les enregistrements DNS. Pour connaître la procédure de configuration spécifique, consultez la documentation de Cloud DNS.

Si vous utilisez un VPC partagé, notez les exigences réseau spécifiques. Vous pouvez également utiliser d'autres fonctionnalités de Cloud DNS, telles que les zones de transfert, pour extraire des enregistrements d'un serveur DNS sur site.

Résolution de l'adresse IP pour les points de terminaison `INTERNET_FQDN_PORT` globaux

Lorsqu'un point de terminaison INTERNET_FQDN_PORT pointe sur un enregistrement DNS qui renvoie plusieurs adresses IP, l'adresse IP est résolue comme suit :

L'équilibreur de charge utilise un résolveur DNS dans la région Google Cloud qui est la plus proche de son client sur Internet. Si l'enregistrement DNS de votre point de terminaison INTERNET_FQDN_PORT renvoie différentes adresses IP en fonction de l'emplacement du client, assurez-vous que l'équilibreur de charge peut atteindre chacune de ces adresses IP.
L'équilibreur de charge tente de se connecter à la première adresse IP de la réponse DNS. Si cette adresse IP n'est pas accessible, l'équilibreur de charge renvoie une réponse HTTP 502 (Bad Gateway). Cela est vrai même si d'autres adresses IP de la réponse DNS sont disponibles.

Pour en savoir plus sur les plages d'adresses IP et les emplacements utilisés par l'infrastructure du résolveur DNS de Google, consultez la documentation sur le DNS public de Google. Les noms qui ne peuvent pas être résolus par le système DNS public ne sont pas utilisables en tant que backends externes.

Résolution de l'adresse IP pour les points de terminaison `INTERNET_FQDN_PORT` régionaux

Les NEG Internet régionaux sont compatibles avec la résolution de noms de domaine à l'aide de Cloud DNS et du DNS public de Google. Dans le cas de serveurs DNS publics, Cloud DNS transfère le trafic vers les serveurs DNS publics.

Si le serveur DNS renvoie plusieurs adresses IP, Envoy équilibre la charge du trafic entre les adresses IP renvoyées en fonction de l'algorithme d'équilibrage de charge configuré (à tour de rôle, plus faible nombre de requêtes, etc.). La liste des points de terminaison est régulièrement actualisée en fonction de la valeur TTL DNS. Vous pouvez configurer des règles de nouvelle tentative pour forcer Envoy à tenter de se connecter à une autre adresse IP en cas d'échec de l'une d'entre elles.

Service de backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés.

Pour configurer un équilibreur de charge avec un backend externe, vous devez configurer le service de backend avec un backend NEG Internet. Lorsque vous ajoutez un NEG Internet à un service de backend, les considérations suivantes s'appliquent, en fonction du champ d'application du NEG :

Le service de backend ne peut pas utiliser d'autres types de backend (tels que des NEG zonaux ou des groupes d'instances) en tant que backends.
Nombre de NEG par service de backend
- NEG mondiaux. Vous ne pouvez ajouter qu'un seul backend NEG Internet à un service de backend.
- NEG régionaux Vous pouvez ajouter jusqu'à 50 NEG Internet à un même service de backend.
Nombre de points de terminaison par NEG
- NEG mondiaux. Vous ne pouvez ajouter qu'un seul point de terminaison à un NEG Internet.
Étant donné que chaque NEG Internet mondial ne peut comporter qu'un seul point de terminaison, l'équilibrage de charge n'est pas réellement effectué. L'équilibreur de charge fait uniquement office d'interface, jouant le rôle d'un proxy qui redirige le trafic vers le backend externe spécifié. Cela signifie que vous ne pouvez utiliser aucun des modes d'équilibrage de charge (qui peuvent par exemple être basés sur un taux, un mode de connexion ou sur un niveau d'utilisation).
- NEG régionaux Vous pouvez ajouter jusqu'à 256 points de terminaison par NEG pour un même service de backend.
Les NEG régionaux ne sont pas compatibles avec les modes d'équilibrage de charge, tels que le taux, la connexion ou l'utilisation. Tous les points de terminaison de tous les NEG associés à un service de backend sont regroupés dans un seul groupe. Le trafic d'équilibrage de charge entre ce pool de points de terminaison est géré à l'aide d'algorithmes d'équilibrage de charge Envoy. Pour connaître les algorithmes des règles d'équilibrage de charge compatibles, consultez la description de localityLbPolicy dans la documentation de l'API sur le service de backend régional.
Vérifications d'état
- NEG mondiaux. Le service de backend ne peut pas faire référence à une vérification d'état.
- NEG régionaux L'équilibreur de charge utilise les vérifications d'état Envoy distribuées.
Le schéma d'équilibrage de charge du service de backend doit correspondre au schéma requis par l'équilibreur de charge que vous déployez. Pour obtenir la liste complète, consultez la page Services de backend.
Le protocole du service de backend doit être l'un des protocoles suivants : HTTP, HTTPS ou HTTP2.

Nous vous recommandons vivement d'utiliser HTTPS ou HTTP/2 comme protocole lors de la configuration d'un service de backend avec un NEG Internet afin que la communication entre l'équilibreur de charge et le backend soit chiffrée et authentifiée lors de l'acheminement vers l'Internet public.

En outre, lorsque vous utilisez HTTPS ou HTTP/2 comme protocole backend, veillez à utiliser un point de terminaison INTERNET_FQDN_PORT pour créer votre backend externe. Cela présente deux avantages :
- Il vérifie que l'équilibreur de charge valide le certificat de serveur SSL présenté par le backend externe et vérifie que les informations suivantes sont remplies :
  - Le certificat est signé par des autorités de certification connues.
  - Le certificat n'a pas expiré.
  - La signature du certificat est valide.
  - Le nom de domaine complet configuré correspond à l'un des noms d'objet de remplacement (SAN, Subject Alternative Name) du certificat.
  Si vous créez le backend externe à l'aide d'un point de terminaison INTERNET_IP_PORT, la validation du certificat de serveur SSL n'est pas effectuée.
- L'extension SNI (Server Server Indication) n'est compatible qu'avec les points de terminaison INTERNET_FQDN_PORT. Le nom de domaine complet configuré est envoyé sous la forme d'une extension SNI dans le message "client hello" lors du handshake SSL entre l'équilibreur de charge et le point de terminaison externe. L'extension SNI n'est pas envoyée lorsque vous utilisez un point de terminaison INTERNET_IP_PORT, car les littéraux d'adresse IP ne sont pas autorisés dans le champ HostName d'une charge utile SNI.

Vérifications d'état

La configuration de votre vérification d'état varie en fonction du type d'équilibreur de charge :

Équilibreur de charge d'application externe mondial et équilibreur de charge d'application classique. Un service de backend avec un NEG Internet mondial n'est pas compatible avec les vérifications d'état.

Si votre backend externe devient inaccessible ou si le nom d'hôte configuré (nom de domaine complet) ne peut pas être résolu, l'équilibreur de charge renvoie une réponse HTTP 502 (Bad Gateway) à ses clients.

Équilibreur de charge d'application externe régional, équilibreur de charge d'application interne régional, équilibreur de charge réseau proxy externe régional et équilibreur de charge réseau proxy interne régional. Les vérifications d'état sont facultatives. Les tests de vérification de l'état de ces équilibreurs de charge proviennent du sous-réseau proxy réservé, puis sont traduits par NAT (à l'aide de Cloud NAT) en adresses IP pré-réservées ou Adresses IP NAT allouées automatiquement. Pour en savoir plus, consultez la section NEG régionaux : utiliser une passerelle Cloud NAT.
Les vérifications d'état Envoy distribuées sont créées en utilisant les mêmes processus de console Google Cloud, gcloud CLI et d'API que les vérifications d'état centralisées. Aucune autre configuration n'est requise.

Remarques :
- Les vérifications d'état gRPC ne sont pas acceptées.
- Les vérifications d'état avec le protocole PROXY v1 activé ne sont pas acceptées.
- Étant donné que le plan de données Envoy gère les vérifications d'état, vous ne pouvez pas utiliser la console Google Cloud, l'API ou gcloud CLI pour vérifier l'état de ces points de terminaison externes. Pour les NEG hybrides avec des équilibreurs de charge basés sur Envoy, la console Google Cloud affiche l'état de la vérification de l'état sur N/A. Ce comportement est normal.
- Chaque proxy Envoy attribué au sous-réseau proxy réservé de la région du réseau VPC lance des vérifications d'état indépendamment. Par conséquent, vous pouvez constater une augmentation du trafic réseau en raison de la vérification de l'état. L'augmentation dépend du nombre de proxys Envoy attribués à votre réseau VPC dans une région, de la quantité de trafic reçue par ces proxys et du nombre de points de terminaison dont chaque proxy Envoy a besoin pour effectuer la vérification de l'état. Dans le pire des cas, le trafic réseau augmente à un taux (O(n^2)) quadratique en raison de vérifications de l'état.
- Les journaux des vérifications d'état Envoy distribuées n'incluent pas d'états détaillés. Pour en savoir plus sur les éléments consignés, consultez la section Journalisation des vérifications d'état. Pour résoudre les problèmes de connectivité des proxys Envoy vers vos points de terminaison NEG, vous devez également vérifier les journaux des équilibreurs de charge respectifs.

Permettre au backend externe de recevoir des requêtes

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 pré-réservées ou allouées automatiquement. Cela inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends.

La configuration de votre backend externe pour autoriser le trafic provenant de Google Cloud dépend du champ d'application du NEG : mondial ou régional.

NEG mondiaux : ajouter des adresses IP de sortie Google par défaut à la liste d'autorisation

Si vous utilisez un NEG Internet mondial, vous devez ajouter les plages d'adresses IP utilisées par Google pour envoyer des requêtes à des backends externes. Pour rechercher les adresses IP à ajouter à la liste d'autorisation, interrogez l'enregistrement TXT DNS _cloud-eoips.googleusercontent.com à l'aide d'un outil tel que dig ou nslookup.

Pour obtenir un exemple, consultez la section Autoriser le backend externe à recevoir du trafic de Google Cloud.

NEG régionaux : utiliser une passerelle Cloud NAT

Si vous utilisez un NEG Internet régional, vous devez d'abord configurer une passerelle Cloud NAT pour allouer un ensemble de plages d'adresses IP à partir desquelles le trafic Google Cloud est émis.

Le point de terminaison de la passerelle doit être de type ENDPOINT_TYPE_MANAGED_PROXY_LB.

La passerelle Cloud NAT peut être configurée pour allouer automatiquement des adresses IP externes en fonction de la demande, ou pour utiliser un ensemble pré-réservé manuellement d'adresses IP externes.

Adresses IP allouées automatiquement

Utilisez des adresses IP allouées automatiquement si votre environnement backend externe ne vous oblige pas à ajouter sur une liste d'autorisation des adresses IP Google Cloud spécifiques, pouvant envoyer du trafic vers le backend externe.
Adresses IP attribuées manuellement

Vous ne devez utiliser des adresses IP allouées manuellement que si votre environnement backend externe nécessite la mise sur liste d'autorisation d'adresses IP Google Cloud spécifiques. Étant donné que chaque proxy Envoy attribué à votre sous-réseau proxy consomme une adresse IP entière, assurez-vous que le pool d'adresses IP réservées est assez grand pour accueillir tous les proxys Envoy.

Avertissement : Si vous provisionnez moins d'adresses IP NAT que le nombre de proxys Envoy attribués, les requêtes envoyées au NEG Internet peuvent génère des erreurs HTTP 5xx. Pour être informé lorsqu'un tel événement se produit, configurez une alerte pour la métrique nat_allocation_failed. Contactez l'assistance si vous avez besoin d'aide pour calculer le nombre d'adresses IP à allouer à votre équilibreur de charge dans une région spécifique.

Si vous rencontrez des problèmes de connectivité à grande échelle, vérifiez si vous avez atteint les limites de Cloud NAT. Par défaut, vous êtes limité à 50 adresses IP NAT allouées manuellement par passerelle.

Cette configuration Cloud NAT s'applique à l'ensemble du sous-réseau proxy réservé. Le trafic Internet associé à tous les équilibreurs de charge régionaux basés sur Envoy de la région partagent la même passerelle NAT.

L'utilisation de Cloud NAT entraîne des frais pour le trafic utilisateur et le trafic lié aux vérifications de l'état. Pour en savoir plus sur la tarification des NEG Internet régionaux, consultez la page Tarifs des NEG Internet régionaux.

Les passerelles NAT configurées sur les sous-réseaux proxy réservés présentent certaines limitations :

Une seule traduction NAT de type "un à un" est effectuée. Le partage d'adresses IP n'est pas disponible.
La journalisation et la surveillance ne sont pas compatibles. Autrement dit, les options --enable-logging et --log-filter ne sont pas compatibles.
Les fonctionnalités liées aux ports, telles que l'allocation de ports statique et dynamique, la définition de nombres maximal et minimal de ports par VM, et le mappage indépendant des points de terminaison, ne sont pas acceptées. Chaque proxy reçoit l'ensemble des 65 536 ports.

Authentifier les requêtes sur le backend externe

Cette section ne s'applique qu'aux équilibreurs de charge d'application.

Pour authentifier les requêtes envoyées à votre backend externe, vous pouvez effectuer l'une des opérations suivantes :

Définissez un en-tête personnalisé pour indiquer que la requête provient d'un équilibreur de charge Google Cloud à l'aide d'un en-tête de requête personnalisé. Par exemple, vous pouvez utiliser au moins 16 octets aléatoires générés par chiffrement comme clé partagée.

La mise en œuvre des transformations d'en-tête personnalisées dépend du type d'équilibreur de charge que vous utilisez :
- Équilibreur de charge d'application externe mondial et équilibreur de charge d'application classique. Les transformations d'en-tête personnalisé peuvent être configurées sur le service de backend ou sur le mappage d'URL.
  
  Par exemple, vous pouvez configurer le backend externe pour qu'il attende une valeur particulière pour l'en-tête Host de la requête HTTP. Vous pouvez également configurer l'équilibreur de charge pour définir l'en-tête Host sur cette valeur attendue. Si vous ne configurez pas d'en-tête de requête personnalisé, l'équilibreur de charge conserve les en-têtes que le client a utilisés pour se connecter à l'équilibreur de charge et inclut le même en-tête dans sa réponse. Notez toutefois que la modification de l'en-tête Host n'est pas possible dans le mappage d'URL.
  
  La configuration de l'en-tête Host présente des limites supplémentaires. Pour plus d'informations, consultez la section Créer des en-têtes personnalisés dans les services de backend. Pour obtenir un exemple spécifique, consultez la page Configurer un équilibreur de charge d'application externe mondial avec un backend externe.
- Équilibreur de charge d'application externe régional et équilibreur de charge d'application interne régional. Les transformations d'en-tête personnalisé ne peuvent être configurées que sur le mappage d'URL.
  
  Pour ces équilibreurs de charge basés sur Envoy, Host et authority sont des mots clés spéciaux réservés par Google Cloud. Vous ne pouvez pas modifier ces en-têtes pour ces équilibreurs de charge. Nous vous recommandons plutôt de créer d'autres en-têtes personnalisés (par exemple, MyHost) afin de ne pas interférer avec les noms d'en-têtes réservés.
Activez IAP et vérifiez que le JWT signé de l'en-tête de la requête est signé par Google, et que la revendication aud (audience) contient le numéro du projet dans lequel votre équilibreur de charge est défini.

IAP n'est pas compatible avec Cloud CDN. IAP n'est pas compatible avec les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge réseau proxy (internes et externes).
Activez l'authentification d'origine privée afin d'accorder à un équilibreur de charge d'application externe un accès à long terme à un bucket Amazon Simple Storage Service (Amazon S3) ou à d'autres magasins d'objets compatibles. Cloud CDN (et donc l'authentification d'origine privée) n'est pas compatible avec les équilibreurs de charge d'application régionaux externes et internes.

Journaux

Les requêtes envoyées par proxy à un backend externe sont consignées dans Cloud Logging de la même manière que celles concernant d'autres backends.

Pour en savoir plus, consultez les ressources suivantes :

Si vous activez Cloud CDN pour un équilibreur de charge d'application externe à l'aide d'un backend externe, les succès de cache (hits) sont également consignés.

Traitement des en-têtes avec des backends externes

Équilibreurs de charge d'application externes mondiaux et équilibreurs de charge d'application classiques

Lorsqu'un équilibreur de charge mondial ou classique envoie des requêtes par proxy à un backend externe, il ajuste les en-têtes HTTP comme suit :

Certains en-têtes sont fusionnés. Lorsqu'il existe plusieurs instances de la même clé d'en-tête (par exemple, Via), l'équilibreur de charge combine leurs valeurs dans une même liste d'éléments séparés par des virgules correspondant à une clé d'en-tête unique. Seuls les en-têtes dont les valeurs peuvent être représentées sous la forme d'une liste d'éléments séparés par des virgules sont fusionnés. Les autres en-têtes, tels que Set-Cookie, ne sont jamais fusionnés.
Lorsque le protocole du service de backend est HTTP ou HTTPS, la casse nom propre est utilisée pour les en-têtes :
- La première lettre de la clé d'en-tête et chaque lettre suivant un trait d'union (-) sont mises en majuscule afin de préserver la compatibilité avec les clients HTTP/1.1. Par exemple, user-agent est remplacé par User-Agent, et content-encoding devient Content-Encoding.
- Certains en-têtes, tels que Accept-CH (optimisations client), sont convertis pour correspondre à la représentation à lettres mixtes standard.
Certains en-têtes sont ajoutés ou des valeurs leur sont ajoutées. Les équilibreurs de charge d'application externes ajoutent ou modifient toujours certains en-têtes, tels que Via et X-Forwarded-For.

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

Il n'existe pas de traitement d'en-tête spécial pour les équilibreurs de charge basés sur Envoy qui utilisent des NEG Internet. Pour savoir comment Envoy traite généralement les en-têtes, consultez la section Manipulation des en-têtes HTTP.

Limites

Consultez la section sur le service de backend pour connaître les limites associées à la configuration des NEG Internet en tant que backends.
Lorsque vous modifiez un équilibreur de charge pour changer de backend, en passant d'un NEG Internet à un autre type de backend, ou en remplaçant le backend d'un autre type de backend par un NEG Internet, votre application subit un temps d'arrêt temporaire d'environ 30 à 90 secondes. Par exemple, pendant ce temps d'arrêt, les clients qui envoient des requêtes à des équilibreurs de charge d'application externes mondiaux voient des erreurs 502 avec le code d'erreur failed_to_connect_to_backend. Ce comportement est normal.
Les fonctionnalités avancées de gestion du trafic suivantes ne sont pas compatibles avec les backends NEG Internet mondiaux :
- Demander une mise en miroir
- Règles pour les nouvelles tentatives
- Règles de trafic (y compris la règle d'équilibrage de charge de la localité, l'affinité de session et la détection d'anomalies)
Consultez la section Passerelle Cloud NAT pour connaître les limites associées aux passerelles NAT configurées sur des sous-réseaux proxy réservés.

Quotas et limites

Les quotas et limites suivants s'appliquent aux NEG Internet :

Vous pouvez configurer autant de NEG avec points de terminaison de réseau externes que votre quota de groupes de points de terminaison de réseau existant le permet.
Le nombre de NEG par service de backend dépend du type de NEG Internet (mondial ou régional) :
- Pour les NEG mondiaux, vous ne pouvez ajouter qu'un seul backend NEG Internet à un même service de backend.
- Pour les NEG régionaux, vous pouvez ajouter jusqu'à 50 NEG Internet à un même service de backend.
Le nombre de points de terminaison par NEG dépend également du type de NEG Internet (mondial ou régional) :
- Pour les NEG mondiaux, vous ne pouvez ajouter qu'un seul point de terminaison à un NEG Internet.
- Pour les NEG régionaux, vous pouvez ajouter jusqu'à 256 points de terminaison à un NEG Internet.

Pour en savoir plus, consultez les champs Quota des backends de NEG et Quotas des points de terminaison par NEG.

Tarifs

Le trafic sortant vers des points de terminaison NEG Internet externes est facturé selon les tarifs de sortie Internet appliqués pour le niveau Premium des services réseau. La source est basée sur l'emplacement du client et la destination sur celui de votre point de terminaison public.

Si vous avez configuré une passerelle Cloud NAT pour mapper le sous-réseau proxy réservé de votre équilibreur de charge régional basé sur Envoy, des frais Cloud NAT vous seront facturés. Les passerelles Cloud NAT allouées aux équilibreurs de charge entraînent des frais horaires équivalents à ceux d'un réseau comportant plus de 32 instances de VM. Pour plus d'informations, consultez la page Tarifs de Cloud NAT.

Pour plus d'informations, consultez la page sur les tarifs de Cloud Load Balancing.