Équilibreurs de charge réseau internes à stratégie directe comme sauts suivants

Un équilibreur de charge réseau interne à stratégie directe 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 interne à stratégie directe 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 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 :

• Présentation des routes
• Présentation de l'équilibreur de charge réseau à stratégie directe interne

Un saut suivant d'équilibreur de charge réseau interne à stratégie directe 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 réseau interne à stratégie directe 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.

Remarque : Cette fonctionnalité n'est pas compatible avec les adresses IPv6.

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 interne à stratégie directe envoie des paquets à nic0 sur les VM de backend, et le second équilibreur de charge réseau interne à stratégie directe 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)

Avantages de l'utilisation de votre équilibreur de charge réseau interne à stratégie directe 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 interne à stratégie directe comme saut suivant pour une route statique offre les mêmes avantages qu'un équilibreur de charge réseau interne à stratégie directe 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 internes à stratégie directe comme sauts suivants.

Routes

Vous pouvez créer une route statique personnalisée pour transmettre le trafic TCP, UDP et d'autres protocoles à un équilibreur de charge réseau interne à stratégie directe où 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.

Attention : Lorsque vous envoyez du trafic vers des API et des services Google, ne l'acheminez pas via une VM de saut suivant ou un équilibreur de charge réseau interne à stratégie directe de saut suivant. Routez-le plutôt via une passerelle Internet par défaut de saut suivant. Cela inclut le trafic destiné aux API et services Google envoyé par le biais d'un accès privé à Google.

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.

Remarque : Un équilibreur de charge dont la règle de transfert utilise le protocole L3_DEFAULT ne peut pas être le saut suivant pour une route statique. Si cette route statique est créée, le trafic est interrompu sans notification.

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

Les équilibreurs de charge réseau internes à stratégie directe 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 interne à stratégie directe 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 interne à stratégie directe 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 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 réseau interne à stratégie directe. 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 réseau internes à stratégie directe 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 réseau interne à stratégie directe 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 réseau interne à stratégie directe 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 Équilibreurs de charge réseau avec stratégie internes à stratégie directe et réseaux connectés.

Ordre de priorité des opérations

Vous devez créer un équilibreur de charge réseau interne à stratégie directe 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 saut suivant de l'équilibreur de charge réseau interne à stratégie directe, 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 interne à stratégie directe, 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 réseau interne à stratégie directe pour autoriser le transfert IP (--can-ip-forward = True). Pour en savoir plus, consultez la section Considérations liées au routage de type instance et équilibreur de charge.

• Vous ne pouvez pas utiliser un équilibreur de charge réseau interne à stratégie directe 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

Important : Les informations de cette section ne s'appliquent qu'aux routes personnalisées créées avant le 15 mai 2021.

Si un équilibreur de charge réseau interne à stratégie directe utilisé en tant que route de saut suivant a été créé avant le 15 mai 2021, il ne transfère que le trafic TCP et UDP sur l'ensemble des ports des VM de backend, quelle que soit la configuration de la règle de transfert ou du service de backend. Tout le trafic restant, tel que les pings ICMP, est géré par la route suivante la plus spécifique de votre réseau VPC.

Si une route créée avant le 15 mai 2021 était toujours opérationnelle le 16 août 2021, elle a été migrée automatiquement pour transférer l'ensemble du trafic des protocoles à compter du 16 août 2021.

Lorsqu'un équilibreur de charge réseau interne à stratégie directe 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 interne à stratégie directe, 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 :

  • 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 IPv4 de règle de transfert : lorsque vous spécifiez une règle de transfert de prochain saut par son adresse IPv4, 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 internes à stratégie directe 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 interne à stratégie directe 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 interne à stratégie directe é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 internes à stratégie directe utilisés en tant que saut suivant et les règles de transfert de l'équilibreur de charge réseau interne à stratégie directe avec adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge réseau interne à stratégie directe 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 internes à stratégie directe).

• Même destination et plusieurs équilibreurs de charge réseau internes à stratégie directe comme saut suivant. Si vous créez deux routes statiques personnalisées ou plus avec la même destination et que vous utilisez différents équilibreurs de charge réseau internes à stratégie directe en tant que sauts suivants, Google Cloud ne répartit jamais le trafic entre les équilibreurs de charge utilisés en tant que saut suivant à l'aide d'ECMP. Si les routes ont des priorités uniques, Google Cloud utilise comme saut suivant l'équilibreur de charge réseau interne à stratégie directe 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 réseau interne à stratégie directe comme 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é.

  

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

• Plusieurs destinations avec le même équilibreur de charge réseau interne à stratégie directe comme saut suivant.

  Avec des tags d'instance :

  Si vous appliquez des tags d'instance (également appelés tags réseau), vous pouvez utiliser le même équilibreur de charge réseau interne à stratégie directe comme saut suivant pour plusieurs routes statiques personnalisées avec la même destination et la même priorité.

  Sans tags d'instance : sans tags d'instance, 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 réseau interne à stratégie directe utilisé comme saut suivant. Par exemple, route-x, route-y et route-z peuvent être créés, mais route-x-copy ne peut pas être créé.

  

  Les routes statiques sans tag d'instance ne peuvent pas être créées avec la même destination, la même priorité et le même équilibreur de charge réseau interne à stratégie directe en tant que saut suivant.

• Tags d'instance.

  Vous pouvez spécifier des tags d'instance (également appelés tags réseau) pour 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 réseau interne à stratégie directe préféré afin d'interfacer un ensemble d'appareils.

  Remarque : Les routes avec tag ne sont ni exportées, ni importées via l'appairage.

• 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 d'instance différents pour ces mêmes routes de destination.

Cas d'utilisation

Vous pouvez utiliser un équilibreur de charge réseau interne à stratégie directe 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 interne à stratégie directe est un équilibreur de charge à stratégie directe 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 interne à stratégie directe.

Utiliser un équilibreur de charge réseau interne à stratégie directe 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)

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 réseau internes à stratégie directe 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 interne à stratégie directe 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 réseau interne à stratégie directe.
• 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)

É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 interne à stratégie directe 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 interne à stratégie directe 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)

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 interne à stratégie directe à compter du 22 juin 2021.

• Pour activer le hachage symétrique sur les équilibreurs de charge réseau internes à stratégie directe 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 internes à stratégie directe.

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

Étapes suivantes

• Pour configurer un équilibreur de charge réseau interne à stratégie directe comme saut suivant, consultez la page Configurer un équilibreur de charge réseau interne à stratégie directe pour les dispositifs tiers ou Déployer un réseau hub et spoke à l'aide d'un équilibreur de charge en tant que saut suivant.
• Pour configurer et tester un équilibreur de charge réseau interne à stratégie directe, consultez la page Configurer un équilibreur de charge réseau interne à stratégie directe avec backends de groupe d'instances de VM.
• Pour résoudre les problèmes de saut suivant liés à votre équilibreur de charge réseau interne à stratégie directe, consultez la page Résoudre les problèmes liés à l'équilibreur de charge réseau interne à stratégie directe.