Optimisations avancées de l'équilibrage de charge

Cette page explique comment configurer des optimisations avancées en termes de coût, de latence et de résilience pour les équilibreurs de charge d'application et les équilibreurs de charge réseau proxy.

Cloud Service Mesh 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 de Cloud Service Mesh.

Cloud Load Balancing propose les fonctionnalités avancées suivantes :

  • Règle d'équilibrage de charge de service 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 suivants pour contrôler la répartition du trafic entre les backends associés à un service de backend :

    • Algorithmes d'équilibrage de charge Personnalisez l'algorithme d'équilibrage de charge utilisé pour déterminer la façon dont le trafic est réparti dans une région ou une zone donnée.
    • Drainage de capacité automatique. Activez le drainage de capacité automatique pour que l'équilibreur de charge puisse drainer rapidement le trafic des backends non opérationnels.
    • Seuil de basculement. 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.
    • Isolation du trafic Évitez les défaillances en cascade en limitant ou en interdisant le débordement du trafic interrégional.

  • Backends préférés Vous pouvez désigner des backends spécifiques en tant que backends préférés. Ces backends doivent être utilisés pour faire face à 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.

Équilibreurs de charge et backends compatibles

Les équilibreurs de charge suivants sont compatibles avec les règles d'équilibrage de charge de service et les backends préférés :

  • É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

Les fonctionnalités décrites sur cette page nécessitent des backends compatibles compatibles avec un mode d'équilibrage. Les backends compatibles sont résumés dans le tableau suivant :

Backend Compatibilité
Groupes d'instances
Les groupes d'instances non gérés et gérés zonaux sont acceptés, mais les groupes d'instances gérés régionaux ne le sont pas.
NEG zonaux (points de terminaison GCE_VM_IP_PORT)
NEG zonaux (points de terminaison GCE_VM_IP)
Ces types de NEG ne sont pas compatibles avec les équilibreurs de charge d'application et les équilibreurs de charge réseau proxy.
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 du tout 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) de la région la plus proche de l'utilisateur tentent de remplir les backends proportionnellement à leurs capacités cibles configurées (modifiées par leurs scalers de capacité).

Chaque GFE 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 situés dans la zone préférée du GFE de deuxième couche.

Si tous les backends de la région la plus proche fonctionnent à leur limite de capacité configurée, le trafic commencera à déborder vers la région la plus proche tout en optimisant la latence réseau.

Répartition dans la 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 de réussir leurs vérifications d'état), davantage de GFEs 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 aucune préférence pour une zone par rapport à une autre, les GFE de deuxième couche créent plus de trafic interzone. En fonction du 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.

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é).

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

  • WATERFALL_BY_ZONE ne réduit pas nécessairement les connexions interzones. L'algorithme est guidé par la latence uniquement.
  • 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 temporairement l'envoi 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 saturés, tandis que les backends d'autres zones ne le sont pas.

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 uniforme de la capacité dans une même région Oui Oui Non
Utilisation uniforme de la capacité dans plusieurs régions Non Non Non
Répartition uniforme du trafic 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 réseau. Le trafic peut être envoyé entre les zones si nécessaire. Oui Oui. Le trafic est d'abord acheminé vers la zone la plus proche jusqu'à ce qu'elle atteigne sa capacité. Il passe ensuite à 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 et vidage automatiques de la capacité

Le drainage et le drainage automatique de la capacité combinent les concepts de vérifications de l'état et de la capacité du backend. Avec le drainage de capacité automatique, les vérifications de l'état sont utilisées comme signal supplémentaire pour définir la capacité backend effective sur zéro. Avec le vidage automatique de la capacité, les vérifications de l'état sont utilisées comme signal supplémentaire pour restaurer la capacité backend effective à sa valeur précédente.

Sans vidage et vidage automatique de la capacité, si vous souhaitez détourner les requêtes de tous les backends d'une région spécifique, vous devez définir manuellement la capacité effective de chaque backend de cette région sur zéro. Par exemple, vous pouvez utiliser le scaler de capacité pour ce faire.

Avec le drainage et le drainage automatique de la capacité, les vérifications d'état peuvent être utilisées comme signal pour ajuster la capacité d'un backend, soit par drainage, soit par drainage.

Pour activer le vidage et le vidage automatique de la capacité, consultez Configurer une règle d'équilibrage de charge de service.

Drainage de capacité automatique

