Équilibreurs de charge TCP/UDP internes en tant que sauts suivants

L'équilibrage de charge TCP/UDP 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 TCP/UDP interne en tant que saut suivant vers lequel les paquets sont transférés vers leur destination finale. Pour ce faire, vous définissez l'équilibreur de charge en tant que saut suivant dans une route statique personnalisée.

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

Le saut suivant d'un équilibreur de charge TCP/UDP 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 saut suivant 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 saut suivant pour une route statique personnalisée dans chaque réseau VPC. Chaque équilibreur de charge TCP/UDP 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 équilibrage de charge TCP/UDP interne envoie des paquets à nic0 sur les VM de backend, et le second équilibrage de charge TCP/UDP interne envoie des paquets à nic1 sur les mêmes backends.

Équilibrage de charge sur plusieurs cartes d'interface réseau (cliquez sur l'image pour l'agrandir)
É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 TCP/UDP 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 TCP/UDP interne comme saut suivant pour une route statique offre les mêmes avantages que l'équilibrage de charge TCP/UDP interne. 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 TCP/UDP internes en tant que saut suivant.

Routes

Vous pouvez créer une route statique personnalisée pour transmettre le trafic TCP, UDP et d'autres protocoles à un équilibreur de charge TCP/UDP interne, l'équilibreur de charge représentant le saut suivant 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

Deux options s'offrent à vous pour spécifier l'équilibreur de charge en tant que saut suivant.

Option de spécification Réseau de saut suivant Exportation vers des réseaux appairés
Nom de la règle de transfert et région de l'équilibreur de charge L'équilibreur de charge de saut suivant et la route doivent se trouver sur le même réseau VPC Oui, en exportant les routes personnalisées (applicable aux routes sans tags)
Adresse IP interne de la règle de transfert L'équilibreur de charge de saut suivant peut se trouver sur le même réseau VPC que la route ou sur un réseau VPC appairé. Oui, toujours exportée (sauf pour les routes avec des tags)

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

L'affinité de session basée sur les adresses IP clientes est l'une des options d'affinité de session disponibles. Il s'agit d'une affinité double qui utilise l'adresse IP source et l'adresse IP de destination comme entrées pour une fonction de hachage.

Lorsque vous utilisez uniquement un équilibreur de charge TCP/UDP interne, l'adresse IP de destination est l'adresse IP de la règle de transfert de l'équilibreur de charge. Dans ce contexte, l'affinité de session basée sur les adresses IP clientes signifie que les connexions d'un client avec une adresse IP source constante sont fournies à la même VM de backend si celle-ci est opérationnelle.

En revanche, lorsque vous utilisez un équilibreur de charge TCP/UDP interne en tant que saut suivant pour une route statique, l'adresse IP de destination varie, car les VM de backend de l'équilibreur de charge traitent et acheminent les paquets vers différentes adresses IP de destination. L'utilisation de l'affinité de session basée sur les adresses IP clientes dans ce contexte n'entraîne pas le traitement des paquets par la même VM de backend, même si le client a une adresse IP source constante.

Plage de destination

La destination d'une route statique personnalisée 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 personnalisées, y compris lorsque le saut suivant est un équilibreur de charge TCP/UDP interne. Par exemple, supposons que votre route de sous-réseau soit 10.140.0.0/20. La destination d'une route statique personnalisée 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 personnalisées qui utilisent des équilibreurs de charge TCP/UDP internes en tant que sauts suivants sont limitées aux éléments suivants :

  • Un seul réseau VPC. L'équilibreur de charge et la route statique personnalisée 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 personnalisée 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 personnalisée est disponible pour les ressources de n'importe quelle région.

Annoncer la route statique personnalisée

Pour annoncer le préfixe (destination) de la route statique personnalisée, vous pouvez utiliser une annonce de routage personnalisée 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 TCP/UDP 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 personnalisée 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 TCP/UDP 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 personnalisée 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é Disques Accessible par les routeurs de la même région
Désactivé Mondial Accessible par les routeurs de la même région
Activé Disques 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 Équilibrage de charge TCP/UDP interne et réseaux connectés.

Ordre de priorité des opérations

Vous devez créer un équilibreur de charge TCP/UDP interne avant de pouvoir créer une route statique personnalisée qui l'utilise en tant que saut suivant. 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 équilibreur de charge TCP/UDP interne en tant que saut suivant, 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 TCP/UDP 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 personnalisée n'utilise cet équilibreur de charge en tant que saut suivant.

Exigences du backend

  • Vous devez configurer toutes les VM de backend de l'équilibreur de charge TCP/UDP interne pour autoriser le transfert IP (--can-ip-forward = True). Pour en savoir plus, consultez la section Considérations liées aux sauts suivants de type instance et équilibreur de charge.

  • Vous ne pouvez pas utiliser un équilibreur de charge TCP/UDP interne dont les backends sont des nœuds Google Kubernetes Engine (GKE) en tant que saut suivant pour une route statique personnalisée. 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 TCP/UDP 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 TCP/UDP 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).

