Présentation de l'équilibreur de charge réseau proxy externe

Ce document présente les concepts que vous devez maîtriser pour configurer un équilibreur de charge réseau proxy externe Google Cloud.

L'équilibreur de charge réseau proxy 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 cloud privé virtuel (VPC) Google Cloud. Lorsque vous utilisez un équilibreur de charge réseau proxy externe, le trafic TCP ou SSLentrant est interrompu au niveau de l'équilibreur de charge. Une nouvelle connexion transfère ensuite le trafic vers le backend disponible le plus proche à l'aide du protocole TCP ou SSL (recommandé). Pour en savoir plus, consultez la page Présentation de l'équilibreur de charge réseau proxy.

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

Dans cet exemple, le trafic SSL des utilisateurs de la ville A et de la ville B est interrompu au niveau de la couche d'équilibrage de charge et une connexion distincte est établie avec le backend sélectionné.

Cloud Load Balancing avec terminaison SSL.
Cloud Load Balancing avec terminaison SSL (cliquez pour agrandir).

Modes de fonctionnement

Vous pouvez configurer un équilibreur de charge réseau proxy externe dans les modes suivants:

  • Un équilibreur de charge réseau proxy classique est mis en œuvre sur des Google Front Ends (GFE) distribués à l'échelle mondiale. Cet équilibreur de charge peut être configuré pour gérer le trafic TCP ou SSL, à l'aide d'un proxy TCP cible ou d'un proxy SSL cible, respectivement. Au niveau Premium, cet équilibreur de charge peut être configuré en tant que service global d'équilibrage de charge. Au niveau Standard, cet équilibreur de charge est configuré en tant que service d'équilibrage de charge régional. Les équilibreurs de charge réseau proxy classiques peuvent également être utilisés pour d'autres protocoles exploitant SSL, tels que WebSockets et IMAP over SSL.
  • Un équilibreur de charge réseau proxy externe global est mis en œuvre sur des GFE distribués à l'échelle mondiale et accepte les fonctionnalités de gestion avancée du trafic. Cet équilibreur de charge peut être configuré pour gérer le trafic TCP ou SSL, à l'aide d'un proxy TCP cible ou d'un proxy SSL cible, respectivement. Cet équilibreur de charge est configuré en tant que service global d'équilibrage de charge au niveau Premium. Les équilibreurs de charge réseau proxy externes globaux peuvent également être utilisés pour d'autres protocoles exploitant SSL, tels que WebSockets et IMAP over SSL.
  • Un équilibreur de charge réseau proxy régional externe est mis en œuvre sur la pile logicielle Open Source proxy Envoy. Il ne peut gérer que le trafic TCP. Cet équilibreur de charge est configuré en tant que service d'équilibrage de charge régional compatible avec le niveau Premium ou Standard.

Identifier le mode

Procédez comme suit pour déterminer le mode d'un équilibreur de charge :

Console

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Dans l'onglet Équilibreurs de charge, le type, le protocole et la région de l'équilibreur de charge sont affichés. Si la région est vide, l'équilibreur de charge est global.

    Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

    Mode d'équilibreur de charge Type d'équilibreur de charge Type d'accès Région
    Équilibreur de charge réseau proxy classique Réseau (proxy classique) Externe
    Équilibreur de charge réseau proxy externe global Réseau (proxy) Externe
    Équilibreur de charge réseau proxy externe régional Réseau (proxy) Externe Spécifie une région

gcloud

  1. Exécutez la commande gcloud compute forwarding-rules describe :

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

  2. Dans le résultat de la commande, vérifiez le schéma d'équilibrage de charge, la région et le niveau de réseau. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

    Mode d'équilibreur de charge Schéma d'équilibrage de charge Règle de transfert Niveau de réseau
    Équilibreur de charge réseau proxy classique EXTERNAL Mondial Standard ou Premium
    Équilibreur de charge réseau proxy externe global EXTERNAL_MANAGED Mondial Premium
    Équilibreur de charge réseau proxy externe régional EXTERNAL_MANAGED Régional Standard ou Premium

Architecture

Les schémas suivants montrent les composants des équilibreurs de charge réseau proxy externes.

Monde

Ce schéma montre les composants d'un déploiement de l'équilibreur de charge réseau proxy externe global. Cette architecture s'applique à la fois à l'équilibreur de charge réseau proxy externe global et à l'équilibreur de charge réseau proxy classique au niveau Premium.

