Présentation de l'équilibrage de charge TCP/UDP interne

L'équilibrage de charge TCP/UDP interne de Google Cloud est un équilibreur de charge régional basé sur la pile de virtualisation de réseau Andromeda.

L'équilibrage de charge TCP/UDP interne répartit le trafic entre les instances de machines virtuelles (VM) internes de la même région sur un réseau de cloud privé virtuel (VPC). Il vous permet d'exécuter et de faire évoluer vos services derrière une adresse IP interne accessible uniquement aux systèmes du même réseau VPC ou des systèmes connectés à votre réseau VPC.

Un service d'équilibrage de charge TCP/UDP interne possède une interface (la règle de transfert) et un backend (le service de backend). Vous pouvez utiliser des groupes d'instances ou des NEG zonaux GCE_VM_IP en tant que backends sur le service de backend. Cet exemple montre les backends de groupe d'instances.

Exemple d'équilibreur de charge TCP/UDP interne
Vue d'ensemble d'un équilibreur de charge TCP/UDP interne (cliquez pour agrandir)

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

Cas d'utilisation

Utilisez l'équilibrage de charge TCP/UDP interne dans les cas suivants :

  • Vous avez besoin d'un équilibreur de charge hautes performances de couche directe 4 pour le trafic TCP ou UDP.
  • Si le trafic diffusé via TLS (SSL) est accepté, le trafic SSL doit être interrompu par vos backends plutôt que par l'équilibreur de charge. L'équilibreur de charge TCP/UDP interne ne peut pas interrompre le trafic SSL.

  • Vous devez transférer les paquets d'origine sans proxy. Par exemple, si vous souhaitez que l'adresse IP source du client soit préservée.

  • Vous disposez d'une configuration existante qui utilise un équilibreur de charge pass-through et vous souhaitez la transférer sans modification.

Les équilibreurs de charge TCP/UDP internes répondent à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux.

Exemples d'accès

Vous pouvez accéder à un équilibreur de charge TCP/UDP interne de votre réseau VPC à partir d'un réseau connecté à l'aide des éléments suivants :

  • Appairage de réseaux VPC
  • Cloud VPN et Cloud Interconnect

Pour obtenir des exemples détaillés, reportez-vous à la section Équilibrage de charge TCP/UDP interne et réseaux connectés.

Exemple de service Web à trois niveaux

Vous pouvez utiliser l'équilibrage de charge TCP/UDP interne avec d'autres équilibreurs de charge. Par exemple, si vous incorporez des équilibreurs de charge HTTP(S) externes, l'équilibreur de charge HTTP(S) externe est le niveau Web et repose sur des services derrière la charge TCP/UDP interne.

Le schéma suivant illustre un exemple de configuration à trois niveaux qui utilise des équilibreurs de charge HTTP(S) externes et des équilibreurs de charge TCP/UDP internes :

Application Web à trois niveaux avec équilibrage de charge HTTP(S) et équilibrage de charge TCP/UDP interne.
Application Web à trois niveaux avec équilibrage de charge HTTP(S) et TCP/UDP interne (cliquez pour agrandir)

Exemple de service Web à trois niveaux avec accès mondial

Si vous activez l'accès mondial, vos VM de niveau Web peuvent se trouver dans une autre région, comme illustré dans le schéma suivant.

Cet exemple d'application multiniveau présente les éléments suivants :

  • Un niveau Web disponible dans le monde entier qui gère l'équilibrage de charge du trafic via l'équilibrage de charge HTTP(S)
  • Un niveau de base de données backend soumis à l'équilibrage de charge interne dans la région us-east1 auquel accède le niveau Web mondial
  • Une VM cliente qui fait partie du niveau Web dans la région europe-west1 qui accède au niveau de base de données soumis à l'équilibrage de charge interne situé dans us-east1
Application Web à trois niveaux avec équilibrage de charge HTTP(S), accès mondial et équilibrage de charge TCP/UDP interne.
Application Web à trois niveaux avec équilibrage de charge HTTP(S), accès mondial et équilibrage de charge TCP/UDP interne (cliquez pour agrandir)

Utiliser des équilibreurs de charge TCP/UDP internes en tant que sauts suivants

Vous pouvez utiliser un équilibreur de charge TCP/UDP interne en tant que passerelle suivante vers laquelle les paquets sont transférés le long de la route menant à leur destination finale. Pour ce faire, vous définissez l'équilibreur de charge comme saut suivant dans une route statique personnalisée.

Un équilibreur de charge TCP/UDP interne déployé en tant que saut suivant dans une route personnalisée traite tout le trafic, quel que soit le protocole (TCP, UDP ou ICMP).

Voici un exemple d'architecture utilisant un équilibreur de charge TCP/UDP interne comme saut suivant vers une passerelle NAT. Vous pouvez acheminer le trafic vers les backends de vos dispositifs virtuels de pare-feu ou de passerelle via un équilibreur de charge TCP/UDP interne.

Cas d'utilisation de NAT (cliquez pour agrandir)
Cas d'utilisation de NAT (cliquez sur l'image pour l'agrandir)

