Configurer la gestion du trafic pour les équilibreurs de charge d'application externes mondiaux

Ce document présente des exemples d'utilisation de la gestion du trafic pour certains cas d'utilisation spécifiques. De nombreux autres cas d'utilisation sont possibles.

Ce document contient des exemples pour les équilibreurs de charge d'application externes globaux. Les équilibreurs de charge d'application externes globaux utilisent le schéma d'équilibrage de charge EXTERNAL_MANAGED et les composants d'équilibrage de charge global, tels que la règle de transfert, le mappage d'URL et le service de backend.

Pour en savoir plus sur la gestion du trafic avec un équilibreur de charge d'application classique, consultez la page Présentation de la gestion du trafic pour un équilibreur de charge d'application classique.

Pour plus d'informations sur la gestion du trafic avec des équilibreurs de charge d'application externes régionaux, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux.

Outre les fonctionnalités de routage avancées décrites sur cette page, certains équilibreurs de charge d'application s'intègrent aux extensions de service pour vous permettre d'injecter une logique personnalisée dans le chemin d'accès aux données d'équilibrage de charge en configurant des appels d'extensions de service.

Avant de commencer

Assurez-vous de bien comprendre le fonctionnement de la gestion du trafic. Pour en savoir plus, consultez la section Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.

Configurer et tester la gestion du trafic

Dans l'environnement de configuration que vous avez choisi, vous configurez la gestion du trafic à l'aide de configurations YAML. Un mappage d'URL et un service de backend possèdent chacun leur propre fichier YAML. Selon la fonctionnalité choisie, vous devez écrire un fichier YAML de mappage d'URL, un fichier YAML de service de backend, ou les deux.

Pour obtenir de l'aide concernant l'écriture de ces fichiers YAML, vous pouvez utiliser les exemples de cette page et la documentation de l'API Cloud Load Balancing.

La console Google Cloud n'est pas compatible.

La documentation sur l'API de mappage d'URL global et l'API de service de backend global fournit une liste complète des champs, y compris la sémantique concernant les relations, les restrictions et cardinalité.

Vous pouvez ajouter des tests de configuration à un mappage d'URL pour vous assurer que votre mappage d'URL dirige les requêtes comme prévu. Vous pouvez tester différentes règles de mappage d'URL et exécuter autant de tests que nécessaire pour vous assurer que le mappage achemine le trafic vers le service de backend ou le bucket backend approprié. Pour en savoir plus, consultez la section Ajouter des tests à un mappage d'URL. Si vous souhaitez tester de nouvelles modifications dans un mappage d'URL sans le déployer effectivement, consultez la section Valider la configuration du mappage d'URL.

Mapper le trafic à un service unique

Envoyez l'intégralité du trafic vers un service unique. Veillez à remplacer les espaces réservés.

    defaultService: global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: global/backendServices/BACKEND_SERVICE_1
            weight: 100

Répartir le trafic entre deux services

Répartissez le trafic entre deux services au minimum. Veillez à remplacer les espaces réservés.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: global/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurer une redirection d'URL

L'exemple suivant renvoie un code de réponse 3xx configurable. Il définit également l'en-tête de réponse Location à l'aide de l'URI approprié, en remplaçant l'hôte et le chemin d'accès comme spécifié dans l'action de redirection.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

Mettre en miroir le trafic

En plus de transmettre la requête au service de backend sélectionné, vous pouvez envoyer une requête identique au service de backend en miroir, selon une configuration de type fire and forget. L'équilibreur de charge n'attend pas de réponse du backend auquel il envoie la requête en miroir. La mise en miroir est utile pour tester une nouvelle version d'un service de backend. Elle permet également de déboguer les erreurs de production sur une version de débogage du service de backend, plutôt que sur la version de production.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_2

La mise en miroir du trafic est possible lorsque les deux services de backend disposent de groupes d'instances gérés, de NEG zonaux ou de NEG hybrides. Elle n'est pas compatible avec les NEG Internet, les NEG sans serveur et les backends Private Service Connect.

