Présentation de l'équilibrage de charge réseau TCP/UDP externe basé sur un service de backend

L'équilibrage de charge réseau TCP/UDP externe de Google Cloud (nommé "équilibrage de charge réseau" ci-après) est un équilibreur de charge régional à stratégie directe. Un équilibreur de charge réseau distribue le trafic externe entre les instances de machines virtuelles (VM) de la même région.

Vous pouvez configurer un équilibreur de charge réseau pour le trafic TCP, UDP, ESP, GRE, ICMP et ICMPv6.

Un équilibreur de charge réseau peut recevoir du trafic provenant des éléments suivants :

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

L'équilibrage de charge réseau présente les caractéristiques suivantes :

  • L'équilibrage de charge réseau est un service géré.
  • L'équilibrage de charge réseau est mis en œuvre à l'aide du réseau virtuel Andromeda et de Google Maglev.
  • Les équilibreurs de charge réseau ne sont pas des proxys.
    • Les paquets à équilibrage de charge sont reçus par les VM de backend avec les adresses IP source et de destination de paquet, le protocole et, si celui-ci est basé sur le port, les ports source et de destination inchangés.
    • Les connexions à équilibrage de charge sont interrompues par les VM backend.
    • Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Le terme utilisé dans le secteur est retour direct du serveur.

Les équilibreurs de charge réseau basés sur un service de backend présentent les caractéristiques suivantes :

  • Backends de groupes d'instances gérés. Les équilibreurs de charge réseau basés sur un service de backend acceptent l'utilisation de groupes d'instances gérés comme backends. Les groupes d'instances gérés automatisent certains aspects de la gestion des backends, et offrent une meilleure évolutivité et davantage de fiabilité que les groupes d'instances non gérés.
  • Compatibilité avec la connectivité IPv6 Les équilibreurs de charge réseau basés sur un service de backend peuvent gérer à la fois le trafic IPv4 et IPv6.
  • Contrôle ultraprécis de la répartition du trafic. La configuration d'un service de backend contient un ensemble de valeurs, telles que les vérifications d'état, l'affinité de session, le suivi des connexions, les règles de drainage de connexion et les règles de basculement. La plupart des paramètres possèdent des valeurs par défaut qui facilitent la configuration afin de démarrer rapidement.
  • Vérifications d'état. Les équilibreurs de charge réseau basés sur un service de backend utilisent des vérifications d'état qui correspondent au type de trafic (TCP, SSL, HTTP, HTTPS ou HTTP/2) qu'ils distribuent.

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans GKE, nous vous recommandons d'utiliser le contrôleur de service GKE intégré, qui déploie des équilibreurs de charge Google Cloud pour le compte des utilisateurs de GKE. Cela est identique à l'architecture d'équilibrage de charge autonome décrite sur cette page, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE.

Documentation GKE associée :

Architecture

Le schéma suivant illustre les composants d'un équilibreur de charge réseau :

Équilibreur de charge réseau TCP/UDP externe avec un service de backend régional
Équilibrage de charge réseau avec un service de backend régional

L'équilibreur de charge est constitué de plusieurs composants de configuration. Un équilibreur de charge unique peut inclure les composants suivants :

  • Une ou plusieurs adresses IP externes régionales
  • Une ou plusieurs règles de transfert externes régionales
  • Un service de backend externe régional
  • Un ou plusieurs groupes d'instances backend
  • Vérification de l'état associée au service de backend

En outre, vous devez créer des règles de pare-feu permettant à votre trafic d'équilibrage de charge et aux requêtes de vérification d'état d'atteindre les VM de backend.

Adresse IP

Un équilibreur de charge réseau nécessite au moins une règle de transfert. La règle de transfert fait référence à une adresse IP externe régionale accessible partout sur Internet.

  • Pour le trafic IPv4, la règle de transfert fait référence à une seule adresse IPv4 externe régionale. Les adresses IPv4 externes régionales proviennent d'un pool propre à chaque région Google Cloud. L'adresse IP peut être une adresse statique réservée ou une adresse éphémère.
  • Pour le Trafic IPv6, la règle de transfert fait référence à une plage d'adresses IP /96 de la plage d'adresses IPv6 externe du sous-réseau /64. Le sous-réseau doit être un sous-réseau à deux piles, avec le paramètre ipv6-access-type défini sur EXTERNAL. Les adresses IPv6 externes ne sont disponibles qu'avec le niveau Premium. La réservation d'une adresse IPv6 externe régionale n'est possible que pour les instances. Vous devez donc utiliser une adresse IPv6 éphémère pour la règle de transfert.

Utilisez une adresse IP réservée pour la règle de transfert si vous devez conserver l'adresse associée à votre projet pour pouvoir la 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 à la même adresse IP.

L'équilibrage de la charge réseau est compatible avec les niveaux Standard et Premium pour les adresses IPv4 externes régionales. L'adresse IP et la règle de transfert doivent utiliser le même niveau réseau. Les adresses IPv6 externes régionales ne sont disponibles qu'avec le niveau Premium.

Règle de transfert

Une règle de transfert externe régionale spécifie le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic. Les équilibreurs de charge réseau n'étant pas des proxys, ils transmettent le trafic aux backends sur le même protocole et le même port si le paquet contient des informations sur le port. La règle de transfert et l'adresse IP forment l'interface de l'équilibreur de charge.

L'équilibreur de charge conserve les adresses IP sources des paquets entrants. L'adresse IP de destination des paquets entrants est une adresse IP associée à la règle de transfert de l'équilibreur de charge.

