Présentation de l'équilibreur de charge réseau passthrough externe global

Les équilibreurs de charge réseau passthrough externes globaux sont des équilibreurs de charge passthrough de couche 4 qui distribuent le trafic externe entre les backends (groupes d'instances ou groupes de points de terminaison du réseau) pouvant résider dans plusieurs régions Cloud de Confiance . Ces équilibreurs de charge sont basés sur des Maglevs distribués dans le monde entier, qui fonctionnent conjointement grâce au réseau mondial et au plan de contrôle de Google.

Un équilibreur de charge réseau passthrough externe global dirige automatiquement le trafic vers la région de backend la plus proche du point d'entrée du trafic utilisateur dans le réseau mondial deS3NS.

À condition que les backends éligibles soient configurés dans au moins deux régions :

• Si une région est saturée, l'équilibreur de charge transfère automatiquement certaines des nouvelles connexions utilisateur qui dépassent la capacité de la région vers la ou les régions les plus proches où de la capacité est disponible, tout en conservant les connexions existantes dans la région actuelle.

• Si une région est hors service, l'équilibreur de charge bascule automatiquement le trafic vers la région la plus proche disposant d'une capacité suffisante.

Les équilibreurs de charge réseau passthrough externes mondiaux peuvent recevoir du trafic provenant de :

• N'importe quel client sur Internet
• Cloud de Confiance VM avec adresses IP externes
• Cloud de Confiance VM ayant accès à Internet via Cloud NAT ou une NAT basée sur une instance

Utilisez un équilibreur de charge réseau passthrough externe mondial dans les cas suivants :

• Vous avez besoin d'un équilibreur de charge hautes performances passthrough de couche 4 pour le trafic TCP, UDP, ESP, GRE, ICMP et ICMPv6. L'équilibreur de charge peut gérer le trafic IPv4 et IPv6.

• Vous devez recevoir les paquets d'origine sans proxy. Par exemple, si vous souhaitez que l'adresse IP source du client soit conservée.

• Vous devez diffuser du trafic vers des backends dans plusieurs régions Cloud de Confiance avec une faible latence, en utilisant la même adresse IP anycast.

• Votre déploiement doit être résilient aux défaillances et aux surcharges régionales des backends, en redirigeant automatiquement et de manière fluide le trafic vers la région disponible la plus proche.

Pour utiliser un équilibreur de charge réseau passthrough externe global, votre déploiement doit répondre à l'exigence suivante :

• Si vous diffusez du trafic TLS (SSL), vos backends doivent interrompre le trafic SSL. L'équilibreur de charge réseau passthrough externe mondial n'est pas compatible avec l'arrêt SSL.

Principales fonctionnalités

Les équilibreurs de charge réseau passthrough externes mondiaux sont compatibles avec les principales fonctionnalités suivantes.

Haute disponibilité intégrée

L'équilibreur de charge vous fournit deux adresses IP Anycast externes mondiales, chacune étant diffusée par une infrastructure de serveur de plan de contrôle et de plan de données d'équilibrage de charge mondial disjoint et isolé (également appelée groupe de disponibilité) pour assurer une haute disponibilité. Les clients peuvent utiliser l'une ou l'autre adresse IP pour se connecter au backend opérationnel le plus proche disposant de la capacité nécessaire.

L'équilibreur de charge vous permet d'améliorer la disponibilité des services lorsque vous créez des services de backend globaux avec des backends dans plusieurs régions Cloud de Confiance . Si les backends d'une région spécifique sont indisponibles, le trafic bascule de manière optimale vers la région la plus proche.

Nous vous recommandons de déployer des backends dans au moins trois régions Cloud de Confiance pour assurer la résilience en cas de panne régionale, même si vous êtes autorisé à configurer tous vos backends dans une seule région Cloud de Confiance .

Équilibrage sensible à la latence et à la charge

Un équilibreur de charge réseau passthrough externe global utilise exclusivement le niveau Premium. Avec le niveau Premium, le trafic entrant en provenance d'Internet entre dans le réseau hautes performances à faible latence de S3NSau niveau du point de présence (POP) le plus proche de l'utilisateur. De même, le trafic sortant est envoyé via le réseau de S3NSet sort au niveau du POP le plus proche de l'utilisateur.

Les équilibreurs de charge Maglev distribués à l'échelle mondiale acheminent le trafic entrant vers la régionCloud de Confiance la plus proche du point de présence où le trafic entre dans le réseau deS3NS, à condition que la région dispose de backends opérationnels avec une capacité disponible. Sinon, l'équilibreur de charge transfère automatiquement et de manière fluide le trafic vers la région la plus proche qui dispose de backends opérationnels avec une capacité disponible.

Vous déterminez les emplacements et les capacités du backend pour optimiser la latence des paquets et l'efficacité du backend. Les capacités du backend peuvent être basées sur le taux maximal de PPS (paquets par seconde) entrants, sur l'utilisation maximale du processeur, ou sur les deux. Les capacités de backend configurées dans un service de backend sont partagées équitablement entre les adresses IP de toutes les règles de transfert qui font référence au service de backend.

Fonctionnement des équilibreurs de charge réseau passthrough externes mondiaux

Un équilibreur de charge réseau passthrough externe global dispose d'une interface (la règle de transfert) et d'un backend (le service de backend et ses groupes de backends). Vous pouvez utiliser des groupes d'instances ou des NEG zonaux GCE_VM_IP comme groupes de backends.

Architecture

Le schéma suivant montre un équilibreur de charge réseau passthrough externe global qui distribue le trafic vers des backends dans plusieurs régions Cloud de Confiance . Lorsque l'équilibreur de charge est créé, Cloud de Confiance lui attribue deux adresses IP Anycast externes globales, diffusées par une infrastructure de plan de contrôle et de plan de données disjoints et isolés (également appelés groupes de disponibilité, AG0 et AG1).

Les deux plans de contrôle et de données offrent une haute disponibilité, une tolérance aux pannes et une résilience pour chaque équilibreur de charge réseau passthrough externe global. Une défaillance dans le plan de contrôle ou de données d'un groupe de disponibilité n'affecte pas l'autre groupe de disponibilité. Les clients correctement configurés doivent pouvoir se connecter aux deux adresses IP de l'équilibreur de charge. Par exemple, si un client ne parvient pas à se connecter à l'adresse IP AG0, il doit être configuré pour se connecter à l'adresse IP AG1 à la place.

L'équilibreur de charge se compose des éléments de configuration suivants.

• Deux adresses IP externes globales, une pour chaque groupe de disponibilité (AG0 et AG1). Elles peuvent être statiques ou éphémères. Pour en savoir plus, consultez Adresses IP.

• Une règle de transfert globale qui spécifie les deux adresses IP externes globales, une pour chaque groupe de disponibilité (AG0 et AG1). Lorsque vous créez cette règle de transfert, Cloud de Confiance génère deux règles de transfert enfants en lecture seule, une pour chaque groupe de disponibilité, afin d'assurer une haute disponibilité. Pour en savoir plus, consultez Règles de transfert.

• Un service de backend mondial qui définit la manière dont le trafic est distribué aux backends dans plusieurs régionsCloud de Confiance . Les groupes de backends peuvent être tous des groupes d'instances (groupes d'instances gérés zonaux ou groupes d'instances non gérés zonaux) ou tous des backends de NEG zonaux (NEG zonaux avec des points de terminaison GCE_VM_IP). Pour en savoir plus, consultez Services de backend.

• Vérification de l'état globale associée au service de backend. Pour en savoir plus, consultez Vérifications de l'état.

• Des règles de pare-feu permettant à votre trafic d'équilibrage de charge et aux requêtes de vérification de l'état d'atteindre les VM de backend. Pour en savoir plus, consultez Règles de pare-feu.

Retour direct du serveur

Un équilibreur de charge réseau passthrough externe global, comme les autres équilibreurs de charge réseau passthrough, n'est pas un proxy. L'équilibreur de charge lui-même ne met pas fin aux connexions des utilisateurs. Les paquets à équilibrage de charge sont envoyés aux VM de backend avec leurs adresses IP source et de destination, leur protocole et, le cas échéant, leurs ports, inchangés. Les VM de backend mettent ensuite fin aux connexions des utilisateurs et envoient les paquets renvoyés directement aux clients. Les réponses ne repassent pas par l'équilibreur de charge. Ce processus est appelé retour direct du serveur.

Routage local pour l'adresse IP de l'équilibreur de charge

Comme les autres équilibreurs de charge réseau passthrough, l'équilibreur de charge réseau passthrough externe global n'effectue pas de NAT de source ni de destination pour l'adresse IP ou les ports.

L' Cloud de Confiance environnement invité configure chaque VM de backend avec les adresses IP de l'équilibreur de charge. Une entrée dans la table de routage locale de la VM configure la carte d'interface réseau (NIC) à équilibrage de charge de la VM de backend pour qu'elle accepte les paquets dont les adresses IP de destination correspondent à chaque adresse IP de règle de transfert. Pour en savoir plus, consultez Vérifier la table de routage locale pour les adresses IP de l'équilibreur de charge.

Adresses IP pour les paquets de requêtes et de retours

Lorsqu'une VM de backend reçoit un paquet à équilibrage de charge d'un client, la source et la destination du paquet sont les suivantes :

• Source : adresse IP externe associée au client, à une VM Cloud de Confiance ou à un système sur Internet.
• Destination : l'une des adresses IP de la règle de transfert de l'équilibreur de charge.

L'équilibreur de charge étant un équilibreur de charge passthrough (et non un proxy), les paquets qui arrivent contiennent l'une des adresses IP de la règle de transfert de l'équilibreur de charge.

Bien que l'environnement invité configure automatiquement les routes locales afin que le système d'exploitation de la VM accepte le trafic destiné à l'adresse IP de l'équilibreur de charge, le système d'exploitation ne peut pas distribuer ces paquets à votre application si celle-ci est configurée pour n'écouter que l'adresse IP interne attribuée à la VM.

Pour vous assurer que le système d'exploitation transmet les paquets à votre application, configurez l'application exécutée sur les VM de backend pour effectuer les opérations suivantes :

• Écouter (être lié à) les adresses IP de la règle de transfert de l'équilibreur de charge ou toute adresse IP (0.0.0.0 ou ::)

• Si le protocole de la règle de transfert de l'équilibreur de charge est compatible avec les ports, écouter (être lié à) un port inclus dans la règle de transfert de l'équilibreur de charge

Les paquets de retour sont envoyés directement aux VM de backend de l'équilibreur de charge au client. L'adresse IP source du paquet de retour dépend du protocole :

• TCP est orienté connexion. Les VM de backend doivent donc répondre avec des paquets dont les adresses IP sources correspondent à l'adresse IP de destination du paquet de requête, de sorte que le client puisse associer les paquets de réponse à la connexion TCP appropriée.
• Les protocoles UDP, ESP, GRE, ICMP et ICMPv6 sont sans connexion. Les VM de backend peuvent envoyer des paquets de réponse dont les adresses IP sources correspondent à l'adresse IP de la règle de transfert ou à toute adresse IP externe attribuée à la VM. En pratique, la plupart des clients s'attendent à ce que la réponse provienne de l'adresse IP à laquelle ils ont envoyé des paquets.

Le tableau suivant récapitule les adresses IP source et de destination des paquets de réponse :

Type de trafic	Source	Destination
TCP	Destination du paquet à l'origine de la requête	Source du paquet à l'origine de la requête
UDP, ESP, GRE, ICMP et ICMPv6	Dans la plupart des cas, destination du paquet de requête1	Source du paquet à l'origine de la requête

Composants

Les sections suivantes décrivent en détail chaque composant de configuration d'un équilibreur de charge réseau passthrough externe mondial.

Adresses IP

Un équilibreur de charge réseau passthrough externe global nécessite deux adresses IP externes globales pour assurer une haute disponibilité. Les règles de transfert de l'équilibreur de charge utilisent ces adresses pour accepter le trafic entrant. Elles doivent appartenir à la même version d'adresse IP (IPv4 ou IPv6). Cloud de Confiance annonce les adresses IP de votre équilibreur de charge à partir de tous les points de présence dans le monde. Chaque adresse IP d'équilibreur de charge est une adresse IP Anycast globale qui n'est compatible qu'avec le niveau Premium.

Chacune des deux adresses IP doit provenir de pools d'adresses IP externes globales appartenant à un groupe de disponibilité distinct. Les adresses IP ne sont pas associées à un sous-réseau dans un réseau VPC. Dans l'API, les groupes de disponibilité sont représentés à l'aide du champ purpose sur la ressource globalAddresses :

• PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0 : pour les adresses du groupe de disponibilité 0.
• PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1 : pour les adresses du groupe de disponibilité 1.

Le champ IPAddresses d'une ressource de règle de transfert spécifie zéro, une ou deux adresses IP :

• Si cette option est omise, Cloud de Confiance attribue deux adresses IP éphémères, une pour chaque groupe de disponibilité.
• Si vous spécifiez une adresse IP qui fait référence à une ressource d'adresse IP statique existante d'un groupe de disponibilité, Cloud de Confiance attribue une adresse IP éphémère de l'autre groupe de disponibilité.
• Si vous spécifiez deux adresses IP qui font référence à des ressources d'adresses IP statiques existantes, elles doivent provenir de groupes de disponibilité différents.

Utilisez des adresses IP statiques réservées pour la règle de transfert si vous devez conserver les adresses associées à votre projet pour pouvoir les réutiliser après avoir supprimé une règle de transfert ou si vous avez besoin de plusieurs règles de transfert pour faire référence aux mêmes adresses IP.

Pour une règle de transfert d'équilibreur de charge réseau passthrough externe global, les adresses IP peuvent être l'une des suivantes :

• Adresse IPv4 statique ou éphémère provenant d'un pool d'adresses IP globales appartenant à Google.
• Plage /96 statique ou éphémère d'adresses IPv6 externes provenant d'un pool d'adresses IP globales appartenant à Google.
• Adresse IPv4 BYOIP statique provenant d'un préfixe délégué public global.

Un équilibreur de charge réseau passthrough externe global accepte les adresses IP que vous apportez (BYOIP) pour les adresses IPv4 uniquement. L'assistance est limitée à l'API BYOIP v1. Le provisionnement de nouvelles plages d'adresses IPv4 peut prendre jusqu'à quatre semaines. De plus, aucune API ne vous permet de contrôler l'état de votre annonce BGP. Pour en savoir plus, consultez Configurer l'utilisation de vos propres adresses IP.

Le champ IPAddresses d'une règle de transfert ne peut être défini qu'au moment de la création et ne peut pas être mis à jour.

Quelle que soit leur origine (propriété de Google ou BYOIP), les adresses IP externes globales dans Cloud de Confiance proviennent de trois types distincts de pools d'adresses IP externes globales :

• Pools d'adresses IP utilisés par les équilibreurs de charge réseau passthrough externes globaux pour le groupe de disponibilité AG0
• Pools d'adresses IP utilisés par les équilibreurs de charge réseau passthrough externes globaux pour le groupe de disponibilité AG1
• Pools d'adresses IP utilisés par les équilibreurs de charge proxy externes globaux

Par conséquent, les équilibreurs de charge réseau passthrough externes globaux ne peuvent pas partager d'adresses IP avec d'autres équilibreurs de charge globaux ou régionaux.

Règles de transfert globales

Une règle de transfert d'équilibreur de charge réseau passthrough externe global constitue l'interface de l'équilibreur de charge. Elle spécifie les adresses IP de destination, le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic. Comme un équilibreur de charge réseau passthrough externe global n'est pas un proxy, il transmet le trafic aux backends sans modifier leurs adresses IP source et de destination, leur protocole ni leurs ports, si le protocole contient des informations sur le port.

Une règle de transfert d'équilibreur de charge réseau passthrough externe global que vous configurez spécifie les éléments suivants :

• Le schéma d'équilibrage de charge est désigné par EXTERNAL_PASSTHROUGH.
• La paire d'adresses IP mondiales dans le champ IPAddresses[], une pour chaque groupe de disponibilité.
• Protocole (TCP, UDP ou L3_DEFAULT) et port(s).

Pour chaque règle de transfert d'équilibreur de charge réseau passthrough externe global que vous créez (également appelée règle de transfert parente), Cloud de Confiancegénère deux règles de transfert enfant en lecture seule pour chaque pile d'équilibrage de charge : AVAILABILITY_GROUP0 et AVAILABILITY_GROUP1. La règle de transfert enfant possède les mêmes paramètres de protocole IP, de port et de service de backend que la règle de transfert parente, mais ne possède qu'une des deux adresses IP de la règle de transfert parente.

Les règles de transfert enfants peuvent être identifiées de manière unique, car les éléments -ag0 et -ag1 sont ajoutés au nom de la règle de transfert parente. Elles ne consomment pas de quota supplémentaire et n'entraînent pas de coûts supplémentaires. Les métriques de surveillance et l'état de santé sont signalés au niveau de la règle de transfert enfant.

Le trafic entrant est mis en correspondance avec une règle de transfert, qui associe l'adresse IP, le protocole et le port de destination d'un paquet à une combinaison de champs de règle de transfert(deux adresses IP, un protocole et, si ce protocole est basé sur un port, un des ports, une plage de ports ou tous les ports). La règle de transfert dirige ensuite le trafic vers le service de backend de l'équilibreur de charge.

Les règles de transfert d'un équilibreur de charge réseau passthrough externe global peuvent être configurées avec des adresses IPv4 ou IPv6. Si vous souhaitez que l'équilibreur de charge gère à la fois le trafic IPv4 et IPv6, créez deux règles de transfert :

• Règle de transfert pour le trafic IPv4 qui pointe vers des backends IPv4 uniquement ou à double pile

• Une règle de transfert pour le trafic IPv6 qui pointe vers des backends IPv6 uniquement ou à double pile

Il est possible de disposer d'une règle de transfert IPv4 et d'une règle de transfert IPv6 faisant référence au même service de backend, mais le service de backend doit faire référence à des backends avec des interfaces réseau de VM à double pile.

La version IP de votre règle de transfert doit correspondre au type de pile des interfaces réseau de la VM de backend.

Type de pile des interfaces réseau des VM de backend	Règle de transfert
Interface réseau de VM IPv4 uniquement (IPV4_ONLY)	Ne peuvent être des backends que pour les règles de transfert IPv4.
Interface réseau de VM IPv6 uniquement (IPV6_ONLY)	Ne peuvent être des backends que pour les règles de transfert IPv6.
Interface réseau de VM à double pile (IPV4_IPV6)	Peuvent être des backends pour les règles de transfert IPv4, les règles de transfert IPv6 ou les deux.

Protocoles de règles de transfert

Les équilibreurs de charge réseau passthrough externes mondiaux acceptent les options de protocole suivantes pour chaque règle de transfert : TCP, UDP et L3_DEFAULT.

Utilisez les options TCP et UDP pour configurer l'équilibrage de charge TCP ou UDP, respectivement. L'option de protocole L3_DEFAULT permet à un équilibreur de charge réseau passthrough externe mondial d'équilibrer le trafic TCP, UDP, ESP, GRE, ICMP et ICMPv6.

En plus d'accepter les protocoles autres que TCP et UDP, l'option L3_DEFAULT permet à une règle de transfert de diffuser plusieurs protocoles. Par exemple, les services IPSec gèrent généralement une certaine combinaison de trafic IKE basé sur ESP et UDP, et de trafic NAT-T. L'option L3_DEFAULT permet de configurer une seule règle de transfert pour traiter tous ces protocoles.

Si vous utilisez le protocole L3_DEFAULT, vous devez configurer la règle de transfert de façon à accepter le trafic sur tous les ports. Étant donné que L3_DEFAULT est une règle générique, nous vous recommandons, pour des raisons de sécurité, de configurer des règles de pare-feu d'entrée qui n'autorisent que les protocoles IP et les ports dont vous avez besoin.

Plusieurs règles de transfert

Vous pouvez configurer plusieurs règles de transfert, qui peuvent être de deux types :

• Plusieurs règles de transfert pour les mêmes adresses IP Vous pouvez configurer plusieurs règles de transfert pour la même paire d'adresses IP, à condition qu'aucune règle de transfert n'utilise la même combinaison de protocole et de port. Chaque règle de transfert peut avoir son propre service de backend, ou plusieurs règles de transfert peuvent avoir le même service de backend.

• Plusieurs règles de transfert qui font référence au même service de backend. Vous pouvez configurer plusieurs règles de transfert qui font référence au même service de backend. Sous réserve des conditions mentionnées dans le premier point, deux règles de transfert ou plus peuvent utiliser la même paire d'adresses IP, ou chaque règle de transfert peut utiliser une paire d'adresses IP unique. Le trafic de toutes les adresses IP de toutes les règles de transfert qui font référence au même service de backend partage équitablement les capacités cibles de backend.

Toutefois, vous ne pouvez pas partager la même adresse IP externe globale entre un équilibreur de charge réseau passthrough externe global et un équilibreur de charge d'application externe global ou un équilibreur de charge réseau proxy externe global.

Lorsque vous utilisez plusieurs règles de transfert, veillez à configurer l'application qui s'exécute sur vos VM backend, de sorte qu'elle soit liée à toutes les adresses IP externes des règles de transfert de l'équilibreur de charge.

La configuration de plusieurs règles de transfert peut être utile dans les cas suivants :

• Vous devez configurer plusieurs paires d'adresses IP externes pour le même service de backend. Par exemple, une règle de transfert pour les adresses IPv4 et une autre pour les adresses IPv6.
• Vous devez configurer plusieurs règles de transfert pour la même paire d'adresses IP externes, mais avec des protocoles différents, ou des ports ou plages de ports qui ne se chevauchent pas. Les règles de transfert peuvent utiliser les mêmes services de backend ou des services différents.

Contraintes liées au protocole et au port pour plusieurs règles de transfert

Cloud de Confiance sélectionne au maximum une règle de transfert pour traiter un paquet entrant. Deux règles de transfert ou plus utilisant la même paire d'adresses IP externes globales doivent posséder des combinaisons uniques de protocole et de port, conformément aux contraintes suivantes :

• Une règle de transfert configurée pour tous les ports d'un protocole empêche la création d'autres règles de transfert utilisant la même paire protocole/adresse IP.

  Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent être configurées pour utiliser tous les ports, ou elles peuvent être configurées pour des ports spécifiques.

  Par exemple, si vous créez une règle de transfert basée sur la paire d'adresses IP 136.124.69.214 et 136.124.83.205, le protocole TCP et tous les ports, vous ne pouvez pas créer d'autre règle de transfert spécifiant la même paire d'adresses IP et le protocole TCP.

  Vous pouvez créer deux règles de transfert, utilisant toutes deux la paire d'adresses IP et le protocole TCP, si chacune dispose de ports uniques ou de plages de ports qui ne se chevauchent pas. Par exemple, vous pouvez créer deux règles de transfert utilisant la même paire d'adresses IP et le protocole TCP, avec l'une de ces règles de transfert utilisant les ports 80,443, et l'autre la plage de ports 81-442.

• Une seule règle de transfert L3_DEFAULT peut être créée par paire d'adresses IP.

  En effet, le protocole L3_DEFAULT utilise par définition tous les ports. ce qui inclut les protocoles sans informations de port.

• Une seule règle de transfert L3_DEFAULT peut coexister avec d'autres règles de transfert qui utilisent des protocoles spécifiques (TCP ou UDP) et la même paire d'adresses IP.

  Si vous avez des règles de transfert TCP ou UDP spécifiques associées à une paire d'adresses IP, vous pouvez également associer une règle de transfert L3_DEFAULT à cette même paire d'adresses IP pour servir de solution de repli pour tout trafic qui ne correspond pas aux règles de transfert spécifiques. Une règle de transfert L3_DEFAULT traite les paquets envoyés à son adresse IP de destination si et seulement si l'adresse IP de destination, le protocole et le port de destination du paquet ne correspondent pas à une règle de transfert spécifique au protocole.

  Pour illustrer cela, prenons pour exemple ces deux scénarios, dans lesquels les règles de transfert utilisent la même paire d'adresses IP : 136.124.69.214 et 136.124.83.205.

  • Scénario 1. La première règle de transfert utilise le protocole L3_DEFAULT. La deuxième règle de transfert utilise le protocole TCP et tous les ports. Les paquets TCP envoyés à n'importe quel port de destination de l'une ou l'autre des adresses IP sont traités par la deuxième règle de transfert, plus spécifique. Les paquets utilisant des protocoles différents sont traités par la première règle de transfert.

  • Scénario 2 La première règle de transfert utilise le protocole L3_DEFAULT. La deuxième règle de transfert utilise le protocole TCP et le port 8080. Les paquets TCP envoyés au port 8080 de l'une ou l'autre des adresses IP sont traités par la deuxième règle de transfert. Tous les autres paquets, y compris les paquets TCP envoyés à d'autres ports de destination, sont traités par la première règle de transfert.

Sélection des règles de transfert

Cloud de Confiance sélectionne une règle de transfert (ou aucune règle) pour traiter un paquet entrant à l'aide du processus d'élimination ci-après, en commençant par l'ensemble de règles de transfert applicables à l'adresse IP de destination du paquet :

• Éliminer les règles de transfert dont le protocole ne correspond pas au protocole du paquet, à l'exception des règles de transfert L3_DEFAULT. Les règles de transfert utilisant le protocole L3_DEFAULT ne sont jamais éliminées à cette étape, car L3_DEFAULT correspond à tous les protocoles. Par exemple, si le protocole du paquet est TCP, seules les règles de transfert utilisant le protocole UDP sont éliminées.

• Éliminer les règles de transfert dont le port ne correspond pas au port du paquet. Les règles de transfert configurées pour tous les ports ne sont jamais éliminées à cette étape, car elles correspondent comme leur nom l'indique à n'importe quel port.

• À ce stade, les règles de transfert applicables restantes peuvent se présenter comme suit :

  • Il reste deux règles de transfert : une règle de transfert L3_DEFAULT et une règle de transfert spécifique à un protocole. Utilisez la règle de transfert spécifique au protocole pour acheminer le paquet.

  • Il ne reste qu'une seule règle de transfert, qu'il s'agisse d'une règle de transfert L3_DEFAULT ou d'une règle de transfert spécifique à un protocole. Il est utilisé pour acheminer le paquet.

  • Il ne reste aucune règle de transfert applicable et le paquet est supprimé.

Services de backend mondiaux

Un service de backend d'un équilibreur de charge réseau passthrough externe global répartit le trafic entrant entre les backends associés, qui peuvent résider dans plusieurs régions Cloud de Confiance . Chaque backend est composé d'un groupe d'instances ou d'un groupe de points de terminaison du réseau, ainsi que d'informations sur la capacité de diffusion du backend. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur, sur le nombre de paquets entrants par seconde (PPS) ou sur les deux. Le service de backend gère la répartition du trafic en fonction des paramètres d'affinité et de capacité configurés.

Le service de backend définit les paramètres de backend suivants :

• Schéma d'équilibrage de charge. Pour désigner un service de backend pour un équilibreur de charge réseau passthrough externe global, le schéma d'équilibrage de charge doit être explicitement défini sur EXTERNAL_PASSTHROUGH.

• Protocole. Le champ du protocole de service de backend est redondant et ne peut être défini que sur UNSPECIFIED. Les services de backend avec le protocole UNSPECIFIED peuvent être utilisés avec n'importe quelle règle de transfert, quel que soit le protocole de cette règle.

• Répartition du trafic : Un service de backend distribue le trafic en fonction de l'affinité de session configurée, de la règle de suivi des connexions, du mode d'équilibrage de charge, des capacités de backend et de la règle de localité d'équilibrage de charge. Le service de backend peut également être configuré pour activer le drainage de connexion, réduire les capacités de backend et désigner des backends préférés. La plupart de ces paramètres possèdent des valeurs par défaut qui facilitent la configuration afin de démarrer rapidement.

• Vérification de l'état : Un service de backend doit être associé à une vérification d'état.

• Backends Les backends sont les points de terminaison réels qui reçoivent le trafic à équilibrage de charge. Un équilibreur de charge réseau passthrough externe global peut distribuer le trafic vers des groupes d'instances ou des NEG zonaux situés dans plusieurs Cloud de Confiance régions :

  • Si vous choisissez des groupes d'instances, vous pouvez utiliser des groupes d'instances gérés zonaux, des groupes d'instances non gérés zonaux ou une combinaison de ces types de groupes d'instances. Les groupes d'instances sont compatibles avec les modes d'équilibrage de charge RATE et UTILIZATION.

  • Si vous choisissez des NEG zonaux, vous devez utiliser des NEG zonaux GCE_VM_IP. Les NEG ne sont compatibles qu'avec le mode d'équilibrage de charge RATE.

Compatibilité des interfaces réseau de VM avec les règles de transfert

Étant donné que les équilibreurs de charge réseau passthrough externes globaux n'interrompent ni ne traduisent le trafic, le type de pile de l'interface réseau de la VM de backend doit être compatible avec la version de l'adresse IP de la règle de transfert.

Règle de transfert	Type de pile des interfaces réseau de la VM de backend
Règles de transfert IPv4 uniquement	IPv4 uniquement (IPV4_ONLY) ou double pile (IPV4_IPv6)
Règles de transfert IPv6 uniquement	IPv6 uniquement (IPV6_ONLY) ou double pile (IPV4_IPv6)
Règles de transfert IPv4 et IPv6	Double pile (IPV4_IPv6)

Compatibilité de l'interface réseau de la VM de backend avec les sous-réseaux VPC

Comme indiqué dans le tableau précédent, vous pouvez configurer un équilibreur de charge réseau passthrough externe global pour qu'il dispose de backends contenant des interfaces IPv4 uniquement, des interfaces à double pile et des interfaces IPv6 uniquement. Le tableau suivant récapitule les types d'interfaces réseau de VM de backend compatibles avec chaque type de pile de sous-réseau VPC.

Type de pile des sous-réseaux VPC	Type de pile de l'interface réseau de la VM de backend
IPV4_ONLY (pile unique) Plages de sous-réseaux IPv4 uniquement	IPv4 uniquement (IPV4_ONLY)
IPV4_IPV6 (double pile) Plages de sous-réseaux IPv4 et IPv6	IPv4 uniquement (IPV4_ONLY), double pile (IPV4_IPv6) et IPv6 uniquement (IPV6_ONLY)
IPV6_ONLY (pile unique) Plages de sous-réseaux IPv6 uniquement	IPv6 uniquement (IPV6_ONLY)

Veuillez noter les points suivants :

• L'adresse IP attribuée à une interface réseau de VM est allouée directement à partir du sous-réseau VPC sous-jacent.

• Pour la connectivité IPv6, lorsqu'une interface réseau de VM est attribuée à un sous-réseau /64 compatible avec IPv6, Cloud de Confiance attribue à l'interface réseau de VM une plage d'adresses /96 à partir de la première moitié (/65) de la plage d'adresses IPv6 externes /64 du sous-réseau. Pour en savoir plus, consultez Spécifications IPv6 externes.

• Lorsque le type de pile de l'interface réseau de la VM est à double pile (IPV4_IPv6) ou IPv6 uniquement (IPV6_ONLY), vous devez choisir comment l'adresse IPv6 de l'interface réseau de la VM peut être atteinte en configurant le paramètre --ipv6-access-type sur le sous-réseau VPC sur EXTERNAL ou INTERNAL. Si le --ipv6-access-type du sous-réseau est défini sur EXTERNAL, vous devez également définir le --ipv6-network-tier sur l'interface réseau de la VM sur PREMIUM. Pour en savoir plus, consultez Plages de sous-réseaux IPv6.

Backends de groupes d'instances et interfaces réseau

Dans un groupe d'instances donné (géré ou non), l'interface réseau nic0 de chaque VM membre se trouve toujours dans le même réseau VPC :

• Pour les groupes d'instances gérés (MIG), le réseau VPC du groupe d'instances provient de l'interface nic0 définie 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 sur le réseau VPC utilisé par l'interface réseau nic0 de la première instance de VM que vous ajoutez au groupe d'instances non géré. Vous ne pourrez pas modifier ultérieurement le réseau VPC du groupe d'instances, même si vous supprimez la première instance que vous avez ajoutée au groupe.

Les VM membres peuvent avoir des interfaces réseau supplémentaires (cartes d'interface réseau virtuelles ou interfaces réseau dynamiques). Chaque interface non nic0 peut se trouver dans le réseau VPC du groupe d'instances (le réseau utilisé par l'interface nic0) ou dans un autre réseau VPC.

Pour distribuer le trafic à équilibrage de charge vers une interface réseau non-nic0, vous ne pouvez pas utiliser de backends de groupes d'instances. Utilisez plutôt des NEG zonaux avec des points de terminaison GCE_VM_IP. Pour en savoir plus, consultez Services de backend et réseaux VPC.

Backends de NEG zonaux et interfaces réseau

Lorsque vous créez un NEG zonal avec des points de terminaison GCE_VM_IP, vous devez explicitement associer le NEG au sous-réseau d'un réseau VPC avant de pouvoir lui attribuer des points de terminaison. Ni le sous-réseau ni le réseau VPC ne peuvent être modifiés une fois le NEG créé.

Dans un NEG donné, chaque point de terminaison GCE_VM_IP représente une interface réseau. L'interface réseau doit se trouver dans le sous-réseau associé au NEG. Du point de vue d'une instance Compute Engine, l'interface réseau peut utiliser n'importe quel identifiant. Du point de vue d'un point de terminaison dans un NEG, l'interface réseau est identifiée à l'aide de son adresse IPv4 interne principale. Pour en savoir plus, consultez NEG avec des points de terminaison GCE_VM_IP.

Il existe deux manières d'ajouter un point de terminaison GCE_VM_IP à un NEG :

• Si vous ne spécifiez qu'un nom de VM (sans aucune adresse IP) lors de l'ajout d'un point de terminaison, Cloud de Confiance exige que la VM dispose d'une interface réseau dans le sous-réseau associé au NEG. L'adresse IP choisie par Cloud de Confiancepour le point de terminaison est l'adresse IPv4 interne principale de l'interface réseau de la VM dans le sous-réseau associé au NEG.
• Si vous spécifiez à la fois un nom de VM et une adresse IP lors de l'ajout d'un point de terminaison, l'adresse IP que vous fournissez doit être une adresse IPv4 interne principale pour l'une des interfaces réseau de la VM. Cette interface réseau doit se trouver dans le sous-réseau associé au NEG. Notez que la spécification d'une adresse IP est redondante, car une seule interface réseau peut se trouver dans le sous-réseau associé au NEG.

Services de backend et réseaux VPC

Le service de backend n'est associé à aucun réseau VPC. Cependant, chaque groupe d'instances backend ou NEG zonal est associé à un réseau VPC, comme indiqué précédemment. Tant que tous les backends sont situés dans le même projet et qu'ils sont du même type (groupes d'instances ou NEG zonaux), l'équilibreur de charge et ses backends peuvent se trouver dans le même réseau VPC ou dans des réseaux VPC différents.

Pour distribuer des paquets à des interfaces non-nic0, vous devez remplir les deux conditions suivantes :

• Vous devez utiliser des NEG zonaux (avec des points de terminaison GCE_VM_IP), et non des groupes d'instances.

• Les interfaces réseau nic0 et nic0 doivent se trouver dans des réseaux VPC différents. (Le réseau VPC du NEG ne peut pas contenir l'interface nic0 et l'interface non nic0 souhaitée.)

Backends préférés

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

Le service de backend d'un équilibreur de charge réseau passthrough externe global ne peut comporter qu'un seul groupe de backends préféré et n'autorise pas les backends préférés et non préférés dans la même région Cloud de Confiance .

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

Vérifications d'état

Les informations de vérification de l'état sont utilisées pour déterminer les backends éligibles aux nouvelles connexions et pour contrôler si les connexions existantes persistent sur les backends non opérationnels.

L'équilibreur de charge envoie des vérifications d'état pour chaque adresse IP de règle de transfert séparément. Par conséquent, une règle de transfert d'équilibreur de charge réseau passthrough externe global avec deux adresses IP est analysée pour chaque adresse IP, ce qui double la fréquence d'analyse sur chaque backend. Pour en savoir plus, consultez Vérifications multiples et fréquence de vérification.

Type, protocole et port de la vérification d'état

Le service de backend de l'équilibreur de charge doit faire référence à une vérification de l'état globale, en utilisant n'importe quel protocole et port de vérification de l'état d'état compatibles. Les informations sur le protocole et le port de la vérification de l'état d'état ne doivent pas nécessairement correspondre à celles de la règle de transfert.

 Étant donné que tous les protocoles de vérification de l'état compatibles reposent sur TCP (les vérifications d'état UDP ne sont pas acceptées), lorsque vous utilisez un équilibreur de charge réseau passthrough externe global pour équilibrer les connexions et le trafic pour d'autres protocoles, les VM de backend doivent exécuter un serveur basé sur TCP pour répondre aux vérifications d'état. Par exemple, vous pouvez utiliser une vérification de l'état HTTP combinée à l'exécution d'un serveur HTTP sur chaque VM de backend. Dans cet exemple, vos scripts ou logiciels sont responsables de la configuration du serveur HTTP afin qu'il renvoie l'état 200 uniquement lorsque le logiciel qui écoute les connexions à équilibrage de charge est opérationnel.

Pour en savoir plus sur les protocoles et ports de vérification de l'état de l'état compatibles, consultez Catégories, protocoles et ports pour les vérifications de l'état et Fonctionnement des vérifications de l'état.

Paquets de vérification de l'état

Pour les backends de groupe d'instances, les vérificateurs d'état envoient des paquets à l'interface réseau nic0 de chaque VM de backend. Pour les backends de NEG zonaux GCE_VM_IP, les vérificateurs de l'état de santé envoient des paquets à l'interface réseau du sous-réseau VPC du NEG. Les paquets de vérification de l'état présentent les caractéristiques suivantes :

• Adresse IP source de la plage d'adresses IP de la vérification de l'état'état concernée.

• Adresse IP de destination correspondant à l'une des deux adresses IP de la règle de transfert qui fait référence au service de backend de l'équilibreur de charge réseau passthrough externe global. Les paquets de vérification de l'état sont envoyés aux deux adresses IP.

• Port de destination correspondant au numéro de port que vous spécifiez dans la vérification de l'état.

Les applications exécutées sur les VM de backend doivent se lier aux combinaisons d'adresse IP et de port appropriées, et les écouter. Pour ce faire, configurez l'application pour qu'elle se lie aux ports concernés de l'une des adresses IP de la VM (0.0.0.0 ou ::/0) et qu'elle les écoute. Pour en savoir plus, consultez Destination des paquets associés à la vérification d'état.

Règles de pare-feu

Comme un équilibreur de charge réseau passthrough externe global n'est pas un proxy, il transmet le trafic aux VM de backend sans modifier leurs adresses IP source et de destination, leur protocole ni leurs ports, si le protocole contient des informations sur le port. Par conséquent, vous devez créer des règles de pare-feu autorisant les entrées ou une stratégie de pare-feu hiérarchique autorisant les entrées pour contrôler l'accès aux VM de backend de l'équilibreur de charge, plus précisément pour autoriser les vérifications d'état et le trafic dont vous équilibrez la charge. Sinon, la règle de pare-feu d'entrée "Tout refuser" implicite bloque les paquets entrants provenant de toutes les adresses IP sources externes.

Les règles de transfert et les règles de pare-feu ou les règles de pare-feu spécifiques autorisant les entrées fonctionnent ensemble de la manière suivante : une règle de transfert spécifie l'adresse IP de destination, le protocole et, lorsque la règle est définie, les exigences de port qu'un paquet doit respecter pour être transféré à une VM de backend. Les règles de pare-feu autorisant les Ingress contrôlent si le pare-feu distribue les paquets transférés à la VM ou les supprime. Le réseau VPC par défaut Cloud de Confiance inclut un ensemble limité de règles de pare-feu préremplies autorisant les entrées.

• Pour accepter le trafic provenant de n'importe quelle adresse IP sur Internet, vous devez créer une règle de pare-feu autorisant les entrées avec la plage d'adresses IP sources 0.0.0.0/0 ou ::/0. Pour autoriser uniquement le trafic provenant de certaines plages d'adresses IP, utilisez des plages sources plus restrictives.

• Selon les bonnes pratiques de sécurité, vos règles de pare-feu autorisant les entrées doivent se limiter aux seuls protocoles IP et ports dont vous avez besoin. Il est particulièrement important de limiter la configuration du protocole (et, si possible, du port) lorsque vous utilisez des règles de transfert dont le protocole est défini sur L3_DEFAULT. Les règles de transfert L3_DEFAULT transfèrent les paquets pour tous les protocoles IP compatibles (sur tous les ports si le protocole et les paquets contiennent des informations de port).

• Les équilibreurs de charge réseau passthrough externes globaux utilisent des vérifications d'état Cloud de Confiance . Par conséquent, vous devez toujours autoriser le trafic provenant des plages d'adresses IP associées aux vérifications d'état. Vous pouvez configurer ces règles de pare-feu autorisant le trafic entrant en fonction du protocole et des ports de la vérification de l'état de l'équilibreur de charge.

Répartition du trafic

Pour un équilibreur de charge réseau passthrough externe mondial, la distribution du trafic dépend de différents attributs tels que l'affinité de session, la règle de suivi des connexions, le mode d'équilibrage de charge et les capacités de backend, les backends préférés et la règle de localité d'équilibrage de charge. Ils font tous partie d'un workflow coordonné visant à optimiser la configuration de l'équilibrage de charge pour des performances fiables et une utilisation efficace des ressources.

Architecture du VPC partagé

Notez les points suivants concernant une architecture de VPC partagé pour un équilibreur de charge réseau passthrough externe global :

• À l'exception des ressources d'adresse IP, toutes les autres ressources associées à un équilibreur de charge réseau passthrough externe global (règle de transfert, service de backend, vérification de l'état#39;état et groupes de backend [groupes d'instances ou NEG]) doivent exister dans le même projet. Ce projet peut être un projet hôte ou un projet de service.

