Présentation de l'équilibreur de charge proxy TCP externe

L'équilibreur de charge proxy TCP externe 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 un équilibreur de charge proxy TCP externe, 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.

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

Au Niveau Premium, les équilibreurs de charge proxy TCP externes peuvent être configurés en tant que service global d'équilibrage de charge. Au niveau Standard, l'équilibreur de charge proxy TCP externe gère l'équilibrage de charge à l'échelle régionale.

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)

Les équilibreurs de charge proxy TCP externes sont destinés 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 un équilibreur de charge proxy SSL externe.

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 externe :

  • Terminaison IPv6 Les équilibreurs de charge proxy TCP externes acceptent 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 tous les ports. Les équilibreurs de charge proxy TCP externes autorisent tous les ports valides compris entre 1 et 65535.
  • Intégration à Google Cloud Armor. Vous pouvez utiliser les stratégies de sécurité Google Cloud Armor pour protéger votre infrastructure contre les attaques par déni de service distribué (DDoS) et d'autres attaques ciblées.

Architecture

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

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 externe peuvent faire référence à un seul des ports répertoriés dans les spécifications des ports pour les règles de transfert.

Les équilibreurs de charge proxy TCP externes acceptent un seul port dans la plage de ports (contigus). Pour accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Plusieurs règles de transfert peuvent être configurées avec la même adresse IP virtuelle et différents ports. Par conséquent, vous pouvez relayer plusieurs applications par proxy avec des ports personnalisés distincts vers la même adresse IP virtuelle du proxy TCP.

Proxys cibles

Les équilibreurs de charge proxy TCP externes interrompent les connexions TCP du client et créent des connexions vers les backends. Le proxy cible achemine ces nouvelles connexions vers le service de backend.

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.

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).

Chaque équilibreur de charge proxy TCP externe possède 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.

Backends et réseaux VPC

Tous les backends doivent être situés dans le même projet, mais peuvent être se trouver sur différents réseaux VPC. Les différents réseaux VPC n'ont pas besoin d'être connectés via l'appairage de réseaux VPC, car les systèmes de proxy GFE communiquent directement avec les backends dans leurs réseaux VPC respectifs.

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour l'équilibreur de charge proxy TCP externe, 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

Les équilibreurs de charge proxy TCP externes et proxy SSL externes nécessitent les règles de pare-feu suivantes :

  • Une règle de pare-feu autorisant le trafic entrant pour autoriser les GFE (Google Front End) à accéder à vos backends.

  • Une règle de pare-feu autorisant le trafic entrant pour autoriser le trafic provenant des plages de vérification d'état à atteindre vos backends. 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 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.

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 plages d'adresses IP sources requises sont les suivantes :

  • 35.191.0.0/16
  • 130.211.0.0/22

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 externes 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 n'envoient des paquets SYN-ACK en réponse aux vérifications SYN que pour les ports sur lesquels vous avez configuré une règle de transfert, et sur les ports 80 et 443, si votre équilibreur de charge utilise une adresse IP de niveau Premium. 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.

  • 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.

Architecture du VPC partagé

Les équilibreurs de charge proxy TCP externes sont compatibles avec les réseaux qui utilisent un VPC partagé. Les réseaux VPC partagés vous permettent de séparer clairement les responsabilités entre les administrateurs réseau et les développeurs de services. Vos équipes de développement peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes d'infrastructure réseau peuvent provisionner et administrer l'équilibrage de charge. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.

Adresse IP Règle de transfert Proxy cible Composants backend
Une adresse IP externe doit être définie dans le même projet que l'équilibreur de charge. La règle de transfert externe doit être définie dans le même projet que les instances backend (le projet de service). Le proxy TCP cible doit être défini dans le même projet que les instances backend. Un service de backend global doit être défini dans le même projet que les instances backend. Ces instances doivent se trouver dans des groupes d'instances associés au service de backend en tant que backends. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.

Distribution du trafic

La façon dont un équilibreur de charge proxy TCP externe 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

Un équilibreur de charge proxy TCP externe 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 :

  • 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 l'équilibreur de charge ne dirige les requêtes que vers les backends opérationnels dans cette région.

Processus de distribution des requêtes :

  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 de couche 3/4 (Maglev).
  2. 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.

  3. Le GFE de deuxième couche dirige les requêtes vers les backend des zones de sa région.
  4. Parfois, pour le niveau Premium, les GFE de deuxième couche envoient des requêtes aux backends dans des zones de différentes régions. Ce comportement est appelé basculement.

    5. 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.

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

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 externe, 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.

Les équilibreurs de charge proxy TCP externes offrent 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 :

Étapes suivantes