Présentation de l'équilibreur de charge réseau passthrough externe basé sur un pool cible

Un équilibreur de charge réseau passthrough externe est un équilibreur de charge régional de couche 4. Les équilibreurs de charge réseau passthrough externes distribuent le trafic TCP et UDP entre les instances de machines virtuelles (VM) backend situées dans la même région au sein d'un réseau cloud privé virtuel (VPC). Un équilibreur de charge réseau passthrough externe peut recevoir du trafic provenant de l'un 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

Selon la configuration des règles de transfert, chaque équilibreur de charge basé sur un pool cible accepte l'un des types de trafic de protocole suivants :

  • TCP
  • UDP
  • TCP et UDP

Le champ d'application de l'équilibreur de charge est régional et non global. Cela signifie que toutes les instances backend d'un équilibreur de charge réseau passthrough externe doivent être situées dans la même région. Vous pouvez placer des backends dans n'importe quelle zone de la région.

Les équilibreurs de charge réseau passthrough externes sont compatibles avec tous les ports. Vous pouvez utiliser un équilibreur de charge réseau passthrough externe pour équilibrer le trafic TCP ou UDP. L'équilibreur de charge est un équilibreur de charge à stratégie directe. Par conséquent, vos backends mettent fin à la connexion TCP à équilibrage de charge ou aux paquets UDP eux-mêmes. Vous pouvez par exemple exécuter un serveur Web HTTPS sur vos backends et utiliser un équilibreur de charge réseau passthrough externe pour acheminer les requêtes vers celui-ci, interrompant le protocole TLS sur vos backends eux-mêmes.

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. Il s'agit de la même architecture que l'architecture d'équilibrage de charge autonome, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE. Pour en savoir plus, consultez la page Exposer des applications à l'aide de services.

Architecture

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

Un équilibreur de charge réseau passthrough externe possède toujours un pool cible. Plusieurs règles de transfert peuvent référencer le pool cible.

Le pool cible est un backend pour l'équilibreur de charge. Il spécifie les instances backend parmi lesquelles le trafic est équilibré. Chaque règle de transfert est un frontend pour l'équilibreur de charge. N'oubliez pas qu'il existe des limites au nombre de règles de transfert et de pools cibles par projet.

Les équilibreurs de charge réseau passthrough externes é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 passthrough externe 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 passthrough externe 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 pools cibles. L'IPV est diffusée n'importe où sur les points de présence mondiaux de Google, mais les backends 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 passthrough externe 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. L'équilibreur de charge réseau passthrough externe transfère les paquets à la première interface réseau (nic0) des instances du pool cible.

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

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. Chaque pool cible fonctionne dans une seule région et distribue le trafic vers la première interface réseau (nic0) de l'instance backend. Pour en savoir plus sur la distribution du trafic aux instances, consultez la section Algorithme de répartition de la charge.

Les équilibreurs de charge réseau passthrough externes ne sont pas des proxys. Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. L'équilibreur de charge préserve les adresses IP sources des paquets. L'adresse IP de destination des paquets entrants 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 backend pour les équilibreurs de charge réseau passthrough externes 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 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).

Les équilibreurs de charge réseau passthrough externes sont compatibles avec l'autoscaler Compute Engine, 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 Scaling basé sur l'utilisation du processeur.

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

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.

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.

Les équilibreurs de charge réseau passthrough externes basés sur un pool cible acceptent les protocoles suivants pour chaque règle de transfert : TCP ou UDP. Si vous souhaitez que l'équilibreur de charge transfère tout le trafic du protocole IP, vous devez utiliser un équilibreur de charge réseau passthrough externe basé sur un service de backend.

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 passthrough externe. É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.

Pour permettre un arrêt progressif et la fermeture des connexions TCP, les connexions existantes ne sont pas délibérément fermées. Cependant, il n'est pas garanti que les connexions existantes à un backend non opérationnel restent viables pour une longue période. Si possible, il est donc conseillé de commencer un processus d'arrêt progressif le plus rapidement possible pour votre backend non opérationnel.

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 comme UNHEALTHY, l'équilibreur de charge dirige le nouveau trafic vers toutes les instances existantes.

Les équilibreurs de charge réseau passthrough externes s'appuient sur les vérifications d'état HTTP héritées 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.

Les vérifications d'état HTTPS héritées ne sont pas compatibles avec les équilibreurs de charge réseau passthrough externes et ne peuvent pas être utilisées avec la plupart des autres équilibreurs de charge.

Règles de pare-feu

Les vérifications d'état pour les équilibreurs de charge réseau passthrough externes 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.

Les équilibreurs de charge réseau passthrough externes sont des équilibreurs 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 règle de pare-feu et un exemple de configuration, consultez la page Règles de pare-feu pour les équilibreurs de charge réseau passthrough externes.

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.
  • Le protocole UDP est sans connexion. Les VM de backend peuvent donc 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 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 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

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 pour les équilibreurs de charge.

Architecture du VPC partagé

Le tableau suivant récapitule les composants du VPC partagé pour les équilibreurs de charge réseau passthrough externes

Adresse IP Règle de transfert Composants backend
Une adresse IP externe régionale doit être définie dans le même projet que les instances soumises à l'équilibrage de charge. Une règle de transfert externe régionale doit être définie dans le même projet que les instances du pool cible (le projet de service). Le pool cible doit être défini dans le même projet et dans la même région que les instances qu'il cible. Les vérifications d'état associées au pool cible doivent également être définies dans le même projet.

Répartition du trafic

La façon dont un équilibreur de charge réseau passthrough externe basé sur un pool cible distribue les nouvelles connexions dépend de la configuration de l'affinité de session.

Affinité de session

L'affinité de session contrôle la méthode de hachage utilisée pour répartir les nouvelles connexions des clients aux VM de backend de l'équilibreur de charge. Les équilibreurs de charge basés sur un pool cible utilisent le paramètre sessionAffinity pour configurer l'affinité de session.

Pour en savoir plus, consultez 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 NONE, CLIENT_IP_PROTO ou CLIENT_IP.
    • Définir l'affinité de session sur NONE indique qu'il n'est pas nécessaire de conserver l'affinité. 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
    • Définir l'affinité de session sur CLIENT_IP_PROTO ou CLIENT_IP signifie que les ports source et de destination ne sont pas utilisés pour le hachage. Le même hachage est donc calculé pour les paquets fragmentés comme non fragmentés.
  • 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.

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 passthrough externe 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 0 à 65535. 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.

Limites

  • Vous ne pouvez pas utiliser la console Google Cloud pour créer des équilibreurs de charge réseau passthrough externes basés sur un pool cible. Utilisez plutôt gcloud ou l'API REST.
  • Les équilibreurs de charge réseau passthrough externes ne sont pas compatibles avec l'appairage de réseaux VPC.

Étapes suivantes