Présentation de l'équilibrage de charge réseau TCP/UDP externe

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 sans proxy.

L'équilibrage de charge réseau de Google Cloud répartit le trafic entre les instances de machine virtuelle (VM) d'une même région au sein d'un réseau cloud privé virtuel (VPC). Un équilibreur de charge réseau dirige le trafic TCP et UDP sur les backends régionaux. L'équilibrage de charge réseau permet d'équilibrer la charge du trafic UDP, TCP et SSL sur les ports non compatibles avec les équilibreurs de charge proxy TCP et proxy SSL.

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 réponses provenant des VM de 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.
  • L'équilibreur de charge préserve les adresses IP sources des paquets.
  • L'adresse IP de destination des paquets est l'adresse IP externe régionale associée à la règle de transfert de l'équilibreur de charge.

Par conséquent :

  • Les instances qui participent en tant que VM de backend d'équilibreurs de charge réseau doivent exécuter l'environnement invité Linux, l'environnement invité Windows ou d'autres processus adaptés présentant des fonctionnalités équivalentes.

    L'environnement invité OS (ou un processus équivalent) est chargé de configurer les routages locaux sur chaque VM de backend. Ces routages permettent à la VM d'accepter les paquets dont la destination correspond à l'adresse IP de la règle de transfert de l'équilibreur de charge.

  • Sur les instances de backend qui acceptent le trafic encadré par un équilibrage de charge, vous devez configurer le logiciel pour qu'il soit lié à l'adresse IP associée à la règle de transfert de l'équilibreur de charge (ou à toute adresse IP 0.0.0.0/0).

Le schéma suivant illustre des utilisateurs en Californie, à New York et à Singapour. Ils se connectent tous à leurs ressources de backend, à savoir Myapp, Test et Travel. Lorsqu'un utilisateur situé à Singapour se connecte au backend des États-Unis, le trafic est routé vers Singapour, la région la plus proche, car la diffusion utilise la méthode anycast. De là, le trafic est acheminé vers le backend régional.

Trois backends régionaux et trois règles de transfert (cliquez pour agrandir)
Trois backends régionaux et trois règles de transfert (cliquez pour agrandir)

Pour en savoir plus sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Protocoles, schéma et champ d'application

Chaque équilibreur de charge réseau gère le trafic TCP ou UDP, mais pas les deux.

Un équilibreur de charge réseau utilise un pool cible pour contenir les instances de backend qui transmettent du trafic à équilibrage de charge.

Un équilibreur de charge réseau équilibre le trafic en provenance d'Internet. Vous ne pouvez pas l'utiliser pour équilibrer le trafic en provenance de Google Cloud entre vos instances.

Le champ d'application d'un équilibreur de charge réseau est régional et non mondial. Cela signifie que l'équilibreur ne peut pas s'étendre sur plusieurs régions. Dans une même région, l'équilibreur de charge dessert toutes les zones.

Utilisez l'équilibrage de la charge réseau dans les cas suivants :

  • Vous devez équilibrer la charge du trafic UDP ou la charge d'un port TCP qui n'est pas gérée par les autres équilibreurs de charge.
  • Il est possible que le trafic SSL soit déchiffré par vos backends plutôt que par l'équilibreur de charge. L'équilibreur de charge réseau ne peut pas effectuer cette tâche. Lorsque les backends déchiffrent le trafic SSL, la charge processeur augmente sur les VM.
  • Vous acceptez les certificats SSL autogérés de l'équilibreur de charge. Les certificats SSL gérés par Google ne sont disponibles que pour l'équilibrage de charge HTTP(S) et l'équilibrage de charge du proxy SSL.
  • Vous devez transférer les paquets d'origine sans proxy.
  • Vous disposez d'une configuration existante qui utilise un équilibreur de charge à stratégie directe et vous souhaitez la transférer sans modification.

Architecture

Les équilibreurs de charge réseau équilibrent la charge sur vos systèmes en fonction des données du protocole IP entrant, telles que l'adresse, le port et le type de protocole.

L'équilibreur de charge réseau est un équilibreur de charge à stratégie directe. Vos backends reçoivent donc la requête du client d'origine. L'équilibreur de charge réseau n'effectue pas de déchargement ni de transit par proxy TLS (Transport Layer Security). Le trafic est directement acheminé vers vos VM.