Composants de l'équilibreur de charge réseau proxy externe global
Composants de l'équilibreur de charge réseau proxy externe global (cliquez pour agrandir).

Régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy externe régional.

Composants de l'équilibreur de charge réseau proxy externe régional.
Composants de l'équilibreur de charge réseau proxy externe régional (cliquez pour agrandir).

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

Sous-réseau proxy réservé

Remarque: Les sous-réseaux proxy réservés ne sont requis que pour les équilibreurs de charge réseau proxy externes régionaux.

Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau VPC dans laquelle vous utilisez des équilibreurs de charge. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy situés dans la même région et sur le même réseau VPC partagent un pool de proxys Envoy du même sous-réseau proxy réservé.

Les VM de backend ou les points de terminaison de tous les équilibreurs de charge situés dans une région et sur un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.

Points à retenir :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • L'adresse IP de l'équilibreur de charge n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en externe.

Règles de transfert et adresses IP

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

Spécification de l'adresse IP. Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Vous pouvez soit réserver une adresse IP statique que vous pouvez utiliser, soit laisser Cloud Load Balancing en attribuer une pour vous. 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 et en créez une autre.

Spécification du port Les règles de transfert externes utilisées dans la définition de cet équilibreur de charge peuvent faire référence à un seul port de la plage 1-65535. Si vous souhaitez 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. Pour plus d'informations, consultez la section Spécifications de ports pour les règles de transfert.

Pour accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Celles-ci peuvent être configurées avec la même adresse IP virtuelle et des ports différents. 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.

Le tableau suivant présente les exigences concernant les règles de transfert pour les équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Network Service Tier Règle de transfert, adresse IP et schéma d'équilibrage de charge Routage depuis Internet vers l'interface de l'équilibreur de charge
Équilibreur de charge réseau proxy classique Niveau Premium

Règle de transfert externe globale

Adresse IP externe globale

Schéma d'équilibrage de charge : EXTERNAL

 Requêtes acheminées vers les GFE les plus proches du client sur Internet.
Niveau Standard

Règle de transfert externe régionale

Adresse IP externe régionale

Schéma d'équilibrage de charge : EXTERNAL

 Requêtes acheminées vers un GFE dans la région de l'équilibreur de charge
Équilibreur de charge réseau proxy externe global Niveau Premium

Règle de transfert externe globale

Adresse IP externe globale

Schéma d'équilibrage de charge : EXTERNAL_MANAGED

 Requêtes acheminées vers les GFE les plus proches du client sur Internet.
Équilibreur de charge réseau proxy externe régional Niveaux Premiumet Standard

Règle de transfert externe régionale

Adresse IP externe régionale

Schéma d'équilibrage de charge : EXTERNAL_MANAGED

 Requêtes acheminées vers les proxys Envoy situés dans la même région que l'équilibreur de charge.

Règles de transfert et réseaux VPC

Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application externes sont associées aux réseaux VPC.

Mode d'équilibreur de charge Association de réseaux VPC
Équilibreur de charge réseau proxy externe global

Équilibreur de charge réseau proxy classique

Aucun réseau VPC associé.

La règle de transfert utilise toujours une adresse IP externe au réseau VPC. Par conséquent, la règle de transfert n'a aucun réseau VPC associé.
Équilibreur de charge réseau proxy externe régional

Le réseau VPC de la règle de transfert est le réseau dans lequel le sous-réseau proxy réservé a été créé. Vous spécifiez le réseau lorsque vous créez la règle de transfert.

Proxy cibles

Les équilibreurs de charge réseau proxy externes mettent fin aux connexions du client et créent de nouvelles connexions vers les backends. Le proxy cible achemine ces nouvelles connexions vers le service de backend.

Selon le type de trafic que votre application doit gérer, vous pouvez configurer un équilibreur de charge réseau proxy externe avec un proxy TCP cible ou un proxy SSL cible.

  • Proxy TCP cible: configurez l'équilibreur de charge avec un proxy TCP cible si vous prévoyez un trafic TCP.
  • Proxy SSL cible: configurez l'équilibreur de charge avec un proxy SSL cible si vous prévoyez un trafic client chiffré. Ce type d'équilibreur de charge est destiné uniquement au trafic autre que HTTP(S). Pour le trafic HTTP(S), nous vous recommandons plutôt d'utiliser un équilibreur de charge d'application externe.