Le trafic entrant est mis en correspondance avec une règle de transfert, qui consiste en la combinaison d'une adresse IP particulière (adresse IPv4 ou plage d'adresses IPv6) et d'un protocole. Si le protocole est basé sur le port, il doit utiliser l'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.

  • Si la règle de transfert fait référence à une adresse IPv4, elle n'est associée à aucun sous-réseau. Autrement dit, son adresse IP provient d'une plage de sous-réseau autre que Google Cloud.

  • Si la règle de transfert fait référence à une adresse IPv6, la règle de transfert doit être associée à un sous-réseau, et ce sous-réseau doit être (a) à double pile et (b) avoir --ipv6-access-type définir surEXTERNAL.

Un équilibreur de charge réseau nécessite au moins une règle de transfert. Les règles de transfert peuvent être configurées pour diriger le trafic provenant d'une plage spécifique d'adresses IP sources vers un service de backend (ou une instance cible) spécifique. Pour en savoir plus, consultez Orientation du trafic. Vous pouvez définir plusieurs règles de transfert pour le même équilibreur de charge, comme décrit dans la section Plusieurs règles de transfert.

Si vous souhaitez que l'équilibreur de charge gère à la fois le trafic IPv4 et IPv6, créez deux règles de transfert: une règle pour le trafic IPv4 qui pointe vers les backends IPv4 (ou double pile), et une règle pour le trafic IPv6 qui pointe uniquement vers les backends à deux piles. 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 à double pile.

Protocoles de règles de transfert

L'équilibrage de charge réseau est compatible avec 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. L'option de protocole L3_DEFAULT permet à un équilibreur de charge réseau 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.

Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent faire référence à un service de backend utilisant le même protocole que la règle de transfert ou à un service de backend dont le protocole est UNSPECIFIED. Les règles de transfert L3_DEFAULT ne peuvent faire référence qu'à un service de backend avec le protocole UNSPECIFIED.

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. Pour configurer tous les ports, définissez --ports=ALL à l'aide de Google Cloud CLI ou définissez allPorts sur True à l'aide de l'API.

Le tableau suivant récapitule comment utiliser ces paramètres pour différents protocoles.