Lorsque vous créez une règle de transfert pour l'équilibreur de charge, vous recevez une adresse IP virtuelle éphémère (IPV) ou réservez une IPV provenant d'un bloc réseau régional.

Vous associez ensuite cette règle de transfert à vos backends. L'IPV est diffusée à partir des points de présence mondiaux de Google (méthode anycast), mais les backends d'un équilibreur de la charge réseau sont régionaux. L'équilibreur de charge ne peut pas avoir de backends couvrant plusieurs régions.

Vous pouvez utiliser les pare-feu Google Cloud pour contrôler ou filtrer l'accès aux VM de backend.

L'équilibreur de charge réseau examine les ports source et de destination, l'adresse IP et le protocole afin de déterminer le mode de transfert des paquets. Pour le trafic TCP, vous pouvez modifier le comportement de transfert de l'équilibreur de charge en configurant l'affinité de session.

Algorithme de répartition de la charge

Par défaut, pour distribuer le trafic aux instances, la valeur d'affinité de session est définie sur NONE. Cloud Load Balancing sélectionne une instance sur la base d'un hachage de l'adresse IP et du port source, de l'adresse IP et du port de destination, ainsi que du protocole. Cela signifie que les connexions TCP entrantes sont réparties sur plusieurs instances et que chaque nouvelle connexion peut accéder à une instance différente. Tous les paquets d'une connexion sont dirigés vers la même instance jusqu'à la fermeture de la connexion. Les connexions établies ne sont pas prises en compte dans le processus d'équilibrage de charge.

Quel que soit le paramètre d'affinité de session, tous les paquets d'une connexion sont dirigés vers l'instance choisie jusqu'à ce que la connexion soit fermée. Une connexion existante n'a aucun impact sur les décisions d'équilibrage de charge pour les nouvelles connexions entrantes. Un déséquilibre entre les backends peut se produire si des connexions TCP de longue durée sont utilisées.

Vous pouvez choisir un autre paramètre d'affinité de session si vous avez besoin de plusieurs connexions d'un client pour accéder à la même instance.

Pools cibles

Une ressource de pool cible définit un groupe d'instances qui doivent recevoir le trafic entrant acheminé par les règles de transfert. Lorsqu'une règle de transfert achemine le trafic vers un pool cible, Cloud Load Balancing sélectionne une instance de ces pools cibles en fonction du hachage de l'adresse IP et du port source, ainsi que de l'adresse IP et du port de destination. Pour en savoir plus sur la distribution du trafic aux instances, consultez la section Algorithme de répartition de la charge de cette page.

Les pools cibles ne sont disponibles que pour les règles qui gèrent le trafic TCP-UDP. Pour tous les autres protocoles, vous devez créer une instance cible. Un pool cible doit être créé avant de pouvoir être utilisé avec une règle de transfert. Chaque projet peut contenir jusqu'à 50 pools cibles.

Si vous souhaitez que votre pool cible ne contienne qu'une seule instance de VM, utilisez plutôt la fonctionnalité de transfert de protocole.

L'équilibrage de charge réseau est compatible avec l'autoscaler Cloud Load Balancing, qui permet aux utilisateurs d'effectuer un autoscaling sur les groupes d'instances d'un pool cible en fonction de l'utilisation du backend. Pour en savoir plus, consultez la section Autoscaling basé sur l'utilisation du processeur.

Règles de transfert

Les règles de transfert fonctionnent conjointement avec les pools cibles pour permettre l'équilibrage de charge. Pour utiliser l'équilibrage de charge, vous devez créer une règle de transfert qui dirige le trafic vers des pools cibles spécifiques. Il n'est pas possible d'équilibrer la charge de votre trafic sans règle de transfert.

Chaque règle de transfert fait correspondre une adresse IP, un protocole et, le cas échéant, une plage de ports spécifiques avec un pool cible unique. Lorsque du trafic est envoyé à une adresse IP externe desservie par une règle de transfert, celle-ci dirige ce trafic vers le pool cible correspondant.

Si vous effectuez un équilibrage de charge des paquets UDP susceptibles d'être fragmentés avant d'arriver sur votre VPC (réseau virtuel privé) Google Cloud, consultez la section Équilibrage de charge et paquets UDP fragmentés.

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 externe TCP/UDP. É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 pool cible.
  • Vous devez configurer des plages de ports ou des protocoles différents, en utilisant la même adresse IP externe, pour le même pool cible.

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 requises. Cette liaison est nécessaire, car les adresses IP de destination des paquets distribués via l'équilibreur de charge correspondent à l'adresse IP externe régionale associée à la règle de transfert externe régionale correspondante.

