Présentation de l'équilibrage de charge avancé

L'équilibrage de charge avancé comprend des fonctionnalités qui vous permettent d'ajuster l'équilibrage de charge global et la répartition du trafic pour atteindre au mieux vos objectifs de disponibilité, de performances et de rentabilité. Ce document est destiné aux utilisateurs qui possèdent au moins une compréhension intermédiaire des concepts de Cloud Service Mesh et de l'équilibrage de charge.

Pour mettre en œuvre l'équilibrage de charge avancé, créez une règle d'équilibrage de charge de service (ressource serviceLbPolicies), qui contient des valeurs qui influencent la sélection d'un backend. Vous devez ensuite associer la stratégie d'équilibrage de charge du service à un service de backend. La règle d'équilibrage de charge du service spécifie l'algorithme utilisé pour déterminer comment le trafic est équilibré par rapport aux backends.

Vous avez le choix entre les options d'algorithme suivantes pour l'équilibrage de charge avancé:

  • Cascade par région (algorithme par défaut).
  • Vaporisez sur la zone.
  • Vaporiser sur le monde.
  • Cascade par zone.

Les options supplémentaires suivantes sont disponibles:

  • Désignez des backends préférés. Cloud Service Mesh envoie le trafic à ces MIG ou NEG avant de l'envoyer à d'autres backends.
  • Configurez la décharge automatique de la capacité.
  • Personnalisez le comportement de basculement.

Avant de configurer l'une des options d'équilibrage de charge avancées, nous vous recommandons de consulter la documentation relative à la ressource de service de backend.

Comment Cloud Service Mesh achemine et équilibre la charge du trafic

Le schéma suivant montre comment Cloud Service Mesh décide d'acheminer le trafic.

Comment Cloud Service Mesh prend des décisions concernant l'équilibrage de charge
Comment Cloud Service Mesh prend des décisions concernant l'équilibrage de charge (cliquez pour agrandir)

Tout d'abord, Cloud Service Mesh choisit un service de backend en fonction des caractéristiques des requêtes et des règles de routage de la ressource Route ou du mappage d'URL, en fonction de l'API utilisée par votre déploiement.

Ensuite, Cloud Service Mesh choisit un MIG ou un NEG de backend associé au service de backend, en fonction de l'emplacement du client, de l'emplacement, de l'état et de la capacité du MIG ou du NEG, ainsi que des informations contenues dans la règle d'équilibrage de charge du service associée au service de backend.

Enfin, Cloud Service Mesh choisit une instance ou un point de terminaison dans le MIG ou le NEG. Ce choix est basé sur les informations de la stratégie d'équilibrage de charge de localité des services de backend.

Backends compatibles et non compatibles

Les types de backends suivants sont compatibles avec l'équilibrage de charge avancé:

  • Groupes d'instances non gérés
  • Groupes d'instances gérés (MIG)
  • Groupes de points de terminaison du réseau zonaux (NEG GCE_VM_IP_PORT)
  • Groupes de points de terminaison du réseau de connectivité hybride (NEG NON_GCP_PRIVATE_IP_PORT)

Les types de backend suivants ne sont pas compatibles avec l'équilibrage de charge avancé:

  • Groupes d'instances gérés régionaux
  • Groupes de points de terminaison du réseau Internet (NEG INTERNET_FQDN_PORT)

Cas d'utilisation

Les sections suivantes décrivent le fonctionnement de chaque algorithme et décrivent ceux qu'il faut choisir en fonction des besoins spécifiques de votre entreprise.

Équilibrer le trafic entre les backends d'une région

L'algorithme d'équilibrage de charge par défaut, cascade par région, répartit le trafic de manière uniforme entre tous les MIG ou NEG des zones d'une région. Nous vous recommandons d'utiliser l'algorithme par défaut, sauf si vous avez des exigences particulières.

Avec une cascade d'annonces par région, les backends reçoivent le trafic proportionnellement à leur capacité, ce qui leur protège contre la surcharge. Le trafic est envoyé dans les limites de zone si nécessaire pour que les backends soient chargés de manière uniforme dans la région. Même si la zone locale du client a une capacité restante, il y a du trafic interzone. Les requêtes de chaque client peuvent être réparties sur plusieurs MIG ou NEG zonaux de la région, ce qui permet de maintenir uniforme la charge sur les MIG ou les NEG lorsque la charge du trafic des clients n'est pas uniforme.

