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 pour répondre 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 Traffic Director et de l'équilibrage de charge.

Pour mettre en œuvre l'é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 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é vers les backends.

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

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

Les options supplémentaires suivantes sont disponibles:

  • Désignez des backends préférés. Traffic Director envoie le trafic à ces MIG ou groupes de points de terminaison du réseau avant de l'envoyer à d'autres backends.
  • Configurez la décharge automatique de la capacité.
  • Personnalisez le comportement du 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 Traffic Director répartit et équilibre la charge du trafic

Le schéma suivant montre comment Traffic Director décide de router le trafic.

Comment Traffic Director prend des décisions concernant l'équilibrage de charge
Comment Traffic Director prend des décisions concernant l'équilibrage de charge (cliquez pour agrandir)

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

Ensuite, Traffic Director choisit un MIG ou un groupe de points de terminaison du réseau 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 groupe de points de terminaison du réseau, ainsi que des informations contenues dans la règle d'équilibrage de charge du service associée au service de backend.

Enfin, Traffic Director choisit une instance ou un point de terminaison dans le MIG#39;instances géré ou le groupe de points de terminaison du réseau. Ce choix est basé sur les informations de la règle d'équilibrage de charge de 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 lequel 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, en cascade par région, répartit le trafic de manière uniforme entre tous les MIG ou les 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 par région, les backends reçoivent le trafic proportionnellement à leur capacité, ce qui les 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 dispose d'une capacité restante, il y a du trafic interzone. Les requêtes de chaque client peuvent être réparties sur plusieurs MIG ou groupes de points de terminaison du réseau zonaux de la région, ce qui permet d'uniformiser 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 entre différentes 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, en vertu de 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 d'une seule zone.

Utilisez l'algorithme de pulvérisation vers une région lorsque vous souhaitez que les clients répartissent leurs requêtes à l'ensemble des MIG ou des NEG d'une région. Cela 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 la 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 Traffic Director puisse répondre au changement.

Notez que lorsque vous utilisez l'algorithme de pulvérisation vers une région, le trafic de chaque client est toujours réparti entre les zones backend d'une région. Cela se traduit par un trafic interzone toujours plus important, même s'il reste de la capacité dans la zone locale, et peut étendre la zone affectée pour le trafic provenant de Traffic Director si deux clients Traffic Director envoient du trafic vers les mêmes zones.

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

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

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

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

Réduire le trafic entre zones

Vous pouvez optimiser la latence globale et réduire le trafic interzone en utilisant la cascade par paramètre de 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, dans la limite de sa capacité, avant d'envoyer le trafic au MIG ou au NEG suivant dans la zone, et ainsi de suite jusqu'à ce que toute la capacité du MIG ou du NEG de la zone soit utilisée. Ce n'est qu'alors que le trafic est déversé dans la zone la plus proche.

Grâce à cet algorithme, vous pouvez minimiser 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 inégal entre les MIG ou les 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 algorithmes d'équilibrage de charge de Traffic Director.

Comportement Cascade d'annonces par région Pouser sur la zone Tout le monde à pulvériser Cascade d'annonces 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épartira le trafic uniformément entre les zones d'une région 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 de sa capacité maximale. Il ira ensuite dans la zone suivante.
Sensibilité aux pics de trafic locaux Moyenne : en fonction de la quantité de trafic déjà déplacée pour équilibrer les zones. Plus faible, car les pics d'une seule zone sont répartis sur toutes les zones de la région. Plus faible, car les pics sur une seule zone seront répartis dans toutes les régions. Plus élevé, car les pics d'une seule zone sont plus susceptibles d'être diffusés entièrement par une seule zone jusqu'à ce que Traffic Director puisse réagir.

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

Les sections suivantes présentent les options permettant de modifier l'équilibrage de charge de Traffic Director.

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 complètement utilisés avant que les requêtes suivantes soient acheminées vers les backends restants. Traffic Director 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 dépassant 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.

L'un des cas d'utilisation est un 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 de backend Google Cloud avec autoscaling. Cette configuration peut minimiser la consommation de ressources de calcul Google Cloud tout en conservant la résilience pour un renversement progressif sur Google Cloud ou pour un basculement 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 prises concernant l'équilibrage de charge. L'exclusion du backend empêche l'envoi de requêtes au backend non opérationnel. En outre, 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. Il demande à Traffic Director de réduire automatiquement la capacité du backend à zéro lorsque moins de 25% de ses instances ou points de terminaison individuels réussissent des 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 automatiquement drainés sont à 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. Traffic Director 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 la capacité avec des backends de votre choix. Si un MIG ou un groupe de points de terminaison du backend est privilégié, et qu'un grand nombre des points de terminaison qu'il contient 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

