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

Cette configuration est utile dans les cas suivants :

  • Lorsque vous devez équilibrer le trafic sur plusieurs VM qui fonctionnent comme des dispositifs virtuels de traduction d'adresses réseau (NAT).

  • Lorsque vous avez besoin qu'un équilibreur de charge serve de saut suivant pour une route par défaut. Lorsque des instances de VM de votre réseau de cloud privé virtuel (VPC) envoient du trafic vers Internet, le trafic est acheminé via des dispositifs virtuels de passerelle à équilibrage de charge.

  • Lorsque vous devez envoyer du trafic via plusieurs équilibreurs de charge dans deux directions ou plus en utilisant le même ensemble de VM dotées 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.

É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)

Dans le schéma précédent, un groupe d'instances de VM sert de backend pour deux équilibreurs de charge différents. Ce cas d'utilisation est appelé équilibreurs de charge TCP/UDP internes en tant que sauts suivants avec des backends communs, car plusieurs cartes d'interface réseau (nic0 et nic1, dans ce cas) sur les VM de backend sont en cours d'équilibrage de charge. Ce déploiement est autorisé, car l'équilibrage de charge TCP/UDP interne accepte l'équilibrage de charge vers n'importe quelle interface sur les instances de VM de backend (pas seulement l'interface principale nic0).

En revanche, deux ensembles d'instances de VM peuvent servir de backends pour deux équilibreurs de charge différents. Vous pouvez utiliser deux ensembles de backends lorsque vous disposez de profils de trafic différents pour le trafic entrant et sortant. Ce cas d'utilisation est appelé équilibreurs de charge TCP/UDP internes en tant que sauts suivants avec des backends différents, car seules les interfaces principales (nic0) sur les VM de backend sont soumises à l'équilibrage de charge. Cette configuration est illustrée par le schéma ci-dessous :

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

Vous pouvez créer une route statique personnalisée pour transmettre le trafic TCP et UDP à un équilibreur de charge TCP/UDP interne, l'équilibreur de charge représentant le saut suivant pour la route statique. La route peut être la route par défaut (0.0.0.0/0), 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.

Pour utiliser la route statique personnalisée, les instances de VM dans chaque réseau VPC doivent se trouver dans la même région que leur équilibreur de charge associé.

Si un routeur cloud se trouve dans la même région qu'un équilibreur de charge, vous pouvez annoncer cette route à d'autres réseaux connectés à l'aide des annonces de routage personnalisées Cloud Router. Pour en savoir plus, consultez la page Équilibrage de charge TCP/UDP interne et réseaux connectés.

Pour en savoir plus, consultez les pages suivantes :

Avantages de l'utilisation de votre équilibreur de charge TCP/UDP interne en tant que saut suivant

Lorsque vous utilisez un équilibreur de charge en tant que saut suivant pour une route statique, vous n'avez pas besoin de configurer explicitement vos clients pour envoyer du trafic vers l'équilibreur de charge ou vers chaque VM de backend. Vous pouvez intégrer vos VM de backend 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.

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

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, et non en utilisant 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 cette règle de transfert 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 Remarques sur le routage basé sur l'instance ou sur l'é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 tronçon suivant, Google Cloud transfère tout le trafic TCP/UDP sur tous les ports aux machines virtuelles 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 traite uniquement le trafic TCP et UDP et ignore tout autre trafic, tel que ICMP. Le trafic qui n'utilise pas le protocole TCP ou UDP est géré par la route suivante la plus spécifique de votre réseau VPC. Les routes du trafic non TCP et UDP présentent les caractéristiques suivantes :

  • Elles n'ont pas d'équilibreur de charge TCP/UDP interne comme saut suivant.
  • Elles sont choisies en fonction de l'ordre de routage.

Par exemple, supposons que vous disposez des routes suivantes dans votre réseau VPC :

  • Destination : 1.1.1.1/32, saut suivant : équilibreur de charge TCP/UDP interne
  • Destination : 1.0.0.0/8, saut suivant : passerelle Internet par défaut

Pour les clients situés dans la même région que l'équilibreur de charge (ou dans n'importe quelle région lorsque l'accès global est activé), le trafic TCP et UDP destiné à 1.1.1.1/32 utilise la route avec le saut suivant d'équilibreur de charge TCP/UDP.

Pour le trafic non TCP et UDP (comme les pings ICMP), la route 1.0.0.0/8 est utilisée à la place.

