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 qui vous permet d'exécuter et d'adapter vos services derrière une adresse IP d'équilibrage de charge interne accessible uniquement sur vos instances de VM internes.

L'équilibrage de charge TCP/UDP interne distribue le trafic entre les instances de VM dans la même région d'un réseau VPC en utilisant une adresse IP interne.

Comme décrit dans le schéma général ci-dessous, 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 et les groupes d'instances).

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

Pour plus d'informations sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

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)
  • Des groupes d'instances backend gérés et non gérés situés dans une région et un réseau VPC
  • 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

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

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.

Cas d'utilisation

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 intégrez des équilibreurs de charge HTTP(S) externes, l'équilibreur de charge externe correspond au niveau Web et repose sur les services derrière l'équilibreur de charge 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 (cliquez pour agrandir)
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 (cliquez pour agrandir)
Application Web à trois niveaux avec équilibrage de charge HTTP(S), accès mondial et équilibrage de charge TCP/UDP interne (cliquez pour agrandir)

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.

Autres cas d'utilisation

  • Utilisation d'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 passerelle ou de pare-feu via un équilibreur de charge TCP/UDP interne.
  • 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.

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 basé sur un appareil ou une instance de VM, un équilibreur de charge TCP/UDP interne ne met pas fin aux connexions des clients. Au lieu d'envoyer le trafic à un équilibreur de charge, puis aux backends, les clients l'envoient directement aux backends :

  • 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. La mise en réseau virtuelle de Google Cloud gère la diffusion du trafic en procédant au scaling approprié.

Architecture

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

Vous pouvez utiliser n'importe quel type de groupe d'instances (groupes d'instances non gérés, groupes d'instances gérés zonaux ou groupes d'instances gérés régionaux) en tant que backends pour votre équilibreur de charge, sauf des groupes de points de terminaison du réseau (NEG).

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.

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.

Composants

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 (groupes d'instances) et spécifie une vérification d'état. Les backends peuvent être des groupes d'instances non gérés, des groupes d'instances zonaux gérés ou des groupes d'instances régionaux gérés. 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égion de la règle de transfert et de tous les groupes d'instances de backend doit être identique à celle du 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.
Vérification 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 opérationnelles des groupes d'instances de backend 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 :

  • Régionalité. Les backends sont des groupes d'instances dans la même région que le service de backend (et la règle de transfert). Les backends peuvent être des groupes d'instances non gérés, des groupes d'instances gérés zonaux ou des groupes d'instances gérés régionaux.

  • Réseau VPC. Toutes les VM de backend doivent avoir une interface réseau sur le réseau VPC associé au service de backend. Vous pouvez soit spécifier explicitement le réseau d'un service de backend, soit utiliser un réseau implicite. Dans les deux cas, le sous-réseau de chaque règle de transfert interne doit se trouver sur le réseau VPC du service de backend.

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. Exemple :

    • 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.
  • Si vous n'incluez pas l'option --network lorsque vous créez le service de backend, ce dernier 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.

Contrôle d'état

Le service de backend de l'équilibreur de charge doit être associé à une vérification d'état. 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 l'équilibreur de charge TCP/UDP interne, simulant l'envoi du trafic soumis à l'équilibrage de charge. Le logiciel s'exécutant sur vos VM de backend doit répondre à la fois au trafic soumis à l'équilibrage de charge et aux tests de vérification d'état envoyés à 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é.

Paquets de requêtes et de retours TCP et UDP

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.

Lorsque l'équilibreur de charge envoie un paquet de réponses, la source et la destination de ce paquet 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

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 entre toutes les VM de backend opérationnelles, si au moins l'une de ces VM 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.

  • 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 décider de supprimer le trafic.

Par défaut, la méthode de distribution des connexions utilise un hachage calculé à partir de cinq informations : l'adresse IP du client, le port source, l'adresse IP de la règle de transfert interne de l'équilibreur de charge, le port de destination et le protocole. Vous pouvez modifier la méthode de distribution du trafic pour le trafic TCP en spécifiant une option d'affinité de session.

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 lors de l'envoi de trafic TCP. Il s'agit d'une exigence courante pour les applications Web.

L'affinité de session a pour objectif de faciliter autant que possible le trafic TCP. Comme le protocole UDP n'est pas compatible avec les sessions, l'affinité de session n'affecte pas le trafic UDP.

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 :

  • Aucune. Il s'agit du paramètre par défaut, qui est identique à l'adresse IP, au protocole et au port du client.
  • Adresse IP du client. Dirige les requêtes d'un client spécifique vers la même VM de backend en fonction d'un hachage créé à partir de l'adresse IP du client et de l'adresse IP de destination.
  • Adresse IP et protocole du client. Dirige les requêtes d'un client spécifique vers la même VM de backend en fonction d'un hachage créé à partir de trois informations : l'adresse IP du client, l'adresse IP de destination et le protocole de l'équilibreur de charge (TCP ou UDP).
  • Adresse IP, protocole et port du client. Dirige les requêtes d'un client spécifique vers la même VM de backend en fonction d'un hachage créé à partir de cinq informations :

    • l'adresse IP source du client qui envoie la requête ;
    • le port source du client qui envoie la requête ;
    • l'adresse IP de destination ;
    • le port de destination ;
    • le protocole (TCP ou UDP).

    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.

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