Trafficverwaltung für regionale externe HTTP(S)-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 HTTP(S)-Load-Balancer
  • Regionaler interner HTTP(S)-Load-Balancer

Bei der Konfiguration der Trafficverwaltung für regionale Load-Balancer besteht der einzige Unterschied zwischen diesen beiden Load-Balancern im Load-Balancing-Schema:

  • Regionale externe HTTP(S)-Load-Balancer verwenden EXTERNAL_MANAGED.
  • Verwenden Sie für regionale interne HTTP(S)-Load-Balancer INTERNAL_MANAGED.

Globale externe HTTP(S)-Load-Balancer verwenden das Load-Balancing-Schema EXTERNAL_MANAGED und globale Load-Balancing-Komponenten wie Weiterleitungsregel, URL-Zuordnung und Back-End-Dienst. Informationen zur Trafficverwaltung mit globalen externen HTTP(S)-Load-Balancern finden Sie unter Trafficverwaltung für globale externe HTTP(S)-Load-Balancer.

Informationen zur Trafficverwaltung mit globalen externen HTTP(S)-Load-Balancern (klassisch) finden Sie unter Trafficverwaltung für globale externe HTTP(S)-Load-Balancer (klassisch).

Trafficverwaltung 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 Beispiele auf dieser Seite und die Cloud Load Balancing API-Dokumentation verwenden.

Die API für regionale URL-Zuordnungen und die API für regionale Back-End-Dienste bieten eine 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 Back-End-Dienst können Sie eine identische Anfrage an den konfigurierten Spiegel-Back-End-Dienst auf Fire-and-Forget-Basis senden. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, an den 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.

   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 Back-End-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 Back-End-Service senden. Außerdem können Antwort-Header hinzugefügt oder entfernt werden, nachdem eine Antwort vom Back-End-Dienst empfangen wurde.

   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 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. 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 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 Pfad-Abgleichstool 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.

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

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

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.

Nächste Schritte