Équilibreurs de charge réseau passthrough internes comme sauts suivants

Un équilibreur de charge réseau passthrough interne est un équilibreur de charge régional qui vous permet d'exécuter et de dimensionner vos services derrière une adresse IP interne. Vous pouvez utiliser un équilibreur de charge réseau passthrough interne comme saut suivant vers lequel les paquets sont transférés vers leur destination finale. Pour ce faire, vous définissez l'équilibreur de charge comme prochain saut dans une route statique.

Avant de consulter les informations figurant sur cette page, vous devez déjà connaître les concepts suivants :

Un saut suivant d'équilibreur de charge réseau passthrough interne est utile dans les cas suivants :

  • Pour équilibrer le trafic sur plusieurs VM qui fonctionnent en tant que VM de passerelle ou de routeur.

  • Pour utiliser des dispositifs virtuels de passerelle en tant que prochain saut pour une route par défaut. Avec cette configuration, les instances de machine virtuelle (VM) de votre réseau cloud privé virtuel (VPC) envoient du trafic vers Internet via un ensemble de VM de passerelles virtuelles à équilibrage de charge.

  • Pour envoyer du trafic via plusieurs équilibreurs de charge dans deux directions ou plus en utilisant le même ensemble de VM de passerelle ou de routeur otéesd de plusieurs cartes d'interface réseau en tant que backends. Pour ce faire, vous créez un équilibreur de charge et l'utilisez en tant que prochain saut pour une route statique dans chaque réseau VPC. Chaque équilibreur de charge réseau passthrough interne fonctionne au sein d'un réseau VPC unique, distribuant le trafic vers les interfaces réseau des VM de backend de ce réseau.

Architecture

Dans le schéma suivant, un groupe d'instances de VM de routeur sert de backend pour deux équilibreurs de charge différents. Le premier équilibreur de charge réseau passthrough interne envoie des paquets à nic0 sur les VM de backend, et le second équilibreur de charge réseau passthrough interne envoie des paquets à nic1 sur les mêmes backends.

Équilibrage de charge sur plusieurs cartes d'interface réseau
Équilibrage de charge sur plusieurs cartes d'interface réseau (cliquez sur l'image pour l'agrandir)

Avantages de l'utilisation de votre équilibreur de charge réseau passthrough interne en tant que saut suivant

Lorsque l'équilibreur de charge est un saut suivant pour une route statique, aucune configuration spéciale n'est requise dans les systèmes d'exploitation invités des VM clientes du réseau VPC dans lequel la route est définie. Les VM clientes envoient des paquets aux backends de l'équilibreur de charge via un routage réseau VPC, avec une mise en œuvre de type bump-in-the-wire.

L'utilisation d'un équilibreur de charge réseau passthrough interne comme saut suivant pour une route statique offre les mêmes avantages qu'un équilibreur de charge réseau passthrough interne autonome. La vérification de l'état de l'équilibreur de charge garantit que les nouvelles connexions sont routées vers des VM de backend opérationnelles. En utilisant un groupe d'instances géré comme backend, vous pouvez configurer l'autoscaling pour augmenter ou réduire l'ensemble de VM en fonction de la demande du service.

Spécifications

Voici les spécifications d'utilisation des équilibreurs de charge réseau passthrough internes comme sauts suivants.

Routes

Vous pouvez créer une route statique pour transmettre le trafic TCP, UDP et d'autres protocoles à un équilibreur de charge réseau passthrough interne où l'équilibreur de charge représentant le prochain saut pour la route statique. La route peut être un préfixe CIDR externe (publiquement routable) ou un préfixe CIDR interne, si le préfixe n'entre pas en conflit avec une route de sous-réseau. Par exemple, vous pouvez remplacer votre route par défaut (0.0.0.0/0) par une route qui dirige le trafic vers des VM de backend tierces pour le traitement des paquets.

Options de spécification du saut suivant

Vous pouvez spécifier un saut suivant d'équilibreur de charge réseau passthrough interne à l'aide de l'une des deux méthodes suivantes :

  • En utilisant le nom et la région de la règle de transfert
  • En utilisant l'adresse IP de la règle de transfert

Pour plus d'informations sur le projet et le réseau VPC dans lesquels un saut suivant d'équilibreur de charge réseau passthrough interne peut résider, consultez la section Prochains sauts et caractéristiques.