Voici quelques cas d'utilisation supplémentaires :

  • Réseau en étoile : échanger des routes de saut suivant via l'appairage de réseaux VPC. Vous pouvez configurer une topologie en étoile avec vos dispositifs virtuels de pare-feu de saut suivant situés dans le réseau VPC hub. Les routes utilisant l'équilibreur de charge en tant que saut suivant dans le réseau VPC hub peuvent être utilisées dans chaque réseau spoke.
  • Équilibrage de charge sur plusieurs cartes d'interface réseau sur les VM de backend.

Pour en savoir plus sur ces cas d'utilisation, consultez la section Équilibreurs de charge TCP/UDP internes en tant que sauts suivants.

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans GKE, nous vous recommandons d'utiliser le contrôleur de service GKE intégré, qui déploie des équilibreurs de charge Google Cloud pour le compte des utilisateurs de GKE. Il s'agit de la même architecture que l'équilibrage de charge autonome décrit sur cette page, à la différence que son cycle de vie est entièrement automatisé et contrôlé par GKE.

Documentation GKE associée :

Fonctionnement de l'équilibrage de charge TCP/UDP interne

Un équilibreur de charge TCP/UDP interne présente les caractéristiques suivantes :

  • C'est un service géré.
  • Ce n'est pas un proxy.
  • Il est mis en œuvre dans les réseaux virtuels.

Contrairement à un équilibreur de charge proxy, un équilibreur de charge TCP/UDP interne ne met pas fin aux connexions des clients, puis ouvre de nouvelles connexions aux backends. À la place, un équilibreur de charge TCP/UDP interne achemine les connexions d'origine directement des clients vers les backends opérationnels, sans interruption.

  • Il n'y a pas d'appareil intermédiaire ni de point de défaillance unique.
  • Les requêtes des clients destinées à l'adresse IP de l'équilibreur de charge sont directement adressées aux VM de backend.
  • Les réponses provenant des VM backend vont directement aux clients. Elles ne passent pas par l'équilibreur de charge. Les réponses TCP utilisent le retour direct du serveur. Pour plus d'informations, consultez la section Paquets de requêtes et de retours TCP et UDP.

L'équilibreur de charge surveille l'intégrité de la machine virtuelle à l'aide de requêtes de vérification d'état. Pour plus d'informations, consultez la section Vérification d'état.

L'environnement invité Linux de Google Cloud, l'environnement invité Windows de Google Cloud, ou un processus équivalent, configure chaque VM de backend avec l'adresse IP de l'équilibreur de charge. Pour les VM créées à partir d'images Google Cloud, l'agent invité (anciennement "environnement invité Windows" ou "environnement invité Linux") installe la route locale pour l'adresse IP de l'équilibreur de charge. Les instances Google Kubernetes Engine basées sur Container-Optimized OS implémentent ceci en utilisant plutôt iptables.

La mise en réseau virtuelle de Google Cloud gère la diffusion du trafic et le scaling de la manière appropriée.

Protocoles, schéma et champ d'application

Chaque équilibreur de charge TCP/UDP interne gère :

  • Un service de backend avec le schéma d'équilibrage de charge INTERNAL et le protocole TCP ou UDP (mais pas les deux)
  • Les VM de backend spécifiées de l'une des manières suivantes :
  • Une ou plusieurs règles de transfert, chacune utilisant le protocole TCP ou UDP, correspondant au protocole du service de backend
  • Chaque règle de transfert avec sa propre adresse IP unique ou plusieurs règles de transfert partageant une adresse IP commune
  • Chaque règle de transfert avec un maximum de cinq ports ou tous les ports
  • Si l'accès mondial est activé, les clients peuvent se trouver dans n'importe quelle région.
  • Si l'accès mondial est désactivé, les clients doivent se trouver dans la même région que l'équilibreur de charge.

Un équilibreur de charge TCP/UDP interne ne gère pas :

Accès des clients

La VM cliente doit se trouver sur le même réseau ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC. Vous pouvez activer l'accès mondial pour autoriser les instances de VM clientes de n'importe quelle région à accéder à votre équilibreur de charge TCP/UDP interne.

Le tableau suivant récapitule l'accès des clients.

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 d'interconnexion (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 d'interconnexion (VLAN). Ces tunnels ou rattachements peuvent se trouver dans n'importe quelle région.

Adresses IP pour les paquets de requêtes et de retours

Lorsqu'un système client envoie un paquet TCP ou UDP à un équilibreur de charge TCP/UDP interne, la source et la destination du paquet sont les suivantes :

  • Source : l'adresse IP interne principale du client ou l'adresse IP de l'une des plages d'adresses IP d'alias du client.
  • Destination : l'adresse IP de la règle de transfert de l'équilibreur de charge.

Par conséquent, les paquets arrivent sur les VM de backend de l'équilibreur de charge avec l'adresse IP de destination de l'équilibreur de charge lui-même. Ce type d'équilibreur de charge n'est pas un proxy, et ce comportement est normal. Par conséquent, le logiciel s'exécutant sur les VM de backend de l'équilibreur de charge doit effectuer les opérations suivantes :

  • Écouter (être associé à) l'adresse IP de l'équilibreur de charge ou toute adresse IP (0.0.0.0 ou ::)
  • Écouter (être associé à) un port inclus dans la règle de transfert de l'équilibreur de charge