Le drainage de capacité automatique définit la capacité de chaque groupe d'instances ou NEG backend candidat à vider sur zéro tant que le ratio de groupes d'instances ou NEG backend candidats à vider par rapport à tous les groupes d'instances ou NEG backend est inférieur à 50 %. Lors du calcul du ratio de 50 %, les backends sans capacité ne sont pas inclus dans le numérateur. Cependant, tous les backends sont inclus dans le dénominateur.

Un backend candidat à vider est un groupe d'instances backend ou un NEG dont moins de 25 % des instances ou des points de terminaison membres réussissent les vérifications d'état de l'équilibreur de charge.

Les backends sans capacité sont les suivants :

  • Groupes d'instances backend sans instances membres, où la capacité du groupe d'instances est définie par instance
  • NEG de backend sans point de terminaison membre, où la capacité du NEG est définie par point de terminaison
  • Groupes d'instances backend ou NEG dont vous avez défini les scaler de capacité sur zéro

La capacité de backend drainée automatiquement est fonctionnellement équivalente à la définition manuelle de backendService.backends[].capacityScaler sur 0 pour un backend, mais sans définir la valeur du scaler de capacité.

Récupération automatique de la capacité

Le drainage automatique de la capacité rétablit la capacité d'un backend à la valeur contrôlée par le scaler de capacité du backend lorsque 35 % ou plus des instances ou des points de terminaison du backend réussissent les vérifications d'état pendant au moins 60 secondes. L'exigence de 60 secondes réduit les risques de vidage et de vidage séquentiels lorsque les vérifications de l'état échouent et réussissent de manière rapide.

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.

Isolation du trafic

Par défaut, Cloud Load Balancing utilise l'algorithme WATERFALL_BY_REGION pour déterminer vers où le trafic utilisateur doit être acheminé. Avec WATERFALL_BY_REGION, le trafic déborde vers d'autres régions lorsque les backends de la région la plus proche de l'utilisateur sont saturés ou non opérationnels. L'activation de l'isolation du trafic permet à l'équilibreur de charge d'acheminer le trafic uniquement vers la région la plus proche de l'utilisateur, même si tous les backends de cette région fonctionnent à leur limite de capacité configurée. L'activation de l'isolation du trafic peut vous aider à éviter les défaillances régionales en cascade et à limiter les pannes potentielles à une seule région.

L'isolation du trafic est configurée dans la règle d'équilibrage de charge du service. Deux modes d'isolation sont disponibles :

  • NEAREST (par défaut), où l'équilibreur de charge (c'est-à-dire le GFE de deuxième couche ou le proxy Envoy qui gère la connexion) envoie le trafic aux backends de la région la plus proche de l'utilisateur. Si aucun backend n'est configuré dans la région la plus proche ou si les backends de la région la plus proche ne sont pas opérationnels, le trafic est acheminé vers la région la plus proche suivante tout en optimisant la latence du réseau. Cette situation se poursuit à mesure que chaque région manque de capacité de diffusion.

    Le mode d'isolation NEAREST est disponible pour tous les équilibreurs de charge compatibles.

  • STRICT, où l'équilibreur de charge (c'est-à-dire le proxy Envoy qui gère la connexion) n'envoie le trafic qu'aux backends de la région la plus proche de l'utilisateur. Si aucun backend n'est configuré dans la région la plus proche, ou si les backends de la région la plus proche ne sont pas opérationnels et ne peuvent pas répondre aux requêtes, le trafic est abandonné et les requêtes commencent à échouer.

    Le mode d'isolation STRICT n'est disponible que pour les équilibreurs de charge d'application internes interrégionaux et les équilibreurs de charge réseau proxy internes interrégionaux.

Aucune isolation

Le schéma suivant montre le comportement des équilibreurs de charge interrégionaux lorsque l'isolation du trafic n'est pas activée.

Comportement de Cloud Load Balancing lorsque l'isolation du trafic n'est pas activée
Comportement de Cloud Load Balancing lorsque l'isolation du trafic n'est pas activée.

le plus proche ;

Le schéma suivant montre le comportement des équilibreurs de charge interrégionaux lorsque l'isolation du trafic est activée avec le mode NEAREST.

Comportement de Cloud Load Balancing lorsque l'isolation du trafic est activée en mode NEAREST.
Comportement de Cloud Load Balancing lorsque l'isolation du trafic est activée en mode NEAREST.

Strict

Le schéma suivant montre le comportement des équilibreurs de charge interrégionaux lorsque l'isolation du trafic est activée avec le mode STRICT.

