Übersicht über Trafficverwaltung für externe HTTP(S)-Load-Balancer

Das externe HTTP(S)-Load-Balancing unterstützt erweiterte Trafficverwaltungsfunktionen, mit denen Sie die folgenden Features verwenden können:

Sie konfigurieren diese Funktionen mithilfe der URL-Zuordnung des Load-Balancers. Hintergrundinformationen finden Sie in den folgenden Themen:

Trafficverwaltung – Komponenten

Auf allgemeiner Ebene bieten externe HTTP(S)-Load-Balancer die Trafficverwaltung mithilfe von globalen URL-Zuordnungen.

Der Load-Balancer bietet die folgenden sich gegenseitig ausschließenden primären Aktionen:

  • Anfragen an einen Back-End-Dienst weiterleiten
  • Weiterleitung ausführen

Wenn Sie einen Load-Balancer einrichten, können Sie eine URL-Überschreibungsaktion konfigurieren, bevor der Load-Balancer Anfragen an den Back-End-Dienst oder den Back-End-Bucket sendet.

Umschreibungen oder Weiterleitungen können in der URL-Zuordnung auf drei Ebenen angewendet werden:

  • Auf der Ebene pathRule, wobei die Aktion wirksam wird, wenn ein Pfad übereinstimmt
  • Auf der Ebene pathMatcher, wobei die Aktion wirksam wird, wenn keine Pfade für die Ebene pathMatcher übereinstimmen
  • Auf der Ebene urlMap, wobei die Aktion wirksam wird, wenn keiner der in einer der Hostregeln angegebenen Hosts übereinstimmt

Die Verwendung von routeRules in einem pathMatcher ist eine Alternative zu pathRules. pathRules und routeRules dürfen nicht zusammen im selben pathMatcher vorkommen. Im Gegensatz zu pathRules, bei dem die Reihenfolge keine Rolle spielt, werden routeRules in Bezug auf die Reihenfolge untersucht. Ein routeRule kann den URL-Pfad, die HTTP-Header und die URL-Abfrageparameter testen.

Fallbeispiele

Die Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Umschreibungen

Mit URL-Überschreibungen können Sie externen Nutzern URLs bereitstellen, die sich von den URLs unterscheiden, die von Ihren Diensten verwendet werden.

Eine URL-Überschreibung trennt eine URL von einer Ressource. Sie können von benutzerfreundlichen URLs übersetzen, die für Nutzer leichter zu merken und zu verwenden sind. Dabei werden sie in suchmaschinenfreundliche URLs, die von Suchmaschinen leichter gefunden werden können, oder in interne implementierungsspezifische URLs umgewandelt.

Die Funktion zum Umschreiben von URLs mit HTTP(S)-Load-Balancing hat folgende Aufgaben:

  1. Eingehende URL in der Anfrage lesen.
  2. Host und/oder Pfad ersetzen und die URL umwandeln, bevor Traffic an den Back-End-Dienst oder den Back-End-Bucket weitergeleitet wird.

Im folgenden Diagramm geschieht Folgendes:

  1. Ein Nutzer in Japan sendet eine Anfrage für die URL www.mydomain.com/static/images/someimage.jpg.
  2. Wenn die Anfrage den externen HTTP(S)-Load-Balancer erreicht, verwendet der Load-Balancer Informationen in der URL-Zuordnung, um die URL in www.myorigin.com/august_snapshot/images/someimage.jpg umzuschreiben.
  3. (Optional) In diesem Beispiel sendet die URL-Zuordnung die Anfrage an einen benutzerdefinierten Ursprung.
Eine Umschreibung des HTTP(S)-Load-Balancings (zum Vergrößern klicken)
Externe HTTP(S)-Load-Balancer-Umschreibung

Ein Konfigurationsbeispiel finden Sie unter Überschreibungen.

Weiterleitungen

Mit URL-Weiterleitungen können Sie Clientanfragen von einer URL an eine andere URL weiterleiten.

Sie haben folgende Möglichkeiten:

  • Alle HTTP-Anfragen an HTTPS-Anfragen weiterleiten.
  • An eine andere URL weiterleiten, indem Sie den Host, den Pfad oder den Host- und Pfadteil der URL ändern und entweder Abfrageparameter entfernen oder beibehalten.
  • Auswählen, welche Weiterleitungsantwortcodes ausgegeben werden sollen.

