Trafficverwaltung für interne HTTP(S)-Load-Balancer einrichten

Diese Anleitung enthält Beispiele für die Einrichtung der Trafficverwaltung für das interne HTTP(S)-Load-Balancing. Dieses Dokument enthält für bestimmte Anwendungsfälle Beispiele für die Verwendung der Trafficverwaltung. Darüber hinaus sind noch weitere Anwendungsfälle möglich.

Vorbereitung

Trafficverwaltung konfigurieren

Sie können die Trafficverwaltung mithilfe der Cloud Console, anhand von gcloud oder über die Cloud Load Balancing API konfigurieren. In der ausgewählten Konfigurationsumgebung richten Sie die Trafficverwaltung mithilfe von YAML-Konfigurationen ein. Eine URL-Zuordnung und ein Back-End-Dienst haben jeweils eine eigene YAML-Datei. Je nach gewünschter Funktion muss entweder eine YAML-Datei für eine URL-Zuordnung, eine YAML-Datei für einen Back-End-Dienst oder beides geschrieben werden.

Wenn Sie Hilfe beim Schreiben dieser YAML-Dateien benötigen, können Sie die folgenden Ressourcen nutzen:

Auf YAML-Beispiele in der Cloud Console zugreifen

So rufen Sie in der Cloud Console YAML-Beispiele auf:

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
    Zur Seite "Load-Balancing"
  2. Klicken Sie unter HTTP(S)-Load-Balancing auf Konfiguration starten.
  3. Wählen Sie Nur zwischen meinen VMs aus. Diese Einstellung bedeutet, dass der Load-Balancer intern ist.
  4. Klicken Sie auf Weiter.
  5. Wählen Sie in der Konfiguration der Routingregeln Erweiterte Host-, Pfad- und Routingregel aus.
  6. Klicken Sie auf Tool zum Abgleich von Hosts und Pfaden hinzufügen.
  7. Klicken Sie auf den Link Code-Anleitung.

Die Seite YAML-Beispiele für Pfadabgleich wird angezeigt.

YAML-Beispiele für URL-Zuordnung

Eine pro URL-Zuordnung zulässig

Einzelner Dienst

Der gesamte Traffic wird an einen einzelnen Dienst gesendet. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100

Traffic aufteilen

Traffic auf mehrere Dienste aufteilen Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: regions/[region]/backendServices/[backend-service1]
        weight: 95
      - backendService: regions/[region]/backendServices/[backend-service2]
        weight: 5

URL-Weiterleitung

Ein konfigurierbarer 3xx-Antwortcode wird zurückgegeben. Außerdem wird der Location-Antwortheader mit dem entsprechenden URI festgelegt. Dabei werden der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      urlRedirect:
        hostRedirect: [REDIRECT_HOST]
        pathRedirect: [REDIRECT_PATH]
        redirectResponseCode: FOUND
        stripQuery: True

Mehrere pro URL-Zuordnung zulässig

Traffic spiegeln

Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst wird eine identische Anfrage an den konfigurierten Spiegel-Back-End-Dienst auf Fire-and-Forget-Basis gesendet. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, an die die gespiegelte Anfrage gesendet wird. Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Back-End-Dienstes anstatt in der Produktionsversion zu beheben. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        requestMirrorPolicy:
          backendService: regions/[region]/backendServices/[backend-service2]

URL umschreiben

Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Back-End-Dienst gesendet wird. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        urlRewrite:
          hostRewrite: [REWRITE_HOST]
          pathPrefixRewrite: [REWRITE_PATH]

Anfrage wiederholen

Die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum Neuversuch sowie die maximal zulässige Anzahl von Wiederholungsversuchen werden konfiguriert. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        retryPolicy:
          retryConditions: 502, 504
          numRetries: 3
          perTryTimeout:
            seconds: 1
            nanos: 50

Zeitüberschreitung

Die Zeitüberschreitung für die ausgewählte Route wird angegeben. Die Zeitüberschreitung wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Hierbei werden alle Wiederholungen berücksichtigt. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        timeout:
          seconds: 30
          nanos: 100