Comportement de Cloud Load Balancing lorsque l'isolation du trafic est activée en mode STRICT.
Comportement de Cloud Load Balancing lorsque l'isolation du trafic est activée en mode STRICT.

Tenez compte des points suivants avant d'activer cette fonctionnalité :

  • Si vos backends d'une région sont surchargés, l'équilibreur de charge peut toujours leur envoyer du trafic supplémentaire, même si les backends d'autres régions peuvent gérer le trafic. Cela signifie que les backends de chaque région sont plus susceptibles d'être surchargés en raison du trafic supplémentaire, et vous devez planifier en conséquence.

  • Même si l'isolation est activée, votre trafic est toujours acheminé par un plan de contrôle global. Cela signifie qu'il existe toujours un risque de défaillances globales dans plusieurs régions. Pour une meilleure isolation au niveau de l'infrastructure, choisissez un équilibreur de charge régional.

Lorsque vous configurez le mode d'isolation du trafic, vous devez également définir la granularité d'isolation sur REGION, ce qui empêche le débordement du trafic interrégional. Si la granularité n'est pas configurée, l'isolation du trafic ne sera pas appliquée. Pour savoir comment activer l'isolation du trafic, consultez la section Configurer une règle d'équilibrage de charge de service.

Backends préférés

Les backends préférés sont ceux dont vous souhaitez utiliser toute la capacité avant de rediriger le trafic vers d'autres backends. Tout trafic dépassant la capacité configurée pour les backends préférés est acheminé vers les backends non préféré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 servir les clients avec une latence plus faible.
  • 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 préférés.

Pour savoir comment définir des backends préférés, consultez la section 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
  • Isolation du trafic

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 :

Console

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

  1. Dans la console Google Cloud , accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer une règle d'équilibrage de charge de service.

  3. Saisissez un nom pour votre règle d'équilibrage de charge de service.

  4. Pour activer le drainage de capacité automatique, sélectionnez Drainer le trafic des backends non opérationnels.

  5. Pour Seuil d'état de basculement, saisissez un nombre compris entre 1 et 99.

  6. Pour Distribution du trafic, sélectionnez l'algorithme d'équilibrage de charge que vous souhaitez utiliser.

  7. Cliquez sur Créer.

gcloud

  1. Créez une ressource de règle d'équilibrage de charge de service. Pour ce faire, vous pouvez utiliser un fichier YAML ou directement des 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
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
isolationConfig:
  isolationGranularity: ISOLATION_GRANULARITY
  isolationMode: ISOLATION_MODE

    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.
    • FAILOVER_THRESHOLD_VALUE : valeur du seuil de basculement. Ce nombre doit être compris entre 1 et 99.
    • 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.
    • ISOLATION_GRANULARITY : précision de la restriction d'isolation. Pour éviter le débordement du trafic interrégional, définissez ce paramètre sur REGION. Si aucune valeur n'est spécifiée, aucune isolation n'est appliquée.
    • ISOLATION_MODE : comportement d'isolation. Les valeurs possibles sont NEAREST ou STRICT.

    Après avoir créé le fichier YAML, importez-le dans une nouvelle règle d'équilibrage de charge de service.

    gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
   --source=PATH_TO_POLICY_FILE \
   --location=global
    • Sans fichier YAML. Vous pouvez également configurer les fonctionnalités des règles 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 la commande suivante :

    gcloud 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.

    Pour configurer l'isolation du trafic (Preview), utilisez la commande suivante :

    gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
   --isolation-config-granularity=ISOLATION_GRANULARITY \
   --isolation-config-mode=ISOLATION_MODE \
   --location=global

    Remplacez les éléments suivants :

    • ISOLATION_GRANULARITY : précision de la restriction d'isolation. Pour éviter le débordement du trafic interrégional, définissez ce paramètre sur REGION. Si aucune valeur n'est spécifiée, aucune isolation n'est appliquée.
    • ISOLATION_MODE : comportement d'isolation. Les valeurs possibles sont NEAREST ou STRICT.

  2. 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 compute backend-services update BACKEND_SERVICE_NAME \
 --service-lb-policy=SERVICE_LB_POLICY_NAME \
 --global

    Vous pouvez également associer une stratégie d'équilibrage de charge de service à un service de backend lors de sa création.

    gcloud 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

Désactiver les fonctionnalités configurées sur la règle

Cette section explique comment réinitialiser ou désactiver les fonctionnalités configurées sur la règle d'équilibrage de charge du service.

Réinitialiser l'algorithme d'équilibrage de charge