Vérifications d'état

Les vérifications d'état permettent de s'assurer que Compute Engine ne transfère les nouvelles connexions qu'aux instances qui sont prêtes à les recevoir. Compute Engine envoie des requêtes de vérification d'état à chaque instance, à la fréquence spécifiée. Une fois qu'une instance dépasse le nombre autorisé d'échecs de vérification d'état, elle n'est plus considérée comme une instance éligible pour recevoir du nouveau trafic. Les connexions existantes ne sont pas fermées activement, ce qui permet aux instances de s'arrêter normalement et de fermer les connexions TCP.

Le vérificateur d'état continue d'interroger les instances non opérationnelles et renvoie une instance au pool lorsque le nombre spécifié de vérifications abouties est atteint. Si toutes les instances sont signalées en tant que UNHEALTHY, l'équilibreur de charge dirige le nouveau trafic vers toutes les instances existantes.

L'équilibrage de la charge réseau s'appuie sur les anciennes vérifications d'état HTTP pour déterminer l'état de l'instance. Même si votre service n'utilise pas HTTP, vous devez exécuter un serveur Web de base sur chaque instance que le système de vérification d'état peut interroger.

Chemin de retour

Pour les vérifications d'état, Google Cloud utilise des routages spéciaux non définis dans votre réseau VPC. Pour en savoir plus, consultez la section Chemins de retour des équilibreurs de charge.

Règles de pare-feu

Les vérifications d'état des équilibreurs de la charge réseau sont envoyées à partir de plages d'adresses IP. Vous devez créer des règles de pare-feu autorisant le trafic entrant en provenance de ces plages.

L'équilibrage de charge réseau est un équilibrage de charge à stratégie directe, ce qui signifie que vos règles de pare-feu doivent autoriser le trafic provenant des adresses IP sources du client. Si votre service est ouvert au trafic Internet, il est plus facile d'autoriser le trafic provenant de toutes les plages d'adresses IP. Si vous souhaitez limiter l'accès à certaines adresses IP sources, vous pouvez configurer des règles de pare-feu pour appliquer cette restriction. Vous devez toutefois autoriser l'accès à partir des plages IP de vérification d'état.

Pour obtenir un exemple de stratégie de pare-feu et un exemple de configuration, consultez la section Règles pour l'équilibrage de la charge réseau.

Affinité de session

L'équilibrage de la charge réseau n'utilise pas l'affinité de session des services de backend. Des pools cibles pour l'affinité de session sont utilisés à la place.

Pour en savoir plus, consultez la documentation du paramètre sessionAffinity sur la page Utiliser des pools cibles.

Équilibrage de charge et paquets UDP fragmentés

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

  1. Les paquets non fragmentés sont traités normalement dans toutes les configurations.
  2. Les paquets UDP peuvent être fragmentés avant d'atteindre Google Cloud. Les réseaux intermédiaires peuvent attendre que tous les fragments soient arrivés avant de les transférer, ce qui entraîne un retard ou une suppression de fragments. Google Cloud n'attend pas que tous les fragments soient arrivés. Chaque fragment est transféré dès sa réception.
  3. Étant donné que les fragments UDP ultérieurs ne contiennent pas le port de destination, des problèmes peuvent survenir dans les situations suivantes :

    • Si l'affinité de session des pools cibles est définie sur NONE (affinité à cinq tuples), les fragments suivants peuvent être supprimés, car l'équilibreur de charge ne peut pas calculer le hachage à cinq tuples.
    • S'il existe plusieurs règles de transfert UDP pour la même adresse IP à équilibrage de charge, les fragments suivants peuvent arriver à la mauvaise règle de transfert.

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

  • Définissez l'affinité de session sur CLIENT_IP_PROTO ou CLIENT_IP. N'utilisez pas la valeur NONE (affinité à cinq tuples). Étant donné que CLIENT_IP_PROTO et CLIENT_IP n'utilisent pas le port de destination pour le hachage, le même hachage peut être calculé pour les fragments suivants comme pour le premier fragment.
  • N'utilisez qu'une seule règle de transfert UDP par adresse IP à équilibrage de charge. Les fragments arriveront ainsi à la même règle de transfert.

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.

Étape suivante