Trafic dont la charge doit être équilibrée Protocole de règle de transfert Protocole de service de backend
TCP TCP TCP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE,
ICMP/ICMPv6 (requête d'écho uniquement)
L3_DEFAULT UNSPECIFIED

Plusieurs règles de transfert

Vous pouvez configurer plusieurs règles de transfert externes régionales pour un même équilibreur de charge réseau. Chaque règle de transfert peut avoir sa propre adresse IP externe régionale, ou plusieurs règles de transfert peuvent avoir la même adresse IP externe régionale.

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

  • Vous devez configurer plusieurs adresses IP externes pour le même service de backend.
  • Vous devez configurer différents protocoles, ou des ports ou plages de ports qui ne se chevauchent pas, pour une même adresse IP externe.
  • Vous devez orienter le trafic de certaines adresses IP sources vers des backends d'équilibreur de charge spécifiques.

Google Cloud exige que les paquets entrants ne correspondent pas à plus d'une règle de transfert. À l'exception des règles de transfert qui sont décrites dans la section suivante, deux règles de transfert ou plus utilisant la même adresse IP externe régionale 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 le même protocole et la même 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 l'adresse IP 198.51.100.1, le protocole TCP et tous les ports, vous ne pouvez pas créer d'autre règle de transfert spécifiant l'adresse IP 198.51.100.1 et le protocole TCP. Vous pouvez créer deux règles de transfert, utilisant toutes deux l'adresse IP 198.51.100.1 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 spécifiant l'adresse IP 198.51.100.1 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 adresse 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). La règle de transfert L3_DEFAULT peut être utilisée en dernier recours, en présence de règles de transfert utilisant la même adresse IP, mais avec des protocoles plus 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 adresse IP 198.51.100.1.

    • 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'adresse 198.51.100.1 sont traités par la deuxième règle de transfert. 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 à l'adresse 198.51.100.1:8080 sont traités par la seconde 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

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

  • Si les règles de transfert applicables restantes incluent à la fois des règles de transfert L3_DEFAULT et des règles de transfert spécifiques à un protocole, éliminer les règles de transfert L3_DEFAULT. Si les règles de transfert applicables restantes sont toutes des règles de transfert L3_DEFAULT, aucune n'est éliminée à cette étape.

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

    • Il ne reste qu'une seule règle de transfert, correspondant à l'adresse IP de destination, au protocole et au port du paquet, et qui est utilisée pour acheminer le paquet.
    • Il reste au moins deux règles de transfert applicables, qui correspondent à l'adresse IP de destination, au protocole et au port du paquet. Cela signifie que les règles de transfert applicables restantes incluent des règles de transfert d'orientation (décrites dans la section suivante). Sélectionnez la règle de transfert d'orientation dont la plage source inclut le CIDR le plus spécifique (correspondance du préfixe le plus long), contenant l'adresse IP source du paquet. Si aucune règle de transfert d'orientation n'a de plage source englobant l'adresse IP source du paquet, sélectionnez la règle de transfert parente.
    • Il ne reste aucune règle de transfert applicable et le paquet est supprimé.

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

Orientation du trafic

Les règles de transfert des équilibreurs de charge réseau peuvent être configurées pour diriger le trafic provenant d'une plage spécifique d'adresses IP sources vers un service de backend (ou une instance cible) spécifique.

L'orientation du trafic est utile pour le dépannage et pour les configurations avancées. Avec l'orientation du trafic, vous pouvez diriger certains clients vers un ensemble de backends différent, une configuration de service de backend différente, ou les deux à la fois. Exemple :

  • L'orientation du trafic vous permet de créer deux règles de transfert qui dirigent le trafic vers le même groupe d'instances backend, via deux services de backend. Les deux services de backend peuvent être configurés avec différentes vérifications d'état, différentes affinités de session ou différentes règles de contrôle de la distribution du trafic (suivi des connexions, drainage de connexion et basculement).
  • L'orientation du trafic vous permet de créer deux règles de transfert qui dirigent le trafic vers des services de backend différents, avec différents groupes d'instances backend. Par exemple, un groupe d'instances peut être configuré à l'aide de différents types de machines afin de mieux traiter le trafic provenant d'un certain ensemble d'adresses IP sources.

L'orientation du trafic est configurée avec un paramètre d'API de règle de transfert appelé sourceIPRanges. Les règles de transfert pour lesquelles au moins une plage d'adresses IP sources est configurée sont appelées des règles de transfert d'orientation.

Une règle de transfert d'orientation peut répertorier jusqu'à 64 plages d'adresses IP sources. Vous pouvez à tout moment mettre à jour la liste des plages d'adresses IP sources configurées pour une règle de transfert d'orientation.

Chaque règle de transfert d'orientation nécessite d'abord de créer une règle de transfert parente. Les règles de transfert parente et d'orientation partagent les mêmes adresses IP externes régionales, le même protocole et les mêmes informations de port. Cependant, la règle de transfert parente ne comporte aucune information d'adresse IP source. Exemple :

  • Règle de transfert parente : adresse IP : 198.51.100.1, protocole IP : TCP, port : 80
  • Règle de transfert d'orientation : adresse IP : 198.51.100.1, protocole IP : TCP, port : 80, plage d'adresses IP sources : 203.0.113.0/24

Une règle de transfert parente pointant vers un service de backend peut être associée à une règle de transfert d'orientation qui pointe vers un service de backend ou une instance cible.

Pour une règle de transfert parente donnée, deux règles de transfert d'orientation ou plus peuvent avoir des plages d'adresses IP sources qui se chevauchent, sans être identiques. Par exemple, une règle de transfert d'orientation peut avoir la plage d'adresses IP sources 203.0.113.0/24 et une autre règle de transfert d'orientation pour la même règle parente peut avoir la plage d'adresses IP sources 203.0.113.0.

Avant de pouvoir supprimer une règle de transfert parente, vous devez supprimer toutes les règles de transfert d'orientation dépendant de cette règle parente.

Pour savoir comment les paquets entrants sont traités lors de l'utilisation des règles de transfert d'orientation, consultez la section Sélection des règles de transfert.

Comportement d'affinité de session lors des changements d'orientation

Cette section décrit les conditions dans lesquelles l'affinité de session peut échouer lorsque les plages d'adresses IP sources pour les règles de transfert d'orientation sont mises à jour :

  • Si une connexion existante continue de correspondre à la même règle de transfert après la modification des plages d'adresses IP sources d'une règle de transfert d'orientation, l'affinité de session n'est pas interrompue. Si par contre une connexion existante correspond à une autre règle de transfert, suite à votre modification, alors :
  • l'affinité de session est toujours interrompue dans les cas suivants :
    • la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend (ou une instance cible) qui ne fait pas référence à la VM de backend précédemment sélectionnée ;
    • la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend qui fait référence à la VM de backend précédemment sélectionnée, mais le service de backend n'est pas configuré pour faire persister les connexions lorsque les backends ne sont pas opérationnels, et la VM de backend échoue à la vérification de l'état du service de backend ;
  • l'affinité de session peut être interrompue lorsque la nouvelle règle de transfert correspondante dirige une connexion établie vers un service de backend, et que celui-ci fait référence à la VM précédemment sélectionnée, mais la combinaison du mode d'affinité de session et du mode de suivi des connexions du service de backend génère un hachage de suivi de connexion différent.

Préserver l'affinité de session lors des changements d'orientation

Cette section explique comment éviter d'interrompre l'affinité de session lorsque les plages d'adresses IP sources pour les règles de transfert d'orientation sont mises à jour :

  • Règles de transfert d'orientation pointant vers des services de backend. Si la règle de transfert parente et la règle de transfert d'orientation pointent vers des services de backend, vous devez vérifier manuellement que les paramètres d'affinité de session et de règle de suivi de connexion sont identiques. Google Cloud ne rejette pas automatiquement les configurations si elles ne sont pas identiques.
  • Règles de transfert d'orientation pointant vers des instances cibles. Une règle de transfert parente pointant vers un service de backend peut être associée à une règle de transfert d'orientation qui pointe vers une instance cible. Dans ce cas, la règle de transfert d'orientation hérite des paramètres d'affinité de session et de règle de suivi de connexion de la règle de transfert parente.

Pour obtenir des instructions sur la configuration de l'orientation du trafic, consultez Configurer l'orientation du trafic.

Service backend régional

Chaque équilibreur de charge réseau dispose d'un service de backend régional qui définit le comportement de l'équilibreur de charge et la façon dont le trafic est distribué à ses backends. Le nom du service de backend correspond au nom de l'équilibreur de charge réseau affiché dans Google Cloud Console.

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

  • Protocole. Un service de backend accepte du trafic sur l'adresse IP et les ports spécifiés (le cas échéant) par une ou plusieurs règles de transfert externes régionales. Le service de backend transmet des paquets aux VM de backend tout en conservant les adresses IP source et de destination des paquets, le protocole et, si le protocole est basé sur le port, les ports source et de destination.

    Les services de backend utilisés avec les équilibreurs de charge réseau acceptent les options de protocole suivantes : TCP, UDP ou 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. Les services de backend avec un protocole spécifique (TCP ou UDP) ne peuvent être référencés que par des règles de transfert ayant le même protocole (TCP ou UDP). Les règles de transfert avec le protocole L3_DEFAULT ne peuvent faire référence qu'aux services de backend avec le protocole UNSPECIFIED.

    Pour obtenir le tableau des combinaisons possibles de règles de transfert et de protocoles de services de backend, consultez la section Spécification du protocole d'une règle de transfert.

  • Distribution du trafic. Un service de backend permet de distribuer le trafic en fonction de règles d'affinité de session et de suivi de connexion configurables. Le service de backend peut également être configuré afin d'activer le drainage de connexion et de désigner des backends de basculement pour l'équilibreur de charge.

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

Chaque service de backend fonctionne dans une seule région et distribue le trafic vers la première interface réseau (nic0) des VM de backend. Les backends doivent être des groupes d'instances de la même région que le service de backend (et la règle de transfert). Les backends peuvent être des groupes d'instances non gérés zonaux, des groupes d'instances gérés zonaux ou des groupes d'instances gérés régionaux.

Les équilibreurs de charge réseau basés sur un service de backend acceptent les groupes d'instances dont les instances membres utilisent n'importe quel réseau VPC de la même région, à condition que ce réseau VPC se trouve dans le même projet que le service de backend. (Toutes les VM d'un groupe d'instances donné doivent utiliser le même réseau VPC.)

Si vous souhaitez que l'équilibreur de charge accepte le trafic IPv6, le service de backend doit référencer des backends qui répondent aux exigences de gestion du trafic IPv6.

Groupes d'instances backend

Un équilibreur de charge réseau répartit les connexions entre les VM de backend appartenant à des groupes d'instances gérés ou non gérés. Les groupes d'instances peuvent être régionaux ou zonaux.

  • Groupes d'instances gérés régionaux Utilisez des groupes d'instances gérés régionaux si vous pouvez déployer votre logiciel à l'aide de modèles d'instance. Les groupes d'instances gérés régionaux distribuent automatiquement le trafic entre plusieurs zones, offrant ainsi la meilleure option pour éviter les problèmes potentiels dans une zone donnée.

    Un exemple de déploiement utilisant un groupe d'instances géré régional est présenté ici. Le groupe d'instances dispose d'un modèle d'instance qui définit la manière dont les instances doivent être provisionnées, et chaque groupe déploie des instances dans trois zones de la région us-central1.

    Équilibreur de charge réseau avec un groupe d'instances géré régional
    Équilibrage de charge réseau avec un groupe d'instances géré régional
  • Groupes d'instances gérés ou non gérés zonaux. Utilisez des groupes d'instances zonaux dans différentes zones (de la même région) pour vous protéger contre les problèmes potentiels pouvant survenir dans une zone donnée.

    Un exemple de déploiement utilisant des groupes d'instances zonaux est présenté ici. Cet équilibreur de charge assure la disponibilité sur deux zones.

    Équilibreur de charge réseau avec des groupes d'instances zonaux
    Équilibrage de charge réseau avec des groupes d'instances zonaux

Si vous souhaitez que l'équilibreur de charge accepte le trafic IPv6, les backends doivent répondre aux exigences suivantes:

  • Les backends doivent être configurés dans des sous-réseaux à deux piles, situés dans la même région que la règle de transfert IPv6 de l'équilibreur de charge. Pour les backends, vous pouvez utiliser un sous-réseau avec le paramètre ipv6-access-type défini sur EXTERNAL ou INTERNAL. L'utilisation d'un sous-réseau avec ipv6-access-type défini sur INTERNAL nécessite l'utilisation d'un sous-réseau double pile distinct avec ipv6-access-type défini sur EXTERNAL pour la règle de transfert externe de l'équilibreur de charge. Pour obtenir des instructions, reportez-vous à la section Ajouter un sous-réseau double pile.
  • Les groupes d'instances backend doivent être configurés pour être double pile, avec le paramètre --ipv6-network-tier défini sur PREMIUM. Pour obtenir des instructions, consultez la page Créer un modèle d'instance avec des adresses IPv6.

Vérifications d'état

L'équilibrage de charge réseau utilise des vérifications d'état régionales pour déterminer les instances qui peuvent recevoir de nouvelles connexions. Le service de backend de chaque équilibreur de charge réseau doit être associé à une vérification d'état régionale. Les équilibreurs de charge utilisent l'état de la vérification d'état pour déterminer comment acheminer les nouvelles connexions vers les instances backend.

Pour en savoir plus sur le fonctionnement des vérifications d'état de Google Cloud, consultez la page Fonctionnement des vérifications d'état.

L'équilibrage de charge réseau est compatible avec les types de vérification d'état suivants :

Vérifications d'état pour le trafic d'autres protocoles

Google Cloud n'offre pas de vérification d'état spécifique au protocole en plus de celles répertoriées ici. Lorsque vous utilisez l'équilibrage de charge réseau pour équilibrer la charge d'un protocole autre que TCP, vous devez exécuter un service basé sur TCP sur vos VM de backend pour fournir les informations requises sur la vérification d'état.

Par exemple, si vous équilibrez la charge du trafic UDP, la charge des requêtes client est équilibrée à l'aide du protocole UDP, et vous devez exécuter un service TCP pour fournir des informations aux vérificateurs d'état Google Cloud. Pour ce faire, vous pouvez exécuter un simple serveur HTTP sur chaque VM de backend qui renvoie une réponse HTTP 200 aux vérificateurs d'état. Dans cet exemple, vous devez utiliser votre propre logique s'exécutant sur la VM de backend pour vous assurer que le serveur HTTP renvoie la réponse 200 uniquement si le service UDP est correctement configuré et exécuté.

Règles de pare-feu

Étant donné que l'équilibrage de charge réseau est un équilibreur de charge à stratégie directe, vous contrôlez l'accès aux backends de l'équilibreur de charge à l'aide de règles de pare-feu Google Cloud. Vous devez créer des règles de pare-feu ou une règle de pare-feu hiérarchique autorisant les entrées pour autoriser les vérifications d'état et le trafic dont vous équilibrez la charge.

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 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 entrées contrôlent si les paquets transférés sont distribués à la VM ou supprimés. Tous les réseaux VPC possèdent une règle de pare-feu implicite interdisant les entrées qui bloque les paquets entrants, quelle que soit leur source. Le réseau VPC par défaut de Google Cloud inclut un ensemble limité de règles de pare-feu prédéfinies 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. 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).

  • L'équilibrage de charge réseau utilise les vérifications d'état Google Cloud. Par conséquent, vous devez toujours autoriser le trafic provenant des plages d'adresses IP associées aux vérifications d'état. Ces règles de pare-feu autorisant le trafic entrant peuvent être spécifiques au protocole et aux ports de la vérification d'état 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 à une VM Google Cloud ou adresse IP routable sur Internet d'un système se connectant à l'équilibreur de charge.
  • Destination : adresse IP de la règle de transfert de l'équilibreur de charge.