Par défaut, le proxy cible ne conserve ni l'adresse IP ni les informations de port d'origine du client. Vous pouvez conserver ces informations en activant le protocole de PROXY sur le proxy cible.

Le tableau suivant présente les exigences concernant le proxy cible pour les équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Network Service Tier Proxy cible
Équilibreur de charge réseau proxy classique Niveau Premium targetTcpProxies ou targetSslProxies
Niveau Standard targetTcpProxies ou targetSslProxies
Équilibreur de charge réseau proxy externe global Niveau Premium targetTcpProxies ou targetSslProxies
Équilibreur de charge réseau proxy externe régional Niveau Premium et Standard regionTargetTcpProxies

Certificats SSL

Les certificats SSL ne sont requis que si vous déployez un équilibreur de charge réseau proxy externe global et un équilibreur de charge réseau proxy classique avec un proxy SSL cible.

Les équilibreurs de charge réseau proxy externes utilisant des proxys SSL cibles nécessitent des clés privées et des certificats SSL dans la configuration de l'équilibreur de charge.

  • Google Cloud propose deux méthodes de configuration pour l'attribution de clés privées et de certificats SSL aux proxys SSL cibles : les certificats SSL Compute Engine et le gestionnaire de certificats. Pour obtenir une description de chaque configuration, consultez la section Méthodes de configuration des certificats dans la présentation des certificats SSL.

  • Google Cloud fournit deux types de certificats : les certificats autogérés et les certificats gérés par Google. Pour obtenir une description de chaque type, consultez la section Types de certificats dans la présentation des certificats SSL.

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 possède une seule ressource de service de backend qui spécifie la vérification de l'état à effectuer sur les backends disponibles.

Les modifications apportées au service de backend ne sont pas instantanées. La propagation des modifications sur les GFE peut prendre plusieurs minutes. 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.

Pour plus d'informations sur la ressource du service de backend, voir Présentation des services de backend.

Le tableau suivant spécifie les différents backends compatibles avec le service de backend des équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Backends compatibles sur un service de backend
Groupes d'instances NEG zonaux NEG Internet NEG sans serveur NEG hybrides NEG Private Service Connect GKE
Équilibreur de charge réseau proxy classique Utiliser des NEG zonaux autonomes
Équilibreur de charge réseau proxy externe global * Points de terminaison de type GCE_VM_IP_PORT*
Équilibreur de charge réseau proxy externe régional Points de terminaison de type GCE_VM_IP_PORT NEG régionaux uniquement Ajouter un NEG Private Service Connect

* Les équilibreurs de charge réseau proxy externes globaux sont compatibles avec les groupes d'instances IPv4 et IPv6 (double pile) et les backends de NEG zonaux avec des points de terminaison GCE_VM_IP_PORT.

Backends et réseaux VPC

Pour les équilibreurs de charge réseau proxy externes globaux et les équilibreurs de charge réseau proxy classiques, toutes les instances backend des backends de groupe d'instances et tous les points de terminaison backend des backends NEG doivent être situés dans le même projet. Toutefois, un backend de groupe d'instances ou un NEG peut utiliser un réseau VPC différent dans ce projet. 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 GFE communiquent directement avec les backends dans leurs réseaux VPC respectifs.

Pour les backends d'équilibreurs de charge réseau proxy externes régionaux, les éléments suivants s'appliquent:

  • Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent se trouver dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut faire référence à un backend qui utilise un réseau VPC différent dans le même projet que le service de backend (cette fonctionnalité est en version Preview). La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN, de rattachements VLAN Cloud Interconnect ou d'un framework Network Connectivity Center.

    Définition du réseau backend

    • Pour les NEG zonaux et hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
    • Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
    • Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini pour correspondre au réseau VPC de l'interface nic0 de la première VM ajoutée au groupe d'instances.

    Exigences réseau du backend

    Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :

    • Le réseau VPC du backend doit correspondre exactement au réseau VPC de la règle de transfert.

    • Le réseau VPC du backend doit être connecté au réseau VPC de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer des échanges de routes de sous-réseau pour autoriser la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances de backend ou les points de terminaison.

  • Le réseau VPC du backend et le réseau VPC de la règle de transfert doivent être des spokes VPC sur le même hub Network Connectivity Center. Les filtres d'importation et d'exportation doivent autoriser la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison backend.

  • Pour tous les autres types de backends, tous les backends doivent se trouver dans le même réseau VPC et dans la même région.

Backends et interfaces réseau

