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 TCP ou UDP entre les instances de machines virtuelles (VM) de la même région.

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.

Cette page décrit le fonctionnement de l'équilibrage de charge réseau à l'aide d'un service de backend plutôt que d'un pool cible. Auparavant, la seule option pour un équilibreur de charge réseau était l'équilibreur de charge réseau basé sur un pool cible. Par rapport aux pools cibles, les services de backend vous permettent de contrôler plus précisément le comportement de votre équilibreur de charge.

  • 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.
  • Les équilibreurs de charge réseau basés sur un service de backend utilisent des vérifications de l'état qui correspondent au type de trafic (TCP, SSL, HTTP, HTTPS ou HTTP/2) qu'ils distribuent. Les équilibreurs de charge basés sur un pool cible n'acceptent que les vérifications d'état héritées HTTP.
  • 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. Les équilibreurs de charge réseau basés sur un pool cible n'acceptent que les groupes d'instances non gérés.

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. Comme les équilibreurs de charge réseau ne sont pas des proxys, ils transmettent le trafic aux backends sur le même protocole et le même 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 consiste en la combinaison d'une adresse IP, d'un protocole et de ports (ou d'une plage de ports) spécifiques. 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 suivante.

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, ports ou plages de ports en utilisant la même adresse IP externe.

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 TCP ou UDP, mais pas les deux, sur l'adresse IP et les ports spécifiés par une ou plusieurs règles de transfert externes régionales. Le service de backend permet d'acheminer le trafic vers les VM backend sur l'adresse IP et sur les ports auxquels le trafic a été envoyé. Le service de backend et toutes les règles de transfert associées doivent utiliser le même protocole.

  • 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 TCP/UDP externe distribue les connexions entre les VM 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 TCP/UDP externe 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 et trafic UDP

Google Cloud n'offre pas de vérification d'état qui utilise le protocole UDP. Lorsque vous utilisez l'équilibrage de charge réseau avec du trafic UDP, vous devez exécuter un service basé sur TCP sur vos VM backend pour fournir des informations de vérification d'état.

Dans cette configuration, les requêtes client sont soumises à l'équilibrage de charge à l'aide du protocole UDP, et un service TCP est utilisé pour fournir des informations aux vérifications d'état de Google Cloud. Par exemple, vous pouvez exécuter un simple serveur HTTP sur chaque VM 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. Pour accepter le trafic provenant de n'importe quelle adresse IP sur Internet, vous devez créer une règle de pare-feu autorisant le trafic entrant pour le protocole et les ports concernés à l'aide de la plage source 0.0.0.0/0. Pour autoriser uniquement le trafic provenant de certaines plages d'adresses IP, utilisez des plages sources plus restrictives.

De plus, étant donné que l'équilibrage de charge réseau utilise des vérifications d'état Google Cloud, 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.

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é. A 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 est configuré pour abandonner 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 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.
  • Si vous avez configuré une option d'affinité de session, l'équilibreur de charge crée toujours un hachage, mais à partir d'un nombre réduit d'informations, comme décrit dans la section Affinité de session.
  • Si le paquet est un paquet TCP ou si le paquet est un paquet UDP 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.

Comportement des connexions persistantes

  • Trafic TCP. Pour les paquets TCP, l'état de la vérification d'état d'une VM backend ne contrôle que la distribution des paquets pour les nouvelles connexions. Tant qu'une VM backend reste membre de son groupe d'instances et tant que ce groupe d'instances reste configuré en tant que backend pour l'équilibreur de charge, les paquets qui font partie de la même connexion TCP sont envoyés à la VM backend précédemment sélectionnée, même si l'é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).

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.

Protocole Suivi des connexions Connexions persistantes sur des backends non opérationnels
TCP Toujours ACTIVÉE OUI
UDP Par défaut : DÉSACTIVÉ
Le suivi des connexions est ACTIVÉ lorsque l'affinité de session
est définie sur une valeur autre que NONE.
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 Suivi à cinq tuples pour TCP uniquement Pour TCP, cette méthode est identique à Adresse IP client, port client, adresse IP de destination, port de destination, protocole (hachage à cinq tuples).
Pour UDP, le suivi des connexions est désactivé par défaut.
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 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
Adresse IP client, port client, adresse IP de destination, port de destination, protocole (5-tuple)
(CLIENT_IP_PORT_PROTO)
Hachage à cinq tuples Suivi à cinq tuples pour TCP et UDP Pour TCP, cela équivaut à NONE.
Pour UDP, cette option active le suivi des connexions.

Drainage de connexion

Le drainage de connexion est un processus appliqué à des sessions TCP établies lorsque vous supprimez une VM backend d'un groupe d'instances ou lorsqu'un groupe d'instances géré supprime une VM backend (en cas de remplacement, d'abandon, de mises à niveau progressives ou de réduction de capacité).

Par défaut, le drainage de connexion est activé. Lorsqu'il est activé, il permet de conserver les connexions TCP établies tant que la VM existe. Si vous désactivez le drainage de connexion, les connexions TCP établies sont interrompues le plus rapidement possible.

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 TCP/UDP externe pour distribuer les connexions entre les instances de machines virtuelles (VM) dans 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.
  • Pour les services de backend associés aux équilibreurs de charge réseau, le résultat de la commande gcloud compute backend-services get-health ne renvoie que les adresses IP internes des backends, et non les adresses IP externes de la règle de transfert attribuée aux instances.

Étape suivante