Mit URL-Weiterleitungen können Sie Folgendes tun:

  • Eine URL-Kürzung festlegen. Kunden-URLs erheblich verkürzen. Dieser Dienst gibt eine Weiterleitung auf die Webseite mit der langen URL aus.
  • Fehlerhafte Links verhindern, wenn Webseiten verschoben werden oder veraltet sind.
  • Zulassen, dass mehrere Domainnamen desselben Inhabers auf eine einzelne Website verweisen.
  • Aufwände und Ineffizienzen bei der Konfiguration von Problemumgehungen auf dem Back-End-Server vermeiden, um die erforderliche Weiterleitung zu unterstützen.
  • Latenz reduzieren. Am Netzwerkrand erstellte Weiterleitungen können zu einer geringeren Latenz führen als Weiterleitungen, die an den Back-End-Endpunkten erstellt wurden.

HTTP-zu-HTTPS-Weiterleitungen unterstützen Sie insbesondere bei Folgendem:

  • Erfüllen von Compliance-Anforderungen (z. B. HIPAA) für verschlüsselten Traffic.
  • Weiterleiten von Anfragen mit HTTPS, anstatt Anfragen mit dem HTTP-Protokoll abzulehnen.
  • Verbessern des Sicherheitsprofils Ihrer Anwendung, indem der Traffic am Layer-7-Load-Balancer selbst weitergeleitet wird, anstatt die Weiterleitung auf dem Back-End-Server zu implementieren.

Im folgenden Diagramm geschieht Folgendes:

  1. Ein Nutzer in Japan sendet eine GET http://example.com/img1-Anfrage.
  2. Anhand der in der URL-Zuordnung definierten Weiterleitung sendet der Load-Balancer eine HTTP/1.1 302 Found Location: https://example.com/img1-Weiterleitung und leitet die HTTP-Anfrage an eine HTTPS-Anfrage weiter.
  3. Der Browser des Nutzers sendet eine GET https://example.com/img1-Anfrage.
Externen HTTP(S)-Load-Balancer umschreiben
HTTP(S)-Load-Balancing-Weiterleitung

Ein Konfigurationsbeispiel finden Sie unter Weiterleitungen.

Unterstützte Antwortcodes

Die unterstützten Weiterleitungsantwortcodes sind in der Tabelle aufgeführt.

Antwortcode Zahl Hinweise
MOVED_PERMANENTLY_DEFAULT 301
FOUND 302
PERMANENT_REDIRECT 308 In diesem Fall wird die Anfragemethode beibehalten.
TEMPORARY_REDIRECT 307 In diesem Fall wird die Anfragemethode beibehalten.
SEE_OTHER 303

Header- und parameterbasiertes Routing

Header- und parameterbasiertes Routing ermöglicht es einem Load-Balancer, Routingentscheidungen zu treffen, die auf HTTP-Headern und URL-Abfrageparametern beruhen.

Mit dieser Funktion können Sie Ihre Cloud-Architektur vereinfachen, ohne zusätzliche Proxy-Ebenen (z. B. NGINX) für das Routing bereitzustellen.

Mit dem externen HTTP(S)-Load-Balancer können Sie Folgendes tun:

  • A/B-Tests
  • Kunden verschiedenen Diensten, die auf Back-Ends ausgeführt werden, zuweisen
  • Verschiedene Seiten und Varianten anhand der verschiedenen Gerätekategorien, von denen die Anfragen stammen, bereitstellen

Nachdem ein pathMatcher anhand des Hoststrings ausgewählt wurde, wählen die routeRules im pathMatcher einen URL-Pfad aus. Weitere Informationen finden Sie in der Übersicht über URL-Zuordnungen.

Beispiel: A/B-Tests mit abfrageparameterbasiertem Routing konfigurieren

Das folgende Beispiel zeigt, wie Sie A/B-Tests machen, indem Sie den Abfragestring abgleichen, um den Test und die Eingabe anzugeben.

Angenommen, Sie möchten sicherstellen, dass Anfragen so verarbeitet werden:

  • Alle Anfragen mit dem Abfrageparameterwert A werden an den Back-End-Dienst namens BackendServiceForProcessingOptionA gesendet.
  • Alle Anfragen mit dem Abfrageparameterwert B werden an den Back-End-Dienst namens BackendServiceForProcessingOptionB gesendet.

Diese Anforderungen sind in der folgenden Tabelle zusammengefasst.

Anfrage Back-End-Dienst
http://test.mydomain.com?ABTest=A BackendServiceForProcessingOptionA
http://test.mydomain.com?ABTest=B BackendServiceForProcessingOptionB