Störungen

Fehler können in die Verarbeitung von Anfragen eingebracht werden, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Dieses Feature ist hilfreich, um die Ausfallsicherheit eines Diensts gegenüber simulierten Störungen zu testen. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        faultInjectionPolicy:
          delay:
            fixedDelay:
              seconds: 10
              nanos: 20
            percentage: 25
          abort:
            httpStatus: 503
            percentage: 50

CORS

Richtlinien werden für Cross-Origin Resource Sharing (CORS) konfiguriert, um die Einstellungen für das interne HTTP(S)-Load-Balancing zur Durchsetzung von CORS-Anfragen zu verarbeiten. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        corsPolicy:
            allowOrigins: my-domain.com
            allowMethods: GET, POST
            allowHeaders: Authorization, Content-Type
            maxAge: 1200
            allowCredentials: True

Header

Anfrage-Header werden hinzugefügt oder entfernt, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwort-Header hinzugefügt oder entfernt werden, nachdem eine Antwort vom Back-End-Dienst empfangen wurde. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      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

YAML-Beispiele für Back-End-Dienste

Ausreißer erkennen

Kriterien für das Entfernen fehlerhafter Back-End-VMs oder Endpunkte in NEGs werden festgelegt sowie die Kriterien dafür, wann ein Back-End oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
name: regions/[region]/backendServices/[backend-service1]
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
region: region/[region]

Schutzschaltung

Mit einer Schutzschaltung können Sie Fehlerschwellenwerte festlegen, damit Clientanfragen Ihre Back-Ends nicht überlasten. Wenn Anfragen ein von Ihnen festgelegtes Limit erreichen, lässt der Load-Balancer keine neuen Verbindungen mehr zu und sendet keine weiteren Anfragen, damit Ihre Back-Ends Zeit erhalten, ihre Arbeitslast zu verarbeiten. Auf diese Weise verhindern Schutzschaltungen Fehlerkaskaden. Anstatt ein Back-End zu überlasten, werden Fehler an den Client zurückgegeben. Dadurch kann ein Teil des Traffics verarbeitet werden, parallel bleibt Zeit zum Lösen von Überlastungsproblemen. Beispielsweise können Zugriffsspitzen durch Erhöhen der Kapazität mithilfe von Autoscaling bewältigt werden.

Legen Sie Obergrenzen für Anfragen pro Verbindung sowie die Anzahl der Verbindungen mit einem Back-End-Dienst fest. Begrenzen Sie auch die Anzahl der ausstehenden Anfragen und Wiederholungsversuche. Ersetzen Sie die mit [] gekennzeichneten Variablen durch entsprechende Werte:

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: region/[region]/instanceGroups/[instance-group]
  maxUtilization: 0.8
circuitBreakers:
  maxConnections: 1000
  maxPendingRequests: 200
  maxRequests: 1000
  maxRequestsPerConnection: 100
  maxRetries: 3
connectionDraining:
  drainingTimeoutSec: 0
healthChecks:
- region/[region]/healthChecks/[health-check]

Trafficaufteilung einrichten

In diesem Beispiel werden die folgenden Schritte veranschaulicht:

  1. Unterschiedliche Vorlagen für verschiedene Dienste erstellen

  2. Instanzgruppen für diese Vorlagen erstellen

  3. Routingregeln erstellen, die 95 % bzw. 5 % Trafficteilung einrichten

  4. curl-Befehle senden, mit denen Sie prüfen, ob die Prozentwerte für die Trafficaufteilung ungefähr der Konfiguration entsprechen

