Configura la gestione del traffico per i bilanciatori del carico delle applicazioni esterni globali

Questo documento mostra esempi di utilizzo della gestione del traffico per alcuni casi d'uso specifici. Sono possibili molti altri casi d'uso.

Il documento contiene esempi per i bilanciatori del carico delle applicazioni esterni globali. I bilanciatori del carico delle applicazioni esterni globali utilizzano lo schema di bilanciamento del carico EXTERNAL_MANAGED e i componenti di bilanciamento del carico globali, come la regola di forwarding, la mappa URL e il servizio di backend.

Per informazioni sulla gestione del traffico con un bilanciatore del carico delle applicazioni classico, consulta Panoramica della gestione del traffico per un bilanciatore del carico delle applicazioni classico.

Per informazioni sulla gestione del traffico con i bilanciatori del carico delle applicazioni esterni regionali, consulta la Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.

Oltre alle funzionalità di routing avanzate descritte in questa pagina, i bilanciatori del carico delle applicazioni supportati si integrano con le estensioni di servizio per consentirti di inserire una logica personalizzata nel percorso dei dati di bilanciamento del carico.

Prima di iniziare

Assicurati di comprendere il funzionamento della gestione del traffico. Per saperne di più, consulta la Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni globali.

Configurare e testare la gestione del traffico

Nell'ambiente di configurazione scelto, configuri la gestione del traffico utilizzando le configurazioni YAML. Una mappa URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda della funzionalità scelta, devi scrivere un file YAML della mappa degli URL, un file YAML del servizio di backend o entrambi.

Per assistenza nella scrittura di questi file YAML, puoi utilizzare gli esempi riportati in questa pagina e la documentazione dell'API Cloud Load Balancing.

La console Google Cloud non è supportata.

La documentazione dell'API global URL map e dell' API global servizio di backend service fornisce un elenco completo dei campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.

Puoi aggiungere test di configurazione a una mappa URL per assicurarti che instradi le richieste come previsto. Puoi sperimentare diverse regole della mappa URL ed eseguire tutti i test necessari per assicurarti che la mappa indirizzi il traffico al servizio di backend o al bucket di backend appropriato. Per maggiori dettagli, vedi Aggiungere test a una mappa degli URL. Se vuoi testare le nuove modifiche a una mappa URL senza eseguirne il deployment, consulta Convalida la configurazione della mappa URL.

Mappa il traffico a un singolo servizio

Invia tutto il traffico a un singolo servizio. Assicurati di sostituire i segnaposto.

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

Suddividi il traffico tra due servizi

Suddividi il traffico tra due o più servizi. Assicurati di sostituire i segnaposto.

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

Configurare un reindirizzamento URL

L'esempio seguente restituisce un codice di risposta 301 MOVED_PERMANENTLY_DEFAULT configurabile. L'esempio imposta anche l'intestazione di risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.

Per creare un reindirizzamento per un bucket di backend, utilizza projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET per il campo defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

Mirroring del traffico

Oltre a inoltrare la richiesta al servizio di backend selezionato, puoi inviare una richiesta identica al servizio di backend mirror configurato in base al principio fire and forget. Ciò significa che il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta sottoposta a mirroring. Il mirroring delle richieste è utile per testare una nuova versione di un servizio di backend. Puoi anche utilizzarlo per eseguire il debug degli errori di produzione in una versione di debug del servizio di backend, anziché nella versione di produzione.

Per impostazione predefinita, il servizio di backend sottoposto a mirroring riceve tutte le richieste, anche se il traffico originale viene suddiviso tra più servizi di backend ponderati. Puoi configurare il servizio di backend sottoposto a mirroring in modo che riceva solo una percentuale delle richieste utilizzando il flag facoltativo mirrorPercent per specificare la percentuale di richieste da sottoporre a mirroring espressa come valore compreso tra 0 e 100,0. La duplicazione delle richieste basata sulla percentuale è in anteprima.

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

Se hai più servizi di backend ponderati e vuoi registrare quale servizio di backend è stato utilizzato per gestire la richiesta originale, puoi aggiungere un'intestazione personalizzata che includa queste informazioni a tutte le richieste. L'esempio seguente aggiunge un'intestazione personalizzata chiamata x-weighted-picked-backend a tutte le richieste client. Per il valore dell'intestazione, utilizza il nome del servizio di backend che ha gestito la richiesta originale.

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

Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:

• Il mirroring del traffico è supportato quando entrambi i servizi di backend hanno backend di gruppi di istanze gestite, NEG a livello di zona o NEG ibridi. Non è supportato per i NEG di internet, i NEG serverless e i backend Private Service Connect.
• Le richieste al servizio di backend sottoposto a mirroring non generano log o metriche per Cloud Logging e Cloud Monitoring.

Riscrivere l'URL richiesto

Riscrivi la parte del nome host dell'URL, la parte del percorso dell'URL o entrambe, prima di inviare una richiesta al servizio di backend selezionato. Assicurati di sostituire i segnaposto.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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

Riprovare a inviare una richiesta

Configura le condizioni in base alle quali il bilanciatore del carico ritenta le richieste non riuscite, il tempo di attesa del bilanciatore del carico prima di riprovare e il numero massimo di tentativi consentiti.

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

Specifica il timeout del percorso

Specifica il timeout per l'itinerario selezionato. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui la risposta viene elaborata completamente. Timeout include tutti i tentativi. Assicurati di sostituire i segnaposto.

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

Configura l'inserimento di errori

Introduci errori durante la gestione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori del servizio e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio a guasti simulati.

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

Configurare CORS

Configura i criteri di condivisione delle risorse tra origini (CORS) per controllare il modo in cui il bilanciatore del carico gestisce le richieste tra origini diverse.

Policy CORS applicata a livello di matcher percorso

In questa configurazione, le norme CORS sono definite in defaultRouteAction del matcher di percorso (pathMatchers[].defaultRouteAction.corsPolicy). Ciò significa che le norme vengono applicate a tutte le richieste instradate tramite il matcher di percorso predefinito, indipendentemente dal percorso o dalla route specifici.

Questo approccio è adatto quando vuoi un'unica policy CORS coerente per tutte le route gestite da un path matcher.

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

Come funziona

• Il bilanciatore del carico applica la policy CORS a tutte le richieste gestite dal matcher di percorso.
• Sono consentite solo le richieste dall'host example.com che utilizzano i metodi GET o POST e con le intestazioni consentite (Authorization, Content-Type).
• Le credenziali (come cookie o intestazioni di autorizzazione) sono consentite nelle richieste multiorigine.
• Il servizio di backend riceve solo le richieste conformi a queste norme CORS.

Policy CORS applicata a livello di regola di route

In questa configurazione, il criterio CORS è definito all'interno di un routeAction per una regola di route specifica (pathMatchers[].routeRules[].routeAction.corsPolicy). Ciò consente di applicare criteri CORS diversi a route o prefissi di percorso diversi.

Questo approccio è adatto quando hai bisogno di un controllo granulare, ad esempio per applicare criteri CORS diversi a endpoint o percorsi API diversi.

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

Come funziona

• Le norme CORS vengono applicate solo alle richieste che corrispondono al prefisso del percorso specificato (ad esempio, /PREFIX).
• Per questa route sono consentite solo le richieste dell'host example.com che utilizzano i metodi GET o POST e con le intestazioni consentite.
• Il campo maxAge specifica per quanto tempo i risultati di una richiesta preflight possono essere memorizzati nella cache dal browser (in secondi).
• Le credenziali sono consentite nelle richieste multiorigine.
• Altri percorsi possono avere criteri CORS diversi o non averne affatto.

Puoi anche definire una policy CORS ai seguenti livelli di una mappa URL:

• defaultRouteAction.corsPolicy
• pathMatchers[].pathRules[].routeAction.corsPolicy

Aggiungere e rimuovere intestazioni di richiesta e risposta

Aggiungi e rimuovi le intestazioni della richiesta prima di inviare una richiesta al servizio di backend. Aggiungi e rimuovi anche le intestazioni delle risposte dopo aver ricevuto una risposta dal servizio di backend.

Esistono limitazioni sui valori validi per headerName e headerValue. Per maggiori dettagli, vedi Come funzionano le intestazioni personalizzate.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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

Configurare il rilevamento outlier

Specifica i criteri per l'espulsione di VM o endpoint di backend non integri nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro da ricevere nuovamente traffico. Assicurati di sostituire i segnaposto.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/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