Spécifications supplémentaires

  • Une route statique personnalisée ne peut pas utiliser de tags réseau si elle dispose d'un équilibreur de charge TCP/UDP interne en tant que saut suivant.

  • Vous ne pouvez pas créer plusieurs routes statiques personnalisées avec la même priorité, la même destination et le même équilibreur de charge TCP/UDP interne de saut suivant. Par conséquent, chaque route statique personnalisée avec le même équilibreur de charge de saut suivant doit comporter au moins une destination unique ou une priorité unique.

  • Si vous avez différents équilibreurs de charge TCP/UDP internes en tant que sauts suivants pour plusieurs routes ayant la même destination et la même priorité, Google Cloud ne distribue pas le trafic entre les équilibreurs de charge. Au lieu de cela, Google Cloud choisit un seul équilibreur de charge comme saut suivant pour tout le trafic correspondant à la destination et ignore les autres équilibreurs de charge.

  • Lorsque vous utilisez un équilibreur de charge TCP/UDP interne comme saut suivant pour une route statique personnalisée, vous ne pouvez pas utiliser le tag --purpose=SHARED_LOADBALANCER_VIP avec l'adresse IP de la règle de transfert interne. En effet, l'adresse IP interne partagée peut référencer indirectement plusieurs services de backend.

Pour en savoir plus, consultez la page Présentation des routes.

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 transmissions par NAT et par proxy ne sont effectuées que par les VM de backend : les dispositifs virtuels de pare-feu.

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 utilisent des tags réseau ou qui présentent un saut suivant vers la passerelle Internet par défaut sont exclus.

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.

L'équilibreur de charge du dispositif de pare-feu du saut suivant dans le réseau VPC hub peut être utilisé dans chaque réseau spoke, selon l'ordre de routage.

Réseau en étoile (cliquez pour agrandir)
Réseau en étoile (cliquez sur l'image pour l'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 instances de pare-feu ou des passerelles NAT) avec des cartes d'interface réseau dans plusieurs réseaux VPC. Les instances de pare-feu et les passerelles NAT peuvent être fournies par un tiers en tant que dispositifs virtuels. 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 sur chaque dispositif virtuel, mais il peut s'agir de n'importe quelle carte d'interface réseau.

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.

Utiliser un équilibreur de charge TCP/UDP interne en tant que saut suivant avec une carte d'interface réseau unique

Comme dans le cas d'utilisation précédent, les VM de backend sont des instances de dispositif virtuel (par exemple, des instances de pare-feu ou des passerelles NAT) avec des cartes d'interface réseau dans plusieurs réseaux VPC.

Les exemples suivants présentent deux ensembles de dispositifs virtuels de backend dans deux groupes d'instances de VM gérées.

Les backends sont résumés comme suit.

Instances à équilibrage de charge pour le trafic testing vers le trafic production Instances à équilibrage de charge pour le trafic production vers le trafic testing
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

Dans la direction testing vers production, le trafic provient du réseau VPC appelé testing. Dans le réseau testing, l'équilibreur de charge TCP/UDP interne dispose d'une règle de transfert appelée fr-ilb1. Cet exemple utilise des équilibreurs de charge TCP/UDP internes avec des services de backend qui n'ont pas de paramètre network spécifié. Cela signifie que chaque équilibreur de charge ne distribue que le trafic vers l'interface réseau principale de chaque VM de backend.

Trafic avec équilibrage de charge sur une carte d&#39;interface réseau unique (<code>testing</code> vers <code>production</code>) (cliquez sur l&#39;image pour l&#39;agrandir)
Trafic avec équilibrage de charge sur une carte d'interface réseau unique (testing vers production) (cliquez sur l'image pour l'agrandir)

Dans la direction production vers testing, le trafic provient du réseau VPC appelé production. Dans le réseau production, un autre équilibreur de charge TCP/UDP interne dispose d'une règle de transfert appelée fr-ilb2. Encore une fois, cet exemple utilise des équilibreurs de charge TCP/UDP internes avec des services de backend qui n'ont pas de paramètre network spécifié. Cela signifie que chaque équilibreur de charge ne distribue que le trafic vers l'interface réseau principale de chaque VM de backend. Chaque dispositif virtuel ne pouvant avoir qu'une seule interface réseau nic0, ce déploiement nécessite un second ensemble de dispositifs virtuels, le premier pour l'équilibrage de charge testing vers production et le second pour l'équilibrage de charge production vers testing.

Trafic avec équilibrage de charge sur une carte d&#39;interface réseau unique (<code> production</code> vers <code> tests</code>) (cliquez sur l&#39;image pour l&#39;agrandir)
Trafic avec équilibrage de charge sur une carte d'interface réseau unique (production vers testing) (cliquez sur l'image pour l'agrandir)

Étape suivante