Optimisations avancées de l'équilibrage de charge

Cette page décrit comment utiliser une règle d'équilibrage de charge de service pour permettre des optimisations avancées en termes de coût, de latence et de résilience pour les équilibreurs de charge suivants :

Équilibreur de charge d'application externe global
Équilibreur de charge d'application interne interrégional
Équilibreur de charge réseau proxy externe global
Équilibreur de charge réseau proxy interne interrégional

Traffic Director est également compatible avec les optimisations avancées de l'équilibrage de charge. Pour en savoir plus, consultez la page Présentation de l'équilibrage de charge avancé dans la documentation Traffic Director.

Une règle d'équilibrage de charge de service (serviceLbPolicy) est une ressource associée au service de backend de l'équilibreur de charge. Une règle d'équilibrage de charge de service vous permet de personnaliser les paramètres permettant de contrôler la répartition du trafic entre les backends associés à un service de backend :

Personnalisez l'algorithme d'équilibrage de charge utilisé pour déterminer la façon dont le trafic est distribué dans une région ou une zone particulière.
Activez le drainage de capacité automatique pour que l'équilibreur de charge puisse drainer rapidement le trafic des backends non opérationnels.
Définissez un seuil de basculement pour déterminer à quel moment un backend est considéré comme non opérationnel. Cela permet au trafic de basculer vers un autre backend pour éviter d'avoir des backends non opérationnels.

De plus, vous pouvez désigner des backends spécifiques en tant que backends préférés. Ces backends doivent être utilisés pour gérer la capacité avant que les requêtes ne soient envoyées aux backends restants.

Le schéma suivant montre comment Cloud Load Balancing évalue le routage, l'équilibrage de charge et la répartition du trafic.

Comment Cloud Load Balancing prend des décisions en matière de routage et de distribution du trafic — Comment Cloud Load Balancing prend les décisions de routage et de distribution du trafic.

Avant de commencer

Avant d'examiner le contenu de cette page, examinez attentivement le processus de distribution des requêtes décrit sur la page de présentation de l'équilibreur de charge d'application externe. Pour les équilibreurs de charge qui bénéficient toujours du niveau Premium, tous les algorithmes d'équilibrage de charge décrits sur cette page permettent de passer d'une région à l'autre si la région choisie en premier lieu est déjà saturée.

Backends compatibles

Les règles d'équilibrage de charge de service et les backends préférés ne peuvent être configurés que sur les équilibreurs de charge qui utilisent les backends compatibles, comme indiqué dans le tableau suivant.

Backend	Compatible ?
Groupes d'instances Non géré Gestion zonale
MIG régionaux
NEG zonaux (points de terminaison `GCE_VM_IP_PORT`)
NEG hybrides (points de terminaison `NON_GCP_PRIVATE_IP_PORT`)
NEG sans serveur
NEG Internet
NEG Private Service Connect

Algorithmes d'équilibrage de charge

Cette section décrit les algorithmes d'équilibrage de charge que vous pouvez configurer dans une règle d'équilibrage de charge de service. Si vous ne configurez pas d'algorithme, ou si vous ne configurez pas de règle d'équilibrage de charge de service, l'équilibreur de charge utilise WATERFALL_BY_REGION par défaut.

Cascade par région

WATERFALL_BY_REGION est l'algorithme d'équilibrage de charge par défaut. Avec cet algorithme, tous les GFE (Google Front End) d'une région tentent de remplir les backends proportionnellement à leurs capacités cibles (modifiées par leurs scalers de capacité).

Chaque GFE individuel de deuxième couche préfère sélectionner des instances backend ou des points de terminaison dans une zone aussi proche que possible (définie par le délai aller-retour du réseau) du GFE de deuxième couche. Comme WATERFALL_BY_REGION minimise la latence entre les zones, à des taux de requêtes faibles, chaque GFE de deuxième couche peut envoyer exclusivement des requêtes aux backends de la zone préférée de la deuxième couche.

Appliquer à une région

L'algorithme SPRAY_TO_REGION modifie le comportement individuel de chaque GFE de deuxième couche dans la mesure où chaque GFE de deuxième couche n'a aucune préférence lors de la sélection des instances backend ou points de terminaison situés dans une zone aussi proche que possible du GFE de deuxième couche. Avec SPRAY_TO_REGION, chaque GFE de deuxième couche envoie des requêtes à tous les points de terminaison ou instances backend, dans toutes les zones de la région, sans préférence pour un délai aller-retour plus court entre le GFE de deuxième couche et les instances backend ou points de terminaison.

