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

L'équilibreur de charge réseau proxy interne Google Cloud est basé sur un proxy et fourni par un logiciel proxy Envoy Open Source et par la pile de virtualisation de réseau Andromeda.

L'équilibreur de charge réseau proxy interne est un équilibreur de charge de couche 4 qui vous permet d'exécuter et de mettre à l'échelle votre trafic de service TCP derrière une adresse IP interne régionale accessible uniquement aux clients situés dans le même réseau VPC ou aux clients connectés à votre réseau VPC. L'équilibreur de charge interrompt d'abord la connexion TCP entre le client et l'équilibreur de charge au niveau d'un proxy Envoy. Le proxy ouvre une deuxième connexion TCP aux backends hébergés dans Google Cloud, sur site ou dans d'autres environnements cloud. Pour plus de cas d'utilisation, consultez la page Présentation de l'équilibreur de charge réseau proxy.

Modes de fonctionnement

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

  • Équilibreur de charge réseau proxy interne régional Il s'agit d'un équilibreur de charge régional mis en œuvre en tant que service géré sur le proxy Envoy Open Source. Le mode régional garantit que tous les clients et backends proviennent d'une région spécifiée, ce qui s'avère utile lorsque vous avez besoin d'une conformité régionale.

  • Équilibreur de charge réseau proxy interne interrégional. Il s'agit d'un équilibreur de charge multirégional mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Le mode interrégional vous permet d'équilibrer la charge du trafic sur les services de backend distribués à l'échelle mondiale avec des backends dans plusieurs régions, y compris la gestion du trafic qui garantit que celui-ci est dirigé vers le backend le plus proche. Cet équilibreur de charge permet également la haute disponibilité. Le positionnement des backends dans plusieurs régions permet d'éviter les défaillances dans une seule région. Si les backends d'une région sont indisponibles, le trafic peut basculer vers une autre région. Les adresses IP des règles de transfert de l'équilibreur de charge sont toujours accessibles dans toutes les régions.

    Le tableau suivant décrit les principales différences entre les modes régional et interrégional :

    Caractéristique Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau proxy interne interrégional
    Adresse IP virtuelle de l'équilibreur de charge. Allouée depuis un sous-réseau dans une région Google Cloud spécifique. Allouée depuis un sous-réseau dans une région Google Cloud spécifique.

    Les adresses IP virtuelles de plusieurs régions peuvent partager le même service de backend global.
    Accès des clients Par défaut, non accessible mondialement.
    Vous pouvez éventuellement activer l'accès mondial.    		 Toujours accessible mondialement. Les clients de n'importe quelle région Google Cloud peuvent envoyer du trafic vers l'équilibreur de charge.
    Backends à équilibrage de charge Backends régionaux.
    L'équilibreur de charge ne peut envoyer du trafic qu'aux backends situés dans la même région que le proxy de l'équilibreur de charge.    		 Backends globaux.
    L'équilibreur de charge peut envoyer du trafic vers des backends dans n'importe quelle région.
    Haute disponibilité et basculement Basculement automatique vers des backends opérationnels dans la même région. Basculement automatique vers des backends opérationnels dans la même région ou dans des régions différentes.

Identifier le mode

Console

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

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

  2. Dans l'onglet Équilibreurs de charge, vous pouvez voir le type, le protocole et la région de l'équilibreur de charge. Si la région est vide, l'équilibreur de charge est en mode interrégional. 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 interne régional Réseau (proxy) Interne Spécifie une région
    Équilibreur de charge réseau proxy interne interrégional Réseau (proxy) Interne

gcloud

Pour déterminer le mode d'un équilibreur de charge, exécutez la commande suivante :

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

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
Équilibreur de charge réseau proxy interne régional INTERNAL_MANAGED Régional
Équilibreur de charge réseau proxy interne interrégional INTERNAL_MANAGED Mondial

Architecture

Le schéma suivant présente les ressources Google Cloud requises pour les équilibreurs de charge réseau proxy internes.

Régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy interne régional au niveau Premium.

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

Interrégional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy interne interrégional de niveau Premium au sein du même réseau VPC. Chaque règle de transfert globale utilise une adresse IP régionale que les clients utilisent pour se connecter.

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

Sous-réseau proxy réservé

Dans le diagramme ci-dessus, 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 du réseau VPC dans lequel vous utilisez un équilibreur de charge réseau proxy interne basé sur Envoy.

Le tableau suivant décrit les exigences relatives aux sous-réseaux proxy réservés pour les équilibreurs de charge réseau proxy internes :

