Présentation de l'équilibrage de charge proxy TCP

L'équilibrage de charge proxy TCP est un équilibreur de charge de proxy inverse qui distribue le trafic TCP provenant d'Internet aux instances de machines virtuelles (VM) de votre réseau VPC Google Cloud. Lorsque vous utilisez l'équilibrage de charge proxy TCP, le trafic provenant d'une connexion TCP est interrompu au niveau de la couche d'équilibrage de charge, puis transmis au backend disponible le plus proche à l'aide du protocole TCP ou SSL.

L'équilibrage de charge proxy TCP vous permet d'utiliser une adresse IP unique pour vos utilisateurs du monde entier. L'équilibreur de charge proxy TCP redirige automatiquement le trafic vers les backends les plus proches de l'utilisateur.

Au niveau Premium, l'équilibrage de charge proxy TCP peut être configuré en tant que service global d'équilibrage de charge. Au niveau Standard, l'équilibreur de charge proxy TCP gère l'équilibrage de charge à l'échelle régionale. Pour en savoir plus, consultez la section Comportement de l'équilibreur de charge dans les niveaux de service réseau.

Dans cet exemple, les connexions associées au trafic des utilisateurs de Séoul et de Boston sont interrompues au niveau de la couche d'équilibrage de charge. Ces connexions sont identifiées par les libellés 1a et 2a. Des connexions distinctes sont établies entre l'équilibreur de charge et les instances de backend sélectionnées. Ces connexions sont identifiées par les libellés 1b et 2b.

Cloud Load Balancing avec terminaison TCP (cliquez pour agrandir)
Cloud Load Balancing avec terminaison TCP (cliquez pour agrandir)

L'équilibrage de charge proxy TCP est destiné au trafic TCP sur des ports connus spécifiques, tels que le port 25 du protocole SMTP (Simple Mail Transfer Protocol). Pour en savoir plus, consultez la section Spécifications de ports. Pour gérer le trafic client chiffré sur ces ports, utilisez l'équilibrage de charge proxy SSL.

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

Avantages

Voici certains des avantages de l'équilibreur de charge proxy TCP :

  • Terminaison IPv6 L'équilibrage de charge proxy SSL accepte le trafic client provenant d'adresses IPv4 et d'adresses IPv6. Les requêtes client IPv6 sont interrompues au niveau de la couche d'équilibrage de charge, puis transmises par serveur proxy, via IPv4, à vos backends.
  • Routage intelligent. L'équilibreur de charge peut acheminer les requêtes vers les emplacements de backend disposant d'une capacité suffisante. En revanche, un équilibreur de charge L3/L4 ne peut acheminer les requêtes que vers des backends régionaux, sans tenir compte de leur capacité. L'utilisation d'un routage plus intelligent permet de provisionner à N+1 ou N+2 au lieu de x*N.
  • Correctifs de sécurité. En cas de survenue de failles dans la pile TCP, Cloud Load Balancing applique automatiquement des correctifs à l'équilibreur de charge afin de préserver la sécurité de vos backends.
  • Compatibilité avec les ports TCP connus suivants. 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 et 9300.

Architecture

Les éléments présentés ci-dessous sont les composants des équilibreurs de charge proxy TCP.

Règles de transfert et adresses IP

Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.

Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Aucun équilibrage de charge DNS n'est requis. Vous pouvez soit réserver une adresse IP statique qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une pour votre compte. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert ou que vous en créez une.

Les règles de transfert externes utilisées dans la définition d'un équilibreur de charge proxy TCP peuvent faire référence à un seul des ports répertoriés dans les spécifications des ports pour les règles de transfert.

Proxy cibles

L'équilibrage de charge proxy TCP met fin aux connexions TCP du client et crée des connexions vers les backends. Par défaut, l'adresse IP et les informations de port d'origine du client ne sont pas conservées. Vous pouvez conserver ces informations à l'aide du protocole de PROXY. Les proxys cibles acheminent directement les requêtes entrantes vers les services de backend.

Services de backend

Les services de backend dirigent le trafic entrant vers un ou plusieurs backends associés. Chaque backend est composé d'un groupe d'instances ou d'un groupe de points de terminaison du réseau, ainsi que d'informations sur la capacité de diffusion du backend. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur ou sur le nombre de requêtes par seconde (RPS).