Vous pouvez échanger des routes statiques avec des sauts suivants d'équilibreur de charge réseau passthrough interne à l'aide de l'appairage de réseaux VPC. Pour plus d'informations, consultez la section Options d'échange de routes statiques.

Affinité de session basée sur les adresses IP clientes

Les équilibreurs de charge réseau passthrough internes proposent deux options d'affinité de session "adresse IP client" similaires :

  • Adresse IP client (CLIENT_IP) : hachage à deux tuples de l'adresse IP source et de l'adresse IP de destination d'un paquet. Lorsqu'un équilibreur de charge réseau passthrough interne n'est pas le saut suivant d'une route, les paquets envoyés à l'adresse IP de la règle de transfert de l'équilibreur de charge partagent une adresse IP de destination commune : l'adresse IP de la règle de transfert. Dans ce cas de figure, l'une des adresses utilisées par le hachage à deux tuples reste constante. Ainsi, si le nombre de backends configurés et opérationnels ne change pas et que les paquets ont des adresses IP sources identiques, cette option d'affinité de session à deux tuples sélectionne le même backend.
  • Adresse IP client, aucune destination (CLIENT_IP_NO_DESTINATION) : hachage à un tuple de l'adresse IP source d'un paquet. Lorsque vous utilisez un équilibreur de charge réseau passthrough interne en tant que saut suivant, l'adresse IP de destination varie souvent, car les adresses IP de destination sont celles spécifiées par l'attribut de destination de la route. Dans ce cas de figure, l'affinité de session de l'adresse IP client (CLIENT_IP) par hachage à deux tuples ne peut pas sélectionner le même backend, même lorsque le nombre de backends configurés et opérationnels ne change pas et que les paquets ont des adresses IP sources identiques. (Une exception à cette règle concerne les cas où un seul backend est configuré.) Si vous souhaitez que les paquets avec des adresses IP sources identiques soient acheminés vers le même backend, vous devez utiliser l'option d'affinité de session Adresse IP client, aucune destination (CLIENT_IP_NO_DESTINATION).

Plage de destination

La destination d'une route statique ne peut pas être identique à une route de sous-réseau ou plus spécifique que celle-ci. Notez que plus spécifique signifie que le masque de sous-réseau est plus long. Cette règle s'applique à toutes les routes statiques, y compris lorsque le prochain saut est un équilibreur de charge réseau passthrough interne. Par exemple, supposons que votre route de sous-réseau soit 10.140.0.0/20. La destination d'une route statique ne peut pas être identique (10.140.0.0/20) et ne peut pas être plus spécifique, comme dans 10.140.0.0/22.

Réseau et région VPC identiques

Les routes statiques qui utilisent des équilibreurs de charge réseau passthrough internes en tant que prochains sauts sont limitées aux éléments suivants :

  • Un seul réseau VPC. L'équilibreur de charge et la route statique doivent se trouver sur le même réseau VPC.

  • Une seule région ou toutes les régions. À moins que vous ne configuriez l'accès global, la route statique n'est disponible que pour les ressources de la même région que l'équilibreur de charge. Cette restriction régionale s'applique même si la route figure dans la table de routage pour l'ensemble du réseau VPC. Si vous activez l'accès global, la route statique est disponible pour les ressources de n'importe quelle région.

Annoncer la route statique

Pour annoncer le préfixe (destination) de la route statique, vous pouvez utiliser le mode d'annonce personnalisé de Cloud Router. Le champ d'application de l'annonce de routage dépend du paramètre d'accès mondial de l'équilibreur de charge, comme suit :

  • Lorsque l'accès mondial est désactivé, l'équilibreur de charge réseau passthrough interne n'est disponible que pour les VM, les tunnels Cloud VPN et les rattachements Cloud Interconnect (VLAN) qui se trouvent dans la même région que l'équilibreur de charge. Par conséquent, une annonce de routage personnalisée pour le préfixe d'une route statique n'a de sens que si le routeur Cloud Router et l'équilibreur de charge se trouvent dans la même région.

  • Lorsque l'accès mondial est activé, l'équilibreur de charge réseau passthrough interne est disponible pour les VM, les tunnels Cloud VPN et les rattachements Cloud Interconnect (VLAN) qui se trouvent dans n'importe quelle région. Le routage dynamique mondial permet aux systèmes sur site d'utiliser la route statique de n'importe quelle région connectée.

Le tableau suivant récapitule l'accessibilité de l'équilibreur de charge.