La mise en miroir ne peut pas être configurée pour une partie spécifique des requêtes. Même si vous répartissez le trafic entre plusieurs services de backend pondérés, le service de backend en miroir reçoit toutes les requêtes. Toutefois, vous pouvez utiliser des en-têtes personnalisés pour enregistrer quel service de backend a été utilisé pour diffuser la requête d'origine. L'exemple suivant ajoute un en-tête personnalisé appelé x-weighted-picked-backend à toutes les requêtes client. Pour la valeur d'en-tête, utilisez le nom du service de backend qui a diffusé la requête d'origine.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_3

Réécrire l'URL demandée

Réécrivez la partie du nom d'hôte de l'URL, la partie du chemin de l'URL, ou les deux, avant d'envoyer une requête au service de backend sélectionné. Veillez à remplacer les espaces réservés.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Réessayer une requête

Configurez les conditions dans lesquelles l'équilibreur de charge doit effectuer une nouvelle tentative pour les requêtes ayant échoué, le délai d'attente avant de procéder à une nouvelle tentative et le nombre maximal de tentatives autorisées.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Spécifier le délai avant expiration de la route

Indiquez le délai avant expiration pour la route sélectionnée. Le délai avant expiration est calculé à partir du moment où la requête est entièrement traitée et jusqu'à ce que la réponse soit elle aussi entièrement traitée. Le délai avant expiration inclut l'ensemble des nouvelles tentatives. Veillez à remplacer les espaces réservés.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

Configurer l'injection de pannes

Intégrez des erreurs lors du traitement des requêtes pour simuler des pannes, y compris une latence élevée, une surcharge de service, des défaillances de service et un partitionnement réseau. Cette fonctionnalité est utile pour tester la résilience d'un service aux pannes simulées.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configurer le CORS

Configurez les règles CORS (Cross-Origin Resource Sharing) afin de gérer les paramètres d'application des requêtes CORS.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://my-domain.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Ajouter et supprimer des en-têtes de requête et de réponse

Ajoutez et supprimez des en-têtes de requête avant d'envoyer les requêtes au service de backend. Ajoutez et supprimez également des en-têtes de réponse après avoir reçu une réponse du service de backend.

Il existe des restrictions concernant les valeurs valides pour headerName et headerValue. Pour en savoir plus, consultez la section Fonctionnement des en-têtes personnalisés.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Configurer la détection des anomalies

Spécifiez les critères d'exclusion des VM backend ou des points de terminaison défaillants dans les NEG, ainsi que des critères permettant de définir à quel moment un backend ou un point de terminaison est considéré comme suffisamment opérationnel pour recevoir à nouveau le trafic. Veillez à remplacer les espaces réservés.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

Configurer la répartition du trafic : étapes détaillées

Cet exemple illustre les étapes suivantes :

  1. Créer des modèles distincts pour les différents services.

  2. Créer des groupes d'instances pour ces modèles.

  3. Créer des règles de routage qui configurent une répartition du trafic de type 95 % / 5 %.

  4. Envoyer des commandes curl pour vérifier que les pourcentages de répartition du trafic correspondent approximativement à la configuration.

Ces instructions partent du principe que :

  • un proxy cible et une règle de transfert ont été créés, de même qu'un mappage d'URL nommé global-lb-map ;

  • le mappage d'URL envoie tout le trafic vers un service de backend, nommé red-service, qui est le service de backend par défaut ;

  • vous avez configuré un autre chemin d'accès qui envoie 5 % du trafic vers blue-service et 95 % du trafic vers green-service ;

  • un outil de mise en correspondance des chemins d'accès est utilisé ;

  • vous utilisez Cloud Shell ou un autre environnement avec bash installé.

Définir les services

La fonction bash suivante crée un service de backend, incluant le modèle d'instance et le groupe d'instances géré.

Ces instructions partent du principe qu'une vérification d'état HTTP global-lb-basic-check a été créée. Pour obtenir des instructions, consultez l'une des pages suivantes :

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

Créer les services

Appelez la fonction permettant de créer trois services : red, green et blue. Le service red sert de service par défaut pour les requêtes envoyées à /. Les services green et blue sont configurés sur /prefix pour traiter respectivement 95 % et 5 % du trafic.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

