Par défaut, un équilibreur de charge réseau passthrough interne distribue les nouvelles connexions aux backends éligibles sans tenir compte de la zone dans laquelle se trouvent le client et le backend.
Grâce à l'affinité zonale, l'équilibreur de charge peut distribuer les nouvelles connexions d'une VM cliente donnée à un ensemble modifié de backends éligibles situés dans la zone de la VM cliente. Limiter le trafic interzone en le gardant local à la zone chaque fois que possible permet de réduire les coûts de transfert de données interzones, de réduire la latence et d'améliorer les performances, tout en conservant les avantages de l'architecture multizone.
L'affinité zonale est configurée sur le service de backend d'un équilibreur de charge réseau passthrough interne. L'équilibreur de charge est compatible avec différentes options d'affinité zonale qui offrent divers degrés de préférence pour le routage des nouvelles connexions vers les backends éligibles situés dans la même zone qu'un client compatible. Notez que les connexions établies dans la table de suivi des connexions de l'équilibreur de charge ne sont pas affectées par l'affinité de zone.
Compatibilité des fonctionnalités
Avant d'activer l'affinité zonale, vous devez comprendre quelles fonctionnalités d'équilibreur de charge réseau passthrough interne sont compatibles avec l'affinité zonale.
Fonctionnalités compatibles
- Prochains sauts pour les routes statiques
- Prochains sauts pour les routes basées sur des règles
- Basculement
- Service publié Private Service Connect. L'affinité de zone est compatible avec les clients qui envoient des paquets à un point de terminaison Private Service Connect dont le producteur de services publié utilise un équilibreur de charge réseau passthrough interne.
Fonctionnalités non compatibles
L'affinité zonale n'est pas compatible avec les équilibreurs de charge réseau passthrough internes configurés avec les éléments suivants :
Clients compatibles
L'affinité zonale n'est possible que pour les VM clientes situées dans la même région que l'équilibreur de charge. L'affinité zonale n'est pas compatible avec les clients suivants, qui fonctionnent toujours comme si l'affinité zonale était désactivée :
Clients connectés via des tunnels Cloud VPN et des rattachements de VLAN Cloud Interconnect : les tunnels Cloud VPN et les rattachements de VLAN Cloud Interconnect sont des ressources régionales, et non zonales. Les paquets acheminés via un tunnel Cloud VPN ou un rattachement de VLAN ne sont jamais compatibles avec l'affinité zonale, qu'ils se trouvent ou non dans la même région que l'équilibreur de charge.
VM clientes dans des régions qui ne correspondent pas à la région de l'équilibreur de charge : un équilibreur de charge réseau passthrough interne situé dans une région est accessible par les clients de toutes les autres régions si l'accès mondial est activé. Lorsque les VM clientes se trouvent dans une région différente de celle de l'équilibreur de charge, elles ne partagent jamais de zone commune avec les backends de l'équilibreur de charge.
Compatibilité avec les équilibreurs de charge réseau passthrough internes comme prochain saut
Bien que l'affinité zonale puisse être activée pour les équilibreurs de charge réseau passthrough internes utilisés comme prochains sauts pour les routes statiques, elle est généralement déconseillée pour les architectures avec état où des dispositifs virtuels tels que des pare-feu sont configurés en parallèle et où des entités d'équilibrage de charge sont placées de chaque côté des pare-feu.
Pour en savoir plus, consultez la section Exigences du guide Équilibreurs de charge réseau passthrough internes comme prochains sauts.
Options d'affinité zonale
Les équilibreurs de charge réseau passthrough internes sont compatibles avec les options d'affinité zonale suivantes :
ZONAL_AFFINITY_DISABLED(par défaut) : l'affinité zonale est désactivée. L'équilibreur de charge sélectionne un backend éligible pour une nouvelle connexion sans modifier l'ensemble des backends éligibles d'origine.ZONAL_AFFINITY_STAY_WITHIN_ZONE: l'affinité zonale est activée. Lorsqu'une correspondance zonale se produit, l'équilibreur de charge conserve le trafic dans la zone du client, même si cela signifie utiliser des backends non opérationnels. Pour en savoir plus sur cette option, consultez Fonctionnement deZONAL_AFFINITY_STAY_WITHIN_ZONE.ZONAL_AFFINITY_SPILL_CROSS_ZONE: l'affinité zonale est activée. Lorsqu'une correspondance zonale se produit, l'équilibreur de charge permet de distribuer les nouvelles connexions dans la zone du client ou de les répartir dans d'autres zones. Le débordement est contrôlé par le ratio de débordement. Pour en savoir plus sur cette option, consultez Fonctionnement deZONAL_AFFINITY_SPILL_CROSS_ZONEet du ratio de débordement.
Pour savoir comment configurer l'affinité zonale sur le service de backend d'un équilibreur de charge réseau passthrough interne, consultez Utiliser l'affinité zonale.
Fonctionnement de l'affinité zonale
Les sections suivantes vous permettront de mieux comprendre le fonctionnement de l'affinité zonale. Il n'est pas nécessaire de comprendre ces détails pour configurer l'affinité zonale, mais cela peut vous aider à comprendre les cas spéciaux et le comportement précis de la répartition du trafic.
Plus précisément, ces sections couvrent les points suivants :
Différents types de backends utilisés dans le processus de sélection.
Comment l'équilibreur de charge détermine une correspondance zonale.
La logique d'affinité zonale détaillée pour différentes options de configuration.
Différents types de backends
L'affinité zonale crée un ensemble de backends éligibles modifiés en fonction des backends éligibles et configurés d'origine de l'équilibreur de charge. Pour expliquer comment l'affinité zonale effectue cette modification, nous définissons précisément cinq ensembles de backend différents. Ce document fait référence aux termes suivants dans les sections ultérieures pour expliquer le fonctionnement de l'affinité de zone.
Ensembles d'entrées
Backends configurés : ensemble de tous les backends qui font partie du service de backend de l'équilibreur de charge. Cela inclut tous les backends principaux et, si la fonctionnalité de basculement est activée, tous les backends principaux et de basculement.
Backends éligibles d'origine : sous-ensemble de backends configurés qui sont éligibles pour recevoir de nouvelles connexions. L'ensemble des backends éligibles d'origine est produit par l'étape Identifier les backends éligibles du processus de sélection du backend et de suivi des connexions.
Ensembles intermédiaires
Backends de test de correspondance zonale : sous-ensemble de backends configurés utilisés pour tester une correspondance zonale. Les backends configurés et les backends éligibles d'origine déterminent les VM qui sont des backends de test de correspondance zonale.
Backends zonaux correspondants : sous-ensemble des backends de test de correspondance zonale qui se trouvent dans la même zone qu'un client compatible.
Ensemble de sortie
- Backends éligibles modifiés : selon le type d'affinité zonale configuré et le ratio de débordement, les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, un sous-ensemble des backends éligibles d'origine ou différents des backends éligibles d'origine. Cet ensemble est utilisé pour fournir l'affinité zonale configurée.
Correspondance zonale
Une correspondance zonale décrit les conditions dans lesquelles l'affinité zonale est déclenchée. L'équilibreur de charge peut ensuite modifier l'ensemble des backends éligibles d'origine pour fournir l'affinité zonale configurée. La modification des backends éligibles d'origine a lieu après que l'équilibreur de charge a sélectionné un backend éligible pour une nouvelle connexion.
Pour que la logique d'affinité zonale soit déclenchée, la séquence d'événements suivante doit se produire :
L'affinité zonale doit être activée.
Si l'affinité zonale est activée, passez à l'étape suivante.
Déterminez si le client est un client compatible.
Si le client est compatible, passez à l'étape suivante.
Déterminez si une correspondance zonale peut se produire.
Une correspondance zonale signifie que la VM cliente se trouve dans une zone contenant au moins un backend de test de correspondance zonale. Les backends de test de correspondance zonale sont un ensemble de backends configurés, basés sur les backends éligibles d'origine. Pour en savoir plus, consultez Conditions de correspondance zonale.
Une correspondance zonale n'est jamais possible si l'une des conditions suivantes est remplie :
- L'affinité zonale est désactivée
- Le client n'est pas un client compatible
Appliquez la logique d'affinité zonale.
Conditions de correspondance zonales
Pour qu'une correspondance zonale se produise, au moins une instance ou un point de terminaison dans les backends de test de correspondance zonale doit se trouver dans la même zone qu'un client compatible. Les backends configurés et les backends éligibles d'origine sont des entrées utilisées pour déterminer les backends de test de correspondance zonale.
| Backends éligibles d'origine | Backends de test de correspondance zonale |
|---|---|
| Tous les backends principaux opérationnels |
Tous les backends principaux configurés Les backends principaux configurés peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
| Tous les backends de secours opérationnels |
Tous les backends de basculement configurés Les backends de basculement configurés peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
| Tous les backends principaux non opérationnels |
Tous les backends principaux configurés Les backends principaux configurés sont tous non opérationnels par définition lorsque les backends éligibles d'origine sont tous des backends principaux non opérationnels. |
Exemple de correspondance zonale
Prenons l'exemple de configuration suivant pour un équilibreur de charge réseau passthrough interne afin de comprendre si une correspondance zonale se produit.
- Backends principaux : zones A et B
- Backends de basculement : zones C et D
- Emplacement de la VM cliente : zone A
- Affinité zonale activée
- La stratégie de basculement par défaut est présente
Scénario 1 :
- Backends éligibles d'origine : tous les backends principaux opérationnels (zones A et B)
- Backends de test de correspondance zonale : tous les backends principaux configurés (zones A et B)
- Existe-t-il une correspondance zonale ? : Oui. Dans ce cas, la VM cliente se trouve dans la même zone que les backends de test de correspondance zonale. Il y a donc une correspondance zonale.
Scénario 2 :
- Backends éligibles d'origine : tous les backends de basculement opérationnels (zones C et D)
- Backends de test de correspondance zonale : tous les backends de basculement configurés (zones C et D)
- Existe-t-il une correspondance zonale ? : Non. Pour qu'une correspondance zonale se produise, la VM cliente doit se trouver dans une zone contenant au moins un backend de l'ensemble de backends de test de correspondance zonale. Dans ce cas, le client se trouve dans la zone A, et les backends de test de correspondance zonale se trouvent dans les zones C et D.
Une fois qu'une correspondance zonale s'est produite, vous appliquez la logique d'affinité zonale, comme indiqué dans les sections suivantes.
Logique d'affinité zonale
Si une correspondance zonale se produit, appliquez la logique d'affinité zonale en fonction de l'option d'affinité zonale configurée. Les options qui activent l'affinité zonale sont les suivantes :
ZONAL_AFFINITY_STAY_WITHIN_ZONEZONAL_AFFINITY_SPILL_CROSS_ZONEavec un ratio de basculement de0ZONAL_AFFINITY_SPILL_CROSS_ZONEavec un ratio de basculement non nul
Une fois qu'une correspondance zonale est établie et en fonction du type d'option d'affinité zonale configuré, les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, un sous-ensemble des backends éligibles d'origine ou différents des backends éligibles d'origine.
Fonctionnement de ZONAL_AFFINITY_STAY_WITHIN_ZONE
Si l'affinité zonale est définie sur ZONAL_AFFINITY_STAY_WITHIN_ZONE et qu'une correspondance zonale se produit, l'équilibreur de charge distribue les nouvelles connexions aux backends éligibles modifiés. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, un sous-ensemble des backends éligibles d'origine ou différents des backends éligibles d'origine.
Pour créer des backends éligibles modifiés, l'équilibreur de charge utilise le processus suivant :
Commencez par les backends de test de correspondance zonale identifiés par la condition de correspondance zonale.
Supprimez tous les backends qui ne se trouvent pas dans la même zone que le client. Cela nous donne un ensemble de backends zonaux correspondants. Cet ensemble n'est jamais vide, car une correspondance zonale a eu lieu.
Calculez l'intersection des backends zonaux correspondants avec les backends éligibles d'origine. Cette intersection peut être vide ou non.
Si l'intersection n'est pas vide, les backends éligibles modifiés sont l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, ou les backends éligibles modifiés peuvent être un sous-ensemble des backends éligibles d'origine.
Si l'intersection est vide, les backends éligibles modifiés sont les backends correspondants zonaux eux-mêmes, qui sont toujours différents des backends éligibles d'origine. Dans ce cas, tous les backends éligibles modifiés ne sont pas opérationnels.
Le tableau suivant récapitule le processus de création de l'ensemble de backends éligibles modifiés lorsque l'option d'affinité zonale est ZONAL_AFFINITY_STAY_WITHIN_ZONE. Cette option d'affinité zonale favorise les backends de la zone du client, même si cela signifie utiliser des backends non opérationnels.
| Backends éligibles d'origine (A) | Backends de tests de correspondance zonaux (B) | Backends zonaux correspondants (C) | Intersection (A∩C) | Backends éligibles modifiés |
|---|---|---|---|---|
| Tous les backends principaux opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends principaux dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels ou une combinaison des deux. |
Tous les backends principaux opérationnels dans la zone du client |
Intersection non vide : les backends éligibles modifiés sont tous les backends principaux opérationnels de la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou constituer un sous-ensemble de ceux-ci. L'intersection est vide : les backends éligibles modifiés sont tous les backends principaux non opérationnels de la zone du client. Les backends éligibles modifiés sont les mêmes que les backends zonaux correspondants, qui sont tous des backends principaux dans la zone du client. Cependant, tous ces backends ne sont pas opérationnels, car l'intersection avec les backends éligibles d'origine est vide. |
| Tous les backends de secours opérationnels |
Tous les backends de basculement configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends de secours dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels, ou une combinaison des deux. |
Tous les backends de basculement opérationnels dans la zone du client |
L'intersection n'est pas vide : les backends éligibles modifiés sont tous les backends de secours opérationnels dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou constituer un sous-ensemble de ceux-ci. L'intersection est vide : les backends éligibles modifiés sont tous les backends de basculement non opérationnels dans la zone du client. Les backends éligibles modifiés sont les mêmes que les backends zonaux correspondants, qui sont tous des backends de basculement dans la zone du client. Cependant, tous ces backends ne sont pas opérationnels, car l'intersection avec les backends éligibles d'origine est vide. |
| Tous les backends principaux non opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale sont tous non opérationnels par définition lorsque les backends éligibles d'origine sont tous des backends principaux non opérationnels. |
Tous les backends principaux non opérationnels dans la zone du client |
Tous les backends principaux non opérationnels dans la zone du client |
L'intersection n'est jamais vide : les backends éligibles modifiés sont tous les backends principaux non opérationnels de la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou à un sous-ensemble des backends éligibles d'origine. |
Fonctionnement de ZONAL_AFFINITY_SPILL_CROSS_ZONE et du ratio de basculement
Si l'affinité zonale est définie sur ZONAL_AFFINITY_SPILL_CROSS_ZONE et qu'une correspondance zonale se produit, l'équilibreur de charge distribue les nouvelles connexions aux backends éligibles modifiés. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou en être un sous-ensemble.
Lorsque les backends éligibles modifiés sont identiques aux backends éligibles d'origine, les nouvelles connexions peuvent être envoyées aux backends éligibles de la zone du client ou à des backends éligibles de n'importe quelle zone ("débordement"). Cette répartition dépend d'un ratio de débordement configurable.
Un ratio de basculement configurable indique la valeur seuil pour conserver le trafic dans la zone du client. La valeur du ratio de basculement peut être comprise entre 0.0 et 1.0 (inclus). Si vous ne spécifiez pas de taux de débordement lorsque vous configurez ZONAL_AFFINITY_SPILL_CROSS_ZONE, Cloud de Confiance utilise la valeur par défaut 0.0.
Ratio de basculement nul
Si le ratio de débordement configuré est de 0.0, l'équilibreur de charge utilise le processus suivant pour créer les backends éligibles modifiés :
Commencez par les backends de test de correspondance zonale identifiés par la condition de correspondance zonale.
Supprimez tous les backends qui ne se trouvent pas dans la même zone que le client. Cela nous donne un ensemble de backends zonaux correspondants. Cet ensemble n'est jamais vide, car une correspondance zonale a eu lieu.
Calculez l'intersection des backends correspondants aux zones avec les backends éligibles d'origine. Cette intersection peut être vide ou non.
Si cette intersection n'est pas vide, les backends éligibles modifiés sont l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, ou les backends éligibles modifiés peuvent être un sous-ensemble des backends éligibles d'origine.
Si l'intersection est vide, les backends éligibles modifiés sont identiques aux backends éligibles d'origine.
Le tableau suivant récapitule le processus de création de l'ensemble de backends éligibles modifiés lorsque l'option d'affinité zonale est ZONAL_AFFINITY_SPILL_CROSS_ZONE et que le ratio de débordement configuré est 0.0.
| Backends éligibles d'origine (A) | Backends de tests de correspondance zonaux (B) | Backends zonaux correspondants (C) | Intersection (A∩C) | Backends éligibles modifiés |
|---|---|---|---|---|
| Tous les backends principaux opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends principaux dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels ou une combinaison des deux. |
Tous les backends principaux opérationnels dans la zone du client |
Intersection non vide : les backends éligibles modifiés sont tous les backends principaux opérationnels de la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou à un sous-ensemble des backends éligibles d'origine. L'intersection est vide : les backends éligibles modifiés sont identiques aux backends éligibles d'origine. Les nouvelles connexions peuvent être distribuées dans la zone du client ou dans d'autres zones. |
| Tous les backends de secours opérationnels |
Tous les backends de basculement configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends de secours dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels, ou une combinaison des deux. |
Tous les backends de basculement opérationnels dans la zone du client |
L'intersection n'est pas vide : les backends éligibles modifiés sont tous les backends de secours opérationnels dans la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou constituer un sous-ensemble de ceux-ci. L'intersection est vide : les backends éligibles modifiés sont identiques aux backends éligibles d'origine. Les nouvelles connexions peuvent être distribuées dans la zone du client ou dans d'autres zones. |
| Tous les backends principaux non opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale sont tous non opérationnels par définition lorsque les backends éligibles d'origine sont tous des backends principaux non opérationnels. |
Tous les backends principaux non opérationnels dans la zone du client |
Tous les backends principaux non opérationnels dans la zone du client |
L'intersection n'est jamais vide : les backends éligibles modifiés sont tous les backends principaux non opérationnels dans la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou à un sous-ensemble des backends éligibles d'origine. |
Ratio de basculement non nul
Si le ratio de débordement configuré est supérieur à 0.0, mais inférieur ou égal à 1.0, l'équilibreur de charge utilise le processus suivant pour créer les backends éligibles modifiés :
Commencez par les backends de test de correspondance zonale identifiés par la condition de correspondance zonale.
Supprimez tous les backends qui ne se trouvent pas dans la même zone que le client. Cela nous donne un ensemble de backends zonaux correspondants. Cet ensemble n'est jamais vide, car une correspondance zonale a été trouvée.
Calculez l'intersection des backends zonaux correspondants avec les backends éligibles d'origine. Cet ensemble peut être vide ou non.
Calculez le ratio suivant :
$$ \frac{\text{count}(\text{zonal matched backends} \; \cap \; \text{original eligible backends})}{\text{count}(\text{zonal matched backends})} $$Notez que le ratio calculé est toujours égal à zéro lorsque l'ensemble d'intersection est vide.
Utilisez le ratio calculé pour déterminer les backends éligibles modifiés :
Si le ratio calculé est supérieur ou égal au ratio de retombées, les backends éligibles modifiés correspondent à l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine, ou ils peuvent être un sous-ensemble des backends éligibles d'origine.
Si le ratio calculé est inférieur au ratio de débordement, les backends éligibles modifiés sont les mêmes que les backends éligibles d'origine.
Le tableau suivant récapitule le processus de création de l'ensemble des backends éligibles modifiés lorsque l'option d'affinité zonale est définie sur ZONAL_AFFINITY_SPILL_CROSS_ZONE et que le ratio de débordement configuré n'est pas 0.0 :
| Backends éligibles d'origine (A) | Backends de tests de correspondance zonaux (B) | Backends zonaux correspondants (C) | Intersection (A∩C) | Backends éligibles modifiés |
|---|---|---|---|---|
| Tous les backends principaux opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends principaux dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels ou une combinaison des deux. |
Tous les backends principaux opérationnels dans la zone du client |
Ratio calculé ≥ ratio de basculement : les backends éligibles modifiés sont tous les backends principaux opérationnels de la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou constituer un sous-ensemble de ceux-ci. Ratio calculé < ratio de débordement : les backends éligibles modifiés sont les mêmes que les backends éligibles d'origine. Les nouvelles connexions peuvent être distribuées dans la zone du client ou dans d'autres zones. |
| Tous les backends de secours opérationnels |
Tous les backends de basculement configurés Les backends de test de correspondance zonale peuvent être tous opérationnels, ou certains peuvent être opérationnels et d'autres non. |
Tous les backends de secours dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels, tous non opérationnels, ou une combinaison des deux. |
Tous les backends de basculement opérationnels dans la zone du client |
Ratio calculé ≥ ratio de basculement : les backends éligibles modifiés sont tous les backends de secours opérationnels de la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou constituer un sous-ensemble de ceux-ci. Ratio calculé < ratio de débordement : les backends éligibles modifiés sont les mêmes que les backends éligibles d'origine. Les nouvelles connexions peuvent être distribuées dans la zone du client ou dans d'autres zones. |
| Tous les backends principaux non opérationnels |
Tous les backends principaux configurés Les backends de test de correspondance zonale sont tous non opérationnels par définition lorsque les backends éligibles d'origine sont tous des backends principaux non opérationnels. |
Tous les backends principaux non opérationnels dans la zone du client |
Tous les backends principaux non opérationnels dans la zone du client |
Le ratio calculé est toujours ≥ au ratio de basculement : les backends éligibles modifiés sont tous les backends principaux non opérationnels dans la zone du client. Les nouvelles connexions sont distribuées dans la zone du client. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou à un sous-ensemble des backends éligibles d'origine. |
Exemples de ratios de basculement
Les exemples suivants montrent comment fonctionne ZONAL_AFFINITY_SPILL_CROSS_ZONE.
Un ratio de basculement de
1.0signifie :- Lorsque l'intersection des backends zonaux correspondants et des backends éligibles d'origine est le même ensemble que les backends zonaux correspondants, les backends éligibles modifiés sont l'ensemble d'intersection.
- Lorsque l'intersection des backends zonaux correspondants et des backends éligibles d'origine n'est pas identique à l'ensemble des backends zonaux correspondants, les backends éligibles modifiés sont identiques aux backends éligibles d'origine.
Un ratio de basculement de
0.8signifie que :- Lorsque le nombre de backends dans l'intersection des backends zonaux correspondants et des backends éligibles d'origine est d'au moins 80 % du nombre de backends zonaux correspondants, les backends éligibles modifiés correspondent à cet ensemble d'intersection.
- Lorsque le nombre de backends dans l'intersection des backends zonaux mis en correspondance et des backends éligibles d'origine est inférieur à 80 % du nombre de backends zonaux mis en correspondance, les backends éligibles modifiés sont identiques aux backends éligibles d'origine.
Un ratio de basculement de
0.0signifie que :- Si l'intersection des backends zonaux correspondants et des backends éligibles d'origine n'est pas vide, les backends éligibles modifiés correspondent à l'ensemble d'intersection.
- Si l'intersection des backends zonaux correspondants et des backends éligibles d'origine est vide, les backends éligibles modifiés sont identiques aux backends éligibles d'origine.
Prenons l'exemple d'une configuration dans laquelle un équilibreur de charge réseau passthrough interne est configuré avec une option d'affinité zonale ZONAL_AFFINITY_SPILL_CROSS_ZONE et un ratio de débordement de 0.8 :
- Backends configurés : dix backends principaux (cinq dans la zone 1, cinq dans la zone 2)
- Backends éligibles d'origine : tous les backends principaux opérationnels (huit backends : cinq dans la zone 1, trois dans la zone 2)
- Backends de test de correspondance zonale : les dix backends principaux configurés
Scénario A : client compatible dans la zone 1
- Backends zonaux correspondants : cinq backends dans la zone 1.
- Intersection : l'intersection des backends zonaux correspondants et des backends éligibles d'origine se compose des cinq backends opérationnels de la zone 1.
- Ratio calculé : 5 / 5 = 1,0
- Résultat : Comme le ratio calculé de 1,0 est supérieur ou égal à 0,8, les backends éligibles modifiés se trouvent dans l'ensemble d'intersection, c'est-à-dire les cinq backends principaux opérationnels de la zone 1 du client. Les nouvelles connexions sont distribuées exclusivement dans la zone du client.
Scénario B : Client compatible dans la zone 2
- Backends zonaux correspondants : cinq backends dans la zone 2.
- Intersection : l'intersection des backends zonaux correspondants et des backends éligibles d'origine se compose des trois backends opérationnels de la zone 2.
- Ratio calculé : 3 / 5 = 0,6
- Résultat : étant donné que le ratio calculé de 0,6 est inférieur à 0,8, les backends éligibles modifiés sont les backends éligibles d'origine. Les backends éligibles d'origine sont les huit backends opérationnels (cinq dans la zone 1, trois dans la zone 2). Les nouvelles connexions sont réparties entre la zone 1 et la zone 2.
Étapes suivantes
- Pour configurer Cloud Monitoring pour les équilibreurs de charge réseau passthrough internes, consultez la page Journalisation et surveillance des équilibreurs de charge réseau passthrough internes.
- Pour résoudre les problèmes liés à votre équilibreur de charge réseau passthrough interne, consultez la page Résoudre les problèmes liés aux équilibreurs de charge réseau passthrough internes.