Bei dieser Anleitung wird Folgendes vorausgesetzt:

  • Die Region ist us-west1.
  • Ein Zielproxy und eine Weiterleitungsregel wurden zusammen mit einer URL-Zuordnung mit dem Namen l7-ilb-map erstellt.
  • Die Weiterleitungsregel hat die Adresse 10.1.2.99.

    Eine Anleitung finden Sie unter Internes HTTP(S)-Load-Balancing für Compute Engine-VMs einrichten.

  • Die URL-Zuordnung sendet den gesamten Traffic an einen Back-End-Dienst mit dem Namen red-service. Dies ist der Standard-Back-End-Dienst.

  • Sie haben einen alternativen Pfad eingerichtet, der 5 % des Traffics an blue-service und 95 % des Traffics an green-service sendet.

  • Es wird ein Tool zur Abgleichung von Pfaden verwendet.

  • Sie verwenden Cloud Shell oder eine andere Umgebung, in der bash installiert ist.

Dienste definieren

Die folgende bash-Funktion erstellt einen Back-End-Dienst, einschließlich der Instanzvorlage und der verwalteten Instanzgruppe.

Bei dieser Anleitung wird davon ausgegangen, dass eine HTTP-Systemdiagnose (l7-ilb-basic-check) erstellt wurde. Weitere Informationen finden Sie unter Internes HTTP(S)-Load-Balancing für Compute Engine-VMs einrichten.

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-9 \
    --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=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Dienste erstellen

Rufen Sie nun die Funktion auf, um drei Dienste zu erstellen: red, green und blue. Der Dienst red dient als Standarddienst für Anfragen an /. Die Dienste green und blue werden beide unter /prefix für 95 % bzw. 5 % des Traffics eingerichtet.

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

URL-Zuordnung erstellen

Console

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
    Zur Seite "Load-Balancing"
  2. Klicken Sie auf den Link l7-ilb-map.
  3. Klicken Sie auf Bearbeiten .

Neue Routingregeln konfigurieren

  1. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.
  2. Erstellen Sie unter Tool zum Abgleich von neuen Hosts und Pfaden die Standardaktion. Setzen Sie dazu den Dienst auf red-service.
  3. Klicken Sie auf Fertig.
  4. Klicken Sie auf Tool zum Abgleich von Hosts und Pfaden hinzufügen.
  5. Geben Sie im Feld Hosts 10.1.2.99 ein. Dies ist die IP-Adresse der Weiterleitungsregel Ihres Load-Balancers.
  6. Fügen Sie den folgenden YAML-Inhalt in das Feld Tool zum Abgleich von Pfaden ein. Ersetzen Sie dabei [PROJECT_ID] durch Ihre Projekt-ID:

    defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
    name: matcher1
    routeRules:
    - priority: 2
      matchRules:
        - prefixMatch: /prefix
      routeAction:
        weightedBackendServices:
          - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
            weight: 95
          - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
            weight: 5
    
  7. Klicken Sie auf Fertig.

  8. Klicken Sie auf Aktualisieren.

gcloud

  1. Exportieren Sie die vorhandene URL-Zuordnung mit dem Befehl gcloud compute url-maps export:

    gcloud compute url-maps export l7-ilb-map \
      --destination=l7-ilb-map-config.yaml \
      --region=us-west1
    
  2. Aktualisieren Sie die URL-Zuordnungsdatei l7-ilb-map-config.yaml. Fügen Sie dazu Folgendes am Ende der Datei hinzu und ersetzen Sie dabei [PROJECT_ID] durch Ihre Projekt-ID:

    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    pathMatchers:
    - defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
      name: matcher1
      routeRules:
      - priority: 2
        matchRules:
          - prefixMatch: /prefix
        routeAction:
          weightedBackendServices:
            - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
              weight: 95
            - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
              weight: 5
    
  3. Aktualisieren Sie mit dem Befehl gcloud compute url-maps import die URL-Zuordnung:

    gcloud compute url-maps import l7-ilb-map \
       --region=us-west1 \
       --source=l7-ilb-map-config.yaml
    

Konfiguration testen

Testen Sie die Konfiguration. Achten Sie als Erstes darauf, dass Anfragen an 10.1.2.99/ (die IP-Adresse des Load-Balancers, die zuvor eingerichtet wurde) von der Standardkonfiguration red verarbeitet werden.