Traffic Director envoie généralement le trafic aux backends en tenant compte de plusieurs facteurs. Dans un état stable, Traffic Director envoie le trafic aux backends qui sont 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.

Traffic Director 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. Il s'agit généralement de backends situés à proximité qui ont encore une certaine capacité.

Lorsqu'un backend n'est pas opérationnel, Traffic Director tente d'éviter d'envoyer du trafic vers celui-ci 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 en cas de basculement. La valeur de seuil que vous définissez détermine le moment où 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, Traffic Director ne transfère pas nécessairement le trafic immédiatement. À la place, Traffic Director peut déplacer 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. Traffic Director tolère les problèmes de fonctionnement jusqu'au seuil, puis transfère une partie du trafic des backends principaux aux backends de basculement.

Le seuil d'état de basculement est une valeur en pourcentage. La valeur que vous définissez détermine le moment où Traffic Director 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 Traffic Director est de 70 avec Envoy et de 50 pour gRPC sans proxy. Une valeur plus élevée 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. Des métriques de réseau et de Traffic Director supplémentaires peuvent vous aider à comprendre les décisions prises concernant l'équilibrage de charge. Cette section propose des suggestions générales de dépannage et d'atténuation des risques.

Globalement, Traffic Director 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, Traffic Director tente de maintenir le trafic dans la zone la plus proche. Si vous vérifiez les métriques réseau, vous constatez que Traffic Director préfère un backend ayant la plus faible latence DAR lors de l'envoi de requêtes afin d'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 backend privilégiés.

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

Il s'agit du comportement attendu lorsque les backends préférés sont configurés avec des MIG ou des NEG plus distants. Si ce comportement ne vous convient pas, 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 attendu lorsque les MIG ou les NEG sont drainés, car une autoCapacityDrain est configurée. Avec ce paramètre, les MIG ou les NEG comportant de nombreux points de terminaison non opérationnels sont supprimés des décisions relatives à 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, cela signifie que le 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 groupes de points de terminaison du réseau, alors qu'il est préférable d'utiliser certains MIG ou NEG

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

Lorsque les backends préférés sont configurés et n'ont pas atteint leur limite de capacité, le trafic n'est pas envoyé à d'autres MIG ou groupes de points de terminaison du réseau. Les MIG ou groupes de points de terminaison du réseau préférés seront attribués en premier en fonction de la latence DAR à ces backends.

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

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

Ce comportement est intentionnel en cas d'utilisation de pulvérisation vers une région ou de pulvérisation vers le monde. Toutefois, vous risquez de rencontrer des problèmes avec une répartition plus large de votre trafic. Par exemple, les taux de succès de cache (hit) peuvent être réduits lorsque les backends voient le trafic provenant d'un plus grand nombre de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes, comme 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 du comportement prévu. 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 lorsque certains points de terminaison 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 du même MIG ou groupe de points de terminaison du réseau. 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 que vous devez prendre en compte lorsque vous configurez l'équilibrage de charge avancé.

Cascade par zone

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

  • Attendez-vous à ce que certains MIG ou groupes de points de terminaison du réseau aient atteint leur capacité maximale, 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 dans les centres de données Google, par exemple en raison de la virtualisation des zones. Dans ce cas, les VM d'une même zone peuvent ne pas être chargées de manière uniforme. En général, la latence globale est optimisée.

Spray sur une 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 du réseau maillé peut être affecté, mais de manière moins grave.

  • Lorsque les clients envoient des requêtes à tous les MIG ou groupes de points de terminaison du réseau de la région, dans certains cas, cela peut augmenter le trafic interzone.

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

Backends préférés

  • Les MIG ou les NEG configurés en tant que backends privilégiés peuvent se trouver loin 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 groupes de points de terminaison du réseau sont susceptibles de desservir les clients avec une latence plus faible.

  • Les algorithmes d'équilibrage de charge au niveau mondial (cascade par région, pulvérisation vers région, cascade par zone) ne s'appliquent pas aux MIG ou aux NEG configurés en tant que backends privilégiés.

Drainage automatique de la capacité

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

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

  • Si la valeur serviceLbPolicies est définie, le pourcentage minimal de MIG ou de NEG qui ne sont jamais drainés est de 50%. Dans les deux cas, un MIG ou un groupe de points de terminaison du réseau est marqué comme non opérationnel si moins de 25% des instances ou des points de terminaison du MIG ou du groupe de points de terminaison du réseau sont opérationnels.

  • Pour qu'un MIG ou un groupe de points de terminaison soit annulé après un drainage, au moins 35% des instances/points de terminaison doivent être opérationnels. Cela est nécessaire pour s'assurer qu'un MIG ou un NEG n'entrent pas en conflit 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