Comme WATERFALL_BY_REGION, tous les GFE de deuxième couche de la région remplissent les backends proportionnellement à leurs capacités cibles configurées (modifiées par leurs scalers de capacité).

Bien que SPRAY_TO_REGION fournisse une distribution plus uniforme entre les backends de toutes les zones d'une région, en particulier à des taux de requêtes faibles, cette distribution uniforme présente les points suivants :

Lorsque les backends tombent en panne (mais continuent à passer leurs vérifications d'état), des GFE de deuxième couche sont affectés, bien que l'impact individuel soit moins grave.
Étant donné que chaque GFE de deuxième couche n'a pas de préférence pour une zone par rapport à une autre, les GFE de deuxième couche créent plus de trafic interzone. Selon le nombre de requêtes traitées, chaque GFE de deuxième couche peut également créer d'autres connexions TCP aux backends.

Cascade par zone

L'algorithme WATERFALL_BY_ZONE modifie le comportement individuel de chaque GFE de deuxième couche dans la mesure où chaque GFE de deuxième couche présente une préférence très forte pour sélectionner les instances backend ou les points de terminaison qui se trouvent dans la zone la plus proche possible du GFE de deuxième couche. Avec WATERFALL_BY_ZONE, chaque GFE de deuxième couche envoie uniquement des requêtes aux instances backend ou aux points de terminaison d'autres zones de la région lorsque la deuxième couche GFE a rempli (ou proportionné) des instances backend ou des points de terminaison dans sa zone la plus privilégiée.

L'algorithme WATERFALL_BY_ZONE minimise la latence en tenant compte des points suivants :

WATERFALL_BY_ZONE ne réduit pas intrinsèquement les connexions interzones. L'algorithme n'est dirigé que par la latence.
WATERFALL_BY_ZONE ne garantit pas que chaque GFE de deuxième couche remplit toujours sa zone la plus privilégiée avant de remplir d'autres zones. Les événements de maintenance peuvent entraîner l'envoi temporaire de tout le trafic d'un GFE de deuxième couche vers des instances backend ou des points de terminaison d'une autre zone.
La répartition WATERFALL_BY_ZONE peut entraîner une distribution moins uniforme des requêtes entre tous les points de terminaison ou instances backend de la région dans son ensemble. Par exemple, les instances backend ou les points de terminaison de la zone la plus privilégiée du GFE de deuxième couche peuvent être remplis tandis que les backends d'autres zones ne sont pas saturés.

Comparer les algorithmes d'équilibrage de charge

Le tableau suivant compare les différents algorithmes d'équilibrage de charge.

Comportement	Cascade par région	Appliquer à une région	Cascade par zone
Utilisation de la capacité uniforme dans une seule région	Yes	Oui	Non
Utilisation de la capacité uniforme dans plusieurs régions	Non	Non	Non
Répartition du trafic uniforme en fonction de l'équilibreur de charge	Non	Oui	Non
Répartition du trafic interzone	Oui. Le trafic est réparti 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.	Yes	Oui. Le trafic est d'abord acheminé vers la zone la plus proche jusqu'à ce qu'il soit à pleine capacité. Ensuite, il se dirige vers la zone la plus proche.
Sensibilité aux pics de trafic dans une zone locale	Moyenne ; cela dépend du volume de trafic déjà déplacé vers les zones.	Inférieure ; les pics de zone uniques sont répartis sur toutes les zones de la région.	Élevée ; les pics de zone unique sont susceptibles d'être diffusés entièrement par la même zone jusqu'à ce que l'équilibreur de charge soit en mesure de réagir.

Drainage de la capacité automatique

Lorsqu'un backend n'est pas opérationnel, vous souhaitez généralement l'exclure des décisions d'équilibrage de charge aussi rapidement que possible. L'exclusion des backends non opérationnels optimise la latence globale en n'envoyant le trafic qu'aux backends opérationnels.

Lorsque vous activez la fonctionnalité de drainage de capacité automatique, l'équilibreur de charge procède automatiquement au scaling de la capacité d'un backend à zéro lorsque moins de 25 % des instances ou des points de terminaison du backend réussissent les vérifications d'état. Cette opération supprime le backend non opérationnel du pool d'équilibrage de charge global. Cette action équivaut à définir backendService.capacityScaler sur 0 pour un backend lorsque vous souhaitez éviter d'acheminer le trafic vers ce backend.

Si 35 % (10 % du seuil) des instances backend ou des points de terminaison précédemment drainés sont soumis à des vérifications d'état pendant 60 secondes, le backend est automatiquement drainé et ajouté au pool d'équilibrage de charge. Cela garantit que le backend est vraiment opérationnel et ne passe pas d'un état drainé à un état non drainé.

Même si le drainage de capacité automatique est activé, l'équilibreur de charge ne draine pas plus de 50 % des backends associés à un service de backend, quel que soit l'état d'un backend. Conserver 50 % des backends associés réduit le risque de surcharge des backends opérationnels.

Un cas d'utilisation du drainage de capacité automatique est de l'utiliser afin de minimiser le risque de surcharger vos backends préférés. Par exemple, si un backend est préféré, mais que la plupart de ses instances ou points de terminaison sont défectueux, le drainage de capacité automatique supprime le backend du pool d'équilibrage de charge. Au lieu de surcharger les instances ou points de terminaison opérationnels restants dans le backend préféré, le drainage de capacité automatique transfère le trafic vers d'autres backends.

Vous pouvez activer le drainage de capacité automatique dans le cadre de la règle d'équilibrage de charge de service. Pour en savoir plus, consultez la section Configurer une règle d'équilibrage de charge de service.

La capacité automatique n'est pas compatible avec les backends qui n'utilisent pas de mode d'équilibrage. Cela inclut les backends tels que les NEG Internet, les NEG sans serveur et les NEG PSC.

Seuil de basculement

L'équilibreur de charge détermine la répartition du trafic entre les backends suivant une méthode à plusieurs niveaux. Si l'état est stable, il envoie le trafic aux backends qui sont sélectionnés en fonction de l'un des algorithmes d'équilibrage de charge décrits précédemment. Ces backends, appelés backends principaux, sont considérés comme optimaux en termes de latence et de capacité.

L'équilibreur de charge effectue également le suivi des autres backends qui peuvent être utilisés si les backends principaux deviennent non opérationnels et ne sont pas en mesure de gérer le trafic. Ces backends sont appelés backends de basculement. Ces backends sont généralement des backends à proximité ayant de la capacité restante.

Si les instances ou les points de terminaison du backend principal ne sont plus opérationnels, l'équilibreur de charge ne bascule pas immédiatement le trafic vers d'autres backends. Au lieu de cela, l'équilibreur de charge bascule le trafic vers d'autres instances ou points de terminaison opérationnels du même backend pour aider à stabiliser la charge de trafic. Si trop de points de terminaison dans un backend principal ne sont pas opérationnels et que les points de terminaison restants dans le même backend ne peuvent pas gérer le trafic supplémentaire, l'équilibreur de charge utilise le seuil de basculement afin de déterminer quand commencer à envoyer du trafic vers un backend de basculement. L'équilibreur de charge tolère les points de terminaison non opérationnels dans le backend principal jusqu'au seuil de basculement. Passé ce seuil, le trafic est transféré hors du backend principal.

Le seuil de basculement est une valeur comprise entre 1 et 99, exprimée en pourcentage de points de terminaison devant être opérationnels dans un backend. Si le pourcentage de points de terminaison opérationnels est inférieur au seuil de basculement, l'équilibreur de charge tente d'envoyer le trafic vers un backend de basculement. Par défaut, le seuil de basculement est de 70.

Si le seuil de basculement est trop élevé, des déversements de trafic inutiles peuvent se produire en raison de changements d'état temporaires. Si le seuil de basculement est trop faible, l'équilibreur de charge continue d'envoyer du trafic vers les backends principaux, même s'il existe de nombreux points de terminaison non opérationnels.

Les décisions de basculement sont localisées. Chaque GFE (Google Front End) local se comporte indépendamment de l'autre. Il est de votre responsabilité de vous assurer que vos backends de basculement peuvent gérer le trafic supplémentaire.

Le trafic de basculement peut entraîner une surcharge des backends. Même si un backend n'est pas opérationnel, l'équilibreur de charge peut toujours y envoyer du trafic. Pour exclure les backends non opérationnels du pool de backends disponibles, activez la fonctionnalité de drainage de capacité automatique.

Backends préférés

Les backends préférés sont les backends dont vous souhaitez complètement utiliser la capacité avant de répartir le trafic vers d'autres backends. Tout trafic dépassant la capacité configurée des backends préférés est acheminé vers les backends non privilégiés restants. L'algorithme d'équilibrage de charge répartit ensuite le trafic entre les backends non préférés d'un service de backend.

Vous pouvez configurer votre équilibreur de charge pour qu'il préfère et utilise complètement un ou plusieurs backends associés à un service de backend avant d'acheminer les requêtes ultérieures vers les backends restants.

Tenez compte des limitations suivantes lorsque vous utilisez des backends préférés :

Les backends configurés en tant que backends préférés peuvent être plus éloignés des clients et entraîner une latence moyenne plus élevée pour les requêtes client. Cela se produit même si d'autres backends plus proches auraient pu diffuser les clients avec une latence inférieure.
Certains algorithmes d'équilibrage de charge (WATERFALL_BY_REGION, SPRAY_TO_REGION et WATERFALL_BY_ZONE) ne s'appliquent pas aux backends configurés en tant que backends.

Pour savoir comment définir des backends préférés, consultez la page Définir des backends préférés.

Configurer une règle d'équilibrage de charge de service

La ressource de règle d'équilibrage de charge de service vous permet de configurer les champs suivants :

Algorithme d'équilibrage de charge
Drainage de capacité automatique
Seuil de basculement

Pour définir un backend préféré, consultez la section Définir des backends préférés.

Créer une règle

Pour créer et configurer une règle d'équilibrage de charge de service, procédez comme suit :

Créez une ressource de règle d'équilibrage de charge de service. Vous pouvez utiliser un fichier YAML ou directement les paramètres gcloud.
- Avec un fichier YAML. Vous devez spécifier des règles d'équilibrage de charge de service dans un fichier YAML. Voici un exemple de fichier YAML qui vous montre comment configurer un algorithme d'équilibrage de charge, activer le drainage de capacité automatique et définir un seuil de basculement personnalisé :
```
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
- autoCapacityDrain:
    enable: True
- loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
- failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
```
  Remplacez les éléments suivants :
  - PROJECT_ID : ID du projet.
  - SERVICE_LB_POLICY_NAME : nom de la règle d'équilibrage de charge de service.
  - LOAD_BALANCING_ALGORITHM : algorithme d'équilibrage de charge à utiliser. Il peut être défini sur SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
  - FAILOVER_THRESHOLD_VALUE : valeur du seuil de basculement. Ce nombre doit être compris entre 1 et 99.
  Après avoir créé le fichier YAML, importez-le dans une nouvelle règle d'équilibrage de charge de service.
```
gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- Sans fichier YAML. Vous pouvez également configurer des fonctionnalités de règle d'équilibrage de charge de service sans utiliser de fichier YAML.
  
  Pour définir l'algorithme d'équilibrage de charge et activer le drainage automatique, utilisez les paramètres suivants :
```
gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
 --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
 --auto-capacity-drain \
 --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
 --location=global
```
  Remplacez les éléments suivants :
  - SERVICE_LB_POLICY_NAME : nom de la règle d'équilibrage de charge de service.
  - LOAD_BALANCING_ALGORITHM : algorithme d'équilibrage de charge à utiliser. Il peut être défini sur SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
  - FAILOVER_THRESHOLD_VALUE : valeur du seuil de basculement. Ce nombre doit être compris entre 1 et 99.

Mettez à jour un service de backend de sorte que son champ --service-lb-policy fasse référence à la ressource de la règle d'équilibrage de charge de service que vous venez de créer. Un service de backend ne peut être associé qu'à une seule ressource de règle d'équilibrage de charge de service.

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global

Vous pouvez associer une règle d'équilibrage de charge à un service de backend lors de la création du service.

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --protocol=PROTOCOL \
    --port-name=NAMED_PORT_NAME \
    --health-checks=HEALTH_CHECK_NAME \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    --global

Supprimer une stratégie

Pour supprimer une règle d'équilibrage de charge de service d'un service de backend, utilisez la commande suivante :

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Définir les backends préférés

Vous pouvez configurer des backends préférés à l'aide de la Google Cloud CLI ou de l'API.

gcloud

Ajouter un backend préféré

Pour définir un backend préféré, utilisez la commande gcloud beta compute backend-services add-backend pour définir l'option --preference lorsque vous ajoutez le backend au service de backend.

gcloud beta compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Remplacez PREFERENCE par le niveau de préférence que vous souhaitez attribuer au backend. Il peut être défini sur PREFERRED ou DEFAULT.

Le reste de la commande dépend du type de backend que vous utilisez (groupe d'instances ou NEG). Pour obtenir tous les paramètres requis, consultez la documentation sur la commande gcloud beta compute backend-services add-backend.

Mettre à jour les préférences d'un backend

Pour mettre à jour le paramètre --preference d'un backend, utilisez la commande gcloud beta compute backend-services update-backend.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Le reste de la commande dépend du type de backend que vous utilisez (groupe d'instances ou NEG). L'exemple de commande suivant met à jour les préférences d'un groupe d'instances backend et les définit sur PREFERRED :

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Pour définir un backend préféré, définissez l'option preference sur chaque backend à l'aide de la ressource backendServices globale.

Voici un exemple qui vous montre comment configurer les préférences du backend :

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Remplacez les éléments suivants :

PROJECT_ID : ID du projet
BACKEND_SERVICE_NAME : nom du service de backend.
BACKEND_1_NAME : nom du backend préféré
BACKEND_2_NAME : nom du backend par défaut

Dépannage

Les modèles de distribution du trafic peuvent changer lorsque vous associez une nouvelle règle d'équilibrage de charge de service à un service de backend.

Pour déboguer les problèmes de trafic, utilisez Cloud Monitoring afin de voir comment le trafic circule entre l'équilibreur de charge et le backend. Les journaux et les métriques Cloud Load Balancing peuvent également vous aider à comprendre le comportement de l'équilibrage de charge.

Cette section récapitule quelques scénarios courants que vous pouvez rencontrer dans la configuration nouvellement exposée.

Le trafic provenant d'une source unique est envoyé à un trop grand nombre de backends distincts

Il s'agit du comportement attendu de l'algorithme SPRAY_TO_REGION. Toutefois, vous risquez de rencontrer des problèmes causés par une répartition plus importante de votre trafic. Par exemple, les taux d'accès au cache peuvent diminuer, car les backends voient le trafic d'une sélection plus large de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes tels que WATERFALL_BY_REGION.

Le trafic n'est pas envoyé aux backends avec une grande quantité de points de terminaison non opérationnels

Ce comportement est attendu lorsque autoCapacityDrain est activé. Les backends avec beaucoup de points de terminaison non opérationnels sont drainés et supprimés du pool d'équilibrage de charge. Si vous ne souhaitez pas ce comportement, vous pouvez désactiver le drainage de capacité automatique. Toutefois, cela signifie que le trafic peut être envoyé aux backends avec de nombreux points de terminaison non opérationnels, et que les requêtes peuvent échouer.

Le trafic est envoyé à des backends plus distants avant les backends plus proches

Ce comportement est prévu si vos backends préférés sont plus éloignés que vos backends par défaut. Si vous ne souhaitez pas ce comportement, mettez à jour les paramètres de préférence de chaque backend en conséquence.

Le trafic n'est pas envoyé à certains backends lors de l'utilisation de backends préférés

Ce comportement est normal lorsque les backends de votre choix n'ont pas encore atteint la capacité. Les backends préférés sont attribués en premier en fonction de la latence aller-retour de ces backends.

Si vous souhaitez que le trafic soit envoyé à d'autres backends, vous pouvez effectuer l'une des opérations suivantes :

Mettez à jour les paramètres de préférence pour les autres backends.
Définissez un paramètre de capacité cible plus faible pour vos backends préférés. La capacité cible est configurée à l'aide des champs max-rate ou max-utilization en fonction du mode d'équilibrage du service de backend.

Le trafic est envoyé à un backend distant lors de changements d'état temporaires

Il s'agit du comportement attendu lorsque le seuil de basculement est défini sur une valeur élevée. Si vous souhaitez que le trafic continue à être dirigé vers les backends principaux en cas de modifications d'état temporaires, définissez ce champ sur une valeur inférieure.

Les points de terminaison opérationnels sont surchargés lorsque d'autres points de terminaison ne sont pas opérationnels

Il s'agit du comportement attendu lorsque le seuil de basculement est défini sur une valeur faible. Lorsque des points de terminaison ne sont pas opérationnels, le trafic destiné à ces points de terminaison non opérationnels est réparti entre les points de terminaison restants du même backend. Si vous souhaitez que le comportement de basculement se déclenche plus tôt, définissez ce champ sur une valeur plus élevée.

Limites

Chaque service de backend ne peut être associé qu'à une seule ressource de règle d'équilibrage de charge de service.