Um dies in Ihrer globalen URL-Zuordnung zu konfigurieren, können Sie die folgenden Einstellungen festlegen.

Filter Aktion
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB

Ein Konfigurationsbeispiel finden Sie unter Header- und parameterbasiertes Routing.

Routinganfragen an Back-Ends

Beim HTTP(S)-Load-Balancing wird das Back-End für Ihren Traffic mithilfe eines zweistufigen Ansatzes bestimmt:

  • Der Load-Balancer wählt einen Back-End-Dienst mit Back-Ends aus. Folgende Back-Ends sind möglich:

    • Compute Engine-VM-Instanzen in einer nicht verwalteten Instanzgruppe
    • Compute Engine-VMs in einer verwalteten Instanzgruppe (Managed Instance Group, MIG)
    • Container mithilfe eines Google Kubernetes Engine-Knotens (GKE) in einer zonalen Netzwerk-Endpunktgruppe (NEG)
    • Benutzerdefinierte Ursprünge außerhalb von Google Cloud in einer Internet-NEG
    • Cloud Storage in Back-End-Buckets
    • App Engine-, Cloud Functions- oder Cloud Run-Dienste (vollständig verwaltet) in einer serverlosen NEG

    Der Load-Balancer wählt einen Back-End-Dienst anhand von Regeln aus, die in einer globalen URL-Zuordnung definiert sind.

  • Der Back-End-Dienst wählt eine Back-End-Instanz anhand von Richtlinien aus, die in einem globalen Back-End-Dienst definiert sind.

Beim Konfigurieren des Routings können Sie zwischen den folgenden Modi wählen:

  • Einfache Host- und Pfadtests mit pathRules
  • Erweiterte Anfragetests mit routeRules

Für jede URL-Zuordnung können Sie einfache Host- und Pfadregeln oder erweiterte Host-, Pfad- und Routingregeln verwenden. Die beiden Modi schließen sich gegenseitig aus. Jede URL-Zuordnung kann jeweils nur einen der Modi enthalten.

Einfache Host- und Pfadregeln

In einer einfachen Host- und Pfadregel funktionieren URL-Zuordnungen wie unter Übersicht über URL-Zuordnungen beschrieben.

Das folgende Diagramm zeigt den logischen Ablauf einer einfachen Host- und Pfadregel.

Einfache URL-Zuordnung
Einfache URL-Zuordnung

Eine Anfrage wird erst einmal mithilfe von Hostregeln ausgewertet. Ein Host ist die in der Anfrage angegebene Domain. Wenn die Anfrage host mit einem der Einträge im Feld hosts übereinstimmt, wird der zugehörige Pfad-Matcher verwendet.

Als Nächstes wird der Pfad-Matcher ausgewertet. Pfadregeln werden nach dem Prinzip "längster Pfad zuerst" abgeglichen. Sie können Pfadregeln in beliebiger Reihenfolge angeben. Nachdem die genaueste Übereinstimmung gefunden wurde, wird die Anfrage an den entsprechenden Back-End-Dienst weitergeleitet. Wenn die Anfrage nicht übereinstimmt, wird der Standard-Back-End-Dienst verwendet.

Eine typische einfache Host- und Pfadregel sieht in etwa so aus: Der Videotraffic wird auf video-backend-service und der gesamte andere Traffic auf web-backend-service übertragen.

$ gcloud compute url-maps describe ext-https-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Ein Konfigurationsbeispiel finden Sie unter Host und Pfad.

Erweiterte Host-, Pfad- und Routingregel

Erweiterte Host-, Pfad- und Routingregeln bieten im Vergleich zu einfachen Host- und Pfadregeln zusätzliche Konfigurationsoptionen. Diese Optionen ermöglichen erweiterte Trafficverwaltungsmuster und ändern auch einen Teil der Semantik. Beispielsweise werden Routingregeln in der angegebenen Reihenfolge ausgeführt (statt anhand des Prinzips "längster Pfad zuerst").

Wie im vorherigen Beispiel für eine einfache Host- und Pfadregel beschrieben, können Sie die erweiterte Trafficverwaltung mithilfe einer globalen URL-Zuordnung konfigurieren, verwenden jedoch anstelle von pathMatchers[].pathRules[] pathMatchers[].routeRules[].

In den folgenden Abschnitten werden die erweiterten Komponenten für Host-, Pfad- und Routingregeln erläutert.

Hostregeln