• Si les ressources d'équilibrage de charge existent dans le projet hôte, les ressources d'adresse IP doivent également exister dans le projet hôte.

• Si les ressources d'équilibrage de charge existent dans un projet de service, les ressources d'adresse IP peuvent se trouver dans le même projet de service ou dans le projet hôte.

Le tableau suivant indique où se trouvent les différents composants d'un équilibreur de charge réseau passthrough externe global dans une architecture VPC partagé.

Emplacement des ressources d'équilibrage de charge1	Emplacement requis des ressources d'adresse IP
Projet hôte	Projet hôte
Projet de service	Projet de service ou projet hôte

Limites

• Les backends ne peuvent être déployés que dans les régions Cloud de Confiance suivantes :

  • Amérique du Nord : us-west1, us-west4, us-east4, us-east5
  • Europe : europe-west2, europe-west3
  • Asie : asia-southeast1, asia-south1, asia-northeast1
  • Amérique du Sud : southamerica-east1
  • Afrique : africa-south1
  • Australie : australia-southeast1

• L'équilibreur de charge réseau passthrough externe global ne peut être configuré qu'avec le niveau Premium.

• Vous ne pouvez pas configurer un équilibreur de charge réseau passthrough externe mondial à l'aide de la console Cloud de Confiance . Utilisez plutôt Google Cloud CLI ou l'API REST.