Créer le mappage d'URL

Console

  1. Accédez à la page Équilibrage de charge dans la console Google Cloud.
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur le lien global-lb-map.
  3. Cliquez sur Modifier .

Configurer les nouvelles règles de routage

  1. Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.
  2. Sous Nouveaux hôtes et outil de mise en correspondance des chemins d'accès, créez l'action par défaut en définissant le Service sur red-service.
  3. Cliquez sur OK.
  4. Cliquez sur Ajouter des hôtes et un outil de mise en correspondance des chemins d'accès.
  5. Dans le champ Hôtes, saisissez l'adresse IP de la règle de transfert de votre équilibreur de charge.

  6. Collez le contenu YAML suivant dans la zone Outil de mise en correspondance des chemins d'accès :

    defaultService: global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: global/backendServices/green-service
        weight: 95
      - backendService: global/backendServices/blue-service
        weight: 5

  7. Cliquez sur OK.

  8. Cliquez sur Mettre à jour.

gcloud

  1. Exportez le mappage d'URL existant à l'aide de la commande gcloud compute url-maps export :

    gcloud compute url-maps export global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global

  2. Mettez à jour le fichier de mappage d'URL global-lb-map-config.yaml en ajoutant ce qui suit à la fin du fichier :

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: global/backendServices/green-service
          weight: 95
        - backendService: global/backendServices/blue-service
          weight: 5

  3. Mettez à jour le mappage d'URL à l'aide de la commande gcloud compute url-maps import :

    gcloud compute url-maps import global-lb-map \
   --global \
   --source=global-lb-map-config.yaml

Tester la configuration

Pour tester la configuration, vérifiez d'abord que les requêtes envoyées à l'adresse IP de l'équilibreur de charge configurée précédemment sont gérées par la configuration red par défaut.

Vérifiez ensuite que les requêtes envoyées à FORWARDING_RULE_IP_ADDRESS/prefix sont réparties comme prévu.

Le contrôle du trafic vous permet de configurer l'affinité de session en fonction d'un cookie fourni. Suivez ces instructions pour configurer une affinité de session HTTP_COOKIE pour un service de backend nommé red-service.

  1. Exécutez la commande gcloud compute backend_services export pour obtenir la configuration du service de backend.

    gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --global

  2. Mettez à jour le fichier red-service-config.yaml comme suit :

    sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 0
 minimumRingSize: 10000

  3. Dans le fichier red-service-config.yaml, supprimez la ligne suivante :

    sessionAffinity: NONE

  4. Mettez à jour le fichier de configuration du service de backend :

    gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --global

Dépannage

Utilisez ces informations pour le dépannage lorsque le trafic n'est pas acheminé conformément aux règles de routage et de trafic que vous avez configurées.

Pour plus d'informations sur la journalisation et la surveillance, consultez la section Journaux et surveillance HTTP(S) externes.

Symptômes :

  • Augmentation du trafic vers les services dans les règles supérieures à la règle considérée.
  • Augmentation inattendue des réponses HTTP 4xx et 5xx pour une règle de routage donnée.

Solution : vérifiez l'ordre de tri de vos règles de routage. Les règles de routage sont interprétées dans l'ordre dans lequel elles sont spécifiées.

Les règles de routage dans un mappage d'URL sont interprétées dans l'ordre dans lequel elles sont spécifiées. Cela diffère de la façon dont les règles de chemin d'accès sont interprétées par la correspondance du préfixe le plus long. Pour une règle de chemin d'accès, l'équilibreur de charge d'application externe global ne sélectionne qu'une seule règle de chemin d'accès. Cependant, lorsque vous utilisez des règles de routage, plusieurs règles de chemin d'accès peuvent s'appliquer.

Lorsque vous définissez des règles de routage, assurez-vous que les règles en début de liste n'acheminent pas par inadvertance du trafic qu'une règle de routage définie ultérieurement est sensée rediriger. Le service qui reçoit un trafic mal acheminé rejettera probablement les requêtes, et le trafic du service concerné par vos règles de routage sera réduit ou inexistant.

Étape suivante