Autres considérations

  • Lorsque tous les backends sont considérés comme non opérationnels. Lorsque tous les backends d'un équilibreur de charge TCP/UDP interne échouent aux vérifications d'état, les routes qui utilisent ce saut suivant d'équilibreur de charge TCP/UDP interne sont toujours 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. L'équilibreur de charge TCP/UDP interne de saut suivant et les règles de transfert de l'équilibreur de charge TCP/UDP interne avec une adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge TCP/UDP interne de saut suivant doit utiliser une adresse IP unique à la règle de transfert de l'équilibreur de charge afin que seul un service de backend (un équilibreur de charge) soit référencé sans ambiguïté. 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 TCP/UDP internes).

  • Même destination et plusieurs équilibreurs de charge TCP/UDP internes de saut suivant. Si vous créez plusieurs routes statiques personnalisées avec la même destination à l'aide des sauts suivants de l'équilibreur de charge TCP/UDP interne, Google Cloud ne répartit jamais le trafic entre les sauts suivants de l'équilibreur de charge à l'aide de ECMP. Si les routes ont des priorités uniques, Google Cloud utilise l'équilibreur de charge TCP/UDP interne de saut suivant de la route ayant la priorité la plus élevée. Si les routes ont des priorités égales, Google Cloud ne sélectionne qu'un seul équilibreur de charge TCP/UDP interne de saut suivant. Dans ce dernier cas, comme illustré dans le diagramme ci-dessous, Google Cloud utilise un algorithme interne déterministe pour sélectionner une seule règle de transfert de saut suivant (forwarding-rule-a), en ignorant les autres routes ayant la même priorité.

    Même destination, différents sauts suivants de l'équilibreur de charge TCP/UDP interne
    Même destination, différents sauts suivants de l'équilibreur de charge TCP/UDP interne
  • Plusieurs destinations et le même équilibreur de charge TCP/UDP interne de saut suivant.

    Avec tags : si vous utilisez des tags réseau, vous pouvez utiliser le même équilibreur de charge TCP/UDP interne de saut suivant pour plusieurs routes statiques personnalisées disposant de la même destination et de la même priorité.

    Sans tags : sans tags réseau, vous ne pouvez pas créer plusieurs routes statiques personnalisées ayant la même combinaison de destination, de priorité et d'équilibreur de charge TCP/UDP interne de saut suivant. Par exemple, route-x, route-y et route-z peuvent être créés, mais route-x-copy ne peut pas être créé.

    Exemples de routes sans tags utilisant un équilibreur de charge TCP/UDP interne de saut suivant commun
    Exemples de routes sans tags utilisant un équilibreur de charge TCP/UDP interne de saut suivant commun
  • Tags réseau Vous pouvez spécifier des tags réseau de sorte que la route de saut suivant ne s'applique qu'aux instances clientes qui ont été configurées avec le tag. Cela vous permet de sélectionner les instances clientes dotées d'une route de saut suivant avec tags et l'ensemble des appareils vers lesquels acheminer le trafic.

    Vous n'avez pas besoin de répartir les différentes instances clientes dans des réseaux VPC distincts. Chacune d'elles pointe vers son équilibreur de charge TCP/UDP interne préféré afin d'interfacer un ensemble d'appareils.

  • Plusieurs routes vers le même préfixe de destination. Avec les tags, vous pouvez spécifier plusieurs routes vers la même destination avec différents équilibreurs de charge internes en tant que sauts suivants. Vous pouvez utiliser des propriétés ou des tags différents pour ces mêmes routes de destination.

Cas d'utilisation

Vous pouvez utiliser un équilibreur de charge TCP/UDP 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 TCP/UDP interne est un équilibreur de charge pass-through 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 TCP/UDP interne.

Utiliser un équilibreur de charge TCP/UDP 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 (cliquez pour agrandir)
Cas d'utilisation de NAT (cliquez sur l'image pour l'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 personnalisées qui présentent un saut suivant vers la passerelle Internet par défaut sont exclues. Les routes statiques personnalisées qui utilisent des équilibreurs de charge TCP/UDP 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 TCP/UDP interne avec des dispositifs virtuels de pare-feu en tant que backends.
  • Dans le réseau VPC hub, créez une route statique personnalisée et définissez le saut suivant en tant qu'équilibreur de charge TCP/UDP 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 saut suivant 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 saut suivant 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.
Réseau hub et spoke (cliquez pour agrandir)
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 TCP/UDP 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 TCP/UDP 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 (cliquez sur l'image pour l'agrandir)
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.

Notes :

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

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

  • Le hachage symétrique n'est compatible qu'avec l'équilibrage de charge TCP/UDP interne.

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

    • Adresse IP du client (2-tuple)
    • Adresse IP et protocole du client (3-tuple)
    • Adresse IP, protocole et port du client (5-tuple)
  • Vous pouvez éventuellement utiliser la traduction d'adresse réseau source si votre cas d'utilisation l'exige pour une raison quelconque.

Étape suivante