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 distribution du trafic afin de mieux répondre à vos objectifs de disponibilité, de performances et d'efficacité. Ce document s'adresse aux utilisateurs qui ont au moins une compréhension intermédiaire des concepts de Cloud Service Mesh et d'équilibrage de charge.

Pour implémenter un équilibrage de charge avancé, vous devez créer une règle d'équilibrage de charge de service (ressource serviceLbPolicies), qui contient des valeurs qui influencent la sélection d'un backend. Vous associez ensuite la règle d'équilibrage de charge du service à un service de backend. La règle d'équilibrage de charge de service spécifie l'algorithme utilisé pour pour déterminer l'équilibrage du trafic entre les backends.

Vous pouvez choisir l'une des options d'algorithme suivantes pour l'équilibrage de charge avancé :

  • Cascade par région (algorithme par défaut)
  • Répartition dans la région.
  • Vaporisez le monde entier.
  • Cascade par zone.

Les options supplémentaires suivantes sont disponibles:

  • Désignez des backends préférés. Cloud Service Mesh envoie du trafic à ces MIG avant d'envoyer le trafic à d'autres backends.
  • Configurez le drainage 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 sur 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 d'équilibrage de charge
Comment Cloud Service Mesh prend-il des décisions d'équilibrage de charge ? (cliquez pour agrandir)

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

Ensuite, Cloud Service Mesh choisit un MIG ou NEG de backend associé à le service de backend, en fonction de l'emplacement du client, de son emplacement, de son état la capacité du MIG ou du NEG, et les informations contenues dans l'é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 NEG. Ce choix est basé sur les informations contenues dans la règle d'équilibrage de charge de la localité dans les 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 backends 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 le choix d'utiliser en fonction des besoins spécifiques de votre entreprise.

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

L'algorithme d'équilibrage de charge par défaut, en 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 la cascade par région, les backends reçoivent du trafic en fonction de leur capacité, ce qui offre une protection contre la surcharge des backends. Le trafic est acheminé vers des limites de zone si nécessaire pour que les backends soient chargés de manière uniforme dans dans la même région. Même si la zone locale du client dispose d'une capacité restante, est le trafic interzone. Les demandes de chaque client peuvent être réparties plusieurs MIG ou NEG zonaux dans la région, ce qui permet de maintenir la charge des groupes d'instances gérés ou des NEG uniformes lorsque la charge du trafic des clients n'est pas uniforme.

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

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

Utilisez l'algorithme "spray to region" lorsque vous voulez que les clients répartissent leur à tous les MIG ou NEG d'une région, ce qui réduit le risque surcharger les MIG ou les NEG d'une seule zone en cas d'incident rapide, localisé d'augmentation du volume du trafic.

Avec l'algorithme "spray to region", si vous avez deux zones, A et B, 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 pourrait déclencher une surcharge dans la zone avant Cloud Service Mesh peut répondre à la modification.

Notez que lorsque vous utilisez l'algorithme de répartition sur une 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 plus élevé de manière cohérente, même lorsqu'il reste de la capacité dans la zone locale, et peut entraîner une zone affectée plus importante pour le trafic provenant de Cloud Service Mesh, si deux clients Cloud Service Mesh envoient du trafic vers les mêmes zones.

Répartissez 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 par région le trafic de chaque client vers toutes les zones d'une région. Pour les services comportant des MIG ou 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 diffusion plus important, utilisez l'algorithme de projection sur le monde. Avec cet algorithme, les clients répartissent leurs requêtes sur tous les MIG ou NEG du monde dans plusieurs régions.

Notez que, avec cet algorithme, tout le trafic est réparti sur tous les backends à l'échelle mondiale. Une requête défectueuse peut endommager tous les backends de vos déploiements. L'algorithme génère également plus de trafic interrégional, ce qui peut augmenter la latence des requêtes et générer des coûts supplémentaires.

Réduisez au maximum le trafic de sortie interzone

Vous pouvez optimiser la latence globale et réduire le trafic interzone grâce au cascade 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 dans la zone, jusqu'à avant d'envoyer le trafic au prochain MIG ou NEG dans la zone jusqu'à ce que toute la capacité du MIG ou du NEG de la zone soit utilisée. Le trafic n'est alors redirigé vers la zone la plus proche que dans ce cas.