Les paquets de retour sont envoyés directement aux VM de backend de l'équilibreur de charge au client. Les adresses IP source et de destination du paquet de retour dépendent du protocole :

  • TCP est orienté connexion, et les équilibreurs de charge TCP/UDP internes utilisent le retour direct du serveur. Cela signifie que les paquets de réponses sont envoyés à partir de l'adresse IP de la règle de transfert de l'équilibreur de charge.
  • En revanche, UDP est sans connexion. Par défaut, les paquets de retours sont envoyés à partir de l'adresse IP interne principale de l'interface réseau de l'instance de backend. Toutefois, vous pouvez modifier ce comportement. Par exemple, la configuration d'un serveur UDP pour l'associer à l'adresse IP de la règle de transfert entraîne l'envoi de paquets de réponses à partir de l'adresse IP de la règle de transfert.

Le tableau suivant résume les sources et les destinations des paquets de réponses :

Type de trafic Source Destination
TCP Adresse IP de la règle de transfert de l'équilibreur de charge Source du paquet à l'origine de la requête
UDP Dépend du logiciel serveur UDP Source du paquet à l'origine de la requête

Architecture

Un équilibreur de charge TCP/UDP interne avec plusieurs backends distribue les connexions entre tous les backends. Pour en savoir plus sur la méthode de distribution et ses options de configuration, consultez la section Distribution du trafic.

Vous pouvez utiliser des groupes d'instances ou des NEG zonaux, mais pas une combinaison des deux, en tant que backends pour un équilibreur de charge TCP/UDP interne :

  • Si vous choisissez des groupes d'instances, vous pouvez utiliser des groupes d'instances non gérés, des groupes d'instances gérés zonaux, des groupes d'instances gérés régionaux ou une combinaison de ces types de groupes d'instances.
  • Si vous choisissez des NEG zonaux, vous devez utiliser des NEG zonaux GCE_VM_IP.

La section Haute disponibilité décrit comment concevoir un équilibreur de charge interne qui ne dépend pas d'une seule zone.

Les instances qui participent en tant que VM de backend pour les équilibreurs de charge TCP/UDP internes doivent exécuter l'environnement invité Linux ou Windows, ou d'autres processus appropriés présentant des fonctionnalités équivalentes. Cet environnement invité doit pouvoir contacter le serveur de métadonnées (metadata.google.internal, 169.254.169.254) pour lire les métadonnées d'instance afin de générer des routes locales pour accepter le trafic envoyé à l'adresse IP interne de l'équilibreur de charge.

Ce schéma illustre la distribution du trafic entre les VM situées dans deux groupes d'instances distincts. Le trafic envoyé depuis l'instance client vers l'adresse IP de l'équilibreur de charge (10.10.10.9) est réparti entre les VM backend dans l'un des deux groupes d'instances. Les réponses envoyées par l'une des VM backend de diffusion sont directement envoyées à la VM cliente.

Vous pouvez utiliser l'équilibrage de charge TCP/UDP interne avec un réseau VPC en mode personnalisé ou en mode automatique. Vous pouvez également créer des équilibreurs de charge TCP/UDP internes avec un ancien réseau.

Un équilibreur de charge TCP/UDP interne est constitué des composants Google Cloud suivants.

Composant Usage Exigences
Adresse IP interne Il s'agit de l'adresse de l'équilibreur de charge. L'adresse IP interne doit se situer dans le même sous-réseau que la règle de transfert interne. Le sous-réseau doit se trouver dans la même région et sur le même réseau VPC que le service de backend.
Règle de transfert interne Une règle de transfert interne, associée à l'adresse IP interne, constitue l'interface de l'équilibreur de charge. Elle définit le protocole et les ports acceptés par l'équilibreur de charge, et dirige le trafic vers un service de backend régional interne. Les règles de transfert des équilibreurs de charge TCP/UDP internes doivent :
• avoir un schéma d'équilibrage de charge (load-balancing-scheme) défini sur INTERNAL ;
• utiliser le protocole IP (ip-protocol) TCP ou UDP, selon le protocole (protocol) du service de backend ;
• référencer un sous-réseau (subnet) dans le même réseau VPC et dans la même région que le service de backend.
Service de backend régional interne Le service de backend régional interne définit le protocole utilisé pour communiquer avec les backends et spécifie une vérification d'état. Les backends peuvent être des groupes d'instances non gérés, des groupes d'instances gérés zonaux, des groupes d'instances gérés régionaux ou des NEG zonaux avec des points de terminaison GCE_VM_IP. Le service de backend doit :
• avoir un schéma d'équilibrage de charge (load-balancing-scheme) défini sur INTERNAL ;
• utiliser le protocole (protocol) TCP ou UDP, selon le protocole IP (ip-protocol) de la règle de transfert ;
• être associé à une vérification d'état ;
• être associé à une région. La règle de transfert et tous les backends doivent se trouver dans la même région que le service de backend
• être associé à un seul réseau VPC ; Lorsqu'il n'est pas spécifié, le réseau est déduit en fonction du réseau utilisé par l'interface réseau par défaut de chaque VM de backend (nic0)).