Wenn eine Anfrage beim Load-Balancer eingeht, wird das Feld host der Anfrage mit dem in der URL-Zuordnung definierten Wert hostRules abgeglichen. Jede Hostregel besteht aus einer Liste mit einem oder mehreren Hosts und einem einzelnen Pfad-Matcher (pathMatcher). Wenn keine hostRules definiert sind, wird die Anfrage an defaultService weitergeleitet.

Weitere Informationen finden Sie unter hostRules[] und defaultService in der Dokumentation zur globalen URL Map API.

Pfad-Matcher

Wenn eine Anfrage mit einer Hostregel übereinstimmt, wertet der Load-Balancer den Pfad-Matcher aus, der dem Host entspricht.

Ein Pfad-Matcher besteht aus Folgendem:

  • Einer oder mehrerer Pfadregeln (pathRules) oder Routingregeln (routeRules).
  • Eine Standardregel, die ausgeführt wird, wenn keine anderen Back-End-Dienste übereinstimmen. Die Regel hat die folgenden sich gegenseitig ausschließenden Optionen:

    • Ein Standarddienst gibt den Standard-Back-End-Dienst an, an den weitergeleitet wird, wenn keine anderen Back-End-Dienste übereinstimmen.
    • Eine Standardweiterleitung gibt die URL an, an die weitergeleitet wird, wenn keine anderen Back-End-Dienste übereinstimmen.

Wenn der Load-Balancer für einen Standarddienst konfiguriert ist, kann er zusätzlich so konfiguriert werden, dass die URL neu geschrieben wird, bevor die Anfrage an den Standarddienst gesendet wird.

Weitere Informationen finden Sie unter pathMatchers[], pathMatchers[].pathRules[] und pathMatchers[].routeRules[] in der Dokumentation zur globalen URL Map API.

Pfadregeln

Pfadregeln (pathRules) geben einen oder mehrere URL-Pfade an, z. B. / oder /video. Pfadregeln sind im Allgemeinen für das zuvor beschriebene host- und pfadbasierte Routing vorgesehen.

Weitere Informationen finden Sie unter pathRules[] in der Dokumentation zur globalen URL Map API.

Routingregeln

Eine Routingregel (routeRules) gleicht Informationen in einer eingehenden Anfrage ab und trifft anhand der Übereinstimmung eine Routingentscheidung.

Routingregeln können eine Vielzahl verschiedener Übereinstimmungsregeln (matchRules) und eine Vielzahl verschiedener Routingaktionen (routeAction) enthalten.

Eine Übereinstimmungsregel wertet die eingehende Anfrage anhand des Pfades, der Header und der Abfrageparameter der HTTP(S)-Anfrage aus. Übereinstimmungsregeln unterstützen verschiedene Arten von Übereinstimmungen (z. B. Präfixübereinstimmung) sowie Modifikatoren (z. B. Groß- und Kleinschreibung). So können Sie beispielsweise HTTP(S)-Anfragen an eine Reihe von Back-Ends senden, je nachdem, ob ein benutzerdefinierter HTTP-Header vorhanden ist.

Eine detaillierte Liste der von matchRules unterstützten Optionen finden Sie unter matchRules[] in der Dokumentation zur globalen URL Map API.

Wenn Sie mehrere Weiterleitungsregeln haben, führt der Load-Balancer diese in der angegebenen Reihenfolge aus, sodass Sie benutzerdefinierte Logik für Abgleich, Routing und andere Aktionen festlegen können.

In einer Routingregel beendet der Load-Balancer nach der ersten Übereinstimmung die Auswertung der Übereinstimmungsregeln. Alle verbleibenden Übereinstimmungsregeln werden ignoriert.

Google Cloud führt die folgenden Aktionen aus:

  1. Sucht nach der ersten Übereinstimmungsregel, die der Anfrage entspricht
  2. Beendet die Suche nach anderen Übereinstimmungsregeln
  3. Wendet die Aktionen in den entsprechenden Routingaktionen an

Routingregeln bestehen aus mehreren Komponenten, die in der folgenden Tabelle beschrieben werden.

Komponente der Routingregel (API field name) Beschreibung
Priorität (priority) Eine Zahl von 0 bis 2.147.483.647 (also (2^31)-1), die einer Routingregel innerhalb eines angegebenen Pfad-Matchers zugewiesen ist, um die Reihenfolge der Auswertung von Routingregeln zu bestimmen.

