Trafficverwaltung für regionale externe Application Load Balancer einrichten

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.

Das Dokument enthält Beispiele für die folgenden Load-Balancer:

  • Regionaler externer Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Regionenübergreifender interner Application Load Balancer

Regionaler externer Application Load Balancer im Vergleich zum regionalen internen Application Load Balancer. Für die Trafficverwaltungskonfiguration der regionalen Load Balancer bieten die API für regionale URL-Zuordnungen und die API für regionale Backend-Dienste eine Vollständige Liste der Felder, einschließlich der Semantik in Bezug auf Beziehungen, Einschränkungen und Kardinalität.

Der einzige Unterschied zwischen diesen beiden Load Balancern ist das Load Balancing-Schema:

  • Regionale externe Application Load Balancer verwenden EXTERNAL_MANAGED.
  • Regionale interne Application Load Balancer verwenden INTERNAL_MANAGED.

Regionaler interner Application Load Balancer im Vergleich zum regionenübergreifenden internen Application Load Balancer. Für die Konfiguration der Trafficverwaltung:

Zusätzlich zu den auf dieser Seite beschriebenen erweiterten Routingfunktionen sind bestimmte Anwendungs-Load-Balancer in Diensterweiterungen eingebunden, damit Sie benutzerdefinierte Logik in den Load-Balancing-Datenpfad einfügen können, indem Sie Dienst-Erweiterungs-Callouts konfigurieren.

Trafficverwaltung konfigurieren

In der ausgewählten Konfigurationsumgebung richten Sie die Trafficverwaltung mithilfe von YAML-Konfigurationen ein. Eine URL-Zuordnung und ein Backend-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 Backend-Dienst oder beides geschrieben werden.

Wenn Sie Hilfe beim Schreiben dieser YAML-Dateien benötigen, können Sie die Beispiele auf dieser Seite und die Cloud Load Balancing API-Dokumentation verwenden.

Für regionale interne Application Load Balancer und regionale externe Application Load Balancer bieten die API für regionale URL-Zuordnungen und die API für regionale Backend-Dienste folgende Dokumentation: Vollständige Liste der Felder, einschließlich der Semantik in Bezug auf Beziehungen, Einschränkungen und Kardinalität.

Traffic einem einzelnen Dienst zuordnen

Der gesamte Traffic wird an einen einzelnen Dienst gesendet. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

    defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

Traffic auf zwei Dienste aufteilen

Teilen Sie Traffic auf zwei oder zwischen mehreren Diensten auf. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

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

URL-Weiterleitung konfigurieren

Im folgenden Beispiel wird ein konfigurierbarer 3xx-Antwortcode zurückgegeben. Außerdem wird der Antwortheader Location mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/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

Trafficspiegelung

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

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: regions/REGION/backendServices/BACKEND_SERVICE_2

Angeforderte URL umschreiben

Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Backend-Dienst gesendet wird. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

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

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.

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

Routenzeitlimit angeben

Gibt die Zeitüberschreitung für die ausgewählte Route an. Das Zeitlimit wird ab der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

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

Fehlerinjektion konfigurieren

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.

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

CORS konfigurieren

Richtlinien werden für Cross-Origin Resource Sharing (CORS) konfiguriert, um Einstellungen für die Durchsetzung von CORS-Anfragen zu verarbeiten.

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

Anfrage- und Antwortheader hinzufügen und entfernen

Fügen Sie Anfrageheader hinzu und entfernen Sie sie, bevor Sie eine Anfrage an den Backend-Service senden. Außerdem können Antwort-Header hinzugefügt oder entfernt werden, nachdem eine Antwort vom Backend-Dienst empfangen wurde.

Regionale externe Application Load Balancer und interne Application Load Balancer unterstützen auch die Verwendung von Variablen in benutzerdefinierten Headern. Sie können eine oder mehrere Variablen in den Feldern des benutzerdefinierten Headerwerts (headerValue) angeben, die dann in die entsprechenden Werte pro Anfrage übersetzt werden. Eine Liste der unterstützten Headerwerte finden Sie unter Benutzerdefinierte Header in URL-Zuordnungen erstellen.

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

Ausreißererkennung konfigurieren

Kriterien für das Entfernen fehlerhafter Backend-VMs oder Endpunkte in NEGs werden festgelegt sowie die Kriterien dafür, wann ein Backend oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: regions/REGION/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
    region: region/REGION

Schutzschaltung konfigurieren

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.

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or 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: detaillierte Schritte

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 regional-lb-map erstellt.

  • Die URL-Zuordnung sendet den gesamten Traffic an einen Backend-Dienst mit dem Namen red-service. Dies ist der Standard-Backend-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 Pfad-Abgleichstool verwendet.

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

Dienste definieren

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

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-10 \
    --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=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-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")
}

Erstellen Sie die Dienste:

Rufen Sie 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

gcloud

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

    gcloud compute url-maps export regional-lb-map \
  --destination=regional-lb-map-config.yaml \
  --region=us-west1

  2. Aktualisieren Sie die URL-Zuordnungsdatei regional-lb-map-config.yaml. Fügen Sie dazu Folgendes am Ende der Datei hinzu:

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: 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 regional-lb-map \
   --region=us-west1 \
   --source=regional-lb-map-config.yaml

Konfiguration testen

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

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

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 Backend-Dienst mit dem Namen red-service konfiguriert.

  1. Verwenden Sie den Befehl gcloud compute backend-services export, um die Konfiguration des Backend-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: 500000000
 minimumRingSize: 10000

  3. Fügen Sie in der Datei red-service-config.yaml die folgende Zeile ein:

    sessionAffinity: NONE

  4. Aktualisieren Sie die Konfigurationsdatei für den Backend-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.

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ählen interne Application Load Balancer 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.

Nächste Schritte