• Vous ne pouvez pas utiliser de backends de groupes d'instances gérés régionaux. Vous pouvez utiliser des groupes d'instances gérés zonaux, des groupes d'instances non gérés zonaux et des NEG zonaux avec des points de terminaison GCE_VM_IP.

• Les restrictions et conseils existants pour l'utilisation de groupes d'instances dans les services de backend s'appliquent également aux équilibreurs de charge réseau passthrough externes globaux. Un groupe d'instances partagé entre un équilibreur de charge réseau passthrough externe global et des équilibreurs de charge réseau passthrough régionaux (équilibreur de charge réseau passthrough externe régional ou équilibreur de charge réseau passthrough interne) doit être configuré pour utiliser le mode d'équilibrage RATE sur l'équilibreur de charge réseau passthrough externe global. Les équilibreurs de charge réseau passthrough régionaux utilisent toujours le mode d'équilibrage CONNECTION.

• Vous pouvez partager la même adresse IP externe globale entre plusieurs règles de transfert d'équilibreur de charge réseau passthrough externe global, à condition que les protocoles et ports configurés ne soient pas en conflit. Toutefois, vous ne pouvez pas partager la même adresse IP externe globale entre un équilibreur de charge réseau passthrough externe global et un équilibreur de charge d'application externe global ou un équilibreur de charge réseau proxy externe global.