Les équilibreurs de charge proxy TCP possède chacun une seule ressource de service de backend. Les modifications apportées au service de backend ne sont pas instantanées. La propagation des modifications sur Google Front End (GFE) peut prendre plusieurs minutes.

Chaque service de backend spécifie les vérifications d'état à effectuer pour les backends disponibles.

Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal. De telles interruptions peuvent se produire lorsqu'un backend est arrêté, supprimé manuellement ou supprimé par un autoscaler. Pour en savoir plus sur la manière dont vous pouvez utiliser le drainage de connexion pour minimiser les interruptions de service, consultez la page Activer le drainage de connexion.

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour l'équilibreur de charge proxy TCP, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. Vous avez le choix entre les protocoles SSL et TCP. L'équilibreur de charge n'utilise que le protocole spécifié et n'essaie pas de négocier une connexion à l'aide de l'autre protocole.

Règles de pare-feu

Votre équilibreur de charge HTTP(S) externe nécessite les règles de pare-feu suivantes :

  • Pour l'équilibreur de charge HTTP(S) externe, une règle d'autorisation d'entrée permet au trafic provenant des Google Front End (GFE) d'atteindre vos backends.
    Pour l'équilibreur de charge HTTP(S) externe régional, une règle d'autorisation d'entrée autorise le trafic provenant du sous-réseau proxy réservé.
  • Une règle d'autorisation d'entrée pour autoriser le trafic provenant des plages de vérification de l'état. Pour plus d'informations sur les vérifications de l'état et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.

Les ports de ces règles de pare-feu doivent être configurés comme suit :

  • Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.

  • Pour les backends de groupe d'instances : déterminez les ports à configurer par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros de port peuvent varier entre les groupes d'instances attribués au même service de backend.

  • Pour les backends de NEG GCE_VM_IP_PORT : autorisez le trafic vers les numéros de port des points de terminaison.

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non sur les proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu Google Cloud pour empêcher le trafic d'atteindre l'équilibreur de charge. Pour l'équilibreur de charge HTTP(S) externe, vous pouvez utiliser Google Cloud Armor.

Pour les équilibreurs de charge proxy SSL et les équilibreurs de charge proxy TCP, les plages sources requises sont les suivantes :

  • 130.211.0.0/22
  • 35.191.0.0/16

Ces plages s'appliquent aux vérifications d'état et aux requêtes de l'équilibreur de charge GFE.

Adresses IP sources

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externe Google Cloud de l'équilibreur de charge. En d'autres termes, il existe deux connexions TCP :

  • Connexion 1, du client d'origine vers l'équilibreur de charge (GFE) :

    • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT ou un proxy de transfert).
    • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.
  • Connexion 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le point de terminaison :

    • Adresse IP source : adresse IP située dans l'une des plages spécifiées dans les règles de pare-feu.

    • Adresse IP de destination : une adresse IP interne de la VM de backend ou du conteneur dans le réseau VPC.

Ports ouverts

Les équilibreurs de charge proxy TCP sont des équilibreurs de charge de type "proxy inverse". L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. Ces équilibreurs de charge sont mis en œuvre à l'aide de proxys Google Front End (GFE) dans le monde entier.

Les GFE offrent plusieurs ports ouverts pour les autres services Google exécutés sur la même architecture. Pour afficher la liste de certains ports susceptibles d'être ouverts sur des GFE, consultez la section Règle de transfert : spécifications de port. Il peut y avoir d'autres ports ouverts pour d'autres services Google s'exécutant sur des GFE.

L'exécution d'une analyse de port sur l'adresse IP d'un équilibreur de charge basé sur GFE n'est pas utile du point de vue de l'audit pour les raisons suivantes :

  • Une analyse de port (par exemple, avec nmap) n'attend généralement pas de paquet de réponse ni de paquet TCP RST lors de l'exécution de la vérification TCP SYN. Les GFE envoient des paquets SYN-ACK en réponse aux vérifications SYN pour divers ports si votre équilibreur de charge utilise une adresse IP de niveau Premium. Cependant, les GFE n'envoient des paquets à vos backends qu'en réponse aux paquets envoyés à l'adresse IP de votre équilibreur de charge et au port de destination configuré sur sa règle de transfert. Les paquets envoyés à différentes adresses IP d'équilibreur de charge ou à l'adresse IP de votre équilibreur de charge sur un port non configuré dans votre règle de transfert n'entraînent pas l'envoi de paquets aux backends de votre équilibreur de charge. Même sans configuration particulière, l'infrastructure Google et les GFE offrent une défense en profondeur contre les attaques DDoS et inondations SYN.

  • Les paquets envoyés à l'adresse IP de votre équilibreur de charge peuvent recevoir une réponse de n'importe quel GFE du parc de Google. Cependant, l'analyse d'une combinaison d'adresse IP et de port de destination d'un équilibreur de charge n'interroge qu'un seul GFE par connexion TCP. L'adresse IP de votre équilibreur de charge n'est pas attribuée à un seul appareil ou système. Ainsi, l'analyse de l'adresse IP d'un équilibreur de charge basé sur un GFE n'analyse pas tous les GFE du parc de Google.