Bien que le service de backend ne soit pas lié à un sous-réseau spécifique, le sous-réseau de la règle de transfert doit se trouver sur le même réseau VPC que le service de backend.
Contrôle d'état Chaque service de backend doit être associé à une vérification d'état. La vérification de l'état définit les paramètres qui permettent à Google Cloud de déterminer si les backends qu'il gère sont autorisés à recevoir du trafic. Seules les VM backend opérationnelles reçoivent le trafic envoyé par les VM clientes à l'adresse IP de l'équilibreur de charge.
Même si la règle de transfert et le service de backend peuvent utiliser TCP ou UDP, Google Cloud n'effectue pas de vérification d'état pour le trafic UDP. Pour en savoir plus, consultez la section Vérifications d'état et trafic UDP.

Adresse IP interne

L'équilibrage de charge TCP/UDP interne utilise une adresse IPv4 interne de la plage d'adresses IP principale du sous-réseau que vous sélectionnez lorsque vous créez la règle de transfert interne. L'adresse IP ne peut pas provenir d'une plage d'adresses IP secondaire du sous-réseau.

Vous spécifiez l'adresse IP d'un équilibreur de charge TCP/UDP interne lors de la création de la règle de transfert. Vous pouvez choisir de recevoir une adresse IP éphémère ou d'utiliser une adresse IP réservée.

Règles de pare-feu

Votre équilibreur de charge TCP/UDP interne nécessite les règles de pare-feu suivantes :

L'exemple de la section Configurer des règles de pare-feu montre comment créer les deux.

Règles de transfert

Une règle de transfert spécifie le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic. Les équilibreurs de charge TCP/UDP internes n'étant pas des proxys, ils transmettent le trafic aux backends sur le même protocole et le même port.

Un équilibreur de charge TCP/UDP interne nécessite au moins une règle de transfert interne. Vous pouvez définir plusieurs règles de transfert pour le même équilibreur de charge.

La règle de transfert doit référencer un sous-réseau spécifique sur le même réseau VPC et dans la même région que les composants backend de l'équilibreur de charge. Cette exigence a les implications suivantes :

  • Le sous-réseau que vous spécifiez pour la règle de transfert n'a pas besoin d'être identique à l'un des sous-réseaux utilisés par les VM de backend. Toutefois, le sous-réseau doit se trouver dans la même région que la règle de transfert.
  • Lorsque vous créez une règle de transfert interne, Google Cloud choisit une adresse IP régionale interne provenant de la plage d'adresses IP principale du sous-réseau que vous sélectionnez. Vous pouvez également spécifier une adresse IP interne dans la plage d'adresses IP principale du sous-réseau.

Règles de transfert et accès mondial

Les règles de transfert d'un équilibreur de charge TCP/UDP interne sont régionales, même lorsque l'accès mondial est activé. Après avoir activé l'accès mondial, l'option allowGlobalAccess de la règle de transfert régionale interne est définie sur true.

Règles de transfert et spécifications de ports

Lorsque vous créez une règle de transfert interne, vous devez sélectionner l'une des spécifications de port suivantes :

  • Spécifiez au moins un port et jusqu'à cinq ports par leur numéro.
  • Spécifiez ALL pour transférer le trafic sur tous les ports.

Une règle de transfert interne qui accepte tous les ports TCP ou tous les ports UDP permet aux VM de backend d'exécuter plusieurs applications, chacune sur son propre port. Le trafic envoyé à un port donné est transmis à l'application correspondante, et toutes les applications utilisent la même adresse IP.

Lorsque vous devez transférer le trafic sur plus de cinq ports spécifiques, associez les règles de pare-feu aux règles de transfert. Lorsque vous créez la règle de transfert, spécifiez tous les ports, puis créez des règles de pare-feu d'entrée allow qui autorisent uniquement le trafic vers les ports souhaités. Appliquez les règles de pare-feu aux VM de backend.

Vous ne pouvez pas modifier une règle de transfert après l'avoir créée. Si vous devez modifier les ports spécifiés ou l'adresse IP interne d'une règle de transfert interne, vous devez la supprimer et la recréer.

Plusieurs règles de transfert pour un même service de backend

Vous pouvez configurer plusieurs règles de transfert internes qui font toutes référence au même service de backend interne. Un équilibreur de charge TCP/UDP interne nécessite au moins une règle de transfert interne.

La configuration de plusieurs règles de transfert pour le même service de backend vous permet d'effectuer les opérations suivantes, en utilisant TCP ou UDP (mais pas les deux) :

  • Attribuer plusieurs adresses IP à l'équilibreur de charge. Vous pouvez créer plusieurs règles de transfert, chacune utilisant une adresse IP unique. Chaque règle de transfert peut spécifier tous les ports ou un ensemble de cinq ports maximum.

  • Attribuer à l'équilibreur de charge un ensemble spécifique de ports utilisant la même adresse IP. Vous pouvez créer plusieurs règles de transfert partageant la même adresse IP, chaque règle de transfert utilisant un ensemble spécifique de cinq ports maximum. Il s'agit d'une alternative à la configuration d'une règle de transfert unique qui spécifie tous les ports.