• Un équilibreur de charge réseau passthrough externe global accepte les adresses IP que vous apportez (BYOIP) pour les adresses IPv4 uniquement. L'assistance est limitée à l'API BYOIP v1. Le provisionnement de nouvelles plages d'adresses IPv4 peut prendre jusqu'à quatre semaines. De plus, aucune API ne vous permet de contrôler l'état de votre annonce BGP. Pour en savoir plus, consultez Configurer l'utilisation de vos propres adresses IP.

• Vous ne pouvez pas créer plus de 10 règles de transfert dans un projet ni ajouter plus de 25 groupes de backend à un service de backend. Pour plus de détails, consultez la page Quotas et limites.

• Un service de backend d'équilibreur de charge réseau passthrough externe global ne peut comporter qu'un seul groupe de backends PREFERRED. Vous ne pouvez pas avoir de groupe de backend PREFERRED et non PREFERRED dans la même région Cloud de Confiance .

• Vous ne pouvez pas déployer d'équilibreur de charge réseau passthrough externe global dans GKE.

• Vous ne pouvez pas utiliser Google Cloud Armor pour fournir une protection DDoS avancée du réseau pour les équilibreurs de charge réseau passthrough externes mondiaux. Pour en savoir plus, consultez Configurer la protection DDoS avancée du réseau.