Augmenter la résilience en répartissant le trafic d'un client sur plusieurs zones

L'algorithme de cascade d'annonces par région par défaut tente d'équilibrer l'utilisation de la capacité sur plusieurs MIG ou NEG zonaux. Toutefois, sous cet algorithme, les requêtes provenant d'un seul client ne sont pas systématiquement envoyées à toutes les zones, et les requêtes d'un seul client sont généralement acheminées vers des MIG ou des NEG dans une seule zone.

Utilisez l'algorithme de pulvérisation vers région lorsque vous souhaitez que les clients répartissent leurs requêtes à tous les MIG ou NEG d'une région, ce qui réduit le risque de surcharge des MIG ou des NEG dans une seule zone en cas d'augmentation rapide et localisée du volume de trafic.

Avec l'algorithme de pulvérisation vers région, si vous avez deux zones, A et B, et qu'il y a un pic de trafic dans la zone B, le trafic est réparti entre les deux zones. Avec l'algorithme par défaut, un pic dans la zone B peut déclencher une surcharge dans la zone avant que Cloud Service Mesh ne puisse répondre au changement.

Notez que lorsque vous utilisez l'algorithme de pulvérisation vers région, le trafic de chaque client est toujours réparti entre les zones backend d'une région. Cela entraîne un trafic interzone systématiquement plus élevé, même s'il reste de la capacité dans la zone locale, et peut étendre la zone affectée pour le trafic provenant de Cloud Service Mesh, si deux clients Cloud Service Mesh envoient du trafic vers les mêmes zones.

Répartir le trafic de votre client sur tous les backends de plusieurs régions

Comme indiqué dans les sections précédentes, l'algorithme de pulvérisation sur la région répartit le trafic de chaque client entre toutes les zones d'une région. Pour les services comportant des MIG ou des NEG dans plusieurs régions, Cloud Service Mesh optimise toujours la latence globale en envoyant le trafic vers la région la plus proche.

Si vous préférez un rayon de propagation plus large, utilisez l'algorithme de pulvérisation vers le monde. Avec cet algorithme, les clients répartissent leurs requêtes à l'ensemble des MIG ou des NEG du monde dans plusieurs régions.

Il est important de noter qu'avec cet algorithme, tout le trafic est réparti entre tous les backends du monde entier. Une requête défectueuse peut endommager tous les backends de vos déploiements. L'algorithme augmente également le trafic interrégional, ce qui peut augmenter la latence des requêtes et générer des coûts supplémentaires.

Minimiser le trafic entre zones

Vous pouvez optimiser la latence globale et réduire le trafic interzone à l'aide du paramètre de cascade d'annonces par zone. Lorsque plusieurs MIG ou NEG sont configurés dans une zone, le trafic client est acheminé vers le MIG ou le NEG le plus proche de la zone, dans la limite de sa capacité, avant de l'envoyer au prochain MIG ou NEG dans la zone jusqu'à ce que la totalité de la capacité du MIG ou du NEG de la zone soit utilisée. Ce n'est qu'alors que le trafic est renversé dans la zone la plus proche.

Grâce à cet algorithme, vous pouvez réduire au maximum le trafic interzone inutile. La latence globale peut être légèrement améliorée, car les backends locaux les plus proches sont privilégiés. Toutefois, cela peut également créer un trafic irrégulier entre les MIG ou les NEG d'une région.

Comparaison des algorithmes d'équilibrage de charge

Le tableau suivant fournit une comparaison détaillée des quatre algorithmes d'équilibrage de charge de Cloud Service Mesh.

Comportement Cascades d'annonces par région Poussée sur la zone Spray sur le monde Cascade par zone
Utilisation uniforme de la capacité dans une région en état stable Oui Oui Oui Non
Utilisation uniforme de la capacité dans plusieurs régions en état stable Non Non Oui Non
Répartition uniforme du trafic dans une région stable Non Oui Oui Non
Trafic interzone Oui. Cet algorithme répartit le trafic de manière uniforme entre les zones d'une région tout en optimisant la latence du réseau. Le trafic peut être envoyé d'une zone à l'autre, si nécessaire. Oui Oui Oui, le trafic remplira la zone la plus proche de sa capacité maximale. Ensuite, il passera à la zone suivante.
Sensibilité aux pics de trafic locaux Moyenne, en fonction de la quantité de trafic déjà déplacée vers l'équilibre entre les zones. Plus faible, car les pics d'une seule zone seront répartis dans toutes les zones de la région. Plus faible, car les pics d'une seule zone seront répartis dans toutes les régions. Augmentation, car les pics d'une zone unique sont plus susceptibles d'être diffusés entièrement par une seule zone jusqu'à ce que Cloud Service Mesh puisse réagir.