Accès mondial Mode de routage dynamique du réseau VPC Accessibilité de l'équilibreur de charge
Désactivé Régional Accessible par les routeurs de la même région
Désactivé Mondial Accessible par les routeurs de la même région
Activé Régional Accessible par tous les routeurs dans n'importe quelle région
Activé Mondial Accessible par tous les routeurs dans n'importe quelle région

Pour en savoir plus, consultez la page Équilibreurs de charge réseau avec stratégie passthrough internes et réseaux connectés.

Ordre de priorité des opérations

Vous devez créer un équilibreur de charge réseau passthrough interne avant de pouvoir créer une route statique personnalisée qui l'utilise en tant que prochain saut. Avant de pouvoir créer la route, vous devez vous assurer que l'équilibreur de charge existe. Si vous essayez de créer une route faisant référence à un équilibreur de charge inexistant, Google Cloud renvoie une erreur.

Pour spécifier un saut suivant de l'équilibreur de charge réseau passthrough interne, utilisez le nom de la règle de transfert et la région de l'équilibreur de charge, ou l'adresse IP interne associée à la règle de transfert.

Une fois que vous avez créé une route avec un saut suivant qui fait référence à un équilibreur de charge réseau passthrough interne, vous ne pouvez pas supprimer l'équilibreur de charge, sauf si vous supprimez d'abord la route. Plus précisément, vous ne pouvez pas supprimer une règle de transfert interne tant qu'aucune route statique n'utilise cet équilibreur de charge en tant que prochain saut.

Exigences du backend

  • Vous devez configurer toutes les VM de backend de l'équilibreur de charge réseau passthrough interne pour autoriser le transfert IP (--can-ip-forward = True). Pour en savoir plus, consultez la section Considérations communes aux instances et aux prochains sauts de l'équilibreur de charge réseau passthrough interne.

  • Vous ne pouvez pas utiliser un équilibreur de charge réseau passthrough interne dont les backends sont des nœuds Google Kubernetes Engine (GKE) en tant que prochain saut pour une route statique. Les logiciels sur les nœuds ne peuvent acheminer le trafic vers les pods que si la destination correspond à une adresse IP gérée par le cluster, et non à une destination arbitraire.

Traitement du trafic TCP, UDP et autres protocoles

Lorsqu'un équilibreur de charge réseau passthrough interne est déployé en tant que saut suivant, Google Cloud transfère tout le trafic sur tous les ports aux VM de backend, indépendamment des éléments suivants :

  • Configuration du protocole et des ports de la règle de transfert
  • Configuration du protocole du service de backend

L'équilibreur de charge réseau passthrough interne, qui est le saut suivant de la route, accepte directement le transfert de tout le trafic pour les protocoles acceptés par les réseaux VPC Google Cloud (tels que TCP, UDP et ICMP).

