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

Un équilibreur de charge réseau passthrough interne est un équilibreur de charge régional basé sur la pile de virtualisation de réseau Andromeda.

Les équilibreurs de charge réseau passthrough internes répartissent 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.

Utilisez un équilibreur de charge réseau passthroughinterne dans les cas suivants :

  • Vous avez besoin d'un équilibreur de charge hautes performances passthrough de couche 4 pour les protocoles TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE.
  • 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 réseau passthrough 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 réseau passthrough internes répondent à de nombreux cas d'utilisation. Pour obtenir des exemples généraux, consultez la page Présentation de l'équilibreur de charge réseau passthrough.

Fonctionnement des équilibreurs de charge réseau passthrough internes

Un équilibreur de charge réseau passthrough interne dispose d'une interface (la règle de transfert) et d'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.

Vue d'ensemble d'un équilibreur de charge réseau passthrough interne
Vue d'ensemble d'un équilibreur de charge réseau passthrough interne (cliquez pour agrandir)

Contrairement à un équilibreur de charge proxy, un équilibreur de charge réseau passthrough interne ne met pas fin aux connexions des clients pour ouvrir ensuite de nouvelles connexions aux backends. À la place, un équilibreur de charge réseau passthrough interne achemine les connexions directement des clients vers les backends opérationnels, sans interruption. Les réponses de ces VM de backend opérationnelles 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é du backend à l'aide de requêtes de vérification d'état. Pour plus d'informations, consultez la section Vérification d'état.

L' Google Cloud environnement invité Linux, l'environnement invité Windows 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' Google Cloud images, 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 virtuelleGoogle 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 réseau passthrough interne est compatible avec les éléments suivants :

  • Un service de backend avec le schéma d'équilibrage de charge INTERNAL et un protocole compatible. Pour en savoir plus, consultez la section Service de backend.
  • Les VM de backend spécifiées de l'une des manières suivantes :
  • Compatibilité avec le trafic IPv4 et IPv6 lors de l'utilisation de backends de groupes d'instances. Les groupes de points de terminaison du réseau (NEG) zonaux avec des points de terminaison GCE_VM_IP n'acceptent que le trafic IPv4.
  • Une ou plusieurs règles de transfert, chacune utilisant le protocole TCP, UDP ou L3_DEFAULT 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 réseau passthrough interne n'est pas compatible avec :

Accès des clients

Par défaut, l'équilibreur de charge n'accepte que les clients situés dans la même région que lui. Les clients peuvent se trouver sur le même réseau que l'équilibreur de charge 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 clients de n'importe quelle région à accéder à votre équilibreur de charge réseau passthrough interne.

Équilibreur de charge réseau passthrough interne avec accès mondial.
Équilibreur de charge réseau passthrough interne avec accès mondial (cliquez pour agrandir)

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

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

Lorsqu'une VM de backend reçoit un paquet à équilibrage de charge d'un client, la source et la destination du paquet sont les suivantes :

  • Source : adresse IPv4, IPv6 interne ou adresse IPv4 du client à partir de l'une des plages d'adresses IPv4 d'alias du client.
  • Destination : adresse IP de la règle de transfert de l'équilibreur de charge. La règle de transfert utilise une seule adresse IPv4 interne ou une plage d'adresses IPv6 internes.

L'équilibreur de charge est un équilibreur de charge passthrough (et non un proxy). Par conséquent, les paquets qui arrivent contiennent l'adresse IP de destination de la règle de transfert de l'équilibreur de charge. Le logiciel exécuté sur les VM de backend doit être configuré pour effectuer les opérations suivantes :

  • Écouter (être lié à) l'adresse IP de la règle de transfert de l'équilibreur de charge ou toute adresse IP (0.0.0.0 ou ::)
  • Si le protocole de la règle de transfert de l'équilibreur de charge est compatible avec les ports : écouter (être lié à) 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. Les VM de backend doivent donc répondre avec des paquets dont les adresses IP sources correspondent à l'adresse IP de la règle de transfert, de sorte que le client puisse associer les paquets de réponse à la connexion TCP appropriée.
  • Le protocole UDP est sans connexion. Les VM de backend peuvent donc envoyer des paquets de réponse dont les adresses IP sources correspondent à l'adresse IP de la règle de transfert ou à toute adresse IP attribuée à la VM. En pratique, la plupart des clients s'attendent à ce que la réponse provienne de l'adresse IP à laquelle ils ont envoyé des paquets.

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 Dans la plupart des cas, adresse IP de la règle de transfert de l'équilibreur de charge† Source du paquet à l'origine de la requête