Configurare la suddivisione del traffico: procedura dettagliata

Questo esempio mostra i seguenti passaggi:

1. Crea modelli distinti per servizi diversi.

2. Crea gruppi di istanze per questi modelli.

3. Crea regole di routing che configurino la suddivisione del traffico al 95% / 5%.

4. Invia comandi curl che mostrino che le percentuali di suddivisione del traffico corrispondono approssimativamente alla configurazione.

Queste istruzioni presuppongono quanto segue:

• Sono stati creati un proxy di destinazione e una regola di forwarding, insieme a una mappa URL denominata global-lb-map.

• La mappa URL invia tutto il traffico a un servizio di backend, chiamato red-service, che è il servizio di backend predefinito.

• Hai configurato un percorso alternativo che invia il 5% del traffico a blue-service e il 95% del traffico a green-service.

• Viene utilizzato un matcher percorso.

• Stai utilizzando Cloud Shell o un altro ambiente con bash installato.

Definisci i servizi

La seguente funzione bash crea un servizio di backend, inclusi il modello di istanza e il gruppo di istanze gestite.

Queste istruzioni presuppongono che sia stato creato un controllo di integrità HTTP (global-lb-basic-check). Per istruzioni, consulta una delle seguenti pagine:

• Configurazione di un bilanciatore del carico delle applicazioni esterno globale con un backend Compute Engine
• Configurazione di un bilanciatore del carico delle applicazioni esterno globale con un bucket di backend
• Configurazione di un bilanciatore del carico delle applicazioni esterno globale con connettività ibrida
• Configurazione di un bilanciatore del carico delle applicazioni esterno globale con con Cloud Run, App Engine o Cloud Run Functions

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)
}

Crea i servizi

Chiama la funzione per creare tre servizi: red, green e blue. Il servizio red funge da servizio predefinito per le richieste a /. I servizi green e blue sono entrambi configurati su /prefix per gestire rispettivamente il 95% e il 5% del traffico.

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

Crea la mappa URL

Testare la configurazione

Per testare la configurazione, assicurati innanzitutto che le richieste all'indirizzo IP del bilanciatore del carico configurato in precedenza vengano gestite dalla configurazione red predefinita.

Poi controlla che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/prefix siano suddivise come previsto.

Configura l'affinità sessione in base a HTTP_COOKIE

Il controllo del traffico consente di configurare l'affinità sessione in base a un cookie fornito. Per configurare l'affinità sessione basata su HTTP_COOKIE per un servizio di backend denominato red-service, segui queste istruzioni.

1. Utilizza il comando gcloud compute backend_services export per ottenere la configurazione del servizio di backend.

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

2. Aggiorna il file red-service-config.yaml come segue:

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

3. Nel file red-service-config.yaml, elimina la seguente riga:

   sessionAffinity: NONE
   

4. Aggiorna il file di configurazione del servizio di backend:

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

Risoluzione dei problemi

Utilizza queste informazioni per la risoluzione dei problemi quando il traffico non viene instradato in base alle regole di routing e alle norme sul traffico che hai configurato.

Per informazioni su logging e monitoraggio, consulta Logging e monitoraggio HTTP(S) esterno.

Sintomi:

• Aumento del traffico verso i servizi nelle regole sopra la regola in questione.
• Un aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.

Soluzione: controlla l'ordine delle regole di routing. Le regole di route vengono interpretate nell'ordine in cui vengono specificate.

Le regole di routing all'interno di una mappa URL vengono interpretate nell'ordine in cui sono specificate. Questo è diverso dal modo in cui le regole di percorso vengono interpretate dalla corrispondenza del prefisso più lungo. Per una regola di percorso, il bilanciatore del carico delle applicazioni esterno globale seleziona una sola regola di percorso; tuttavia, quando utilizzi le regole di routing, è possibile che ne vengano applicate più di una.

Quando definisci le regole di routing, verifica che le regole nella parte superiore dell'elenco non indirizzino inavvertitamente il traffico che altrimenti sarebbe stato indirizzato da una regola di routing successiva. Il servizio che riceve il traffico reindirizzato probabilmente rifiuterà le richieste e il servizio nelle regole di routing riceverà un traffico ridotto o nullo.

Passaggi successivi

• Pulisci la configurazione del bilanciatore del carico.