L'équilibreur de charge est un équilibreur de charge à stratégie directe (et non un proxy). Par conséquent, les paquets qui arrivent contiennent l'adresse IP de destination de la règle de transfert de l'équilibreur de charge. Le logiciel exécuté sur les VM de backend doit être configuré pour effectuer les opérations suivantes :

  • Écouter (être lié à) l'adresse 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. Les adresses IP source et de destination du paquet de retour dépendent 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 la règle de transfert, de sorte que le client puisse associer les paquets de réponse à la connexion TCP appropriée.
  • Les protocoles UDP, ESP, GRE et ICMP 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ésume les sources et les destinations des paquets de réponses :

Type de trafic Source Destination
TCP Adresse IP de la règle de transfert de l'équilibreur de charge Source du paquet à l'origine de la requête
UDP, ESP, GRE, ICMP Dans la plupart des cas, adresse IP de la règle de transfert de l'équilibreur de charge Source du paquet à l'origine de la requête.

 Lorsqu'une VM possède une adresse IP externe ou lorsque vous utilisez Cloud NAT, il est également possible de définir l'adresse IP source du paquet de réponse sur l'adresse IPv4 interne principale de la carte d'interface réseau de la VM. Google Cloud ou Cloud NAT remplace l'adresse IP source du paquet de réponse par l'adresse IPv4 externe de la carte d'interface réseau ou une adresse IPv4 externe Cloud NAT afin d'envoyer le paquet de réponse à l'adresse IP externe du client. Ne pas utiliser l'adresse IP de la règle de transfert en tant que source est un scénario avancé, car le client reçoit un paquet de réponse provenant d'une adresse IP externe qui ne correspond pas à l'adresse IP à laquelle il a envoyé un paquet de requête.