Cet algorithme vous permet de réduire au maximum le trafic interzone inutile. Généralités la latence peut être légèrement améliorée, car les backends locaux les plus proches de préférence. Toutefois, cela peut aussi créer un trafic inégal entre les MIG NEG au sein d'une région.

Comparaison des algorithmes d'équilibrage de charge

Le tableau suivant fournit une comparaison détaillée des quatre modèles de maillage de services d'équilibrage de charge.

Comportement Cascade d'annonces par région Répartition dans la région Répartition dans le monde Cascade par zone
Utilisation uniforme de la capacité au sein d'une région dans un état stable Oui Oui Oui Non
Utilisation uniforme de la capacité dans plusieurs régions dans un état stable Non Non Oui Non
Répartition uniforme du trafic dans une région en état stable Non Oui Oui Non
Trafic interzone Oui. Cet algorithme répartira le trafic uniformément entre les zones d'une tout en optimisant la latence du réseau. Le trafic peut être envoyé entre les zones si nécessaire. Oui Oui Oui, le trafic remplira la zone la plus proche jusqu'à sa capacité. Il passe à la zone suivante.
Sensibilité aux pics de trafic dans les zones locales Moyenne ; en fonction de la quantité de trafic déjà réaffectée pour équilibrer entre les zones. Inférieure ; les pics de zone uniques sont répartis sur toutes les zones de la région. Inférieur ; car les pics d'une zone unique s'étendent à toutes les régions. Supérieur ; car les pics d'une zone unique sont plus susceptibles d'être diffusés entièrement jusqu'à ce que Cloud Service Mesh puisse réagir.

Autres options avancées d'équilibrage de charge

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 sorte qu'un groupe de backends d'un service de backend soit désigné comme préféré. 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 répartit d'abord le trafic client vers les backends préférés, ce qui réduit le nombre de requêtes pour vos clients.

Tout trafic dépassant la capacité configurée des backends préférés est sont acheminées 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.

L'un des cas d'utilisation est le débordement vers Google Cloud, où vous spécifiez des ressources de calcul sur site ressources, représentées par un NEG de connectivité hybride, doivent être entièrement utilisées avant les requêtes sont acheminées vers des NEG ou des MIG backend Google Cloud avec autoscaling. Ce peut réduire la consommation de ressources de calcul Google Cloud tout en ont la résilience nécessaire pour renverser progressivement Google Cloud si nécessaire.

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 d'é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 leur surcharge et optimiser la latence globale.

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

Lorsque les backends drainés automatiquement sont de nouveau opérationnels, ils ne sont pas drainé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 santé du backend.

Par exemple, vous pouvez utiliser le drainage automatique de la capacité avec les backends de votre choix. Si un MIG ou un NEG de backend est préféré et que de nombreux points de terminaison ne sont pas opérationnels, ce paramètre protège les points de terminaison restants du MIG ou du NEG en détournant le trafic du MIG ou du NEG.

Personnaliser le comportement du basculement

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

Cloud Service Mesh assure également le suivi des backends à utiliser lorsque les backends principaux ne sont pas opérationnels et ne peuvent pas recevoir de trafic. Ces backends sont appelés de basculement. Il s'agit généralement de backends à proximité qui ont une certaine capacité restant(s).

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

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

Lorsque certains points de terminaison du backend principal ne sont plus opérationnels, Cloud Service Mesh ne bascule pas nécessairement le trafic immédiatement. À la place, Cloud Service Mesh peut basculer le trafic vers des points de terminaison opérationnels du backend principal pour tenter de stabiliser le trafic.

Si un trop grand nombre de points de terminaison du backend ne sont pas opérationnels, les points de terminaison restants sont ne peut pas gérer de trafic supplémentaire. Dans ce cas, le seuil d'échec est sert à décider si le basculement est déclenché ou non. Cloud Service Mesh tolère l'état de non-santé jusqu'au seuil, puis transfère une partie du trafic des backends principaux vers les backends de basculement.

Le seuil d'état de basculement est une valeur en pourcentage. La valeur que vous définissez détermine quand Cloud Service Mesh redirige 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 pour Cloud Service Mesh est 70 avec Envoy et 50 pour gRPC sans proxy. Une valeur plus élevée lance le basculement de trafic plus tôt qu'une valeur inférieure.