† Il est possible de définir la source du paquet de réponse sur l'adresse IPv4 interne principale de la carte d'interface réseau de la VM ou sur une plage d'adresses IP d'alias. Si le transfert IP est activé sur la VM, vous pouvez également utiliser des sources d'adresse IP arbitraires. Ne pas utiliser l'adresse IP de la règle de transfert en tant que source est un scénario avancé, car le client reçoit un paquet de réponse provenant d'une adresse IP interne qui ne correspond pas à l'adresse IP à laquelle il a envoyé un paquet de requête.

Architecture

Un équilibreur de charge réseau passthrough 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 réseau passthrough 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 réseau passthrough 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 un équilibreur de charge réseau passthrough interne avec un réseau VPC en mode personnalisé ou en mode automatique. Vous pouvez également créer des équilibreurs de charge réseau passthrough internes avec un ancien réseau.

Un équilibreur de charge réseau passthrough interne n'est pas compatible avec :

Adresse IP interne

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les sous-réseaux IPv4 uniquement, à double pile et IPv6 uniquement. Pour en savoir plus sur chacun d'eux, consultez la section Types de sous-réseaux.

Un équilibreur de charge réseau passthrough interne nécessite au moins une règle de transfert. La règle de transfert référence l'adresse IP interne:

  • Pour le trafic IPv4, la règle de transfert référence une adresse IPv4 de la plage de sous-réseau IPv4 principale.

  • Pour le trafic IPv6, la règle de transfert référence une plage d'adresses IPv6 internes /96 de la plage d'adresses IPv6 internes du sous-réseau /64. Le sous-réseau doit être un sous-réseau à double pile ou à pile unique (Preview) IPv6 uniquement avec une plage d'adresses IPv6 internes (ipv6-access-type défini sur INTERNAL). La plage d'adresses IPv6 peut être une adresse statique réservée ou une adresse éphémère.

    Pour en savoir plus sur la compatibilité IPv6, consultez la documentation VPC sur les plages de sous-réseaux IPv6 et les adresses IPv6.

Configuration du pare-feu

Les équilibreurs de charge réseau passthrough internes doivent configurer les règles de pare-feu hiérarchiques et les règles de pare-feu VPC comme suit :

Pour en savoir plus, consultez la section Configurer les règles de pare-feu.

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 réseau passthrough 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 réseau passthrough 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.

Si vous souhaitez que l'équilibreur de charge gère à la fois le trafic IPv4 et IPv6, créez deux règles de transfert : une règle pour le trafic IPv4 qui pointe vers les backends IPv4 (ou double pile), et une règle pour le trafic IPv6 qui pointe uniquement vers les backends à deux piles. Il est possible de disposer d'une règle de transfert IPv4 et d'une règle de transfert IPv6 faisant référence au même service de backend, mais le service de backend doit faire référence à des backends à double pile.

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.
  • Pour le trafic IPv4, la règle de transfert interne référence l'adresse IPv4 interne régionale de la plage d'adresses IPv4 principale du sous-réseau que vous sélectionnez. Cette adresse IPv4 peut être sélectionnée automatiquement ou vous pouvez utiliser une adresse IPv4 statique (réservée).
  • Pour le trafic IPv6, la règle de transfert référence une plage d'adresses IPv6 /96 de la plage d'adresses IPv6 internes du sous-réseau /64. Le sous-réseau doit être un sous-réseau à deux piles, avec le paramètre ipv6-access-type défini sur INTERNAL. La plage d'adresses IPv6 /96 est attribuée automatiquement ou vous pouvez utiliser une adresse IP interne réservée.

Protocoles de règles de transfert

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options de protocole IPv4 suivantes pour chaque règle de transfert : TCP, UDP ou L3_DEFAULT.

Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options de protocole IPv6 suivantes pour chaque règle de transfert : TCP ou UDP.