Chemin de retour

L'équilibrage de charge réseau utilise des routes spéciales en dehors de votre réseau VPC pour diriger les requêtes entrantes et les vérifications d'état vers chaque VM backend.

L'équilibreur de charge préserve les adresses IP sources des paquets. Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Le terme utilisé dans le secteur est retour direct du serveur.

Architecture du VPC partagé

À l'exception de l'adresse IP, tous les composants d'un équilibreur de charge réseau doivent exister dans le même projet. Le tableau suivant récapitule les composants du VPC partagé pour l'équilibrage de charge réseau :

Adresse IP Règle de transfert Composants backend
Une adresse IP externe régionale doit être définie dans le même projet que l'équilibreur de charge ou dans le projet hôte du VPC partagé. Une règle de transfert externe régionale doit être définie dans le même projet que les instances du service de backend.

Le service de backend régional doit être défini dans le même projet et dans la même région que les instances du groupe d'instances backend.

Les vérifications d'état associées au service de backend doivent être définies dans le même projet et dans la même région que le service de backend.

Distribution du trafic

La manière dont un équilibreur de charge réseau distribue les nouvelles connexions dépend du fait que vous ayez ou non configuré le basculement :

  • Si vous n'avez pas configuré le basculement, un équilibreur de charge réseau distribue les nouvelles connexions à ses VM backend opérationnelles si au moins l'une d'entre elles est opérationnelle. Lorsqu'aucune VM backend n'est opérationnelle, l'équilibreur de charge distribue les nouvelles connexions entre tous les backends, en dernier recours. Dans ce cas, l'équilibreur de charge achemine chaque nouvelle connexion vers une VM backend non opérationnelle.
  • Si vous avez configuré le basculement, un équilibreur de charge réseau distribue les nouvelles connexions entre les VM de son pool actif, selon une règle de basculement que vous configurez. Lorsqu'aucune VM de backend n'est opérationnelle, vous pouvez choisir l'un des comportements suivants :
    • (Par défaut) L'équilibreur de charge ne distribue le trafic que vers les VM principales. Cette opération est réalisée en dernier recours. Les VM de secours sont exclues de cette distribution des connexions de dernier recours.
    • L'équilibreur de charge abandonne le trafic.