Pour plus d'informations sur les scénarios impliquant deux règles de transfert internes minimum ou une adresse IP interne commune, consultez la page Règles de transfert multiples avec la même adresse IP.

Lorsque vous utilisez plusieurs règles de transfert internes, assurez-vous de configurer le logiciel exécuté sur vos VM de backend de sorte qu'il s'associe à toutes les adresses IP des règles de transfert ou à n'importe quelle adresse (0.0.0.0/0). L'adresse IP de destination d'un paquet livré via l'équilibreur de charge est l'adresse IP interne associée à la règle de transfert interne correspondante. Pour plus d'informations, consultez la section Paquets de requêtes et de retours TCP et UDP.

Service backend

Chaque équilibreur de charge TCP/UDP interne dispose d'un service de backend interne régional qui définit les paramètres et le comportement des backends. Le nom du service de backend est le nom de l'équilibreur de charge TCP/UDP interne affiché dans Google Cloud Console.

Chaque service de backend définit les paramètres de backend suivants :

  • Protocole. Un service de backend accepte le trafic TCP ou UDP, mais pas les deux, sur les ports spécifiés par une ou plusieurs règles de transfert internes. Le service de backend permet d'acheminer le trafic vers les VM de backend sur les ports auxquels le trafic a été envoyé. Le protocole du service de backend doit correspondre au protocole de la règle de transfert.

  • Distribution du trafic. Un service de backend permet de distribuer le trafic en fonction d'une affinité de session configurable.

  • Vérification de l'état. Un service de backend doit être associé à une vérification d'état.

Chaque service de backend fonctionne dans une seule région et distribue le trafic pour les VM de backend sur un seul réseau VPC :

Services de backend et interfaces réseau

Chaque service de backend fonctionne sur un seul réseau VPC et une seule région Google Cloud. Le réseau VPC peut être implicite ou explicitement spécifié avec l'option --network dans la commande gcloud compute backend-services create.

Lorsqu'il est explicitement spécifié, l'option --network du réseau VPC du service de backend identifie l'interface réseau de chaque VM de backend dans laquelle le trafic est soumis à l'équilibrage de charge. Chaque VM de backend doit avoir une interface réseau sur le réseau VPC spécifié. Dans ce cas, les identifiants d'interface réseau (nic0 à nic7) peuvent être différents entre les VM de backend. Selon le type de backend, d'autres points doivent également être pris en compte :

  • Backends de groupes d'instances :

    • Différentes VM de backend dans le même groupe d'instances non géré peuvent utiliser des identifiants d'interface différents si chaque VM possède une interface sur le réseau VPC spécifié.
    • L'identifiant d'interface n'a pas besoin d'être identique dans tous les groupes d'instances du backend. Il peut être nic0 pour les VM de backend dans un groupe d'instances de backend et nic2 pour les VM de backend dans un autre groupe d'instances de backend.
  • Backends de NEG zonaux :

    • Différents points de terminaison dans le même NEG zonal GCE_VM_IP peuvent utiliser des identifiants d'interface différents.
    • Si vous spécifiez à la fois un nom de VM et une adresse IP lors de l'ajout d'un point de terminaison au NEG zonal, Google Cloud valide que le point de terminaison est une adresse IP interne principale de la carte d'interface réseau de la VM située dans le réseau VPC sélectionné du NEG. Les validations qui ont échoué présentent des messages d'erreur indiquant que le point de terminaison ne correspond pas à l'adresse IP principale de la carte d'interface réseau de la VM du réseau du NEG.
    • Si vous ne spécifiez pas d'adresses IP lors de l'ajout de points de terminaison au NEG zonal, Google Cloud sélectionne l'adresse IP interne principale de la carte d'interface réseau dans le réseau VPC sélectionné du NEG.

Si vous n'incluez pas l'option --network lorsque vous créez le service de backend, celui-ci choisit un réseau comme suit :

  • Backends de groupes d'instances :

    • Le service de backend choisit un réseau en fonction du réseau de l'interface réseau initiale (ou unique) utilisée par toutes les VM de backend. Cela signifie que nic0 doit se trouver sur le même réseau VPC pour toutes les VM de tous les groupes d'instances de backend.
  • Backends de NEG zonaux :

    • Si le service de backend est associé à une règle de transfert, le réseau de la règle de transfert est utilisé.
    • En l'absence de règle de transfert, le réseau du NEG zonal associé est sélectionné. Tous les NEG doivent faire référence au même réseau.

Contrôle d'état

Le service de backend de l'équilibreur de charge doit être associé à une vérification d'état globale ou régionale. Des routes spéciales en dehors du réseau VPC facilitent les communications entre les systèmes de vérification d'état et les backends.

Vous pouvez utiliser une vérification d'état existante ou en définir une nouvelle. Les équilibreurs de charge TCP/UDP internes utilisent l'état de la vérification pour déterminer comment router les nouvelles connexions, comme décrit dans la section Distribution du trafic.