Informations complémentaires

  • Règles de transfert compatibles. Google Cloud n'accepte que les règles de transfert des équilibreurs de charge réseau passthrough internes utilisés comme prochain saut. Google Cloud n'est pas compatible avec les règles de transfert de prochain saut utilisées par d'autres équilibreurs de charge, transferts de protocole ou points de terminaison Private Service Connect.

  • Méthodes de spécification, réseau et projet des règles de transfert. Vous pouvez spécifier une règle de transfert de prochain saut à l'aide de l'une des trois méthodes suivantes. La méthode de spécification que vous utilisez détermine si le réseau de la règle de transfert doit correspondre au réseau de la route et le projet dans lequel se trouve la règle de transfert.

    Choisissez l'une des méthodes suivantes et assurez-vous que la version IP de votre règle de transfert correspond à la version IP de la route statique que vous créez:

    • Par nom (--next-hop-ilb) et région (--next-hop-ilb-region) de règle de transfert : lorsque vous spécifiez une règle de transfert de prochain saut par nom et par région, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert doit se trouver dans le projet qui contient le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé).

    • Par lien de ressource de règle de transfert : le lien de ressource d'une règle de transfert utilise le format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, où PROJECT_ID est l'ID du projet contenant la règle de transfert, REGION est la région de la règle de transfert et FORWARDING_RULE_NAME est le nom de la règle de transfert. Lorsque vous spécifiez une règle de transfert de prochain saut par son lien de ressource, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

    • Par adresse IP de règle de transfert: lorsque vous spécifiez une règle de transfert de prochain saut par son adresse IPv4 ou IPv6 (preview), le réseau de la règle de transfert peut être soit le réseau VPC de la route, soit un réseau VPC appairé. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

  • Effet de l'accès mondial : Les routes statiques personnalisées utilisant des équilibreurs de charge réseau passthrough internes en tant que saut suivant sont programmées dans toutes les régions. La possibilité d'utilisation du saut suivant dépend du paramètre d'accès mondial de l'équilibreur de charge. Lorsque l'accès mondial est activé, le saut suivant de l'équilibreur de charge est accessible dans toutes les régions du réseau VPC. Lorsque l'accès mondial est désactivé, le saut suivant de l'équilibreur de charge n'est accessible que dans la même région que l'équilibreur de charge. Lorsque l'accès mondial est désactivé, les paquets envoyés depuis une autre région vers une route utilisant un équilibreur de charge réseau passthrough interne comme saut suivant sont supprimés.

  • Lorsque tous les backends sont considérés comme non opérationnels. Lorsque tous les backends d'un équilibreur de charge réseau passthrough interne échouent aux vérifications d'état, les routes qui utilisent cet équilibreur de charge en tant que saut suivant restent en vigueur. Les paquets traités par la route sont envoyés à l'un des backends d'équilibreur de charge de saut suivant selon la distribution du trafic.

  • Les règles de transfert qui utilisent une adresse IP interne commune (--purpose=SHARED_LOADBALANCER_VIP) ne sont pas compatibles. Les équilibreurs de charge réseau passthrough internes utilisés en tant que saut suivant et les règles de transfert de l'équilibreur de charge réseau passthrough interne avec adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge réseau passthrough interne utilisé en tant que saut suivant doit utiliser une adresse IP propre à la règle de transfert de l'équilibreur de charge, de sorte qu'un seul service de backend (un équilibreur de charge) soit clairement référencé. Il est possible que les règles de transfert utilisent une adresse IP interne commune pour faire référence à différents services de backend (différents équilibreurs de charge réseau passthrough internes).

  • Plusieurs routes avec les mêmes destinations et priorités, mais différents équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Google Cloud ne distribue jamais le trafic entre au moins deux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut à l'aide d'ECMP. À la place, Google Cloud ne sélectionne qu'un seul équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut à l'aide d'un algorithme interne déterministe. Pour éviter cette ambiguïté, vous pouvez utiliser des tags réseau uniques pour chaque route.

    Google Cloud sélectionne un seul saut suivant lorsque des routes statiques avec différents équilibreurs de charge réseau passthrough internes utilisables en tant que saut suivant ont la même priorité et la même destination.

  • Plusieurs routes avec les mêmes destinations, priorités et équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Sans tag réseau, Google Cloud ne vous permet pas de créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut. Avec les tags réseau, vous pouvez créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut.

Cas d'utilisation

Vous pouvez utiliser un équilibreur de charge réseau passthrough interne en tant que saut suivant dans plusieurs déploiements et topologies.

Pour chaque exemple, notez les consignes suivantes :

  • Chaque interface de VM doit se trouver sur un réseau VPC distinct.

  • Vous ne pouvez pas utiliser des VM de backend ou des équilibreurs de charge pour router le trafic entre les sous-réseaux d'un même réseau VPC, car les routes de sous-réseau ne peuvent pas être remplacées.

  • L'équilibreur de charge réseau passthrough interne est un équilibreur de charge passthrough défini par logiciel. Les paquets sont transmis aux VM de backend sans modification des informations sources ou de destination (adresses ou adresses et ports).

    Le routage, le filtrage des paquets, l'utilisation de serveurs proxy et la traduction d'adresse relèvent de la responsabilité des VM de dispositifs virtuels qui servent de backends pour l'équilibreur de charge réseau passthrough interne.

Utiliser un équilibreur de charge réseau passthrough interne en tant que saut suivant vers une passerelle NAT

Dans ce cas d'utilisation, l'équilibrage de charge répartit le trafic des VM internes entre plusieurs instances de passerelle NAT qui routent le trafic vers Internet.

Cas d'utilisation de NAT.
Cas d'utilisation de NAT (cliquez pour agrandir)

Réseau en étoile : échanger des routes de saut suivant via l'appairage de réseaux VPC

Outre l'échange de routes de sous-réseau, vous pouvez configurer l'appairage de réseau VPC pour exporter et importer des routes statiques et dynamiques personnalisées. Les routes statiques disposant d'un prochain saut vers la passerelle Internet par défaut sont exclues. Les routes statiques personnalisées qui utilisent des équilibreurs de charge réseau passthrough internes de saut suivant sont incluses.