• La règle d'équilibrage de charge de la localité, configurée sur le service de backend de l'équilibreur de charge, n'est pas compatible avec l'option WEIGHTED_MAGLEV. Pour les équilibreurs de charge réseau passthrough externes globaux, seul MAGLEV est accepté.

• Le mode de suivi des connexions PER_SESSION n'est pas compatible. Seul le mode de suivi des connexions PER_CONNECTION est accepté.

• Seuls les modes d'équilibrage de charge suivants sont acceptés : RATE et UTILIZATION. Le débit n'est pas défini en termes de requêtes par seconde, mais en termes de paquets entrants par seconde. Les groupes d'instances sont compatibles avec RATE et UTILIZATION, tandis que les NEG ne sont compatibles qu'avec RATE.

• Les règles de transfert d'orientation (orientation du trafic basée sur l'adresse IP source) ne sont pas acceptées.

• Tous les backends associés à un service de backend doivent être du même type. Un service de backend ne peut pas comporter à la fois des groupes d'instances et des NEG zonaux.

• Il est impossible d'interroger ou de filtrer les métriques de surveillance à l'aide des règles de transfert globales parentes. Vous devez les interroger à l'aide des règles de transfert enfants générées par Cloud de Confiance.

Tarifs

Pour obtenir des informations sur la tarification, consultez Tarifs du réseau : Cloud Load Balancing.

Étapes suivantes

• Configurer un équilibreur de charge réseau passthrough externe global avec des backends de groupe d'instances de VM
• Configurer un équilibreur de charge réseau passthrough externe mondial avec des backends de NEG zonaux
• Modes d'équilibrage pour les équilibreurs de charge réseau passthrough
• Spécifications de capacité cible pour les équilibreurs de charge réseau passthrough externes mondiaux
• Documentation de référence de l'API Cloud Load Balancing et de gcloud CLI