Vous pouvez utiliser l'un des protocoles de vérification d'état suivants (le protocole de la vérification d'état ne doit pas nécessairement correspondre au protocole de l'équilibreur de charge) :

  • HTTP, HTTPS ou HTTP/2. Si vos VM de backend acheminent du trafic via HTTP, HTTPS ou HTTP/2, il est préférable d'utiliser une vérification d'état correspondant au protocole, car les vérifications d'état basées sur HTTP offrent des options adaptées à ce protocole. Notez que le fait de diffuser du trafic de type HTTP via un équilibreur de charge TCP/UDP interne signifie que le protocole de l'équilibreur de charge est TCP.
  • SSL ou TCP. Si vos VM de backend ne diffusent pas de trafic de type HTTP, vous devez utiliser une vérification d'état SSL ou TCP.

Quel que soit le type de vérification d'état que vous créez, Google Cloud envoie des tests de vérification d'état à l'adresse IP de la règle de transfert de l'équilibreur de charge TCP/UDP interne, à l'interface réseau dans lVPC sélectionné par le service de backend de l'équilibreur de charge. Ce procédé simule la distribution du trafic à équilibrage de charge. Le logiciel s'exécutant sur vos VM backend doit répondre au trafic à équilibrage de charge et aux vérifications d'état envoyées à l'adresse IP de l'équilibreur de charge. Pour en savoir plus, consultez la section Destination des paquets associés à la vérification d'état.

Vérifications d'état et trafic UDP

Google Cloud n'offre pas de vérification d'état qui utilise le protocole UDP. Lorsque vous utilisez l'équilibrage de charge TCP/UDP interne avec du trafic UDP, vous devez exécuter un service basé sur TCP sur vos VM backend pour fournir des informations de vérification d'état.

Dans cette configuration, les requêtes client sont soumises à l'équilibrage de charge à l'aide du protocole UDP, et un service TCP est utilisé pour fournir des informations aux vérifications d'état de Google Cloud. Par exemple, vous pouvez exécuter un simple serveur HTTP sur chaque VM de backend qui renvoie une réponse HTTP 200 à Google Cloud. Dans cet exemple, vous devez utiliser votre propre logique s'exécutant sur la VM de backend pour vous assurer que le serveur HTTP renvoie la réponse 200 uniquement si le service UDP est correctement configuré et exécuté.

Architecture à haute disponibilité

L'équilibreur de charge TCP/UDP interne est hautement disponible par nature. Aucune étape particulière ne permet de rendre l'équilibreur de charge hautement disponible, car le mécanisme ne repose pas sur un seul appareil ou une seule instance de VM.

Pour vous assurer que vos instances de VM de backend sont déployées dans plusieurs zones, suivez les recommandations suivantes :

  • Utilisez des groupes d'instances gérés régionaux si vous pouvez déployer votre logiciel à l'aide de modèles d'instance. Les groupes d'instances gérés régionaux distribuent automatiquement le trafic entre plusieurs zones, offrant ainsi la meilleure option pour éviter les problèmes potentiels dans une zone donnée.

  • Si vous exploitez des groupes d'instances gérés ou non gérés zonaux, utilisez plusieurs groupes d'instances dans des zones différentes (de la même région) pour le même service de backend. L'utilisation de plusieurs zones offre une protection contre les problèmes potentiels dans une zone donnée.

Architecture du VPC partagé

Le tableau suivant récapitule la configuration requise pour l'équilibrage de charge TCP/UDP interne dans un réseau VPC partagé. Vous trouverez un exemple sur la création d'un équilibreur de charge TCP/UDP interne sur la page Provisionner un VPC partagé.

Adresse IP Règle de transfert Composants backend
Une adresse IP interne doit être définie dans le même projet que les VM de backend.

Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, l'adresse IP interne de Google Cloud 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é.

Si vous créez une adresse IP interne dans un projet de service et que le sous-réseau d'adresses IP se trouve dans le réseau VPC du projet de service, votre équilibreur de charge TCP/UDP interne est local au projet de service. Il n'est associé à aucun projet hôte du réseau VPC partagé.
Une règle de transfert interne doit être définie dans le même projet que les VM de backend.

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 backend et elle 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.

Si vous créez une règle de transfert interne dans un projet de service et que le sous-réseau de la règle de transfert se trouve dans le réseau VPC du projet de service, votre équilibreur de charge TCP/UDP interne est local au projet de service. Il n'est associé à aucun projet hôte du réseau VPC partagé.
Dans un scénario de VPC partagé, les VM backend sont 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

La façon dont un équilibreur de charge TCP/UDP interne distribue les nouvelles connexions dépend du fait que vous ayez ou non configuré le basculement :

  • Si vous n'avez pas configuré le basculement, un équilibreur de charge TCP/UDP interne distribue les nouvelles connexions à ses VM de backend opérationnelles si au moins l'une d'entre elles est opérationnelle. Lorsqu'aucune VM de backend n'est opérationnelle, l'équilibreur de charge distribue les nouvelles connexions entre tous les backends, en dernier recours. Dans ce cas, l'équilibreur de charge achemine chaque nouvelle connexion vers une VM de backend non opérationnelle.

  • Si vous avez configuré le basculement, un équilibreur de charge TCP/UDP distribue les nouvelles connexions entre les VM de son pool actif, selon une stratégie de basculement que vous configurez. Lorsqu'aucune VM de backend n'est opérationnelle, vous pouvez choisir l'un des comportements suivants :

    • (Par défaut) L'équilibreur de charge ne distribue le trafic que vers les VM principales. Cette opération est réalisée en dernier recours. Les VM de secours sont exclues de cette distribution des connexions de dernier recours.
    • L'équilibreur de charge est configuré pour abandonner le trafic.