Pour en savoir plus sur la distribution des connexions, consultez la section suivante Sélection du backend et suivi des connexions.

Pour en savoir plus sur le fonctionnement du basculement, consultez la section Basculement.

Sélection du backend et suivi des connexions

L'équilibrage de charge réseau utilise des algorithmes de sélection et de suivi des connexions configurables pour déterminer la façon dont le trafic est distribué entre les VM de backend.

L'équilibrage de charge réseau utilise l'algorithme suivant pour distribuer les paquets entre les VM de backend (dans son pool actif, si vous avez configuré le basculement) :

  1. Si l'équilibreur de charge possède une entrée dans sa table de suivi des connexions correspondant aux caractéristiques d'un paquet entrant, le paquet est envoyé au backend spécifié par l'entrée de la table de suivi des connexions. Le paquet étant considéré comme faisant partie d'une connexion établie précédemment, il est envoyé à la VM de backend que l'équilibreur de charge a précédemment déterminée et enregistrée dans sa table de suivi des connexions.
  2. Lorsque l'équilibreur de charge reçoit un paquet pour lequel il n'a aucune entrée de suivi de connexion, l'équilibreur de charge effectue les opérations suivantes :

    1. L'équilibreur de charge sélectionne un backend. L'équilibreur de charge calcule un hachage en fonction de l'affinité de session configurée. Il utilise ce hachage pour sélectionner un backend parmi ceux qui sont actuellement opérationnels (sauf si tous les backends sont considérés comme non opérationnels, auquel cas tous les backends sont pris en compte tant la règle de basculement n'a pas été configurée pour supprimer le trafic dans cette situation. L'affinité de session par défaut, NONE, utilise les algorithmes de hachage suivants :

      • Pour les paquets TCP et non fragmentés, un hachage à cinq tuples de l'adresse IP source, du port source, de l'adresse IP de destination, du port de destination et du protocole du paquet
      • Pour les paquets UDP fragmentés et tous les autres protocoles, un hachage à trois tuples de l'adresse IP source, de l'adresse IP de destination et du protocole du paquet

      La sélection du backend peut être personnalisée à l'aide d'un algorithme de hachage qui utilise moins d'informations. Pour connaître toutes les options compatibles, consultez la section Options d'affinité de session.

    2. L'équilibreur de charge ajoute une entrée à sa table de suivi des connexions. Cette entrée enregistre le backend sélectionné pour la connexion du paquet afin que tous les futurs paquets de cette connexion soient envoyés au même backend. L'utilisation du suivi des connexions dépend du protocole :

      • Paquets TCP. Le suivi des connexions est toujours activé et ne peut pas être désactivé. Par défaut, le suivi des connexions est assuré par un hachage à cinq tuples, mais il peut être configuré à un niveau inférieur. Lorsqu'à cinq tuples, les paquets TCP SYN sont traités différemment. Contrairement aux paquets non-SYN, ils suppriment toute entrée de suivi de connexion correspondante et sélectionnent toujours un nouveau backend.

        Le suivi de connexion par défaut à cinq tuples est utilisé lorsque :

        • le mode de suivi est PER_CONNECTION (toutes les affinités de session), ou
        • le mode de suivi est PER_SESSION et l'affinité de session est NONE, ou
        • le mode de suivi est PER_SESSION et l'affinité de session est CLIENT_IP_PORT_PROTO.
      • Paquets UDP, ESP et GRE. Le suivi des connexions n'est activé que si l'affinité de session est définie sur une valeur autre que NONE.

      • Paquets ICMP. Il n'est pas possible d'utiliser le suivi des connexions.

      Pour en savoir plus sur l'utilisation du suivi des connexions et sur la méthode de suivi utilisée, consultez la section Mode de suivi des connexions.

      Notez également les points suivants :

      • Une entrée dans la table de suivi des connexions expire 60 secondes après le traitement de l'équilibreur de charge par le dernier paquet correspondant à l'entrée. Cette valeur de 60 secondes d'inactivité n'est pas configurable.
      • Selon le protocole, l'équilibreur de charge peut supprimer les entrées de la table de suivi des connexions lorsque les backends ne sont plus opérationnels. Pour plus d'informations et pour personnaliser ce comportement, consultez la section Persistance des connexions sur les backends non opérationnels.

Options d'affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux VM backend de l'équilibreur de charge. L'affinité de session est spécifiée pour l'ensemble du service de backend externe régional, et non pour chaque groupe d'instances backend.

L'équilibrage de charge réseau est compatible avec les options d'affinité de session suivantes :

  • Aucune (NONE) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination
  • Adresse IP client, adresse IP de destination (CLIENT_IP) : hachage à deux tuples composé de l'adresse IP source et de l'adresse IP de destination
  • Adresse IP client, adresse IP de destination, protocole (CLIENT_IP_PROTO) : hachage à trois tuples composé de l'adresse IP source, de l'adresse IP de destination et du protocole
  • Adresse IP client, port client, adresse IP de destination, port de destination, protocole (CLIENT_IP_PORT_PROTO) : hachage à cinq tuples composé de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

Pour découvrir comment ces options d'affinité de session affectent les méthodes de sélection du backend et de suivi des connexions, consultez ce tableau.

Mode de suivi des connexions