Pour réinitialiser l'algorithme d'équilibrage de charge, utilisez la commande suivante pour rétablir l'algorithme d'équilibrage de charge par défaut WATERFALL_BY_REGION :

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Réinitialiser le seuil de basculement

Pour réinitialiser le seuil de basculement, utilisez la commande suivante pour rétablir le seuil de basculement par défaut de 70 secondes :

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Désactiver le drainage de capacité automatique

Pour désactiver l'épuisement automatique de la capacité, utilisez la commande suivante :

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Désactiver l'isolation du trafic

Pour désactiver l'isolation du trafic (Preview), définissez les deux paramètres de configuration d'isolation sur UNSPECIFIED, comme indiqué dans la commande suivante :

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=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 compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Définir des 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.

Console

Vous pouvez désigner un backend comme backend préféré lorsque vous créez un équilibreur de charge global ou interrégional dans la console Google Cloud .

Définissez le champ Niveau de préférence de backend sur Préféré lorsque vous ajoutez le backend au service de backend.

gcloud

Ajouter un backend préféré

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

gcloud 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 connaître tous les paramètres obligatoires, consultez la commande gcloud 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 compute backend-services update-backend.

gcloud 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 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'indicateur 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 joignez 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 pour examiner le flux de trafic 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ésume quelques scénarios courants que vous pouvez rencontrer lorsque vous activez chacune de ces fonctionnalités.

Algorithmes d'équilibrage de charge

Le trafic d'une seule source est envoyé à trop de backends distincts

Il s'agit du comportement prévu de l'algorithme SPRAY_TO_REGION. Toutefois, vous pouvez rencontrer des problèmes dus à une distribution plus large de votre trafic. Par exemple, les taux de succès de cache (hit) peuvent diminuer, car les backends voient le trafic d'un plus grand nombre de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes tels que WATERFALL_BY_REGION.

Drainage de capacité automatique

Le trafic n'est pas envoyé aux backends comportant de nombreux points de terminaison non opérationnels

Il s'agit du comportement attendu lorsque autoCapacityDrain est activé. Les backends avec de nombreux points de terminaison non opérationnels sont vidés et supprimés du pool d'équilibrage de charge. Si vous ne souhaitez pas que ce comportement se produise, vous pouvez désactiver l'épuisement automatique de la capacité. 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.

Seuil de basculement

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.

Backends préférés

Le trafic est envoyé à des backends plus éloignés avant les 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

Il s'agit du comportement prévu lorsque vos backends préférés n'ont pas encore atteint leur 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 inférieur 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.

Isolation du trafic

Les requêtes envoyées à votre équilibreur de charge interne interrégional échouent

Si le mode d'isolation STRICT est activé et qu'aucun backend n'est configuré dans la même région que l'équilibreur de charge, le trafic devrait échouer. Si ce n'est pas le comportement souhaité, assurez-vous d'avoir des backends dans la région où vous prévoyez d'envoyer le trafic. Vous pouvez également définir le mode d'isolation sur NEAREST afin que le trafic puisse être acheminé vers la deuxième région la plus proche.

Le trafic est acheminé d'une région éloignée vers une région plus proche

L'isolation des requêtes empêche le débordement du trafic basé sur la capacité. Par conséquent, si vos backends étaient déjà surchargés avant d'activer cette fonctionnalité, le trafic a peut-être déjà été envoyé vers une région distante. Dans ce cas, l'activation de cette fonctionnalité peut entraîner le renvoi de ce trafic vers la région la plus proche.

Le trafic n'a pas été redirigé après l'activation de l'isolation du trafic

L'isolation des requêtes empêche le débordement du trafic basé sur la capacité. Par conséquent, si vos backends dans la région la plus proche n'étaient pas surchargés avant d'activer cette fonctionnalité, il est probable que la région la plus proche soit capable de gérer tout le trafic. Dans ce cas, vous ne devriez pas constater de modification des itinéraires de circulation à court terme. Ce nombre peut varier en fonction du volume de trafic.

Le trafic est déplacé lorsque des backends sont ajoutés ou supprimés d'une région.

Il s'agit d'un comportement attendu, car les équilibreurs de charge tentent d'acheminer le trafic pour optimiser la latence réseau globale. Par conséquent, lorsque de nouveaux backends sont déployés dans une région plus proche, l'équilibreur de charge peut envoyer plus de trafic vers cette région. De même, lorsque des backends sont supprimés, en fonction de votre paramètre d'isolation des requêtes, l'équilibreur de charge commence à envoyer du trafic de débordement vers une région plus éloignée.

Limites

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