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 et ICMP. La compatibilité avec ESP et ICMP est disponible en version bêta.

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 backend avec leur adresse IP source inchangée.
    • 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.
  • 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, les délais avant expiration du 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.

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

De plus, vous devez créer des règles de pare-feu pour autoriser les vérifications d'état sur les VM 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 unique. Les adresses IP externes régionales sont accessibles partout sur Internet, mais elles proviennent d'un pool propre à chaque région Google Cloud.

Lorsque vous créez une règle de transfert, vous pouvez spécifier le nom ou l'adresse IP d'une adresse IP externe régionale réservée existante. Si vous ne spécifiez pas d'adresse IP, la règle de transfert fait référence à une adresse IP externe régionale éphémère. Utilisez une adresse IP réservée 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 adresses IP externes régionales du niveau Standard et Premium. L'adresse IP et la règle de transfert doivent utiliser le même niveau réseau.

Pour connaître les étapes à suivre pour réserver une adresse IP, consultez la page Adresses IP externes.

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 l'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 associe une adresse 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.

Un équilibreur de charge réseau nécessite au moins une règle de transfert. 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.

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 (version bêta).

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 la charge du trafic TCP, UDP, ESP et ICMP.

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 (version bêta). Les règles de transfert L3_DEFAULT ne peuvent faire référence qu'à un service de backend avec le protocole UNSPECIFIED.

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 L3_DEFAULT UNSPECIFIED
ICMP (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. Éventuellement, 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, et ports ou plages de ports qui ne se chevauchent pas, pour une même adresse IP externe.

Pour une adresse IP donnée, une règle de transfert L3_DEFAULT peut coexister avec des règles de transfert utilisant d'autres protocoles (TCP ou UDP), mais non avec une autre règle de transfert L3_DEFAULT.

Un paquet arrivant sur l'adresse IP de l'équilibreur de charge correspond à une règle de transfert L3_DEFAULT uniquement si aucune règle de transfert plus spécifique n'est disponible (par exemple, pour le trafic TCP ou UDP). Plus précisément, un paquet arrivant sur une adresse IP, un protocole et un port correspond à une règle de transfert L3_DEFAULT, sauf s'il n'existe pas d'autres règles de transfert pour cette adresse IP qui correspondent au protocole et au port de destination du packet.

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.

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 les paquets aux VM de backend tout en conservant l'adresse IP de destination, le protocole du paquet et les informations sur le port de destination si elles sont incluses dans le paquet.

    Les services de backend utilisés avec les équilibreurs de charge réseau acceptent les options de protocole suivantes : TCP, UDP ou UNSPECIFIED (version bêta).

    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 d'une affinité de session configurable. 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.)

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. L'équilibreur de charge réseau est hautement disponible par nature. Aucune étape particulière n'est requise pour rendre l'équilibreur de charge hautement disponible, car le mécanisme ne repose pas sur un seul appareil ou une seule instance de VM. Vous devez simplement vous assurer que vos instances de VM de backend sont déployées sur plusieurs zones afin que l'équilibreur de charge puisse contourner les problèmes potentiels survenant dans une zone donnée.

  • 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

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 une règle de pare-feu ou une règle de pare-feu hiérarchique acceptant le trafic entrant pour autoriser les vérifications d'état et le trafic dont vous équilibrez la charge :

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.

Suivi des connexions et hachage cohérent

L'équilibrage de charge réseau utilise une table de suivi des connexions et un algorithme de hachage cohérent configurable pour déterminer la façon dont le trafic est distribué entre les VM backend.

Si l'équilibreur de charge comporte une entrée dans sa table de suivi des connexions pour un paquet entrant faisant partie d'une connexion établie précédemment, ce paquet est envoyé à la VM backend que l'équilibreur de charge a précédemment déterminée. Le backend précédemment déterminé a été enregistré dans la table de suivi des connexions de l'équilibreur de charge.

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 :

  • Si le paquet est un paquet TCP ou un paquet UDP non fragmenté, et si aucune affinité de session n'a été configurée, l'équilibreur de charge crée 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. Il utilise ce hachage pour sélectionner un backend qui est actuellement opérationnel. Pour le trafic des autres protocoles, y compris les paquets UDP fragmentés, l'équilibreur de charge crée un hachage à trois tuples de l'adresse IP source, de l'adresse IP de destination et du protocole du paquet, puis utilise ce hachage pour sélectionner un backend opérationnel.
  • Si vous avez configuré une option d'affinité de session, l'équilibreur de charge crée un hachage, mais possiblement à partir de moins d'informations, comme décrit dans la section Options d'affinité de session.
  • Si le paquet est un paquet TCP ou si le paquet est un paquet UDP ou ESP dont l'affinité de session est définie sur une valeur autre que NONE, l'équilibreur de charge enregistre le backend sélectionné dans sa table de suivi des connexions. Les entrées de la table de suivi des connexions expirent au bout de 60 secondes si elles ne sont pas utilisées. Les autres protocoles ne peuvent pas faire l'objet d'un suivi des connexions. Pour obtenir la liste complète, consultez le tableau de la section suivante.

Comportement des connexions persistantes

  • Trafic TCP. Pour les paquets TCP, l'état de la vérification d'état d'une VM de backend ne contrôle que la distribution des paquets pour les nouvelles connexions. Tant qu'une VM de backend reste membre de son groupe d'instances et tant que ce groupe d'instances reste configuré en tant que backend de l'équilibreur de charge, les paquets qui font partie de la même connexion sont envoyés à la VM de backend précédemment sélectionnée, même si l'état de la vérification d'état de cette VM est devenu non opérationnel. Si le backend non opérationnel répond aux paquets, la connexion n'est pas interrompue. Si le backend non opérationnel refuse les paquets ou ne leur répond pas, le client peut réessayer avec une nouvelle connexion, et un autre backend opérationnel peut être sélectionné pour cette nouvelle tentative.

    Si vous supprimez une VM backend de son groupe d'instances ou si vous supprimez le groupe d'instances du service de backend, les connexions établies ne sont conservées que comme décrit dans la section Drainage de connexion.

  • Trafic UDP. Comme le trafic UDP n'a pas de session, tous les paquets UDP sont par défaut traités sans utiliser de table de suivi des connexions. Les connexions UDP ne sont pas conservées sur les backends non opérationnels. Toutefois, si l'affinité de session est définie sur une valeur autre que NONE, les connexions UDP sont suivies (comme les connexions TCP), mais elles ne sont pas conservées sur les backends non opérationnels (contrairement aux connexions TCP).

  • Trafic ESP et ICMP. Pour le trafic ESP et ICMP, les connexions ne sont pas conservées sur les backends non opérationnels.

Le tableau suivant récapitule les cas où l'équilibreur de charge utilise le suivi des connexions et le comportement des connexions persistantes pour chaque protocole.

Trafic dont la charge doit être équilibrée Suivi des connexions Connexions persistantes sur des backends non opérationnels
TCP Toujours ACTIVÉE OUI
UDP Le suivi des connexions est activé lorsque l'affinité de session
est définie sur une valeur autre que NONE.
Sinon, le suivi des connexions est désactivé.
NON
ESP Le suivi des connexions est activé lorsque l'affinité de session
est définie sur une valeur autre que NONE.
Sinon, le suivi des connexions est désactivé.
NON
ICMP Suivi des connexions non disponible NON

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. Par exemple, vous pouvez diriger les nouvelles connexions d'un même client vers la même VM backend, en tenant compte des concepts décrits dans la section "Suivi des connexions et hachage cohérent".

Les équilibreurs de charge réseau acceptent les options d'affinité de session suivantes, que vous spécifiez pour l'ensemble du service de backend externe régional, et non pour chaque groupe d'instances backend.

Affinité de session Méthode de hachage cohérent Suivi des connexions Remarques
Aucun
(NONE)
Hachage à cinq tuples pour les protocoles TCP et UDP non fragmentés
Hachage à trois tuples pour les autres protocoles
Suivi à cinq tuples pour TCP Pour TCP, cette méthode est identique à Adresse IP client, port client, adresse IP de destination, port de destination, protocole (hachage à cinq tuples).
Pour tous les autres protocoles, le suivi des connexions est désactivé lors de l'utilisation de l'affinité de session NONE.
Adresse IP client, adresse IP de destination
(CLIENT_IP)
Hachage à deux tuples de :
• Adresse IP source du paquet
• Adresse IP de destination du paquet
Suivi à cinq tuples pour TCP et UDP non fragmenté
Suivi à trois tuples pour ESP et UDP fragmenté
Aucun suivi pour les autres protocoles
Utilisez cette option lorsque vous souhaitez que toutes les connexions provenant de la même adresse IP source soient diffusées par la même VM de backend.
Adresse IP client, adresse IP de destination, protocole
(CLIENT_IP_PROTO)
Hachage à trois tuples de :
• Adresse IP source du paquet
• Adresse IP de destination du paquet
Protocole
Suivi à cinq tuples pour TCP et UDP non fragmenté
Suivi à trois tuples pour ESP et UDP fragmenté
Aucun suivi pour les autres protocoles
Adresse IP client, port client, adresse IP de destination, port de destination, protocole (5-tuple)
(CLIENT_IP_PORT_PROTO)
Hachage à cinq tuples pour les protocoles TCP et UDP non fragmentés
Hachage à trois tuples pour les autres protocoles
Suivi à cinq tuples pour TCP et UDP non fragmenté
Suivi à trois tuples pour ESP et UDP fragmenté
Aucun suivi pour les autres protocoles
Pour TCP, cela équivaut à NONE.

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é, il permet de conserver les connexions établies tant que la VM existe.

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

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.

Fragmentation UDP

Si vous effectuez un équilibrage de charge des paquets UDP, tenez compte des points suivants :

  • Les paquets non fragmentés sont traités normalement dans toutes les configurations.
  • Les paquets UDP peuvent être fragmentés avant d'atteindre Google Cloud. Les réseaux autres que Google Cloud peuvent retarder les paquets UDP fragmentés, car ils attendent que tous les fragments arrivent, ou ils suppriment complètement les paquets fragmentés. Les réseaux Google Cloud transfèrent les fragments UDP dès leur arrivée.

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

  • N'utilisez qu'une seule règle de transfert UDP 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 gcloud, ou définissez allPorts sur True à l'aide de l'API.
  • Définissez l'affinité de session sur Aucune (NONE). Cela indique que la préservation de l'affinité n'est pas requise, et que l'équilibreur de charge utilise donc le hachage à cinq tuples afin de sélectionner un backend pour les paquets non fragmentés, mais un hachage à trois tuples pour les paquets fragmentés.

Avec ces paramètres, les fragments UDP d'un même paquet sont transférés vers la même instance pour le réassemblage.

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 par adresse IP à équilibrage de charge 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.

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. Utilisez plutôt l'outil de ligne de commande gcloud ou l'API REST.

Étapes suivantes