En gardant cela à l'esprit, voici quelques moyens plus efficaces d'auditer la sécurité de vos instances backend :

  • Un auditeur de sécurité doit inspecter la configuration des règles de transfert pour la configuration de l'équilibreur de charge. Les règles de transfert définissent le port de destination pour lequel votre équilibreur de charge accepte les paquets et les transfère aux backends. Pour les équilibreurs de charge basés sur GFE, chaque règle de transfert externe ne peut référencer qu'un seul port TCP de destination.

  • Un auditeur de sécurité doit inspecter la configuration des règles de pare-feu applicable aux VM de backend. Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les VM de backends, mais elles ne bloquent pas le trafic entrant vers les GFE. Pour connaître les bonnes pratiques, consultez la section Règles de pare-feu.

Distribution du trafic

La façon dont un équilibreur de charge proxy TCP distribue le trafic vers ses backends dépend du mode d'équilibrage et de la méthode de hachage sélectionnée pour choisir un backend (affinité de session).

Distribution des connexions

L'équilibrage de charge proxy TCP peut être configuré en tant que service global d'équilibrage de charge au niveau Premium et en tant que service régional au niveau standard.

Pour le Niveau Premium (s'applique uniquement à l'équilibreur de charge HTTP(S) externe) :

  • Vous ne pouvez disposer que d'un seul service de backend, lequel peut comporter des backends dans plusieurs régions. Pour l'équilibrage de charge global, vous déployez vos backends dans plusieurs régions, et l'équilibreur de charge dirige automatiquement le trafic vers la région la plus proche de l'utilisateur. Si une région est saturée, l'équilibreur de charge redirige automatiquement les nouvelles connexions vers une autre région disposant d'une capacité suffisante. En pareil cas, les connexions utilisateur existantes restent dans la région actuelle.
  • Google annonce l'adresse IP de votre équilibreur de charge à partir de tous les points de présence dans le monde. Toutes les adresses IP de l'équilibreur de charge sont Anycast globales.
  • Si vous configurez un service de backend avec des backends dans plusieurs régions, les GFE (Google Front End) tentent de diriger les requêtes vers des groupes d'instances backend ou des NEG opérationnels dans la région la plus proche de l'utilisateur. Vous trouverez des détails sur le processus sur cette page.

Pour le niveau Standard :

  • Google annonce l'adresse IP de votre équilibreur de charge à partir des points de présence associés à la région de la règle de transfert. L'équilibreur de charge utilise une adresse IP externe régionale.

  • Vous pouvez configurer des backends dans la même région que la règle de transfert. Le processus documenté ici s'applique toujours, mais les GFE ne dirigent les requêtes que vers les backends opérationnels dans cette région.

Processus de distribution des requêtes :

Le mode d'équilibrage et le choix de la cible définissent l'utilisation maximale du backend du point de vue de chaque NEG GCE_VM_IP_PORT zonal, groupe d'instance zonal ou zone d'un groupe d'instance régional. La distribution au sein d'une zone est ensuite effectuée avec un hachage cohérent.