Options d'équilibrage de charge avancées supplémentaires

Les sections suivantes présentent les options permettant de modifier l'équilibrage de charge de Cloud Service Mesh.

Backends préférés

Vous pouvez configurer l'équilibrage de charge de manière à désigner un groupe de backends d'un service de backend à privilégier. Ces backends sont entièrement utilisés avant que les requêtes ultérieures ne soient acheminées vers les backends restants. Cloud Service Mesh distribue d'abord le trafic client vers les backends de préférence, ce qui réduit la latence des requêtes pour vos clients.

Tout trafic qui dépasse la capacité configurée des backends préférés est acheminé vers des backends non préférés. L'algorithme d'équilibrage de charge répartit le trafic entre les backends non préférés.

Un cas d'utilisation est le débordement vers Google Cloud, où vous spécifiez des ressources de calcul sur site, représentées par un NEG de connectivité hybride, à utiliser avant que les requêtes ne soient acheminées vers des MIG ou des NEG backend Google Cloud avec autoscaling. Cette configuration peut minimiser la consommation de ressources de calcul Google Cloud tout en conservant la résilience nécessaire pour un renversement progressif ou un basculement vers Google Cloud en cas de besoin.

Drainage automatique de la capacité

Lorsqu'un backend n'est pas opérationnel, il est généralement souhaitable de l'exclure le plus rapidement possible des décisions concernant l'équilibrage de charge. L'exclusion du backend empêche l'envoi de requêtes au backend non opérationnel. De plus, le trafic est équilibré entre les backends opérationnels pour éviter la surcharge des backends et optimiser la latence globale.

Cette option est semblable à la définition de capacityscalar sur zéro. Elle demande à Cloud Service Mesh de réduire automatiquement la capacité du backend à zéro lorsque moins de 25% de ses instances ou points de terminaison individuels réussissent les vérifications de l'état. Avec cette option, les backends non opérationnels sont supprimés de l'équilibrage de charge global.

Lorsque les backends qui ont été drainés automatiquement sont à nouveau opérationnels, ils sont annulés si au moins 35% des points de terminaison ou des instances sont opérationnels pendant 60 secondes. Cloud Service Mesh ne draine pas plus de 50% des points de terminaison d'un service de backend, quel que soit l'état de fonctionnement du backend.

Par exemple, vous pouvez utiliser le drainage automatique de capacité avec vos backends préférés. Si un MIG ou un NEG backend est préférable et qu'un grand nombre de ses points de terminaison ne sont pas opérationnels, ce paramètre protège les points de terminaison restants dans le MIG ou le NEG en déplaçant le trafic depuis le MIG ou le NEG.

Personnaliser le comportement de basculement

Cloud Service Mesh envoie généralement le trafic aux backends en tenant compte de plusieurs facteurs. Dans un état stable, Cloud Service Mesh envoie le trafic aux backends sélectionnés en fonction des algorithmes décrits précédemment. Les backends sélectionnés sont considérés comme optimaux en termes de latence et d'utilisation de la capacité. Ils sont appelés backends principaux.

Cloud Service Mesh effectue également le suivi des backends à utiliser lorsque les backends principaux sont non opérationnels et incapables de recevoir du trafic. Ces backends sont appelés backends de basculement. Ce sont généralement des backends à proximité qui ont encore une certaine capacité.

Lorsqu'un backend n'est pas opérationnel, Cloud Service Mesh tente d'éviter d'y envoyer du trafic et le transfère à la place vers des backends opérationnels.

La ressource serviceLbPolicy inclut un champ, failoverHealthThreshold, dont la valeur peut être personnalisée pour contrôler le comportement du basculement. La valeur de seuil que vous définissez détermine à quel moment le trafic est transféré des backends principaux vers les backends de basculement.