Die höchste Priorität ist 0. Die niedrigste Priorität ist 2147483647. Beispielsweise wird eine Regel mit der Priorität 4 vor einer Regel mit der Priorität 25 ausgewertet. Die erste Regel, die der Anfrage entspricht, wird angewendet.

Prioritätsnummern können Lücken haben. Sie müssen nicht fortlaufend sein. Sie können nicht mehrere Regeln mit derselben Priorität erstellen.
Beschreibung (description) Eine optionale Beschreibung von bis zu 1.024 Zeichen.
Dienst (service) Die vollständige oder Teil-URL der Back-End-Dienstressource, an die der Traffic weitergeleitet wird, wenn diese Regel übereinstimmt.
Übereinstimmungsregeln (matchRules) Eine oder mehrere Regeln, die anhand der Anfrage ausgewertet werden. Diese matchRules können mit allen oder einem Teil der HTTP-Attribute der Anfrage übereinstimmen, z. B. mit den Parametern "Pfad", "HTTP-Header" und "Abfrage (GET)".

Innerhalb einer matchRule müssen alle Übereinstimmungskriterien erfüllt sein, damit die routeActions der routeRule wirksam werden. Besitzt eine routeRule mehrere matchRules, werden die routeActions der routeRule wirksam, wenn eine Anfrage mit einer der matchRules der routeRule übereinstimmt.
Routingaktion (routeAction) Hiermit können Sie eine URL-Umschreibungsaktion angeben, die ausgeführt werden soll, wenn die Kriterien der Übereinstimmungsregel erfüllt sind.
Weiterleitungsaktion (urlRedirect) Sie können eine Aktion so konfigurieren, dass sie mit einer HTTP-Weiterleitung antwortet, wenn die Kriterien der Übereinstimmungsregel erfüllt sind. Dieses Feld kann nicht in Verbindung mit einer Routingaktion verwendet werden.

Weitere Informationen finden Sie in den folgenden Feldern der Dokumentation zur globalen URL Map API:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect

Übereinstimmungsregeln

Übereinstimmungsregeln (matchRules) stimmen mit einem oder mehreren Attributen einer Anfrage überein und führen die in der Routingregel festgelegten Aktionen aus. Die folgende Liste enthält einige Beispiele für Anfrageattribute, die mithilfe von Übereinstimmungsregeln abgeglichen werden können:

  • Host: Der Hostname ist der Domainnamen-Teil einer URL. Der Hostname der URL http://example.net/video/hd ist beispielsweise example.net. In der Anfrage stammt der Hostname aus dem Header Host, wie in diesem curl-Beispielbefehl gezeigt, wobei 10.1.2.9 die Load-Balancing-IP-Adresse ist:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Die Pfade folgen dem Hostnamen, z. B. /images. Die Regel kann angeben, ob der gesamte Pfad oder nur der führende Teil des Pfads übereinstimmen muss.

  • Andere HTTP-Anfrageparameter wie HTTP-Header, die einen Cookie-Abgleich ermöglichen, sowie Abgleiche, die auf Abfrageparametern beruhen (GET-Variablen). Beachten Sie, dass der Abgleich regulärer Ausdrücke für Headerwerte nicht unterstützt wird.

Eine vollständige Liste der unterstützten Abgleichsregeln finden Sie unter pathMatchers[].routeRules[].matchRules[] in der Dokumentation zur globalen URL Map API.

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.

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

Beschränkungen

  • UrlMap.tests unterstützt derzeit Tests für einfaches Routing.
  • gcloud import-Befehle löschen keine Felder der obersten Ebene der URL-Zuordnung wie defaultService, defaultRouteAction und defaultUrlRedirect. Sie können dieses Problem umgehen, indem Sie eine neue URL-Zuordnung mithilfe der YAML-Datei mit aktualisierten Werten für diese Felder der obersten Ebene erstellen und die neue URL-Zuordnung mit dem entsprechenden Zielproxy verknüpfen.
  • Reguläre Ausdrücke werden nicht unterstützt.
  • Headeraktionen in der URL-Zuordnung, z. B. Hinzufügen oder Entfernen von Headern, werden nicht unterstützt.
  • Komplexitätslimits:
    • Maximal 50 routeRules pro pathMatcher.
    • Maximal 50 matchRules pro routeRule.
    • Maximal 50 headerMatches pro matchRule.
    • Maximal 50 queryParameterMatches pro matchRule.
  • Sie können keinen pathMatcher mit pathRules und einen weiteren mit routeRules haben.
  • Sie können in routeRules keine Back-End-Buckets angeben.

Nächste Schritte