Mode d'équilibreur de charge Valeur de l'option --purpose du sous-réseau proxy réservé
Équilibreur de charge réseau proxy interne régional

REGIONAL_MANAGED_PROXY

Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux

Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent le même sous-réseau proxy réservé.
Équilibreur de charge réseau proxy interne interrégional

GLOBAL_MANAGED_PROXY

Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux

L'équilibreur de charge interrégional basé sur Envoy doit disposer d'un sous-réseau proxy réservé dans chaque région où il est configuré. Les proxys d'équilibreur de charge interrégionaux dans la même région et le même réseau partagent le même sous-réseau proxy réservé.

En outre :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • Les instances de machine virtuelle (VM) de backend ou les points de terminaison de tous les équilibreurs de charge réseau proxy internes d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP d'un équilibreur de charge réseau proxy interne n'est pas située dans le sous-réseau réservé au proxy. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en interne.

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.

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 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 et en créez une autre.

Les clients utilisent l'adresse IP et le port pour se connecter aux proxys Envoy de l'équilibreur de charge. L'adresse IP de la règle de transfert correspond à l'adresse IP de l'équilibreur de charge (parfois appelée adresse IP virtuelle ou VIP). Les clients se connectant à un équilibreur de charge doivent utiliser TCP. Pour obtenir la liste complète des protocoles acceptés, consultez la page Comparaison des fonctionnalités de l'équilibreur de charge.

L'adresse IP interne associée à la règle de transfert peut provenir d'un sous-réseau du même réseau et de la même région que vos backends.

Spécification du port Chaque règle de transfert que vous utilisez dans un équilibreur de charge réseau proxy interne peut faire référence à un port unique compris entre 1 et 65 535. Pour accepter plusieurs ports, vous devez configurer plusieurs règles de transfert.

Le tableau suivant présente les exigences relatives aux règles de transfert pour les équilibreurs de charge réseau proxy internes :

Mode d'équilibreur de charge Règle de transfert, adresse IP et sous-réseau proxy réservé --purpose Routage depuis le client vers l'interface de l'équilibreur de charge
Équilibreur de charge réseau proxy interne régional

Régional forwardingRules

Adresse IP régionale

Schéma d'équilibrage de charge :

INTERNAL_MANAGED

Sous-réseau proxy réservé --purpose :

REGIONAL_MANAGED_PROXY

Adresse IP --purpose :

SHARED_LOADBALANCER_VIP

Vous pouvez activer l'accès mondial pour autoriser les clients de n'importe quelle région à accéder à votre équilibreur de charge. Les backends doivent également se trouver dans la même région que l'équilibreur de charge.
Équilibreur de charge réseau proxy interne interrégional

Global globalForwardingRules

Adresses IP régionales

Schéma d'équilibrage de charge :

INTERNAL_MANAGED

Sous-réseau proxy réservé --purpose :

GLOBAL_MANAGED_PROXY

Adresse IP --purpose :

SHARED_LOADBALANCER_VIP

L'accès mondial est activé par défaut pour permettre aux clients de n'importe quelle région d'accéder à votre équilibreur de charge. Les backends peuvent se trouver dans plusieurs régions.

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 interne interrégional

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

Les adresses IPv4 internes régionales existent toujours dans les réseaux VPC. Lorsque vous créez la règle de transfert, vous devez spécifier le sous-réseau à partir duquel l'adresse IP interne est extraite. Ce sous-réseau doit se trouver dans la même région et le même réseau VPC qu'un sous-réseau proxy réservé. est créé automatiquement. Il existe donc une association de réseau implicite.

Proxy cibles

L'équilibreur de charge réseau proxy interne 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. Le proxy cible achemine les requêtes entrantes directement vers le service de backend de l'équilibreur de charge.

Le tableau suivant présente les API de proxy cibles requises par les équilibreurs de charge réseau proxy internes :

Mode d'équilibreur de charge Proxy cible
Équilibreur de charge réseau proxy interne régional Régional regionTargetTcpProxies
Équilibreur de charge réseau proxy interne interrégional Global targetTcpProxies

Service de backend

Un service de backend dirige le trafic entrant vers un ou plusieurs backends associés. Un backend est soit un groupe d'instances, soit un groupe de points de terminaison du réseau. Le backend contient des informations sur le mode d'équilibrage permettant de définir l'utilisation maximale en fonction des connexions (ou, pour les backends de groupe d'instances uniquement, de l'utilisation).

Chaque équilibreur de charge réseau proxy interne possède une seule ressource de service de backend.

