Lastverteilung auf Richtlinienbasis
Sowohl öffentliche als auch private Application Load Balancer unterstützen den Lastausgleich auf Layer 4 und Layer 7, bei dem der Datenverkehr auf der Grundlage konfigurierter Richtlinien und Regeln verteilt wird. Eine Richtlinie definiert die Aktion, die ausgeführt werden soll, d. h. sie legt fest, wie der Datenverkehr verteilt wird, wenn die eingehende Anforderung mit den der Richtlinie zugeordneten Regeln übereinstimmt.
Richtlinien der Schicht 7
Sie können Richtlinien für HTTP- und HTTPS-Listener definieren. Für jede Richtlinie müssen Regeln definiert werden. Die Richtlinie wird nur angewendet, wenn alle zugehörigen Regeln erfüllt sind.
Sie können einem Listener eine oder mehrere Richtlinien zuordnen. In der Regel wird die Richtlinie mit der niedrigsten Priorität zuerst ausgewertet. Für jede Richtlinie muss eine andere Priorität definiert werden.
Wenn die eingehende Anforderung nicht mit den Regeln für eine Richtlinie übereinstimmt, wird die Systemanforderung an den konfigurierten HTTPS-Umleitungslistener (falls vorhanden) umgeleitet. Andernfalls leitet das System die Anforderung an den Standardpool des Listeners um. Die HTTPS-Umleitung hat eine Vorrang gegenüber dem Standardpool für einen HTTP-Listener.
Für eine Layer 7-Richtlinie werden die folgenden Aktionen unterstützt:
- Reject (Ablehnen) - Die Anforderung wird mit einer Antwort des Typs 403 zurückgewiesen.
- Redirect (Umleiten) - Die Anforderung wird mit einem Antwortcode an eine konfigurierte URL umgeleitet.
- An Pool weiterleiten – Die Anfrage wird an einen bestimmten Backend-Pool gesendet.
- An Hörer weiterleiten- Die Anfrage wird an einen bestimmten Front-End-Hörer gesendet.
- HTTPS-Umleitung: Die HTTP-Anforderung wird an einen HTTPS-Listener umgeleitet.
Richtlinieneigenschaften
| Eigenschaft | Beschreibung |
|---|---|
| Name | Der Name der Richtlinie. Der Name muss innerhalb des Listeners eindeutig sein. |
| Aktion | Die Aktion, die ausgeführt werden soll, wenn alle Richtlinienregeln erfüllt sind. Die zulässigen Werte sind reject, redirect, forward_to_pool, forward_to_listener und https_redirect. |
| Priorität | Richtlinien werden in aufsteigender Reihenfolge ihrer Priorität ausgewertet. |
| Priorität | Richtlinien werden in aufsteigender Reihenfolge ihrer Priorität ausgewertet. |
| URL | Die URL, an die die Anforderung umgeleitet wird, wenn redirect als Aktion festgelegt ist. Sie müssen entweder eine vollständige URL oder die Parameter einer URI angeben. Wenn Sie eine URL verwenden, wird der gesamte eingehende
Datenverkehr an diese URL weitergeleitet. Bei der Verwendung von URI-Parametern können Werte aus eingehenden Verkehrsanforderungen beibehalten werden, indem die eingehenden Werte der Parameter verwendet werden. Die Standardwerte der
URI-Parameter entsprechen ihren ursprünglichen eingehenden Werten. Um die eingehenden Werte beizubehalten, geben Sie sie als {protocol},{port},{host},{path}, Und {query}.
Wenn der Host der eingehenden Anfrage beispielsweise ibm.com ist, dann ist der Standardwert {host}, was dem eingehenden Wert ibm.com entspricht. |
| HTTP-Statuscode | Der Statuscode der Antwort, die von der Lastausgleichsfunktion für Anwendungen zurückgegeben wird, wenn die Aktion auf redirect oder https_redirect gesetzt ist. Zulässige Werte: 301, 302,
303, 307 und 308. |
| Ziel | Wenn die Aktion auf forward_to_pool gesetzt ist, wird die Anfrage an den Back-End-Pool virtueller Serverinstanzen weitergeleitet. Wenn die Aktion auf forward_to_listener gesetzt ist, wird die Anfrage alternativ
an einen Front-End-Listener desselben ALB weitergeleitet. |
| Empfangsprogramm | Der HTTPS-Listener, an den die Anforderung umgeleitet wird, wenn die Aktion auf https_redirect gesetzt ist. |
| URI | Der relative URI, an den die Anforderung umgeleitet wird, wenn die Aktion https_redirect lautet. Die Angabe dieser Eigenschaft ist optional. |
Layer-7-Regeln
Eine Regel legt fest, wie eine Anfrage abgeglichen wird. URI-basiertes Routing und parameterbasiertes Routing werden unterstützt. Die folgenden fünf Regeltypen werden unterstützt.
| Typ | Beschreibung |
|---|---|
hostname |
Die Anfrage entspricht der angegebenen URL „ hostname “, beispielsweise api.my_company.com. |
header |
Die Anfrage stimmt mit einem Feld und einem Wert unter HTTP header überein, beispielsweise Cookie: xxxx. |
path |
Die Anfrage stimmt mit dem „ path “ im „ URL “ nach dem „ hostname “ überein, wie beispielsweise bei /index.html. |
query |
Die Anfrage stimmt mit der Zeichenfolge „ query “ in der Datei „ URL “ überein, zum Beispiel x=y. Die Zeichenfolge „ query “ muss prozentkodiert sein, und bei der Eingabe wird zwischen Groß- und Kleinschreibung
unterschieden. |
body |
Die Anfrage body für die Anfrage POST ist form-encoded. Die Anforderung stimmt mit dem Hauptteil überein, z. B. key=value. Dabei muss die Groß-/Kleinschreibung beachtet werden. |
sni_hostname |
Der Server, der in der Erweiterung „Server Name Indication“ während der TLS-Verhandlung angegeben wird, stimmt mit dem angegebenen SNI-Hostnamen überein. |
Zum Abgleichen einer Anforderung muss eine Bedingungsanweisung (condition) in einer Regel definiert sein. Die folgenden vier Bedingungen werden unterstützt.
| Bedingung | Art der Auswertung |
|---|---|
contains |
Prüft, ob der anhand von „ type “ extrahierte Wert die Zeichenfolge enthält, die in „ value “ angegeben ist. |
equals |
Prüft, ob der anhand von „ type “ extrahierte Wert mit der in „ value “ angegebenen Zeichenfolge übereinstimmt. |
matches_regex |
Vergleicht den anhand von „ type “ extrahierten Wert mit dem regulären Ausdruck, der unter „ value “ angegeben ist. |
starts_with |
Prüft, ob der anhand von „ type “ extrahierte Wert mit der Zeichenfolge beginnt, die unter „ value “ angegeben ist. |
Regeleigenschaften
In dieser Tabelle werden die Eigenschaften von Richtlinienregeln der Schicht 7 beschrieben.
| Eigenschaft | Beschreibung |
|---|---|
type |
Gibt den Typ der Regel an. Die zulässigen Werte sind hostname, header, path, query oder body. |
condition |
Gibt die Bedingung an, anhand derer die Regel ausgewertet wird. Die unterstützten Werte sind „ contains “, „ equals “ oder „ matches_regex “. |
field |
Gibt den Namen des Felds an. Dieses Feld kann nur auf den Regeltyp header, query und body angewendet werden und unterstützt keine regulären Ausdrücke und keine Platzhalterzeichen. Zum Abgleichen mit
einem Cookie im HTTP-Header kann für das Feld der Wert cookie festgelegt werden. Bei Verwendung der Regeltypen query und body ist dieses Feld optional. Diese Eigenschaft ist nicht auf den Regeltyp
sni_hostname anwendbar. |
value |
Die Zeichenfolge, mit der der Abgleich durchgeführt werden soll. In diesem Feld sind Platzhalterzeichen nicht zulässig. Reguläre Ausdrücke werden unterstützt, wenn die Einstellung „ condition “ auf „ matches_regex “ gesetzt ist. |
Hinweise:
- Wenn der Regeltyp
headerist, sind die folgenden Zeichen fürfieldundvaluenicht zulässig:"(),/:;<=>?@[\]{}'. - Wenn der Regeltyp
bodylautet, ist fürfieldundvaluedie Verwendung der folgenden Zeichen nicht zulässig:"'=,()&und Leerzeichen. - Wenn der Regeltyp
querylautet, muss fürfieldundvalueeine prozentcodierte Zeichenfolge angegeben sein.
Beispiele: Richtlinien und Regeln erstellen
Die folgenden Layer 7-Beispiele zeigen, wie Richtlinien und Regeln erstellt und einem Listener zugeordnet werden.
Beispiel 1: HTTPS-Listener mit Umleitungsrichtlinien erstellen
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" \
-d '{
"certificate_instance": {
"crn": "crn:v1:bluemix:public:cloudcerts:us-south:a/1111111111111111111111111111:22222222-3333-4444-5555-666666666666:certificate:77777777777777777777777777777777"
},
"connection_limit": 2000,
"port": 443,
"protocol": "https",
"policies": [
{
"name": "hostname_header",
"action": "redirect",
"priority": 1,
"target": {
"url": "https://www.examples.com/",
"http_status_code": 307
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "hostname",
"value": "abc.com"
}
]
},
{
"name": "header_cookie",
"action": "redirect",
"priority": 5,
"target": {
"url": "https://www.mycookies.com/",
"http_status_code": 302
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"name": "path_hostname",
"action": "redirect",
"priority": 10,
"target": {
"url": "https://www.myexamples.com/",
"http_status_code": 301
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "abc"
},
{
"condition": "equals",
"value": "/test",
"type": "path"
}
]
},
{
"name": "uri_redirect",
"action": "redirect",
"priority": 10,
"target": {
"url": "https://{host}:8080/{path}?{query}",
"http_status_code": 301
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "pqr"
}
]
}
]
}'
Beispiel 2: Richtlinien für die Weiterleitung von Anforderungen an Pools erstellen und einem vorhandenen Listener zuordnen
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners/$listenerId/policies" \
-d '{
"policies": [
{
"action": "forward",
"priority": 1,
"target": {
"id": "7df616da-4dd6-43d3-881d-801ae29e29fe"
},
"rules": [
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"action": "forward",
"priority": 5,
"target": {
"id": "0738-8061c411-0d50-4c79-b475-102666796434"
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
}
]
},
{
"action": "forward",
"priority": 10,
"target": {
"id": "0738-62914e09-3928-4d89-b7f7-1bb7a6d7fe85"
},
"rules": [
{
"condition": "matches_regex",
"type": "hostname",
"value": "abc[a-z]*.com"
}
]
},
{
"action": "forward",
"priority": 6,
"target": {
"id": "0738-62914e09-3928-4d89-b7f7-1bb7a6d7fe85"
},
"rules": [
{
"condition": "equals",
"type": "path",
"value": "/test/testtest"
}
]
}
]
}'
Beispiel 3: HTTP-Listener mit Richtlinien für die HTTPS-Umleitung
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" \
-d '{
"connection_limit": 2000,
"port": 80,
"protocol": "http",
"policies": [
{
"name": "hostname_header",
"action": "https_redirect",
"priority": 1,
"target": {
"listener": {
"id": "0134-d578be10-31e3-46b3-8513-79babb852319"
},
"http_status_code": 307
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "hostname",
"value": "abc.com"
}
]
},
{
"name": "header_cookie",
"action": "https_redirect",
"priority": 2,
"target": {
"listener": {
"id": "0456-a578be10-31e3-46b3-8513-79babb852398"
},
"http_status_code": 302
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"name": "path_hostname",
"action": "https_redirect",
"priority": 5,
"target": {
"listener": {
"id": "0386-d898be10-21e3-66b3-9513-69babb852390"
},
"http_status_code": 301,
"uri": "/test/sample"
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "abc"
},
{
"condition": "equals",
"value": "/test",
"type": "path"
}
]
}
]
}'
Schicht-4-Richtlinien
Sie können Richtlinien für „ TCP “-Listener festlegen. Für jede Richtlinie müssen Regeln definiert werden. Ähnlich wie bei den Layer-7-Richtlinien wird eine Layer-4-Richtlinie mit der niedrigsten Priorität zuerst und nur dann angewendet, wenn alle ihr zugeordneten Regeln erfüllt sind.
Wenn die eingehende Anfrage keiner der Richtlinien entspricht, erhält der Client möglicherweise die Fehlermeldung „ SSL “.
Die folgenden Aktionen werden für Richtlinien der Schicht 4 unterstützt:
- An Pool weiterleiten – Die Anfrage wird an einen bestimmten Backend-Pool gesendet.
- Weiterleiten an Hörer- Die Anfrage wird an einen bestimmten Front-End-Hörer gesendet.
Schicht-4-Regeln
Eine Schicht-4-Regel definiert, wie Anfragen abgeglichen werden, genau wie eine Schicht-7-Regel. Es wird jedoch nur der Typ sni_hostname unterstützt, wobei field nicht anwendbar ist und die Eigenschaften condition und value die gleichen sind wie bei den Regeln der Schicht 7.
Die Regel „SNI-Hostname“ funktioniert nur mit einem „ TCP “-Listener.
SNI in einem IBM Cloud ALB ist mit dem Listener verbunden und ermöglicht es Ihnen, den Datenverkehr auf der Grundlage des Hostnamens an verschiedene Backend-Pools weiterzuleiten. Innerhalb eines Pools wird der Datenverkehr immer nach dem gewählten Algorithmus (Round-Robin, Least Connections usw.) auf alle Mitglieder aufgeteilt. Sie können SNI nicht verwenden, um ein bestimmtes Mitglied innerhalb eines Pools auszuwählen.
Wenn Sie einen Backend-Pool mit Protokoll HTTP oder HTTPs verwenden, setzt die ALB die SNI nicht, wenn sie die Client-Anfrage an den Backend-Pool weiterleitet. Das liegt daran, dass der ALB die SNI nur zur Weiterleitungsentscheidung heranzieht (sofern Layer-7-Regeln konfiguriert sind) und der ALB einen separaten „ TLS “-Handshake mit dem Backend durchführt (der sich vom Handshake des Clients unterscheidet).
Wenn Sie als Backend das Protokoll „ TCP “ anstelle von „ HTTP “/„HTTPS“ verwenden, legt der ALB den vom Verbraucher gesendeten SNI fest. Das liegt daran, dass der Handshake für „ TLS “ direkt zwischen dem Client und dem Backend stattfindet und nicht zwischen dem ALB und dem Backend.
Verwenden Sie eine der folgenden Abhilfemaßnahmen, wenn Sie HTTP / HTTPS Listener mit einer SNI verwenden:
- Verwenden Sie ein Wildcard-Zertifikat auf einem virtuellen Host. Konfigurieren Sie dann nur einen einzigen Hostnamen auf separaten Backend-Ports. Wenn Sie z. B. für jeden Hostnamen ein Routing zu einzelnen Servern wünschen, können Sie für jeden Hostnamen einen eigenen Pool erstellen und die SNI verwenden, um zum richtigen Pool zu leiten.
- Verwenden Sie für das Backend-Protokoll den Modus „ TCP “ anstelle von HTTPS. TCP Dieser Modus leitet die SNI korrekt weiter und ermöglicht dennoch Lastenausgleich auf Basis von SNI-Hostnamen-Regeln, sofern Sie diese konfigurieren.
Beispiel: Erstellen eines „ TCP “-Listeners mit der Regel „ sni_hostname “
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" -d '{
"connection_limit": 2000,
"port": 443,
"protocol": "tcp",
"policies": [
{
"action": "forward_to_listener",
"name": "listener-forward-policy",
"priority": 4,
"rules": [
{
"condition": "equals",
"type": "sni_hostname",
"value": "www.example.com"
}
],
"target": {
"id": "r006-20275400-825e-4d9b-8177-076fdb4134cc"
}
}
]
}'