Prüfen Sie dann, ob an 10.1.2.99/prefix gesendete Anfragen wie erwartet aufgeteilt werden.

Client-VM erstellen

Informationen hierzu finden Sie unter VM-Instanz zum Testen der Konnektivität erstellen.

Anfragen an 10.1.2.99 senden

Stellen Sie eine SSH-Verbindung zum Client her.

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Führen Sie diesen Befehl aus:

for LB_IP in 10.1.2.99; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done
Ergebnisse prüfen
***
***Results of load balancing to 10.1.2.99:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Anfragen an 10.1.2.99/prefix senden

Senden Sie Anfragen an 10.1.2.99/prefix und notieren Sie sich die Trafficaufteilung.

for LB_IP in 10.1.2.99; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/prefix/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/prefix: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done
Ergebnisse prüfen
***
***Results of load balancing to 10.1.2.99/prefix:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

Bei der Canary-Einrichtung werden 95 % der /prefix-Anfragen erfolgreich an den Dienst green und 5 % der Anfragen erfolgreich an den Dienst blue gesendet.

Mit der Trafficsteuerung können Sie die Sitzungsaffinität anhand eines bereitgestellten Cookies konfigurieren. In diesem Beispiel wird eine auf HTTP_COOKIE basierende Sitzungsaffinität für einen Back-End-Dienst mit dem Namen red-service konfiguriert.

So richten Sie die Sitzungsaffinität mit HTTP_COOKIE ein:

  1. Verwenden Sie den Befehl gcloud compute backend_services export, um die Konfiguration des Back-End-Dienstes abzurufen.

    gcloud compute backend-services export red-service \
        --destination=red-service-config.yaml \
        --region=us-west1
    
  2. Aktualisieren Sie die Datei red-service-config.yaml so:

    sessionAffinity: 'HTTP_COOKIE'
    localityLbPolicy: 'RING_HASH'
    consistentHash:
     httpCookie:
      name: 'http_cookie'
      path: '/cookie_path'
      ttl:
        seconds: 100
        nanos: 30
     minimumRingSize: 10000
    
  3. Löschen Sie in der Datei red-service-config.yaml die folgende Zeile:

    sessionAffinity: NONE
    
  4. Aktualisieren Sie die Konfigurationsdatei für den Back-End-Dienst:

    gcloud compute backend-services import red-service \
        --source=red-service-config.yaml \
        --region=us-west1
    

Fehlerbehebung

Gehen Sie nach den hier beschriebenen Informationen zur Fehlerbehebung vor, wenn der Traffic nicht gemäß den von Ihnen konfigurierten Routingregeln und Trafficrichtlinien weitergeleitet wird.

Informationen zur Protokollierung und Überwachung finden Sie unter Logging und Monitoring für das interne HTTP(S)-Load-Balancing.

Symptome:

  • Vermehrter Traffic an Dienste in Regeln über der betreffenden Regel
  • Unerwartet vermehrte 4xx- und 5xx-HTTP-Antworten für eine bestimmte Routingregel

Lösung: Überprüfen Sie die Reihenfolge Ihrer Routingregeln. Routingregeln werden in der Reihenfolge interpretiert, in der sie angegeben sind.

Routingregeln innerhalb einer URL-Zuordnung werden in der Reihenfolge ihrer Angabe interpretiert. Pfadregeln hingegen werden nach Abgleich mit dem längsten Präfix interpretiert. Bei einer Pfadregel wählt das interne HTTP(S)-Load-Balancing nur eine einzelne Pfadregel aus. Wenn Sie jedoch Routingregeln verwenden, gelten möglicherweise mehrere.

Achten Sie beim Definieren von Routingregeln darauf, dass die Regeln oben in der Liste nicht versehentlich Traffic weiterleiten, der andernfalls von einer nachfolgenden Routingregel weitergeleitet worden wäre. Der Dienst, der fehlgeleiteten Traffic empfängt, würde wahrscheinlich Anfragen ablehnen. Der Dienst in Ihren Routenregeln würde weniger oder keinen Traffic erhalten.