Le tableau suivant spécifie les exigences relatives aux services de backend pour les équilibreurs de charge réseau proxy internes :

Mode d'équilibreur de charge Type de service de backend
Équilibreur de charge réseau proxy interne régional Régional regionBackendServices
Équilibreur de charge réseau proxy interne interrégional Global backendServices

Backends compatibles

Le service de backend accepte les types de backends suivants :

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 interne régional
Points de terminaison pour le type GCE_VM_IP_PORT		 NEG régionaux uniquement Ajouter un NEG Private Service Connect
Équilibreur de charge réseau proxy interne interrégional
Points de terminaison pour le type GCE_VM_IP_PORT		 Ajouter un NEG Private Service Connect

Tous les backends doivent être du même type (groupes d'instances ou NEG). Vous pouvez utiliser simultanément différents types de backends de groupe d'instances ou utiliser différents types de backends NEG, mais vous ne pouvez pas utiliser des backends de groupe d'instances et de NEG ensemble sur le même service de backend.

Vous pouvez combiner des NEG zonaux et des NEG hybrides au sein du même service de backend.

Pour minimiser les interruptions de service pour vos utilisateurs, activez le drainage de connexion sur les services de backend. 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 réduire le plus possible les interruptions de service, consultez la page Activer le drainage de connexion.

Backends et réseaux VPC

  • Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent être situés dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un autre réseau VPC dans le même projet que le service de backend. La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC du backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN, de rattachements de VLAN Cloud Interconnect ou d'un framework Network Connectivity Center.

    Définition du réseau de 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 du réseau de 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 à celui de la règle de transfert.

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

  • Le réseau VPC du backend et celui de la règle de transfert doivent tous deux être des spokes VPC rattachés au 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é dans le réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison de backend.

  • Pour tous les autres types de backend, 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 distribués à nic0. Si vous souhaitez envoyer des paquets à des interfaces non nic0 (vNIC ou interfaces réseau dynamiques), 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 interne, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. 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. Les équilibreurs de charge réseau proxy internes n'acceptent que le protocole TCP pour la communication avec les backends.

Vérification de l'état

Chaque service de backend spécifie une vérification d'état qui vérifie régulièrement que les backends sont disponibles et aptes à recevoir une connexion de l'équilibreur de charge. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter. Les vérifications d'état ne vérifient pas si l'application elle-même fonctionne.

Protocole de vérification d'état

Bien que ce ne soit pas obligatoire et pas toujours possible, il est recommandé d'utiliser une vérification d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état TCP teste plus précisément la connectivité TCP aux backends. Pour obtenir la liste des protocoles de vérification d'état compatibles, consultez la section Vérifications d'état de la page "Comparaison des fonctionnalités de l'équilibreur de charge".

Le tableau suivant spécifie le champ d'application des vérifications d'état compatibles avec les équilibreurs de charge réseau proxy internes dans chaque mode :

Mode d'équilibreur de charge Type de vérification d'état
Équilibreur de charge réseau proxy interne régional Régional regionHealthChecks
Équilibreur de charge réseau proxy interne interrégional Global healthChecks

Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :

Règles de pare-feu

Les équilibreurs de charge réseau proxy internes nécessitent les règles de pare-feu suivantes :

  • Une règle d'autorisation d'entrée qui autorise le trafic provenant des vérifications d'état de Google. Pour en savoir plus sur les plages d'adresses IP de vérification de l'état d'état spécifiques 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.
  • Une règle d'autorisation d'entrée qui autorise le trafic provenant du sous-réseau proxy réservé

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.

Il existe certaines exceptions aux exigences des règles de pare-feu pour ces équilibreurs de charge :

  • Il n'est pas nécessaire d'autoriser le trafic provenant des plages de vérification de l'état de l'état de Google pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez autoriser le trafic provenant des plages de vérification de l'état de l'état Google 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 NEG régionaux : utiliser une passerelle Cloud NAT.

Accès des clients

Les clients peuvent se trouver sur le même réseau ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC.

Pour les équilibreurs de charge réseau proxy internes régionaux, les clients doivent se trouver dans la même région que l'équilibreur de charge par défaut. Vous pouvez activer l'accès mondial pour autoriser les clients de n'importe quelle région à accéder à votre équilibreur de charge.

Pour les équilibreurs de charge réseau proxy internes interrégionaux, l'accès mondial est activé par défaut. Les clients de n'importe quelle région peuvent accéder à votre équilibreur de charge.

Le tableau suivant récapitule l'accès client pour les équilibreurs de charge réseau proxy internes régionaux :

Accès mondial désactivé Accès mondial activé
Les clients doivent se trouver dans la même région que l'équilibreur de charge. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC. Les clients peuvent se trouver dans n'importe quelle région. Ils doivent toujours se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.
Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements doivent se trouver dans la même région que l'équilibreur de charge. Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements peuvent se trouver dans n'importe quelle région.

Architecture du VPC partagé

L'équilibreur de charge réseau proxy interne est compatible 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 interne doit être définie dans le même projet que les backends.

Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, l'adresse IP interne doit être définie dans le même projet de service que les VM de backend et doit faire référence à un sous-réseau du réseau VPC partagé souhaité dans le projet hôte. L'adresse elle-même provient de la plage d'adresses IP principale du sous-réseau référencé.

Une règle de transfert interne doit être définie dans le même projet que les backends.

Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, la règle de transfert interne doit être définie dans le même projet de service que les VM de backend et doit faire référence au même sous-réseau (dans le réseau VPC partagé) que celui auquel l'adresse IP interne associée fait référence.

 Le proxy cible doit être défini dans le même projet que les backends. Dans un scénario de VPC partagé, 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.

Distribution du trafic

Un équilibreur de charge réseau proxy interne distribue le trafic vers ses backends comme suit :

  1. Les connexions provenant d'un seul client sont envoyées à la même zone tant que des backends (groupes d'instances ou NEG) opérationnels dans cette zone sont disponibles et ont une capacité déterminée par le mode d'équilibrage. Pour les équilibreurs de charge réseau proxy internes régionaux, le mode d'équilibrage peut être CONNECTION (backends de groupes d'instances ou de NEG) ou UTILIZATION (backends de groupes d'instances seulement).
  2. Les connexions d'un client sont envoyées au même backend si vous avez configuré l'affinité de session.
  3. Une fois le backend sélectionné, le trafic est réparti entre des instances (dans un groupe d'instances) ou des points de terminaison (dans un NEG), en fonction d'une règle d'équilibrage de charge. Pour en savoir plus sur les algorithmes de règle d'équilibrage de charge compatibles, consultez le paramètre localityLbPolicy dans la documentation de l'API sur le service de backend régional.

Affinité de session

L'affinité de session vous permet de configurer le service de backend de l'équilibreur de charge pour envoyer toutes les requêtes d'un même client au même backend, à condition que le backend soit opérationnel et dispose de la capacité requise.

Les équilibreurs de charge réseau proxy internes offrent les types d'affinité de session suivants :

  • None

    Un paramètre d'affinité de session de NONE ne signifie pas qu'il n'y a pas d'affinité de session. Cela signifie qu'aucune option d'affinité de session n'est explicitement configurée.

    Le hachage est toujours effectué pour sélectionner un backend. Un paramètre d'affinité de session NONE signifie que l'équilibreur de charge utilise un hachage à cinq tuples pour sélectionner un backend. Le hachage à cinq tuples est constitué de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

    La valeur par défaut de l'affinité de session est NONE.

  • Affinité basée sur les adresses IP client

    L'affinité de session Adresse IP client (CLIENT_IP) est un hachage à deux tuples créé à partir des adresses IP source et de destination du paquet. L'affinité basée sur les adresses IP client permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.

    Lorsque vous utilisez l'affinité basée sur les adresses IP client, gardez à l'esprit les points suivants :

    • L'adresse IP de destination du paquet n'est identique à l'adresse IP de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
    • L'adresse IP source du paquet peut ne pas correspondre à une adresse IP associée au client d'origine si le paquet est traité par un système NAT ou proxy intermédiaire avant d'être distribué à un équilibreur de charge Google Cloud . Dans les situations où de nombreux clients partagent la même adresse IP source effective, certaines VM de backend peuvent recevoir plus de connexions ou de requêtes que d'autres.

Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :

  • Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session peut se rompre chaque fois que le nombre de backends actifs et opérationnels change. Pour en savoir plus, consultez la section Perte d'affinité de session.

  • Les valeurs par défaut des options --session-affinity et --subsetting-policy sont NONE, et une seule d'entre elles peut être définie sur une valeur différente.

Perte d'affinité de session

Toutes les options d'affinité de session nécessitent les éléments suivants :

  • L'instance ou le point de terminaison de backend sélectionnés doivent rester configurés en tant que backend. L'affinité de session peut être rompue lorsque l'un des événements suivants se produit :
    • Vous supprimez l'instance sélectionnée de son groupe d'instances.
    • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime l'instance sélectionnée de son groupe d'instances géré.
    • Vous supprimez le point de terminaison sélectionné de son NEG.
    • Vous supprimez du service de backend le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionnés.
  • L'instance ou le point de terminaison de backend sélectionnés doivent rester opérationnels. L'affinité de session peut cesser lorsque l'instance ou le point de terminaison sélectionnés échouent aux vérifications de l'état.
Toutes les options d'affinité de session sont soumises aux exigences supplémentaires suivantes :

  • Le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné ne doit pas être complet, comme défini par sa capacité cible. (Pour les groupes d'instances gérés régionaux, le composant zonal du groupe d'instances contenant l'instance sélectionnée ne doit pas être complet.) L'affinité de session peut être interrompue lorsque le groupe d'instances ou le NEG est plein et que d'autres groupes d'instances ou NEG ne le sont pas. Étant donné que la capacité peut changer de manière imprévisible lorsque vous utilisez le mode d'équilibrage UTILIZATION, vous devez utiliser le mode d'équilibrage RATE ou CONNECTION pour minimiser les situations où l'affinité de session peut être rompue.

  • Le nombre total d'instances ou de points de terminaison de backend configurés doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend configurés change, et l'affinité de session peut être interrompue :

    • Ajouter des instances ou des points de terminaison :

      • Vous ajoutez des instances à un groupe d'instances existant sur le service de backend.
      • L'autoscaling de groupe d'instances géré ajoute des instances à un groupe d'instances géré sur le service de backend.
      • Vous ajoutez des points de terminaison à un NEG existant sur le service de backend.
      • Vous ajoutez des groupes d'instances ou des NEG non vides au service de backend.

    • Supprimer une instance ou un point de terminaison (pas seulement l'instance ou le point de terminaison sélectionné) :

      • Vous supprimez une instance d'un backend de groupe d'instances.
      • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime toute instance d'un backend de groupe d'instances géré.
      • Vous supprimez un point de terminaison d'un backend NEG.
      • Supprimez tout groupe d'instances ou NEG backend existant et non vide du service de backend.

  • Le nombre total d'instances ou de points de terminaison de backend opérationnels doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend opérationnels change, et l'affinité de session peut être rompue :

    • Une instance ou un point de terminaison réussit sa vérification de l'état l'état et passe de l'état "Non opérationnel" à l'état "Opérationnel".
    • Une instance ou un point de terminaison échoue à la vérification de l'état de l'état et passe de l'état "opérationnel" à l'état "non opérationnel" ou "délai avant expiration".

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels.

Le tableau suivant décrit le comportement de basculement des équilibreurs de charge réseau proxy internes :

Mode d'équilibreur de charge Comportement de basculement Comportement lorsque tous les backends ne sont pas opérationnels
Équilibreur de charge réseau proxy interne régional

L'équilibreur de charge implémente un algorithme de basculement souple par zone. Plutôt que d'attendre que tous les backends d'une zone deviennent non opérationnels, l'équilibreur de charge commence à rediriger le trafic vers une zone différente lorsque le ratio entre les backends opérationnels et non opérationnels dans une zone est inférieur à un certain seuil (70 % ; ce seuil n'est pas configurable). Si aucun des backends de toutes les zones n'est opérationnel, l'équilibreur de charge met immédiatement fin à la connexion du client.

Le proxy Envoy envoie le trafic aux backends opérationnels dans une région en fonction de la répartition du trafic configurée.

 Désactivation de la connexion
Équilibreur de charge réseau proxy interne interrégional

Basculement automatique vers des backends opérationnels dans la même région ou dans d'autres régions

Le trafic est réparti entre les backends opérationnels dans plusieurs régions en fonction de la répartition du trafic configurée.

 Désactivation de la connexion

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans Google Kubernetes Engine (GKE), vous pouvez utiliser des NEG zonaux 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 zonal, puis associer le NEG au service de backend afin que l'équilibreur de charge puisse se connecter aux pods.

Documentation GKE associée :

Quotas et limites

Pour en savoir plus sur les quotas et les limites, consultez Quotas et limites.

Limites

  • L'équilibreur de charge réseau proxy interne ne prend pas en charge le trafic IPv6.
  • L'équilibreur de charge réseau proxy interne n'est pas compatible avec les déploiements de VPC partagé pour lesquels l'interface de l'équilibreur de charge se trouve dans un projet hôte ou de service, ou le service de backend et les backends se trouvent dans un autre projet de service (également appelé référencement de services inter-projets).

Étapes suivantes