Lorsque certains points de terminaison du backend principal ne sont pas opérationnels, Cloud Service Mesh ne déplace pas nécessairement le trafic immédiatement. À la place, Cloud Service Mesh peut transférer le trafic vers des points de terminaison opérationnels dans le backend principal, afin d'essayer de le stabiliser.

Si un trop grand nombre de points de terminaison dans le backend ne sont pas opérationnels, les points de terminaison restants ne seront pas en mesure de gérer le trafic supplémentaire. Dans ce cas, le seuil d'échec permet de décider si le basculement est déclenché ou non. Cloud Service Mesh tolère la défaillance jusqu'au seuil défini, puis transfère une partie du trafic des backends principaux aux backends de basculement.

Le seuil de capacité de basculement est une valeur en pourcentage. La valeur que vous définissez détermine à quel moment Cloud Service Mesh dirige le trafic vers les backends de basculement. Vous pouvez définir la valeur sur un entier compris entre 1 et 99. La valeur par défaut de Cloud Service Mesh est 70 avec Envoy et 50 pour gRPC sans proxy. Une valeur supérieure lance le basculement du trafic plus tôt qu'une valeur inférieure.

Dépannage

Les modèles de répartition du trafic peuvent changer en fonction de la configuration du nouveau serviceLbPolicy avec le service de backend.

Pour déboguer les problèmes de trafic, utilisez les systèmes de surveillance existants afin d'examiner le flux du trafic vers vos backends. D'autres métriques Cloud Service Mesh et réseau peuvent vous aider à comprendre comment sont prises les décisions concernant l'équilibrage de charge. Cette section propose des suggestions générales de dépannage et d'atténuation des risques.

Dans l'ensemble, Cloud Service Mesh tente d'attribuer du trafic pour que les backends s'exécutent en dessous de leur capacité configurée. Sachez que cela n'est pas garanti. Pour en savoir plus, consultez la documentation du service de backend.

Le trafic est ensuite attribué en fonction de l'algorithme que vous utilisez. Par exemple, avec l'algorithme WATERFALL_BY_ZONE, Cloud Service Mesh tente de conserver le trafic dans la zone la plus proche. Si vous vérifiez les métriques du réseau, vous constatez que Cloud Service Mesh préfère un backend avec la latence DAR la plus faible lors de l'envoi de requêtes pour optimiser la latence DAR globale.

Les sections suivantes décrivent les problèmes que vous pouvez rencontrer avec la règle d'équilibrage de charge du service et les paramètres de backend préférés.

Le trafic est envoyé à des groupes d'instances gérés (MIG) ou NEG plus éloignés avant les groupes plus proches

Il s'agit du comportement souhaité lorsque les backends préférés sont configurés avec des MIG ou des NEG plus éloignés. Si vous ne souhaitez pas que ce comportement s'applique, modifiez les valeurs dans le champ "Backends préférés".

Le trafic n'est pas envoyé aux MIG ou aux NEG qui comportent de nombreux points de terminaison non opérationnels.

Il s'agit du comportement souhaité lorsque les MIG ou les NEG sont drainés en raison de la configuration d'un autoCapacityDrain. Avec ce paramètre, les MIG ou les NEG comportant de nombreux points de terminaison non opérationnels sont supprimés des décisions concernant l'équilibrage de charge, et sont donc évités. Si ce comportement ne vous convient pas, vous pouvez désactiver le paramètre autoCapacityDrain. Toutefois, notez que cela signifie que du trafic peut être envoyé à des MIG ou des NEG avec de nombreux points de terminaison non opérationnels, et que les requêtes peuvent donc échouer avec des erreurs.

Le trafic n'est pas envoyé à certains MIG ou NEG lorsque certains MIG ou NEG sont à privilégier

Il s'agit du comportement souhaité si les MIG ou les NEG configurés de façon préférée n'ont pas encore atteint leur capacité.

Lorsque les backends préférés sont configurés et qu'ils n'ont pas atteint leur limite de capacité, le trafic n'est pas envoyé aux autres MIG ou NEG. Les MIG ou NEG préférés seront d'abord attribués en fonction de la latence DAR à ces backends.

Si vous préférez que le trafic soit envoyé ailleurs, vous pouvez configurer leur service de backend sans backends privilégiés, ou avec des estimations de capacité plus prudentes pour les MIG ou NEG préférés.