L'activation du suivi des connexions ne dépend que du protocole du trafic à équilibrage de charge et des paramètres d'affinité de session. Le mode de suivi spécifie l'algorithme de suivi des connexions à utiliser lorsque le suivi des connexions est activé. Il existe deux modes de suivi : PER_CONNECTION (par défaut) et PER_SESSION.

  • PER_CONNECTION (par défaut). Il s'agit du mode de suivi par défaut. Avec ce mode de suivi des connexions, le trafic TCP est toujours suivi par hachage à 5 tuples, quel que soit le paramètre d'affinité de session. Pour le trafic UDP, ESP et GRE, le suivi des connexions est activé lorsque le paramètre d'affinité de session sélectionné n'est pas NONE. Le suivi des paquets UDP, ESP et GRE s'effectue via les méthodes de suivi décrites dans ce tableau.

  • PER_SESSION. Si l'affinité de session est CLIENT_IP ou CLIENT_IP_PROTO, la configuration de ce mode entraîne le suivi des connexions à deux tuples et à trois tuples, respectivement, pour tous les protocoles (sauf ICMP qui n'est pas traçable en connexion). Pour les autres paramètres d'affinité de session, le mode PER_SESSION se comporte de la même manière que le mode PER_CONNECTION.

Pour comprendre comment ces modes de suivi fonctionnent avec différents paramètres d'affinité de session pour chaque protocole, consultez le tableau suivant.

Sélection du backend Mode de suivi des connexions
Paramètre d'affinité de session Méthode de hachage pour la sélection du backend PER_CONNECTION (par défaut) PER_SESSION
Par défaut : aucune affinité de session

(NONE)

TCP et UDP non fragmenté : hachage à cinq tuples

UDP fragmenté et tous les autres protocoles : hachage à trois tuples

  • TCP : suivi des connexions à cinq tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP : suivi des connexions à cinq tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, adresse IP de destination

(CLIENT_IP)

Tous les protocoles : hachage à deux tuples
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP, GRE : suivi des connexions à deux tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, adresse IP de destination, protocole

(CLIENT_IP_PROTO)

Tous les protocoles : hachage à trois tuples
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP, UDP, ESP, GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
Adresse IP client, port client, adresse IP de destination, port de destination, protocole

(CLIENT_IP_PORT_PROTO)

TCP et UDP non fragmenté : hachage à cinq tuples

UDP fragmenté et tous les autres protocoles : hachage à trois tuples

  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé
  • TCP et UDP non fragmenté : suivi des connexions à cinq tuples
  • UDP fragmenté, ESP et GRE : suivi des connexions à trois tuples
  • Tous les autres protocoles : suivi des connexions désactivé

Pour savoir comment modifier le mode de suivi des connexions, consultez la page Configurer une règle de suivi des connexions.

Persistance de connexion sur les backends non opérationnels

Les paramètres de persistance de connexion contrôlent si une connexion existante persiste sur un backend sélectionné après que ce backend devient non opérationnel (tant que le backend reste dans le groupe d'instances backend configuré de l'équilibreur de charge).

Le comportement décrit dans cette section ne s'applique pas aux cas où vous supprimez une VM de backend de son groupe d'instances ou du groupe d'instances du service de backend. Dans ce cas, les connexions établies ne sont conservées que comme décrit dans la section Drainage de connexion.

Les options de persistance de connexion suivantes sont disponibles :

  • DEFAULT_FOR_PROTOCOL (par défaut)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

Le tableau suivant récapitule les options de persistance des connexions et indique leur comportement de persistance en fonction des différents protocoles, options d'affinité de session et modes de suivi.

Persistance de connexion sur les backends non opérationnels Mode de suivi des connexions
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)

Tous les autres protocoles : les connexions ne persistent jamais sur les backends non opérationnels.

TCP : les connexions persistent sur les backends non opérationnels si l'affinité de session est NONE ou CLIENT_IP_PORT_PROTO

Tous les autres protocoles : les connexions ne persistent jamais sur les backends non opérationnels.

NEVER_PERSIST Tous les protocoles : les connexions ne persistent jamais sur les backends non opérationnels.
ALWAYS_PERSIST

TCP : les connexions persistent sur les backends non opérationnels (toutes les affinités de session)

ESP, GRE, UDP : les connexions persistent sur les backends non opérationnels si l'affinité de session n'est pas définie sur NONE.

ICMP : non applicable, car le protocole ICMP n'est pas compatible avec le suivi des connexions

N'utilisez cette option que pour les cas d'utilisation avancée.

Configuration impossible

Comportement de la persistance de connexion TCP sur les backends non opérationnels

Chaque fois qu'une connexion TCP avec un suivi à cinq tuples persiste sur un backend non opérationnel :

  • Si le backend non opérationnel continue de répondre aux paquets, la connexion se poursuit jusqu'à ce qu'elle soit réinitialisée ou fermée (par le backend non opérationnel ou le client).
  • Si le backend non opérationnel envoie un paquet de réinitialisation TCP (RST) ou ne répond pas aux paquets, le client peut effectuer une nouvelle tentative de connexion, laissant ainsi l'équilibreur de charge sélectionner un autre backend opérationnel. Les paquets TCP SYN sélectionnent toujours un nouveau backend opérationnel.

Pour savoir comment modifier le comportement de la persistance des connexions, consultez la page Configurer une règle de suivi des connexions.

Drainage de connexion