Dépannage

Les modèles de distribution du trafic peuvent changer en fonction de la façon dont vous configurez le nouveau serviceLbPolicy avec le service de backend.

Pour déboguer les problèmes de trafic, utilisez les systèmes de surveillance existants pour examiner la façon dont le trafic circule vers vos backends. Des métriques réseau et Cloud Service Mesh supplémentaires peuvent vous aider à comprendre comment les décisions d'équilibrage de charge sont prises. Cette section propose des suggestions générales de dépannage et d'atténuation.

Globalement, Cloud Service Mesh tente d'attribuer du trafic pour que les backends fonctionnent en dessous de leur capacité configurée. N'oubliez pas que cette procédure n'est pas garantie. Toi consultez la documentation du service de backend pour en savoir plus.

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 maintenir le trafic dans la zone la plus proche. Si vous vérifiez les métriques réseau, vous constaterez que Cloud Service Mesh préfère un backend avec la latence RTT la plus faible lors de l'envoi de requêtes pour optimiser la latence RTT globale.

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

Le trafic est envoyé à des MIG ou NEG plus distants avant des MIG plus proches.

Il s'agit du comportement prévu 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 se produise, modifiez les valeurs du 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, car autoCapacityDrain est configuré. Avec ce paramètre, les MIG ou les NEG contenant de nombreux points de terminaison non opérationnels seront exclus des décisions d'équilibrage de charge et seront donc évités. Si ce comportement n'est pas souhaité, vous pouvez désactiver autoCapacityDrain . Toutefois, cela signifie que le trafic peut être envoyé aux MIG ou NEG avec un grand nombre des points de terminaison non opérationnels. Les requêtes peuvent donc échouer et générer des erreurs.

Le trafic n'est pas envoyé à certains MIG ou NEG lorsque certains MIG ou NEG sont préférés

Il s'agit du comportement prévu si les MIG ou les NEG configurés comme préférés n'ont pas encore atteint leur capacité.

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

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

Le trafic est envoyé à trop de MIG ou de NEG distincts à partir d'une seule source.

Il s'agit du comportement attendu si vous utilisez "spray-to-region" ou "spray-to-world". Toutefois, il est possible que vous rencontriez des problèmes avec une distribution plus étendue du trafic. Par exemple, les taux de succès de cache (hit) peuvent être réduits lorsque les backends voient le trafic auprès d'un plus large éventail de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes, tels que la cascade par région.

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

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

Les points de terminaison opérationnels sont surchargés lorsque certains d'entre eux ne sont pas opérationnels.

Lorsque failoverHealthThreshold est défini sur une valeur faible, il s'agit de la valeur comportemental. Lorsque certains points de terminaison ne sont pas opérationnels, le trafic vers ces points de terminaison non opérationnels peuvent être réparties entre les points de terminaison restants dans le même MIG ou NEG. Si vous souhaitez que le comportement de basculement soit déclenché de manière anticipée, définissez failoverHealthThreshold sur une valeur plus élevée.

Limites et points à noter

Vous trouverez ci-dessous les limites et les considérations à prendre en 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 à des cas où certains MIG ou NEG ont atteint leur capacité maximale, tandis que d'autres Les 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 interzones est réduit.

  • Une zone peut être mappée à différents clusters de matériel physique interne dans les 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 de manière uniforme. En général, la latence globale sera optimisée.

Sprays dans 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 répartis sur un ensemble plus large de clients ; en d'autres termes, un plus grand nombre des clients du réseau maillé pourraient être affectés, mais moins gravement.

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

  • Le nombre de connexions ouvertes aux points de terminaison peut augmenter, ce qui entraîne une augmentation de l'utilisation 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 peuvent servir les clients avec une latence plus faible.

  • Les algorithmes d'équilibrage de charge globaux (cascade par région, diffusion par 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 diffère du nombre définie avec serviceLbPolicies.

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

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

  • Pour qu'un MIG ou un NEG puisse se vider après un vidage, au moins 35 % des instances ou des points de terminaison doivent être opérationnels. Cela est nécessaire pour s'assurer qu'un MIG ou un NEG ne va pas osciller entre les états de drainage et les états non drainés.

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

Étape suivante