Le trafic est envoyé à un trop grand nombre de MIG ou de NEG distincts à partir d'une même source.

Il s'agit du comportement attendu en cas de pulvérisation sur une région ou de pulvérisation vers le monde. Toutefois, vous risquez de rencontrer des problèmes avec une distribution plus étendue du trafic. Par exemple, les taux de succès de cache (hit) peuvent être réduits, car les backends reçoivent le trafic provenant d'un plus grand nombre de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes, tels que la cascade par région.

Le trafic est envoyé vers un cluster distant lorsque l'état du backend change

Lorsque failoverHealthThreshold est défini sur une valeur élevée, il s'agit du comportement souhaité. Si vous souhaitez que le trafic reste dans les backends principaux en cas de modifications temporaires de l'état, définissez failoverHealthThreshold sur une valeur inférieure.

Les points de terminaison opérationnels sont surchargés lorsqu'ils ne sont pas opérationnels.

Lorsque failoverHealthThreshold est défini sur une valeur faible, il s'agit du comportement souhaité. Lorsque certains points de terminaison ne sont pas opérationnels, leur trafic peut être réparti entre les points de terminaison restants dans le même MIG ou le même NEG. Si vous souhaitez que le comportement de basculement soit déclenché plus tôt, définissez failoverHealthThreshold sur une valeur plus élevée.

Limites et points à noter

Vous trouverez ci-dessous les limites et considérations dont vous devez tenir compte lorsque vous configurez l'équilibrage de charge avancé.

Cascade par zone

  • Lors d'événements de maintenance transparents, il est possible que le trafic soit temporairement équilibré en dehors de la zone locale.

  • Attendez-vous à ce que certains MIG ou NEG soient saturés, tandis que d'autres MIG ou NEG de la même région sont sous-utilisés.

  • Si la source du trafic vers votre service se trouve dans la même zone que ses points de terminaison, le trafic interzone est réduit.

  • Une zone peut être mappée à différents clusters de matériel physique internes au sein des centres de données Google, par exemple en raison de la virtualisation de zone. Dans ce cas, il est possible que les VM d'une même zone ne soient pas chargées uniformément. En général, la latence globale est optimisée.

Spray sur la région

  • Si les points de terminaison d'un MIG ou d'un NEG tombent en panne, les conséquences sont généralement étendues à un plus grand nombre de clients. En d'autres termes, un plus grand nombre de clients de maillage peut être affecté, mais de façon moins sévère.

  • Étant donné que les clients envoient des requêtes à tous les MIG ou NEG de la région, dans certains cas, cela peut augmenter le trafic interzone.

  • Le nombre de connexions ouvertes sur des points de terminaison peut augmenter, ce qui entraîne une utilisation accrue des ressources.

Backends préférés

  • Les MIG ou NEG configurés en tant que backends préférés peuvent être éloignés des clients et entraîner une latence moyenne plus élevée pour les clients. Cela peut se produire même si d'autres MIG ou NEG d'autres MIG ou NEG peuvent servir les clients avec une latence plus faible.

  • Les algorithmes d'équilibrage de charge mondiaux (cascade par région, pulvérisation sur région, cascade par zone) ne s'appliquent pas aux MIG ni aux NEG configurés en tant que backends préférés.

Drainage de capacité automatique

  • Le nombre minimal de MIG qui ne sont jamais drainés est différent de la valeur définie lors de la configuration à l'aide de serviceLbPolicies.

  • Par défaut, le nombre minimal de MIG qui ne sont jamais drainés est de 1.

  • Si serviceLbPolicies est défini, le pourcentage minimal de MIG ou de NEG qui ne sont jamais drainés est de 50%. Selon les deux configurations, un MIG ou un NEG est marqué comme non opérationnel si moins de 25% des instances ou des points de terminaison du MIG ou du NEG sont opérationnels.

  • Pour qu'un MIG ou un NEG soit drainé après un drainage, au moins 35% des instances ou des points de terminaison doivent être opérationnels. Cela est nécessaire pour vous assurer qu'un MIG ou un NEG n'hésite pas entre l'état drainé et l'état non drainé.

  • Les mêmes restrictions concernant le scaler de capacité pour les backends qui n'utilisent pas de mode d'équilibrage s'appliquent également ici.

Étapes suivantes