Si vous utilisez des backends de groupe d'instances, les paquets sont toujours envoyés à nic0. Si vous souhaitez envoyer des paquets à différentes cartes réseau, utilisez plutôt des backends de NEG.

Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour un équilibreur de charge réseau proxy externe, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends.

  • Pour les équilibreurs de charge réseau proxy classiques, vous avez le choix entre TCP et SSL.
  • Pour les équilibreurs de charge réseau proxy externes, vous pouvez choisir TCP ou SSL.
  • Pour les équilibreurs de charge réseau proxy externes régionaux, vous pouvez utiliser 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 règles de pare-feu suivantes sont requises :

  • Pour les équilibreurs de charge réseau proxy classiques, une règle de pare-feu autorisant le trafic entrant (allow) pour permettre aux GFE d'atteindre vos backends.

  • Pour les équilibreurs de charge réseau proxy externes globaux, une règle de pare-feu autorisant le trafic entrant (allow) pour permettre aux GFE d'atteindre vos backends.

  • Pour les équilibreurs de charge réseau proxy externes régionaux, une règle de pare-feu d'entrée pour autoriser le trafic provenant du sous-réseau proxy réservé à accéder à vos backends.

  • Une règle de pare-feu qui autorise le trafic entrant (allow), pour permettre au trafic provenant des plages de vérification d'état d'atteindre vos backends. Pour plus d'informations sur les vérifications d'é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 au niveau des proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu 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 zonaux GCE_VM_IP_PORT NEG : autorisez le trafic vers les numéros de port des points de terminaison.

Le tableau suivant récapitule les plages d'adresses IP sources requises pour les règles de pare-feu :

Mode d'équilibreur de charge Plages sources de vérification d'état Demander des plages sources
Équilibreur de charge réseau proxy externe global
  • 35.191.0.0/16
  • 130.211.0.0/22

Pour le trafic IPv6 vers les backends :

  • 2600:2d00:1:b029::/64
 La source du trafic GFE dépend du type de backend :
  • Groupes d'instances et NEG zonaux (GCE_VM_IP_PORT) :
    • 130.211.0.0/22
    • 35.191.0.0/16

    Pour le trafic IPv6 vers les backends :

    • 2600:2d00:1:1::/64
Équilibreur de charge réseau proxy classique
  • 35.191.0.0/16
  • 130.211.0.0/22
 Ces plages s'appliquent aux vérifications d'état et aux requêtes de GFE.
Équilibreur de charge réseau proxy externe régional *, †
  • 35.191.0.0/16
  • 130.211.0.0/22

Pour le trafic IPv6 vers les backends :

  • 2600:2d00:1:b029::/64
 Ces plages s'appliquent aux vérifications d'état.

*L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification d'état Google à la liste d'autorisation pour les NEG zonaux.

† Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge qui utilisent des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est traduit par la NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez la page NEG régionaux : utiliser Cloud NAT pour la sortie.

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 :

Pour les équilibreurs de charge réseau proxy classiques et les équilibreurs de charge réseau proxy externes globaux:

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