Le drainage de connexion est un processus appliqué aux sessions établies dans les cas suivants :

  • Lorsque vous supprimez une VM de backend d'un groupe d'instances
  • Lorsqu'un groupe d'instances géré supprime une VM de backend (en cas de remplacement, d'abandon, de mises à niveau progressives ou de réduction de capacité)
  • Lorsqu'un groupe d'instances est supprimé d'un service de backend

Par défaut, le drainage de connexion est désactivé. Dans ce cas, les connexions établies sont interrompues le plus rapidement possible. Lorsque le drainage de connexion est activé, les connexions établies sont autorisées à persister pendant un délai configurable, après quoi l'instance de VM de backend est arrêtée.

Pour en savoir plus sur le déclenchement et l'activation du drainage de connexion, consultez la page Activer le drainage de connexion.

Fragmentation UDP

L'équilibrage de charge réseau traite les paquets UDP fragmentés et non fragmentés. Les paquets non fragmentés sont traités normalement dans toutes les configurations. Si votre application utilise des paquets UDP fragmentés, gardez à l'esprit les points suivants :

  • Les paquets UDP peuvent être fragmentés avant d'atteindre un réseau VPC Google Cloud.
  • Les réseaux VPC Google Cloud transfèrent les fragments UDP dès leur arrivée (sans attendre que tous les fragments arrivent).
  • Les réseaux non-Google Cloud et l'équipement réseau sur site peuvent transférer les fragments UDP à leur arrivée, retarder les paquets UDP fragmentés jusqu'à ce que tous les fragments soient arrivés, ou supprimer les paquets UDP fragmentés. Pour en savoir plus, consultez la documentation de l'autre fournisseur ou équipement réseau.

Si vous prévoyez des paquets UDP fragmentés, procédez comme suit :

  • N'utilisez qu'une seule règle de transfert UDP ou L3_DEFAULT par adresse IP à équilibrage de charge, et configurez la règle de transfert de façon à accepter le trafic sur tous les ports. Cela garantit que tous les fragments arrivent à la même règle de transfert, même s'ils n'ont pas le même port de destination. Pour configurer tous les ports, définissez --ports=ALL à l'aide de Google Cloud CLI ou définissez allPorts sur True à l'aide de l'API.

  • Utilisez l'une des approches suivantes pour configurer le service de backend :

    • Désactivez l'affinité de session et le suivi des connexions. Définissez l'affinité de session sur NONE. L'équilibreur de charge utilise un hachage à cinq tuples afin de sélectionner un backend pour les paquets non fragmentés (qui contiennent des informations de port) et un hachage à trois tuples pour les paquets fragmentés (qui ne disposent pas d'informations de port). Dans cette configuration, les paquets UDP fragmentés et non fragmentés d'un même client peuvent être transférés vers différents backends.
    • Activez l'affinité de session à deux ou trois tuples et le suivi des connexions. Définissez l'affinité de session sur CLIENT_IP ou CLIENT_IP_PROTO et le mode de suivi des connexions sur PER_SESSION. Dans cette configuration, les paquets UDP fragmentés et non fragmentés d'un même client sont transférés vers le même backend (sans utiliser d'informations de port).

Utiliser des instances cibles en tant que backends

Si vous utilisez des instances cibles en tant que backends pour l'équilibreur de charge réseau et prévoyez des paquets UDP fragmentés, utilisez une seule règle de transfert UDP ou L3_DEFAULT par adresse IP et configurez la règle de transfert pour qu'elle accepte le trafic sur tous les ports. Cela garantit que tous les fragments arrivent à la même règle de transfert, même s'ils n'ont pas le même port de destination. Pour configurer tous les ports, définissez --ports=ALL à l'aide de gcloud ou définissez allPorts sur True à l'aide de l'API.

Basculement

Vous pouvez configurer un équilibreur de charge réseau pour répartir les connexions entre les instances de machines virtuelles (VM) des groupes d'instances backend principaux. Par la suite, vous pouvez utiliser des groupes d'instances backend de basculement si cela s'avère nécessaire. Avec le basculement, vous disposez d'une autre méthode permettant d'augmenter la disponibilité tout en étant mieux à même de contrôler la gestion de votre charge de travail lorsque les VM de vos backends principaux ne sont pas opérationnelles.

Par défaut, lorsque vous ajoutez un backend au service de backend d'un équilibreur de charge réseau, il s'agit d'un backend principal. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend de l'équilibreur de charge, ou en modifiant le service de backend ultérieurement.

Pour en savoir plus sur le fonctionnement du basculement, consultez la page Présentation du basculement pour l'équilibrage de charge réseau.

Limites

  • Les groupes de points de terminaison du réseau (NEG, Network Endpoint Group) ne sont pas acceptés comme backends pour les équilibreurs de charge réseau.
  • Les équilibreurs de charge réseau basés sur les services de backend ne sont pas compatibles avec Google Kubernetes Engine.
  • Vous ne pouvez pas effectuer les opérations suivantes à l'aide de Google Cloud Console :

    • Créer ou modifier un équilibreur de charge réseau dont la règle de transfert utilise le protocole L3_DEFAULT.
    • Créer ou modifier un équilibreur de charge réseau dont le protocole de service de backend est défini sur UNSPECIFIED.
    • Créez ou modifiez un équilibreur de charge réseau qui configure une règle de suivi des connexions.
    • Créer ou modifier l'orientation du trafic basée sur l'adresse IP source pour une règle de transfert.
    • Créez ou modifiez un équilibreur de charge réseau qui gère le trafic IPv6.

    Utilisez plutôt Google Cloud CLI ou l'API REST.

  • Les équilibreurs de charge réseau ne sont pas compatibles avec l'appairage de réseaux VPC.

Étape suivante