L'option L3_DEFAULT vous permet d'équilibrer la charge des protocoles TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE.

En plus d'accepter les protocoles autres que TCP et UDP, l'option L3_DEFAULT permet à une règle de transfert unique de transférer simultanément le trafic pour plusieurs protocoles Par exemple, vous pouvez non seulement effectuer des requêtes HTTP, mais aussi pinguer l'adresse IP de l'équilibreur de charge.

Les règles de transfert qui utilisent les protocoles TCP ou UDP peuvent faire référence à un service de backend utilisant le même protocole que la règle de transfert ou à un service de backend utilisant le protocole UNSPECIFIED.

Si vous utilisez le protocole L3_DEFAULT, vous devez configurer la règle de transfert de façon à accepter le trafic sur tous les ports. Pour configurer tous les ports, définissez --ports=ALL à l'aide de Google Cloud CLI ou définissez allPorts sur True à l'aide de l'API.

Le tableau suivant récapitule comment utiliser ces paramètres pour différents protocoles :

Trafic dont la charge doit être équilibrée Protocole de règle de transfert Protocole de service de backend
TCP (IPv4 ou IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 ou IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH et GRE L3_DEFAULT UNSPECIFIED

Règles de transfert et accès mondial

Les règles de transfert d'un équilibreur de charge réseau passthrough 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 réseau passthrough 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 :

  • 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, veillez à configurer le logiciel qui s'exécute sur vos VM de backend pour qu'il soit lié à toutes les adresses IP de la règle de transfert ou à toute adresse (0.0.0.0/0 pour IPv4 ou ::/0 pour IPv6). L'adresse IP de destination d'un paquet distribué 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 de backend

Chaque équilibreur de charge réseau passthrough 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 correspond au nom de l'équilibreur de charge réseau passthrough interne affiché dans la console Google Cloud.

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

  • Protocole. Un service de backend accepte le trafic IPv4 et IPv6. Si le protocole comporte un concept de port (tel que TCP ou UDP), le service de backend envoie des paquets aux VM de backend sur le même port de destination auquel le trafic a été envoyé.

    Les services de backend sont compatibles avec les options de protocole IPv4 suivantes : TCP, UDP ou UNSPECIFIED.

    Les services de backend sont compatibles avec les options de protocole IPv6 suivantes : TCP ou UDP. Le protocole du service de backend doit se coordonner avec le protocole de règle de transfert.

    Pour obtenir le tableau des combinaisons possibles de règles de transfert et de protocoles de services de backend, consultez la page Spécification du protocole d'une 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 :

Backends de groupes d'instances et interfaces réseau

Le réseau VPC associé à un groupe d'instances est le réseau VPC utilisé par l'interface réseau nic0 de chaque VM membre.

  • Pour les groupes d'instances gérés (MIG), le réseau VPC du groupe d'instances 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 comme le réseau VPC utilisé par l'interface réseau nic0 de la première instance de VM que vous ajoutez au groupe d'instances non géré.

Dans un groupe d'instances donné (géré ou non), toutes les instances de VM doivent avoir leurs interfaces réseau nic0 sur le même réseau VPC. Chaque VM membre peut éventuellement avoir des interfaces réseau supplémentaires (nic1 via nic7), mais chaque interface réseau doit être associée à un réseau VPC différent. Ces réseaux doivent également être différents du réseau VPC associé au groupe d'instances.

Backends de NEG zonaux et interfaces réseau

Lorsque vous créez un NEG zonal avec des points de terminaison GCE_VM_IP, vous devez explicitement associer le NEG au sous-réseau d'un réseau VPC avant de pouvoir lui attribuer des points de terminaison. Ni le sous-réseau ni le réseau VPC ne peuvent être modifiés une fois le NEG créé.

Dans un NEG donné, chaque point de terminaison GCE_VM_IP représente une interface réseau. L'interface réseau doit se trouver dans le sous-réseau associé au NEG. Du point de vue d'une instance Compute Engine, l'interface réseau peut utiliser n'importe quel identifiant (nic0 via nic7). Du point de vue d'un point de terminaison dans un NEG, l'interface réseau est identifiée à l'aide de son adresse IPv4 principale.

Il existe deux manières d'ajouter un point de terminaison GCE_VM_IP à un NEG :

  • Si vous ne spécifiez qu'un nom de VM (sans aucune adresse IP) lors de l'ajout d'un point de terminaison, Google Cloud exige que la VM dispose d'une interface réseau dans le sous-réseau associé au NEG. L'adresse IP choisie par Google Cloudpour le point de terminaison est l'adresse IPv4 interne principale de l'interface réseau de la VM dans le sous-réseau associé au NEG.
  • Si vous spécifiez à la fois un nom de VM et une adresse IP lors de l'ajout d'un point de terminaison, l'adresse IP que vous fournissez doit être une adresse IPv4 interne principale pour l'une des interfaces réseau de la VM. Cette interface réseau doit se trouver dans le sous-réseau associé au NEG. Notez que la spécification d'une adresse IP est redondante, car une seule interface réseau peut se trouver dans le sous-réseau associé au NEG.

Spécification du réseau du service de backend

Vous pouvez explicitement associer un réseau VPC à un service de backend à l'aide de l'option --network lors de la création du service de backend. Les règles du réseau du service de backend entrent en vigueur immédiatement.

Si vous omettez l'option --network lorsque vous créez un service de backend,Google Cloud utilise l'un des événements éligibles suivants pour définir implicitement le réseau VPC associé au service de backend. Une fois défini, le réseau VPC associé au service de backend ne peut plus être modifié:

  • Si le service de backend n'est pas encore associé à des backends et que vous configurez la première règle de transfert pour référencer le service de backend,Google Cloud définit le réseau VPC associé au service de backend sur le réseau VPC qui contient le sous-réseau utilisé par cette règle de transfert.

  • Si le service de backend ne fait pas encore référence à une règle de transfert et que vous ajoutez le premier backend de groupe d'instances au service de backend,Google Cloud définit le réseau VPC du service de backend sur le réseau VPC associé à ce premier backend de groupe d'instances. Cela signifie que le réseau VPC associé au service de backend est le réseau utilisé par l'interface réseau nic0 de chaque VM du backend du premier groupe d'instances.

  • Si le service de backend ne fait pas encore référence à une règle de transfert et que vous ajoutez le premier backend de NEG zonal (avec des points de terminaison GCE_VM_IP) au service de backend,Google Cloud définit le réseau VPC du service de backend sur le réseau VPC associé à ce premier backend de NEG.

Une fois que le réseau VPC du service de backend a été défini par un événement éligible, les règles de transfert, les groupes d'instances backend ou les NEG zonaux supplémentaires que vous ajoutez doivent respecter les règles de réseau du service de backend.

Règles de réseau du service de backend

Les règles suivantes s'appliquent une fois qu'un service de backend est associé à un réseau VPC spécifique :

  • Lors de la configuration d'une règle de transfert pour référencer le service de backend, la règle de transfert doit utiliser un sous-réseau du réseau VPC du service de backend. La règle de transfert et le service de backend ne peuvent pas utiliser des réseaux VPC différents, même s'ils sont connectés (par exemple, à l'aide de l'appairage de réseaux VPC).

  • Lorsque vous ajoutez des backends de groupe d'instances, l'une des conditions suivantes doit être remplie :

    • Le réseau VPC associé au groupe d'instances, c'est-à-dire le réseau VPC utilisé par l'interface réseau nic0 de chaque VM du groupe d'instances, doit correspondre au réseau VPC associé au service de backend.
    • Chaque VM de backend doit avoir une interface non-nic0 (nic1 à nic7) sur le réseau VPC associé au service de backend.

  • Lorsque vous ajoutez des backends de NEG zonaux disposant de points de terminaison GCE_VM_IP, le réseau VPC associé au NEG doit correspondre au réseau VPC associé au service de backend.

Backends à double pile (IPv4 et IPv6)

Si vous souhaitez que l'équilibreur de charge utilise des backends à double pile qui gèrent à la fois le trafic IPv4 et IPv6, notez les exigences suivantes:

  • Les backends doivent être configurés dans des sous-réseaux à deux piles, situés dans la même région que la règle de transfert IPv6 de l'équilibreur de charge. Pour les backends, vous pouvez utiliser un sous-réseau avec le paramètre ipv6-access-type défini sur INTERNAL ou EXTERNAL. Si ipv6-access-type du sous-réseau backend est défini sur EXTERNAL, vous devez utiliser un autre sous-réseau double pile ou IPv6 uniquement avec ipv6-access-type défini sur INTERNAL pour la règle de transfert interne de l'équilibreur de charge. Pour en savoir plus, consultez la section Ajouter un sous-réseau double pile.
  • Les backends doivent être configurés pour être double pile, avec le paramètre stack-type défini sur IPv4_IPv6. Si l'ipv6-access-type du sous-réseau backend est défini sur EXTERNAL, vous devez également définir --ipv6-network-tier sur PREMIUM. Pour en savoir plus, consultez la section Créer un modèle d'instance avec des adresses IPv6.

Backends IPv6 uniquement

Si vous souhaitez que l'équilibreur de charge utilise des backends IPv6 uniquement, notez les exigences suivantes:

  • Les instances uniquement IPv6 ne sont compatibles qu'avec les groupes d'instances non gérés. Aucun autre type de backend n'est accepté.
  • Les backends doivent être configurés dans des sous-réseaux à double pile ou des sous-réseaux IPv6 uniquement situés dans la même région que la règle de transfert IPv6 de l'équilibreur de charge. Pour les backends, vous pouvez utiliser un sous-réseau avec le paramètre ipv6-access-type défini sur INTERNAL ou EXTERNAL. Si ipv6-access-type du sous-réseau backend est défini sur EXTERNAL, vous devez utiliser un autre sous-réseau IPv6 uniquement avec ipv6-access-type défini sur INTERNAL pour la règle de transfert interne de l'équilibreur de charge.
  • Les backends doivent être configurés pour être IPv6 uniquement, avec le paramètre stack-type de la VM défini sur IPv6_ONLY. Si l'ipv6-access-type du sous-réseau backend est défini sur EXTERNAL, vous devez également définir --ipv6-network-tier sur PREMIUM. Pour en savoir plus, consultez la section Créer un modèle d'instance avec des adresses IPv6.

Notez que vous pouvez créer des VM IPv6 uniquement dans les sous-réseaux à double pile et IPv6 uniquement, mais pas dans les sous-réseaux IPv6 uniquement.

Sous-paramètre du backend

Le sous-paramètre de backend est une fonctionnalité facultative qui améliore les performances en limitant le nombre de backends vers lesquels le trafic est distribué.

Vous ne devez activer le sous-paramètre que si vous devez accepter plus de 250 VM de backend sur un seul équilibreur de charge. Pour en savoir plus, consultez la section Sous-paramètre du backend pour l'équilibreur de charge réseau passthrough interne.

Vérification 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 réseau passthrough 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 réseau passthrough 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 réseau passthrough interne, à l'interface réseau dans le réseau VPC 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 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 chaque règle de transfert (le logiciel doit écouter sur 0.0.0.0:<port> plutôt que sur une adresse IP spécifique attribuée à une interface réseau). 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 ne propose pas de vérification d'état qui utilise le protocole UDP. Lorsque vous utilisez un équilibreur de charge réseau passthrough interne avec du trafic UDP, vous devez exécuter sur vos VM backend un service basé sur TCP 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érificateurs d'état 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 réseau passthrough 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 les équilibreurs de charge réseau passthrough internes utilisés avec les réseaux VPC partagés. Pour obtenir un exemple, consultez la création d'un équilibreur de charge réseau passthrough 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' Google Cloud 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é.

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 réseau passthrough 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 réseau passthrough 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.

Répartition du trafic

Les équilibreurs de charge réseau passthrough internes sont compatibles avec diverses options de personnalisation de la distribution du trafic, y compris l'affinité de session, le suivi des connexions et le basculement. Pour en savoir plus sur la façon dont les équilibreurs de charge réseau passthrough internes distribuent le trafic et sur la façon dont ces options interagissent entre elles, consultez la section Distribution du trafic pour les équilibreurs de charge réseau passthrough internes.

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.

Limites

  • Vous ne pouvez pas utiliser la console Google Cloud pour créer un équilibreur de charge réseau passthrough interne avec des backends de NEG zonaux.

Étapes suivantes