Pour les équilibreurs de charge réseau proxy externes régionaux:

  • Connexion 1, du client d'origine vers l'équilibreur de charge (sous-réseau proxy réservé) :

    • 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 (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :

    • Adresse IP source : une adresse IP du sous-réseau proxy réservé partagée entre tous les équilibreurs de charge basés sur Envoy déployés dans la même région en tant qu'équilibreur de charge.

    • 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 réseau proxy 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. Lorsque vous exécutez une analyse de port, d'autres ports ouverts peuvent s'afficher 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. 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 à une adresse IP ou à un port différents ne sont pas envoyés à vos backends.

    Les GFE mettent en œuvre des fonctionnalités de sécurité telles que Google Cloud Armor. Avec Google Cloud Armor Standard, les GFE offrent une protection permanente contre les attaques DDoS volumétriques et basées sur un protocole, et les inondations SYN. Cette protection est disponible même si vous n'avez pas explicitement configuré Google Cloud Armor. Vous ne serez facturé que si vous configurez des règles de sécurité ou si vous vous inscrivez au niveau Managed Protection Plus.

  • 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 réseau proxy externes régionaux et les équilibreurs de charge réseau proxy classiques sont compatibles avec les déploiements qui utilisent des réseaux VPC partagés. 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 TCPou SSL cible doit être défini dans le même projet que les instances backend.

Pour les équilibreurs de charge réseau proxy classiques, 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 d'état associées aux services de backend doivent être définies dans le même projet que le service de backend.

Pour les équilibreurs de charge réseau externes proxy régionaux, les VM de backend sont généralement situées dans un projet de service. Un service de backend interne régional et une vérification d'état doivent être définis dans ce projet de service.

Répartition du trafic

Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage de charge, qui définit une méthode permettant de mesurer la charge du backend et la capacité cible.

Pour les équilibreurs de charge réseau proxy externes, 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 total de connexions que le backend peut gérer.
  • 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. Ce mode d'équilibrage ne s'applique qu'aux backends de groupes d'instances de VM.

La répartition du trafic entre les backends est déterminée par le mode d'équilibrage de l'équilibreur de charge.

Équilibreur de charge réseau proxy classique

Pour l'équilibreur de charge réseau proxy classique, le mode d'équilibrage permet de sélectionner le backend le plus adapté (groupe d'instances ou NEG). Le trafic est ensuite distribué à tour de rôle entre les instances ou les points de terminaison du backend.

Distribution des connexions

Un équilibreur de charge réseau proxy classique 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.

Le mode d'équilibrage et le choix de la cible déterminent 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. Le trafic est ensuite distribué dans une zone à l'aide d'un hachage cohérent.

Pour le niveau Premium :

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

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 ne pouvez configurer des backends que dans la même région que la règle de transfert. L'équilibreur de charge ne dirige les requêtes que vers les backends opérationnels dans cette région.

Équilibreur de charge réseau proxy externe global

Pour l'équilibreur de charge réseau proxy externe global, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle de localité d'équilibrage de charge.

Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque groupe (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.

Lorsqu'un service de backend reçoit du trafic, il dirige tout d'abord le trafic vers un backend (groupe d'instances ou NEG) en fonction du mode d'équilibrage du backend. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.

Pour en savoir plus, consultez les ressources suivantes :

Distribution des connexions

Un équilibreur de charge réseau proxy externe global peut être configuré en tant que service global d'équilibrage de charge au niveau Premium.

Le mode d'équilibrage et le choix de la cible déterminent l'utilisation maximale du backend du point de vue de chaque NEG GCE_VM_IP_PORT zonal ou groupe d'instances zonal. Le trafic est ensuite distribué dans une zone à l'aide d'un hachage cohérent.

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

Équilibreur de charge réseau proxy externe régional

Pour les équilibreurs de charge réseau proxy externes régionaux, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle d'équilibrage de charge de la localité.

Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque backend (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.

Lorsqu'un service de backend reçoit du trafic, il dirige tout d'abord le trafic vers un backend (groupe d'instances ou NEG) en fonction de son mode d'équilibrage. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.

Pour en savoir plus, consultez les ressources suivantes :

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 réseau proxy externes offrent les types d'affinité de session suivants:

  • NONE : l'affinité de session n'est pas définie pour l'équilibreur de charge.
  • L'affinité basée sur les adresses IP client, qui transfère toutes les requêtes provenant d'une même adresse IP client vers le même backend.

Basculement

Le basculement des équilibreurs de charge réseau proxy externes fonctionne comme suit:

  • 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 (modes global et classique 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.

Pour en savoir plus, consultez la section Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes.

Limites

  • Vous ne pouvez pas créer un équilibreur de charge réseau proxy régional au niveau Premium à l'aide de la console Google Cloud. De plus, seules les régions compatibles avec le niveau Standard sont disponibles pour ces équilibreurs de charge dans la console Google Cloud. Utilisez plutôt la gcloud CLI ou l'API.

  • Les limites suivantes s'appliquent uniquement aux équilibreurs de charge réseau proxy classiques et aux équilibreurs de charge réseau proxy externes globaux qui sont déployés avec un proxy cible SSL :

    • Les équilibreurs de charge réseau proxy classiques et les équilibreurs de charge réseau proxy externes globaux ne sont pas compatibles avec l'authentification basée sur un certificat client, également appelée authentification TLS mutuelle.

    • Les équilibreurs de charge réseau proxy classiques et les équilibreurs de charge réseau proxy externes globaux n'acceptent que les minuscules dans les domaines d'un attribut de nom commun (CN) ou d'un autre nom d'objet (SAN) du certificat. Les certificats dont les domaines contiennent des majuscules ne sont renvoyés que lorsqu'ils sont définis comme certificat principal dans le proxy cible.

Étapes suivantes