La méthode de distribution des nouvelles connexions dépend du paramètre d'affinité de session de l'équilibreur de charge.

La vérification d'état contrôle la distribution des nouvelles connexions. Une session TCP établie persiste sur une VM de backend non opérationnelle si celle-ci gère toujours la connexion.

Options d'affinité de session

L'affinité de session contrôle la distribution des nouvelles connexions des clients aux VM de backend de l'équilibreur de charge. Vous définissez l'affinité de session lorsque vos VM de backend doivent suivre les informations d'état de leurs clients. Il s'agit d'une exigence courante pour les applications devant maintenir un état, y compris les applications Web.

L'affinité de session fonctionne de la manière la plus optimale possible.

Les équilibreurs de charge TCP/UDP internes sont compatibles avec les options d'affinité de session suivantes, que vous spécifiez pour l'ensemble du service de backend interne, et non pour chaque groupe d'instances :

Type Signification Protocoles acceptés
Aucun Il s'agit du paramètre par défaut.

Son fonctionnement est identique à celui de l'adresse IP, du protocole et du port du client.

Trafic TCP et UDP
IP client Les connexions provenant de la même adresse IP source et de destination sont dirigées vers la même instance en fonction d'un hachage à deux tuples des éléments suivants :
  • Adresse source dans le paquet IP
  • Adresse de destination dans le paquet IP
Trafic TCP et UDP
IP client et protocole Les connexions provenant de la même adresse IP source et de destination et utilisant le même protocole sont dirigées vers la même instance en fonction d'un hachage à trois tuples des éléments suivants :
  • Adresse source dans le paquet IP
  • Adresse de destination dans le paquet IP
  • le protocole (TCP ou UDP).
Trafic TCP et UDP
Adresse IP client, protocole et port Les paquets sont envoyés aux backends à l'aide d'un hachage créé à partir des informations suivantes :
  • Adresse IP source du paquet
  • Port source du paquet (le cas échéant)
  • Adresse IP de destination du paquet
  • Port de destination du paquet (le cas échéant)
  • protocole
L'adresse source, l'adresse de destination et les informations de protocole sont obtenues à partir de l'en-tête du paquet IP. Le port source et le port de destination, s'ils sont présents, sont obtenus à partir de l'en-tête de couche 4.
Par exemple, les segments TCP et les datagrammes UDP non fragmentés incluent toujours un port source et un port de destination. Les datagrammes UDP fragmentés n'incluent pas d'informations sur le port.
En l'absence d'informations sur le port, le hachage à cinq tuples est en réalité un hachage à trois tuples.
Trafic TCP uniquement

L'adresse IP de destination est l'adresse IP de la règle de transfert de l'équilibreur de charge, sauf si des paquets sont envoyés à l'équilibreur de charge en raison d'une route statique personnalisée. Si un équilibreur de charge TCP/UDP interne est utilisé comme saut suivant pour une route, consultez la section suivante de cette page : Affinité de session et équilibreur de charge TCP/UDP interne comme saut suivant.

Affinité de session et équilibreur de charge TCP/UDP interne comme saut suivant

Quelle que soit l'option d'affinité de session que vous choisissez, Google Cloud utilise la destination du paquet. Lorsque vous envoyez un paquet directement à l'équilibreur de charge, la destination du paquet correspond à l'adresse IP de la règle de transfert de l'équilibreur de charge.

Toutefois, lorsque vous utilisez un équilibreur de charge TCP/UDP interne comme saut suivant pour une route statique personnalisée, la destination du paquet n'est probablement pas l'adresse IP de la règle de transfert. Pour les paquets dont la destination se trouve dans la plage de destination de la route, la route les dirige vers l'équilibreur de charge.

Pour utiliser un équilibreur de charge TCP/UDP interne comme saut suivant pour une route statique personnalisée, consultez la section Équilibreurs de charge TCP/UDP internes en tant que sauts suivants.

Affinité de session et vérification d'état

Modifier l'état des VM backend peut entraîner une perte d'affinité de session. Par exemple, si une VM de backend n'est plus opérationnelle et qu'il y a au moins une autre VM de backend opérationnelle, un équilibreur de charge TCP/UDP interne ne distribue pas de nouvelles connexions à la VM non opérationnelle. Si un client a des affinités de session avec cette VM non opérationnelle, il est redirigé vers la VM de backend opérationnelle, perdant ainsi son affinité de session.

Tester les connexions à partir d'un seul client

