- Trafficsteuerung: Intelligente Weiterleitung von Traffic auf Basis von HTTP(S)-Parametern, z. B. Host, Pfad, Header und andere Anfrageparameter
- Trafficaktionen: Ausführen anfrage- und antwortbasierter Aktionen, z. B. Weiterleitungen und Headertransformationen
- Trafficrichtlinien: Optimieren des Load-Balancing-Verhaltens, z. B. erweiterte Load-Balancing-Algorithmen
Sie können diese Funktionen mithilfe von URL-Zuordnungen und Back-End-Diensten einrichten. Weitere Informationen finden Sie unter folgenden Links:
Fallbeispiele
Die Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.
Trafficsteuerung: Routing auf Basis von Headern
Mithilfe der Trafficsteuerung können Sie Traffic anhand von HTTP-Parametern wie Anfrageheadern zu Dienstinstanzen leiten. Wenn das Gerät eines Nutzers beispielsweise ein Mobilgerät mit user-agent:Mobile im Anfrageheader ist, kann die Trafficsteuerung diesen Traffic an Dienstinstanzen senden, die zur Verarbeitung von mobilem Traffic bestimmt sind. Traffic ohne user-agent:Mobile wird wiederum an Instanzen zur Verarbeitung von Traffic anderer Geräte gesendet.
Trafficaktionen: Gewichtete Trafficaufteilung
Die Bereitstellung einer neuen Version eines bestehenden Produktionsdienstes birgt in der Regel ein gewisses Risiko. Selbst wenn die Tests in der Staging-Phase positiv ausfallen, möchten Sie wahrscheinlich nicht sofort 100 % Ihrer Nutzer die neue Version verwenden lassen. Mit der Trafficverwaltung können Sie prozentuale Trafficaufteilungen für mehrere Backend-Dienste definieren.
Sie können beispielsweise 95 % des Traffics an die vorherige Version Ihres Dienstes und 5 % an die neue Version Ihres Dienstes senden. Nachdem Sie sich vergewissert haben, dass die neue Produktionsversion wie erwartet funktioniert, können Sie die Prozentsätze schrittweise ändern, bis 100 % des Traffics die neue Version Ihres Dienstes erreichen. Die Trafficaufteilung wird gewöhnlich zur Bereitstellung neuer Versionen, für A/B-Tests, Dienstmigration und ähnliche Prozesse verwendet.
Trafficrichtlinien: Anfragespiegelung
Ihre Organisation hat möglicherweise bestimmte Compliance-Anforderungen, die festlegen, dass der gesamte Traffic auf einen zusätzlichen Dienst gespiegelt wird, der z. B. die Anfragedetails zur späteren erneuten Verwendung in einer Datenbank erfasst.
Erweiterbarkeit mit Diensterweiterungen
Durch die Einbindung von Diensterweiterungen können Sie benutzerdefinierte Logik in den Load Balancing-Datenpfad von unterstützten Application Load Balancern einfügen.
Weitere Informationen finden Sie unter Übersicht über Diensterweiterungen.
Trafficverwaltung – Komponenten
Im Allgemeinen bieten interne HTTP(S)-Load-Balancer eine Funktion zur Trafficverwaltung über die Ressourcen für regionale URL-Zuordnungen und regionale Backend-Dienste.Für regionenübergreifende interne Application Load Balancer verwendet die Trafficverwaltung die Ressourcen globaler URL-Zuordnungen und globale Backend-Dienste.
Sie können die Trafficsteuerung und Trafficaktionen mithilfe regionaler URL-Zuordnungen einrichten. Google Cloud-Ressourcen, die mit URL-Zuordnungen verknüpft sind, umfassen Folgendes:
- Routingregel
- Regelübereinstimmung
- Regelaktion
Sie können Trafficrichtlinien mithilfe von Backend-Diensten einrichten. Google Cloud-Ressourcen, die mit Backend-Diensten verknüpft sind, umfassen Folgendes:
- Schutzschalter
- Load-Balancer-Richtlinie für Standorte
- Konsistente Einstellungen für den Hash-Load-Balancer
- Ausreißererkennung
Im folgenden Diagramm sind die Ressourcen dargestellt, die zur Implementierung der einzelnen Features verwendet werden.
Routinganfragen an Back-Ends
Bei internen Application Load Balancern wird das Backend für Ihren Traffic anhand eines zweiphasigen Ansatzes ermittelt:- Der Load-Balancer wählt einen Backend-Dienst mit Backends aus. Die Back-Ends können Compute Engine-VM-Instanzen in einer nicht verwalteten Instanzgruppe, Compute Engine-VMs in einer verwalteten Instanzgruppe (Managed Instance Group, MIG) oder Container über Google Kubernetes Engine-Knoten (GKE) in einer Netzwerk-Endpunktgruppe (NEG) sein. Der Load-Balancer wählt einen Back-End-Dienst anhand von Regeln aus, die in einer regionalen URL-Zuordnung definiert sind.
- Der Back-End-Dienst wählt anhand von Richtlinien, die in einem regionalen Back-End-Dienst definiert sind, eine Back-End-Instanz aus.
Beim Konfigurieren des Routings können Sie zwischen den folgenden Modi wählen:
- Einfache Host- und Pfadregeln
- Erweiterte Host-, Pfad- und Routingregel
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.
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, wobei der Videotraffic auf video-backend-service und der gesamte andere Traffic auf web-backend-service übertragen wird.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1
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. Routingregeln wird z. B. ein Prioritätswert zugewiesen und sie werden in Prioritätsreihenfolge interpretiert (statt anhand des Prinzips "längster Pfad zuerst").
Wie im vorherigen Beispiel für einfache Host- und Pfadregeln können Sie die erweiterte Trafficverwaltung mithilfe einer URL-Zuordnung konfigurieren. Die folgende URL-Zuordnung konfiguriert z. B. ein Routing, bei dem 95 % des Traffics an einen Backend-Dienst und 5 % des Traffics an einen anderen Backend-Dienst weitergeleitet werden.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: regions/us-west1/backendServices/service-a
weight: 95
- backendService: regions/us-west1/backendServices/service-b
weight: 5
region: regions/us-west1
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.
hostRules[] und defaultService in der API-Dokumentation für regionale URL-Zuordnungen.
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). - Einem Standarddienst (
defaultService), der standardmäßig als Backend-Dienst verwendet wird, wenn keine Übereinstimmung mit anderen Backend-Diensten besteht.
pathMatchers[], pathMatchers[].pathRules[] und pathMatchers[].routeRules[] in der API-Dokumentation für regionale URL-Zuordnungen.
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.
pathRules[] in der API-Dokumentation für regionale URL-Zuordnungen.
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.
Hinweis: Übereinstimmungsoptionen und Semantik unterscheiden sich je nach abgeglichenem Anfrageabschnitt. Weitere Informationen finden Sie untermatchRules[] in der API-Dokumentation für regionale URL-Zuordnungen.
Wenn Sie mehrere Routingregeln haben, führt der Load-Balancer diese in Prioritätsreihenfolge aus (basierend auf dem Feld priority). Dies ermöglicht es Ihnen, benutzerdefinierte Logik für den Abgleich, das Routing und andere Aktionen anzugeben.
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:
- Sucht nach der ersten Übereinstimmungsregel, die der Anfrage entspricht
- Beendet die Suche nach anderen Übereinstimmungsregeln
- 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. Die Priorität bestimmt die Reihenfolge der Routingregelauswertung. Die Priorität einer Regel nimmt mit zunehmender Anzahl ab, sodass eine Regel mit der Priorität 4 vor einer Regel mit der Priorität 25 ausgewertet wird. Die erste Regel, die der Anfrage entspricht, wird angewendet.
Prioritätsnummern müssen nicht aufeinanderfolgen. Sie können nicht mehr als eine Regel 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) |
Lässt Sie angeben, welche Aktionen ausgeführt werden sollen, wenn die Kriterien der Übereinstimmungsregel erfüllt sind. Zu diesen Aktionen gehören Trafficaufteilung, URL-Überschreibungen, Wiederholungsversuche und Spiegelung, Fehlerinjektion und CORS-Richtlinien. |
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. |
Headeraktion (headerAction) |
Sie können Headertransformationsregeln für Anfragen und Antworten konfigurieren, wenn die Kriterien innerhalb der matchRules erfüllt sind. |
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].headerAction
Ü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/hdist beispielsweiseexample.net. In der Anfrage stammt der Hostname aus dem HeaderHost, wie in diesem curl-Beispielbefehl gezeigt, wobei10.1.2.9die 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).
pathMatchers[].routeRules[].matchRules[] in der API-Dokumentation für regionale URL-Zuordnungen.
Routingaktionen
Routingaktionen sind spezifische Aktionen, die ausgeführt werden sollen, wenn eine Routingregel mit den Attributen einer Anfrage übereinstimmt.
Routingaktion (API field name) |
Beschreibung |
|---|---|
Weiterleitungen (urlRedirect) |
Ein konfigurierbarer 3xx-Antwortcode wird 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.
|
URL-Umschreibungen (urlRewrite) |
Der Hostnamen-Teil der URL, der Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Backend-Dienst gesendet wird. |
Headertransformationen (headerAction) |
Fügt Anfrageheader hinzu oder entfernt diese, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwortheader nach Empfang einer Antwort des Back-End-Diensts hinzugefügt oder entfernt werden. |
Trafficspiegelung (requestMirrorPolicy) |
Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst auf Fire-and-Forget-Basis wird hierbei eine identische Anfrage an den konfigurierten Spiegelungs-Back-End-Dienst gesendet. Der Load-Balancer wartet nicht auf eine Antwort des Back-End-Diensts, an den die gespiegelte Anfrage gesendet wird. Beachten Sie bei der Verwendung des Traffic-Mirrorings die folgenden Einschränkungen:
|
Gewichtete Trafficaufteilung (weightedBackendServices) |
Lässt zu, dass Traffic für eine übereinstimmende Regel an mehrere Back-End-Dienste verteilt wird, proportional zu einer benutzerdefinierten Gewichtung, die dem jeweiligen Back-End-Dienst zugewiesen ist. Diese Funktion eignet sich zum Konfigurieren abgestufter Bereitstellungen oder von A/B-Tests. Die Routingaktion könnte beispielsweise so konfiguriert werden, dass 99 % des Traffics an einen Dienst gesendet werden, der eine stabile Version einer Anwendung ausführt, während 1 % des Traffics an einen separaten Dienst mit einer neueren Version dieser Anwendung gesendet wird. |
Wiederholungsversuche (retryPolicy) |
Dient zum Konfigurieren von Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, der Wartezeit des Load-Balancers bis zum erneuten Versuch sowie der maximal zulässigen Anzahl an Wiederholungsversuchen. |
Zeitlimit (timeout) |
Gibt das Zeitlimit für die ausgewählte Route an. Das Zeitlimit wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen. |
Fehlerinjektion (faultInjectionPolicy) |
Kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Diese Funktion ist hilfreich, um die Ausfallsicherheit eines Diensts gegenüber simulierten Störungen zu testen. |
Verzögerungsinjektion (faultInjectionPolicy) |
Bringt Verzögerungen für einen benutzerdefinierten Teil von Anfragen ein, bevor die Anfrage an den ausgewählten Back-End-Dienst gesendet wird. |
Abbruchinjektion faultInjectionPolicy |
Reagiert direkt auf einen Teil der Anfragen mit benutzerdefinierten HTTP-Statuscodes, anstatt diese Anfragen an den Back-End-Dienst weiterzuleiten. |
Sicherheitsrichtlinien (corsPolicy) |
Richtlinien für Cross-Origin Resource Sharing (CORS) verarbeiten die Einstellungen für die Erzwingung von CORS-Anfragen. |
Sie können eine der folgenden Routingaktionen angeben:
- Traffic an einen einzelnen Dienst weiterleiten (
service) - Traffic auf mehrere Dienste aufteilen (
weightedBackendServices weight:x, wobei x zwischen 0 und 1.000 liegen muss) - Weiterleitungs-URLs (
urlRedirect)
Darüber hinaus können Sie eine der zuvor genannten Routingaktionen mit einer oder mehreren der folgenden Routingaktionen kombinieren:
- Trafficspiegelung (
requestMirrorPolicy) - URL-Host und -Pfad umschreiben (
urlRewrite) - Fehlgeschlagene Anfragen wiederholen (
retryPolicy) - Zeitlimit festlegen (
timeout) - Fehler in einem Prozentsatz des Traffics einführen (
faultInjectionPolicy) - CORS-Richtlinie hinzufügen (
corsPolicy) - Anfrage- oder Antwortheader bearbeiten (
headerAction)
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
HTTP-zu-HTTPS-Weiterleitungen
Wenn Sie HTTP-Traffic an HTTPS weiterleiten müssen, können Sie zwei Weiterleitungsregeln mit einer gemeinsamen IP-Adresse erstellen.
Damit zwei Weiterleitungsregeln eine gemeinsame interne IP-Adresse haben können, müssen Sie die IP-Adresse reservieren und das Flag--purpose=SHARED_LOADBALANCER_VIP einfügen:
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Ein vollständiges Beispiel finden Sie unter HTTP-zu-HTTPS-Weiterleitung für interne Application Load Balancer einrichten.
Trafficrichtlinien
Durch die Verwendung von Backend-Dienstressourcen können Sie Trafficrichtlinien so konfigurieren, dass das Load-Balancing innerhalb einer Instanzgruppe oder Netzwerk-Endpunktgruppe (NEG) optimiert wird. Diese Richtlinien werden erst wirksam, nachdem ein Backend-Dienst mithilfe der URL-Zuordnung ausgewählt wurde (wie zuvor beschrieben).
Mit Trafficrichtlinien können Sie:
- Den Load-Balancing-Algorithmus zwischen Instanzen innerhalb des Back-End-Dienstes steuern.
- Die Anzahl der Verbindungen zu einem vorgelagerten Dienst steuern.
- Die Bereinigung fehlerhafter Hosts über einen Backend-Dienst steuern.
Trafficrichtlinie (API field name) |
Beschreibung |
|---|---|
Load-Balancing-Richtlinie für den Ort (LocalityLbPolicy) |
Bei einem Backend-Dienst beruht die Trafficverteilung auf dem Load-Balancing-Modus und einer Ort-Load-Balancing-Richtlinie. Der Balancing-Modus bestimmt die Gewichtung/den Anteil des Traffics, der an jedes Backend (Instanzgruppe oder Informationen zu den unterstützten Balancing-Modi finden Sie unter Balancing-Modus. Informationen zu den unterstützten Load-Balancing-Richtlinienalgorithmen finden Sie unter |
Sitzungsaffinität (consistentHash) |
Umfasst Cookie-basierte HTTP-Affinität, Header-basierte HTTP-Affinität, Client-IP-Adressen-Affinität, zustandsorientierte cookiebasierte Sitzungsaffinität und generierte Cookie-Affinität. Die Sitzungsaffinität versucht, Anfragen von einem bestimmten Client an dasselbe Back-End zu senden, solange das Back-End intakt ist und Kapazität hat. Weitere Informationen zur Sitzungsaffinität finden Sie unter |
Ausreißererkennung (outlierDetection) |
Eine Reihe von Richtlinien, die die Kriterien für das Entfernen fehlerhafter Backend-VMs oder Endpunkte in NEGs festlegen sowie die Kriterien dafür, wann ein Backend oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen. Weitere Informationen zur Ausreißererkennung finden Sie unter |
Schutzschaltung (circuitBreakers) |
Legt Obergrenzen für die Anzahl von Verbindungen und Anfragen pro Verbindung mit einem Backend-Dienst fest. Weitere Informationen zur Schutzschaltung finden Sie unter |
Nächste Schritte
- Informationen zum Konfigurieren der Traffic-Verwaltung für interne Application Load Balancer finden Sie unter Traffic-Verwaltung für interne Application Load Balancer einrichten.