Vous pouvez configurer une topologie en étoile avec vos dispositifs virtuels de pare-feu de saut suivant situés dans un réseau VPC hub en procédant comme suit :

  • Dans le réseau VPC hub, créez un équilibreur de charge réseau passthrough interne avec des dispositifs virtuels de pare-feu en tant que backends.
  • Dans le réseau VPC hub, créez une route statique et définissez le prochain saut en tant qu'équilibreur de charge réseau passthrough interne.
  • Connectez le réseau VPC hub à chacun des réseaux VPC spoke en utilisant l'appairage de réseaux VPC.
  • Pour chaque appairage, configurez le réseau hub pour exporter ses routes personnalisées et configurez le réseau spoke correspondant pour importer des routes personnalisées. La route avec le prochain saut de l'équilibreur de charge est l'une des routes que le réseau hub exporte.

Sous réserve de l'ordre de routage, l'équilibreur de charge du dispositif de pare-feu du prochain saut dans le réseau VPC hub est disponible dans les réseaux spoke :

  • pour les clients de la même région que l'équilibreur de charge, si l'accès mondial est désactivé ;
  • pour les clients de toutes les régions si l'accès mondial est activé, selon l'ordre de routage.
Hub et Spoke.
Réseau hub et spoke (cliquez pour agrandir)

Équilibrage de charge sur plusieurs cartes d'interface réseau

Dans le cas d'utilisation suivant, les VM de backend sont des instances de dispositif virtuel (par exemple, des VM d'inspection de paquets, de routage ou de passerelle) avec des cartes d'interface réseau dans plusieurs réseaux VPC. Ces instances de dispositif virtuel peuvent être des solutions commerciales provenant de tiers ou des solutions que vous créez vous-même. Les dispositifs virtuels sont des VM Compute Engine dotées de plusieurs cartes d'interface réseau.

Cet exemple montre un ensemble unique de dispositifs virtuels de backend dans un groupe d'instances de machine virtuelle gérées.

Dans le réseau VPC appelé testing, l'équilibreur de charge réseau passthrough interne dispose d'une règle de transfert appelée fr-ilb1. Dans l'exemple, cet équilibreur de charge distribue le trafic vers l'interface nic0.

Dans le réseau VPC appelé production, un autre équilibreur de charge réseau passthrough interne dispose d'une règle de transfert appelée fr-ilb2. Cet équilibreur de charge distribue le trafic vers une interface différente, nic1 dans cet exemple.

Trafic avec équilibrage de charge sur plusieurs cartes d'interface réseau.
Trafic avec équilibrage de charge sur plusieurs cartes d'interface réseau (cliquez sur l'image pour l'agrandir)

Pour en savoir plus sur la configuration détaillée, consultez la section Équilibrage de charge sur plusieurs cartes d'interface réseau de backend.

Hachage symétrique

L'exemple précédent n'utilise pas la traduction d'adresse réseau source (SNAT). La traduction d'adresse réseau source n'est pas nécessaire, car Google Cloud utilise le hachage symétrique. Cela signifie que lorsque des paquets appartiennent au même flux, Google Cloud calcule le même hachage. En d'autres termes, le hachage ne change pas lorsque l'élément adresse IP:port source est remplacée par l'élément adresse IP:port.

Remarques :

  • Le hachage symétrique est activé automatiquement si vous créez la règle de transfert de l'équilibreur de charge réseau passthrough interne à compter du 22 juin 2021.

  • Pour activer le hachage symétrique sur les équilibreurs de charge réseau passthrough internes existants, vous devez recréer la règle de transfert et la route de saut suivant, comme décrit dans la section Activer le hachage symétrique.

  • Le hachage symétrique n'est compatible qu'avec les équilibreurs de charge réseau passthrough internes.

  • Le hachage symétrique est compatible avec les types d'affinité de session suivants pour les protocoles TCP et UDP :

    • Adresse IP client (CLIENT_IP)
    • Adresse IP client et protocole (CLIENT_IP_PROTO)
    • Adresse IP client, protocole et port (CLIENT_IP_PORT_PROTO)

    Pour en savoir plus sur ces paramètres, consultez la section Options d'affinité de session.

  • Vous pouvez éventuellement utiliser la traduction d'adresse réseau source si votre cas d'utilisation l'exige pour une raison quelconque.

Étapes suivantes