Lorsque vous testez des connexions à l'adresse IP d'un équilibreur de charge TCP/UDP interne à partir d'un seul système client, gardez les points suivants à l'esprit :

  • Si le système client n'est pas une VM soumise à l'équilibrage de charge (c'est-à-dire, si ce n'est pas une VM de backend), les nouvelles connexions sont distribuées aux VM de backend opérationnelles de l'équilibreur de charge. Toutefois, comme toutes les options d'affinité de session dépendent au moins de l'adresse IP du système client, les connexions du même client peuvent être distribuées à la même VM de backend plus souvent que prévu.

    En pratique, cela signifie que vous ne pouvez pas surveiller précisément la distribution du trafic via un équilibreur de charge TCP/UDP interne en vous y connectant à partir d'un seul client. Le nombre de clients requis pour surveiller la distribution du trafic dépend du type d'équilibreur de charge, du type de trafic et du nombre de backends opérationnels.

  • Si la VM cliente est une VM de backend de l'équilibreur de charge, les connexions envoyées à l'adresse IP de la règle de transfert de l'équilibreur de charge sont toujours traitées par la VM cliente/VM de backend. Cela se produit que la VM de backend soit opérationnelle ou non, et pour tout le trafic envoyé à l'adresse IP de l'équilibreur de charge, pas uniquement pour le trafic sur le protocole et les ports spécifiés dans la règle de transfert interne de l'équilibreur de charge.

    Pour en savoir plus, consultez la section Envoyer des requêtes à partir de VM soumises à l'équilibrage de charge.

Basculement

L'équilibrage de charge TCP/UDP interne vous permet de désigner certains backends en tant que backends de basculement. Ces backends ne sont utilisés que lorsque le nombre de VM opérationnelles dans les groupes d'instances backend principales est inférieur à un seuil configurable. Par défaut, si aucune VM principale ni aucune VM de basculement ne sont opérationnelles, Google Cloud ne distribue les nouvelles connexions qu'entre toutes les VM principales en dernier recours.

Lorsque vous ajoutez un backend au service de backend d'un équilibreur de charge TCP/UDP interne, ce backend est par défaut un backend principal. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend de l'équilibreur de charge, ou en modifiant le service de backend ultérieurement.

Pour obtenir une présentation détaillée du concept de basculement dans l'équilibrage de charge TCP/UDP interne, consultez la page Présentation du basculement pour l'équilibrage de charge TCP/UDP interne.

Sous-paramètre

Le sous-paramètre des équilibreurs de charge TCP/UDP internes vous permet de faire évoluer votre équilibreur de charge TCP/UDP interne de façon à accepter un plus grand nombre d'instances de VM de backend par service de backend interne.

Pour en savoir plus sur la façon dont le sous-paramètre affecte cette limite, consultez la section Services de backend de la page "Quotas et limites des ressources d'équilibrage de charge".

Par défaut, le sous-paramètre est désactivé, ce qui limite le service de backend à distribuer jusqu'à 250 instances backend ou points de terminaison. Si votre service de backend doit accepter plus de 250 backends, vous pouvez activer le sous-paramètre. Lorsque le sous-paramètre est activé, un sous-ensemble d'instances backend est sélectionné pour chaque connexion client.

Le schéma suivant illustre un modèle de réduction de la capacité qui montre la différence entre ces deux modes de fonctionnement.

Comparaison d'un équilibreur de charge TCP/UDP interne avec et sans sous-paramètre (cliquez pour agrandir)
Comparaison d'un équilibreur de charge TCP/UDP interne avec et sans sous-paramètre (cliquez pour agrandir)

Sans sous-paramètre, l'ensemble complet de backends opérationnels est mieux utilisé et les nouvelles connexions clientes sont distribués entre tous les backends opérationnels selon la répartition du trafic. Le sous-paramètre impose des restrictions d'équilibrage de charge, mais autorise l'équilibreur de charge à accepter plus de 250 backends.

Pour obtenir des instructions de configuration, consultez la section Sous-paramètre.

Mises en garde concernant le sous-paramètre

  • Lorsque le sous-paramètre est activé, tous les backends ne reçoivent pas le trafic d'un expéditeur donné, même si le nombre de backends est faible.
  • Pour connaître le nombre maximal d'instances de backend autorisé lorsque le sous-paramètre est activé, consultez la page Quotas.
  • Seule l'affinité de session à cinq tuples est compatible avec le sous-paramètre.
  • La mise en miroir de paquets n'est pas compatible avec le sous-paramètre.
  • L'activation, puis la désactivation du sous-paramètre entraîne l'interruption des connexions existantes.
  • Lorsque vous utilisez un sous-paramètre via Cloud VPN ou Cloud Interconnect et qu'il n'y a pas assez de passerelles VPN (< 10) côté Google Cloud, vous n'utilisez probablement que le sous-ensemble de backends de l'équilibreur de charge. Si les paquets d'une seule connexion TCP redirigent vers une autre passerelle VPN, vous subirez des réinitialisations de connexion. Il doit y avoir suffisamment de passerelles VPN sur Google Cloud pour utiliser tous les pools de backend. Si le trafic d'une seule connexion TCP redirige vers une autre passerelle VPN, vous subirez des réinitialisations de connexion.

Limites

  • Les équilibreurs de charge TCP/UDP internes ne sont pas compatibles avec l'appairage de réseaux VPC. Vous devez créer les règles de transfert et les backends de l'équilibreur de charge dans le même réseau VPC.

Quotas et limites

Pour en savoir plus sur les quotas et les limites, consultez la page Quotas et limites des ressources d'équilibrage de charge.

Étape suivante