L'affinité de zone, configurée sur le service de backend de l'équilibreur de charge, vous permet de limiter le trafic entre les zones, de réduire la latence et d'améliorer les performances, tout en conservant les avantages d'une architecture multizone.
Les équilibreurs de charge réseau passthrough internes sont compatibles 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.
Avant de commencer
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.
Compatible
- Sauts suivants pour les routes statiques
- Sauts suivants pour les routes basées sur des règles
- Basculement
- Le hachage symétrique n'est compatible que lorsque l'affinité zonale est activée pour les deux équilibreurs de charge réseau passthrough internes.
Non compatible
L'affinité zonale n'est pas compatible avec les équilibreurs de charge réseau passthrough internes configurés avec les éléments suivants :
- Sous-paramètre du backend
- Destinations de collecteur pour la mise en miroir de paquets
- Déploiements de l'intégration de la sécurité réseau (NSI, Network Security Integration), en bande ou hors bande. L'utilisation de l'affinité zonale avec l'intégration de la sécurité réseau entraîne une perte de paquets.
- Service Private Service Connect publié L'affinité zonale n'est possible que pour les clients compatibles qui envoient des paquets à l'équilibreur de charge, et non à un point de terminaison Private Service Connect dont le producteur de services publié utilise un équilibreur de charge réseau passthrough interne.
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 :
Tunnels Cloud VPN client et rattachements de VLAN Cloud Interconnect client : 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é de zone, 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 à celle 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 l'un des backends de l'équilibreur de charge.
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 retombées.
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.
Différents types de backend
L'affinité de zone 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é zonale.
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 correspondants zonaux : 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 taux 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 qui contient au moins un backend configuré du type concerné. Les différents backends qui peuvent être configurés sont décrits dans la section Conditions de correspondance zonales.
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 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 tests de correspondance zonaux |
|---|---|
| Tous les backends principaux opérationnels |
Tous les backends principaux configurés Les backends principaux configurés peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
| Tous les backends de secours opérationnels |
Tous les backends de secours configurés Les backends de secours 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 principaux éligibles d'origine sont tous non opérationnels. |
Exemple de correspondance zonale
Pour comprendre si une correspondance zonale se produit, examinez la configuration suivante pour un équilibreur de charge réseau passthrough interne.
- Backends principaux : zones A et B
- Backends de basculement : zones C et D
- Emplacement de la VM cliente : zone A
- Affinité zonale activée
- Une 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)
- Y a-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 secours configurés (zones C et D)
- Y a-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 des 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 a été établie, 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 permettent 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 taux de basculement non nul
Une fois qu'une correspondance zonale est établie, et selon le type d'option d'affinité zonale configurée, 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 correspondants zonaux. 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. Cette intersection peut être vide ou non.
Si l'intersection n'est pas vide, les backends éligibles modifiés correspondent à l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou en être un sous-ensemble.
Si l'intersection est vide, les backends éligibles modifiés sont les backends zonaux correspondants eux-mêmes, qui sont toujours différents des backends éligibles d'origine. Dans ce cas, tous les backends éligibles modifiés sont non opérationnels.
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_STAY_WITHIN_ZONE. Cette option d'affinité zonale privilégie les backends de la zone du client, même si cela signifie utiliser des backends défectueux.
| 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 une combinaison de backends opérationnels et non opérationnels. |
Tous les backends principaux de la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
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. Toutefois, tous ces backends sont non opérationnels, car l'intersection avec les backends éligibles d'origine est vide. |
| Tous les backends de secours opérationnels |
Tous les backends de secours configurés Les backends de test de correspondance zonale peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
Tous les backends de basculement dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
Tous les backends de basculement opérationnels dans la zone du client |
Intersection non vide : les backends de secours éligibles modifiés sont tous les backends de secours 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 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 secours dans la zone du client. Toutefois, tous ces backends sont non 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 principaux éligibles d'origine sont tous 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 constituer un sous-ensemble de ceux-ci. |
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 constituer un sous-ensemble de ceux-ci.
Lorsque les backends éligibles modifiés sont identiques aux backends éligibles d'origine, de 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, Google Cloud utilise la valeur par défaut 0.0.
Ratio de basculement nul
Si le ratio de débordement configuré est 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 correspondants zonaux. 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. Cette intersection peut être vide ou non.
Si cette intersection n'est pas vide, les backends éligibles modifiés correspondent à l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou en être un sous-ensemble.
Si l'intersection est vide, 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é est défini sur 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 une combinaison de backends opérationnels et non opérationnels. |
Tous les backends principaux de la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
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 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 de secours opérationnels |
Tous les backends de secours configurés Les backends de test de correspondance zonale peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
Tous les backends de basculement dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
Tous les backends de basculement opérationnels dans la zone du client |
Intersection non vide : les backends de secours é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. 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 principaux éligibles d'origine sont tous 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 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 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 correspondants zonaux. 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 nul 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 débordement, les backends éligibles modifiés correspondent à l'ensemble d'intersection. Les backends éligibles modifiés peuvent être identiques aux backends éligibles d'origine ou en être un sous-ensemble.
Si le ratio calculé est inférieur au ratio de couverture, 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 une combinaison de backends opérationnels et non opérationnels. |
Tous les backends principaux de la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
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 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 secours configurés Les backends de test de correspondance zonale peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
Tous les backends de basculement dans la zone du client Les backends zonaux correspondants peuvent être tous opérationnels ou une combinaison de backends opérationnels et non opérationnels. |
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 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. Ratio calculé < ratio de débordement : 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 principaux éligibles d'origine sont tous 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 supérieur ou égal au ratio de débordement : 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 constituer un sous-ensemble de ceux-ci. |
É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.