L'équilibreur de charge utilise le processus suivant :

  1. L'adresse IP externe de la règle de transfert est annoncée par les routeurs périphériques aux limites du réseau de Google. Chaque annonce répertorie un saut suivant vers un système d'équilibrage de charge (Maglev) de couche 3/4 au plus près de l'utilisateur.
  2. Les systèmes Maglev inspectent l'adresse IP source du paquet entrant. Ils dirigent la requête entrante vers les systèmes Maglev que les systèmes de géolocalisation IP de Google déterminent au plus près de l'utilisateur.
  3. Les systèmes Maglev acheminent le trafic vers un GFE (Google Front End) de première couche. Le GFE de première couche interrompt le protocole TLS si nécessaire, puis achemine le trafic vers les GFE de deuxième couche en suivant le processus suivant :
    1. Si un service de backend utilise un groupe d'instances ou des backends NEG GCE_VM_IP_PORT, les GFE de première couche préfèrent les GFE de deuxième couche au sein de ou à proximité de la région qui contient le groupe d'instances ou le NEG.
    2. Pour les buckets de backend et les services de backend avec des NEG hybrides, des NEG sans serveur et des NEG Internet, les GFE de première couche choisissent des GFE de deuxième couche dans un sous-ensemble de régions, afin de réduire le délai aller-retour entre les deux GFE.

      La préférence des GFE de deuxième couche n'est pas une garantie. Elle peut changer de manière dynamique en fonction des conditions du réseau et de la maintenance de Google.

      Les GFE de deuxième couche connaissent l'état des vérifications d'état et l'utilisation réelle de la capacité du backend.

  4. Le GFE de deuxième couche dirige les requêtes vers les backend des zones de sa région.
  5. Pour le Niveau Premium, les GFE de deuxième couche envoient parfois des requêtes aux backends dans des zones de différentes régions. Ce comportement est appelé basculement.
  6. Le débordement est régi par deux principes :

    • Le débordement est possible lorsque tous les backends connus d'un GFE de deuxième couche sont au maximum de leur capacité ou non opérationnels.
    • Le GFE de deuxième couche contient des informations sur les backends disponibles et opérationnels dans les zones d'une autre région.

    Les GFE de deuxième couche sont généralement configurés pour desservir un sous-ensemble d'emplacements de backend.

    Le débordement n'épuise pas toutes les zones Google Cloud possibles. Pour détourner le trafic des backends d'une zone spécifique ou d'une région entière, vous devez définir le scaler de capacité sur zéro. Configurer les backends pour qu'ils échouent aux vérifications d'état ne garantit pas le débordement du GFE de deuxième couche sur les backends des zones d'une autre région.

  7. Lors de la distribution des requêtes vers les backends, les GFE fonctionnent au niveau zonal.

    Avec un faible nombre de connexions, les GFE de deuxième couche préfèrent parfois une zone de la région à d'autres. Cette préférence est normale et attendue. La distribution entre les zones de la région ne devient pas uniforme tant que l'équilibreur de charge ne reçoit pas plus de connexions.

Mode d'équilibrage

Lorsque vous ajoutez un backend au service de backend, vous définissez un mode d'équilibrage de charge.

Pour l'équilibrage de charge proxy TCP, le mode d'équilibrage peut être CONNECTION ou UTILIZATION.

Si le mode d'équilibrage de charge est CONNECTION, la charge est répartie en fonction du nombre de connexions simultanées que le backend peut gérer. Vous devez également spécifier l'un des paramètres suivants : maxConnections (sauf pour les groupes d'instances gérés régionaux), maxConnectionsPerInstance ou maxConnectionsPerEndpoint.

Si le mode d'équilibrage de charge est UTILIZATION, la charge est répartie en fonction de l'utilisation des instances dans un groupe d'instances.

Pour en savoir plus sur les différents types d'équilibreurs de charge et les modes d'équilibrage acceptés, consultez la section Méthodes d'équilibrage de charge.

Affinité de session

L'affinité de session permet d'envoyer toutes les requêtes d'un même client au même backend, sous réserve que le backend soit opérationnel et dispose d'une capacité suffisante.

L'équilibrage de charge proxy TCP offre une fonctionnalité d'affinité basée sur les adresses IP client, qui permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend.

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels dans la même région. Si aucun des backends d'une région n'est opérationnel, le trafic est distribué aux backends opérationnels d'autres régions (niveau Premium uniquement). Si aucun des backends n'est opérationnel, l'équilibreur de charge abandonne le trafic.

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans Google Kubernetes Engine, vous pouvez utiliser des NEG autonomes pour équilibrer la charge du trafic directement vers les conteneurs. Avec les NEG autonomes, vous devez créer l'objet Service qui crée le NEG, puis associer le NEG au service de backend afin que l'équilibreur de charge puisse se connecter aux pods.

Documentation GKE associée :

Limites

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

Étape suivante