Mit den Routing-Regeln für dynamisches Routing können Sie für Anforderungen basierend auf den Anforderungsinformationen ein bestimmtes Routing-Verhalten festlegen.
Vorbereitende Schritte
Aktivieren Sie dynamisches Routing in einem Verbundcontroller. Führen Sie die Schritte unter Dynamisches Routing für Liberty-Verbünde konfigurieren aus.
Tipp: Wenn Sie Routing-Regeln verwenden möchten, um Anforderungen an mehrere Verbünde weiterzuleiten, muss jeder Verbund einen anderen Namen haben. Verwenden Sie die Option
--collectiveName, wenn Sie den Befehl
collective create ausführen, um einen Verbund zu benennen. Wenn der Verbund bereits erstellt wurde, können Sie über die Eigenschaft
connectorClusterName des XML-Elements
<dynamicRouting> einen logischen Namen für den Verbund angeben. Wenn die Eigenschaft
connectorClusterName angegeben wurde, hat der Wert Vorrang vor dem mit der Option
--collectiveName angegebenen
collectiveName. Weitere Informationen hierzu finden Sie unter
Dynamic Routing für mehrere Liberty-Verbünde konfigurieren.
Informationen zu diesem Vorgang
Standardmäßig gleicht dynamisches Routing Anforderungslasten über alle die Server hinweg aus, die die Anforderung verarbeiten können. Konfigurieren Sie Routing-Regeln, um das Standardverhalten außer Kraft zu setzen, sodass Routing-Regeln Anforderungen an bestimmte Serverressourcen weiterleiten, Anforderungen
umleiten und Anforderungen zurückweisen können.
Anmerkung: Alle Verbundcontroller im Verbund müssen denselben Satz von Routing-Regeln über den Service für dynamisches Routing bereitstellen. Fügen Sie dem Verzeichnis
configDropins/defaults eine
.xml-Datei mit den Routing-Regeln eines der Controller hinzu, um sicherzustellen, dass alle Controller dieselben Routing-Regeln verwenden. Weitere Informationen
finden Sie im Artikel
Automatische gemeinsame Nutzung einer Konfiguration durch Replikate.
Vorgehensweise
- Fügen Sie das <routingRules>-Element als untergeordnetes Element des Elements <dynamicRouting> der Controllerdatei server.xml hinzu.
Geben Sie das Attribut webServers des Elements <routingRules> an. Jedes <routingRules>-Element kann die gültige Gruppe von Web-Servern, in der die Regeln veröffentlicht werden, definieren. Wenn ein Web-Server eine Verbindung zum DynamicRouting-Service herstellt, stellt der Service diesem Web-Server die Regeln zur Verfügung. Wenn Sie keine Web-Server angeben, stellt der Service die Regeln allen Web-Servern zur Verfügung, die mit ihm verbunden sind. Wenn Sie mehrere Web-Server angeben, verwenden Sie Kommas (,) als Trennzeichen. Alle Regeln, bei denen das Attibut webServers den Wert * hat, werden allen Web-Servern zur Verfügung gestellt. Sehen Sie sich hierzu das folgende Beispiel an:
<dynamicRouting>
<routingRules webServers="webserver1,webserver2">
...
</routingRules>
</dynamicRouting>
Geben Sie das Attribut
overrideAffinity des Elements
<routingRules> an. Standardmäßig wird eine Anforderung mit Affinität zu einem bestimmten Server an diesen Server gesendet, und zwar auch dann, wenn die Anforderung einer Routing-Regel entspricht, die den Affinitätsserver nicht als Ziel enthält. Wenn die Eigenschaft
overrideAffinity auf
true gesetzt ist, dann hat das Ziel in einer übereinstimmenden Regel Vorrang vor dem ausgewählten Affinitätsserver. Wenn der Affinitätsserver mit der Regel übereinstimmt, wird der Affinitätsserver ausgewählt, und zwar auch dann, wenn sich der Affinitätsserver in einer Failover-Endpunktgruppe befindet. Die Eigenschaft
overrideAffinity gilt für alle Routing-Regeln und kann nicht für einzelne Regeln definiert werden.
<dynamicRouting>
<routingRules webServers="webserver1"
overrideAffinity=”true”>
...
</routingRules>
</dynamicRouting>
- Fügen Sie die <routingRule>-Elemente als untergeordnete Elemente des <routingRules>-Elements hinzu.
- Geben Sie ein order-Attribut für die Routing-Regel an und legen Sie eine ganze Zahl dafür fest. Das Attribut order ist erforderlich. Bei der Auswertung der Regeln wird der niedrigste order-Wert zuerst verwendet. Wenn demselben order-Attribut mehr als eine Regel zugeordnet ist, wird die erste Regel, die gefunden wird, veröffentlicht und alle anderen Regeln mit demselben order-Attribut werden verworfen. Es hat sich bewährt, zwischen den order-Zahlen der Regeln Abstände zu lassen, um Platz für zukünftige Regeln zu lassen.
- Geben Sie ein matchExpression-Attribut für die Routing-Regel an. Setzen Sie den Wert auf einen Ausdruck, mit dem übereinstimmende eingehende Anforderungen gefunden werden können. Abgleichausdrücke kombinieren eine Gruppe fester Operanden mit Operatoren. Sie können eine Gruppe von Operanden und Operatoren mithilfe der Operatoren AND und OR kombinieren.
<>
<routingRules webServers="webserver1,webserver2">
<routingRule order="100" matchExpression="URI LIKE'/myapp%'">
...
</routingRule>
</routingRules>
</dynamicRouting>
Tabelle 1. matchExpression-Operanden. Schließen Sie einen Operanden in einer matchExpression-Definition ein. Operand |
Syntax |
Beschreibung |
Client-IPV4 |
clientipv4 |
Die IP-Adresse des Clients, der den IPv4-Adresstyp (Internet Protocol Version 4) mit der Punktnotation n.n.n.n verwendet. |
Client-IPV6 |
clientipv6 |
Der 128-Bit-IPv6-Adresstyp (x:x:x:x:x:x:x:x) gemäß RFC 1924 (Request for Comments) des Client-Computers. |
Cookiename |
cookie$Name |
Ein Cookiename. Der Ausdruck cookie$My_Cookie_Name='My_Cookie_Value' zum Beispiel testet eine Anforderung, um herauszufinden, ob sie einen Cookie mit dem Namen My_Cookie_Name und einem Wert My_Cookie_Value enthält. Wenn Sie das Vorhandensein oder Nichtvorhandensein eines bestimmten Cookies prüfen möchten, verwenden Sie einen der folgenden Ausdrücke:
cookie$MyCookieName IS NOT NULL
cookie$MyCookieName IS NULL
|
Headername |
header$Name |
Ein Headername und Wert. Der Ausdruck header$Host='localhost' zum Beispiel testet eine Anforderung, um herauszufinden, ob sie einen HTTP-Host-Header mit einem locahost-Wert enthält. Wenn Sie das Vorhandensein oder Nichtvorhandensein des Host-Headers prüfen möchten, verwenden Sie einen der folgenden Ausdrücke:
header$Host IS NOT NULL
header$Host IS NULL
|
Prozentsatz |
percentage$Wert |
Der Operand für den Prozentsatz führt eine bestimmte Zeit (in Prozent) zu dem Ergebnis true. Die Angabe
percentage$50 zum Beispiel führt durchschnittlich 50 % der Zeit zu dem Ergebnis true.
|
Abfrageparameter |
queryparm$Name |
Ein Abfrageparametername und -wert. Der Ausdruck queryparm$timezone='EST' zum Beispiel testet eine Anforderung, um herauszufinden, ob die Anforderung einen HTTP-Abfrageparameter mit dem Namen timezone und einem Wert EST enthält. Wenn Sie das Vorhandensein oder Nichtvorhandensein eines Abfrageparameter testen möchten, verwenden Sie eine der folgenden Ausdrücke:
queryparm$timezone IS NOT NULL
queryparm$timezone IS NULL
|
URI |
uri |
Uniform Resource Identifier |
Virtueller Host |
virtualhost |
Virtuelles Hostziel der Anforderung |
Virtueller Port |
numeric |
Virtuelles Portziel der Anforderung. |
Tabelle 2. Abgleichausdrucksoperatoren (matchExpression). Schließen Sie bei Bedarf einen Operator in einer matchExpression-Definition ein. Operator |
Syntax |
Beschreibung |
Equals |
= |
Der Gleichheitsoperator drückt eine Übereinstimmung unter Beachtung der Groß-/Kleinschreibung aus. |
Equals ignore case |
EQUALSIGNORECASE |
Identisch mit 'String = String' mit dem Unterschied, dass die Groß-/Kleinschreibung der Zeichenfolge ignoriert wird. Beispiel: Die Auswertung von 'ABC' EQUALSIGNORECASE 'abc' führt zu dem Ergebnis true und die Auswertung von ('ABC' = 'abc') führt zu dem Ergebnis false. |
IN |
IN |
Drückt einen Operanden mit mehreren Werten in einem einzigen Ausdruck aus. Bei einem Operanden mit dem Namen port wird zum Beispiel das Ausdrucksfragment port IN (9080,9090,9091) verwendet, um auszudrücken, dass der Wert für port eine oder alle der Ganzzahlen 9080, 9090 und 9091 sein kann. Je nach Datentyp werden die Werte in den runden Klammern unterschiedlich angegeben. Wenn zum Beispiel port eine Ganzzahl ist, werden die Werte ohne Anführungszeichen angegeben. Wenn port eine Zeichenfolge ist, ist die richtige Syntax port IN
('9080','9090','9091').
|
Is not null |
IS NOT NULL |
Führt zu dem Ergebnis true, wenn der angegebene Operand vorhanden ist. |
Is null |
IS NULL |
Führt zu dem Ergebnis true, wenn der angegebene Operand nicht vorhanden ist. |
Like |
LIKE |
Drückt Musterabgleich für Zeichenfolgeoperandenwerte aus. Der Wert muss das Platzhalterzeichen % (Prozentzeichen) an der Stelle enthalten, an der der Musterabgleich beginnt. Beispiel: - Der Ausdruck host LIKE %blanca sucht beim Abgleich das Wort blanca bzw. jedes andere Wort, das mit blanca endet.
- Der Ausdruck host LIKE blanca% sucht beim Abgleich das Wort blanca bzw. jedes andere Wort, das mit blanca beginnt.
- Der Ausdruck host LIKE %blanca% sucht beim Abgleich das Wort blanca bzw. jedes Wort, in dem das Wort blanca enthalten ist.
|
Like ignore case |
LIKEIGNORECASE |
Identisch mit 'string LIKE string' mit dem Unterschied, dass die Groß-/Kleinschreibung ignoriert wird. |
Like in |
LIKEIN |
Die Auswertung prüft, ob eine Zeichenfolge in einer Liste mit Zeichenfolgen vorhanden ist. Die Auswertung des Ausdrucks string likein
(string1%, string2%, string3%, etc.) führt zu dem Ergebnis true, wenn string mit einer oder mehreren Zeichenfolgen in den runden Klammern übereinstimmt. In diesem Beispiel sind in den runden Klammern drei string-Werte enthalten. |
- Geben Sie einen Aktionstyp für eine Routing-Regel an.
Die drei möglichen Aktionstypen sind permitAction,
redirectAction und rejectAction. Geben Sie für jede Routing-Regel nur einen der drei Aktionstypen an.
- Geben Sie den Aktionstyp permitAction an, um Anforderungen an angegebene Endpunkte weiterzuleiten.
- Fügen Sie einem <routingRule>-Element das <permitAction>-Element hinzu.
- Fügen Sie optional das Attribut allowMaintenanceModeServers dem Element <permitAction> hinzu, um anzugeben, ob Anforderungen, die mit den Regeln übereinstimmen, an Server im Wartungsmodus gesendet werden sollen. Der Standardwert für dieses Attribut ist false. Wenn dieses Attribut auf true gesetzt wird, können Anforderungen, die mit dieser Regel übereinstimmen, an Server gesendet werden, die im Wartungsmodus sind.
- Fügen Sie dem Element <permitAction> ein oder mehrere <loadBalanceEndPoints>-Elemente hinzu.
Wenn ein <permitAction>-Element mehr als ein <loadBalanceEndPoints>-Element hat, fungiert
das erste <loadBalanceEndPoints>-Element als erste Gruppe von Zielen. Alle nachfolgenden <loadBalanceEndPoints>-Elemente fungieren als Failover-Ziele. Die Reihenfolge, in der die <loadBalanceEndPoints>-Element definiert sind, bestimmt die Failover-Priorität.
- Fügen Sie jedem <loadBalanceEndPoints>-Element ein oder mehrere <endpoint>-Elemente hinzu.
- Fügen Sie jedem <endpoint>-Element ein destination-Attribut hinzu. Setzen Sie die destination-Attribut entweder auf einen Servertyp oder einen Clustertyp.
Wenn Sie einen Endpunkt des Typs Server angeben möchten, setzt sich die Angabe zum Server wie folgt zusammen: server= gefolgt von einer aus vier Teilen bestehenden Serverspezifikation, deren einzelne Teile durch ein Komma voneinander getrennt sind.
<endpoint destination="server=Verbundname,Hostname,wlp.user.dir,Servername"/>
- Verbundname ist der Name des Verbunds, in dem der Server ein Member ist.
- Hostname ist die Hostadresse.
- wlp.user.dir ist das Liberty-Benutzerverzeichnis auf dem Hostsystem, auf dem der Server definiert ist. Sie können evtl. die Variable
${wlp.user.dir} hier verwenden, es ist aber möglicherweise nicht geeignet. Wenn die Datei server.xml ausgewertet wird, entspricht der Wert von ${wlp.user.dir} dem Verzeichnis, in dem der Controller-Server definiert ist. Dieses Verzeichnis ist aber möglicherweise nicht dasselbe Verzeichnis, in dem der Member-Server definiert ist.
- Servername ist der Name des Servers.
Wenn Sie einen Endpunkt des Typs Cluster angeben möchten, setzt sich die Angabe zum Cluster wie folgt zusammen: cluster= gefolgt von einer aus zwei Teilen bestehenden Serverspezifikation, deren einzelne Teile durch Kommas voneinander getrennt sind.
<endpoint destination="cluster=Verbundname,Clustername"/>
- Verbundname ist der Name des Verbunds, in dem der Cluster definiert ist.
- Clustername ist der Name des Clusters.
Alle Teile einer Server- oder Clusterzielspezifikation können Platzhalterzeichen (*) für den Zeichenfolgeabgleich enthalten. Wenn Sie Routing-Regeln verwenden möchten, um Anforderungen an mehrere Verbünde weiterzuleiten, muss jeder Verbund einen anderen Namen haben. Wenn das Attribut
connectorClusterName des Elements <dynamicRouting> angegeben wird, ist der Verbundname der Wert des Attributs connectorClusterName. Wenn das Attribut connectorClusterName des Elements <dynamicRouting> nicht angegeben wird, ist der Verbundname der Wert, der für die Option --collectiveName verwendet wird, wenn Sie den Befehl collective create ausführen. Wenn das Attribut connectorClusterName nicht angegeben wird und die Option --collectiveName nicht verwendet wird, ist der Verbundname defaultCollective.
Das folgende Beispiel zeigt ein <permitAction>-Element mit einem Endpunkt des Typs Server.
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,myhost,/opt/IBM/liberty/wlp/usr,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
</routingRules>
</dynamicRouting>
- Geben Sie den Aktionstyp redirectAction an, um eine Anforderung an eine andere Position weiterzuleiten.
- Fügen Sie einem <routingRule>-Element das <redirectAction>-Element hinzu.
- Fügen Sie dem <redirectAction>-Element ein location-Attribut hinzu. Setzen Sie den Wert für das location-Attribut auf das neue Ziel für die Anforderung.
Das folgende Beispiel zeigt ein <redirectAction>-Element:
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="200" matchExpression="URI LIKE '/myapp%'">
<redirectAction location="http://some.other.destination" />
</routingRule>
</routingRules>
</dynamicRouting>
- Geben Sie den Aktionstyp rejectAction an, um eine Anforderung mit einem bestimmten Antwortcode zurückzuweisen.
- Fügen Sie einem <routingRule>-Element ein <rejectAction>-Element hinzu.
- Fügen Sie dem <rejectAction>-Element ein code-Attribut hinzu. Setzen Sie das code-Attribut auf den HTTP-Antwortcode, der verwendet werden soll, wenn die Anforderung der Regel entspricht. Der Code muss ein Fehlercode sein, den der Web-Server unterstützt.
Das folgende Beispiel zeigt ein <rejectAction>-Element:
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="300" matchExpression="URI LIKE '/myapp%'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
Ergebnisse
Nachdem die Regeln definiert sind, werden die Regeln, die dem Web-Server zugordnet sind, der eine Verbindung zum Service für dynamisches Routing herstellt, und die Regeln bereitgestellt, die allen Web-Servern zugeordnet sind. Der Web-Server gleicht Anforderungen mit den Ausdrücken ab, die in den Regeln gefunden werden. Die Ausdrücke werden gemäß der Regelreihenfolge in aufsteigender Sortierung ausgewertet. Die erste Regel mit einem übereinstimmenden Ausdruck wird verwendet. Die
Aktion, die der Regel zugeordnet ist, bestimmt, wie die Anforderung verarbeitet wird. Wenn es keine Übereinstimmung mit einer Regel gibt, wird die Anforderungslast gleichmäßig über alle Server verteilt, die die Anforderung verarbeiten können.
Hat eine Anforderung Sitzungsaffinität, basiert die Serverauswahl standardmäßig auf Affinität. Wenn ein Affinitätsserver gefunden wird, wird dieser Server ausgewählt und die Routing-Regeln werden nicht ausgewertet. Wenn Sie Routing-Regeln aktivieren möchten, um die Affinitätsauswahl außer Kraft zu setzen, kann das Attribut overrideAffinity dem Element
<routingRules> der Datei server.xml hinzugefügt werden.
Beispiel
Im folgenden Beispiel werden mehrere Regeln kombiniert:
<dynamicRouting>
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,*,*,member1"/>
</loadBalanceEndPoints>
<loadBalanceEndPoints>
<endpoint destination="server=collective2,*,*,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="200" matchExpression="uri like '/AppX%' AND queryparm$test = 'true'">
<permitAction allowMaintenanceModeServers="true">
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterB"/>
<endpoint destination="cluster=collective2,clusterB"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="300" matchExpression=" uri like '/AppX%' ">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterA"/>
<endpoint destination="cluster=collective2,clusterA"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="400" matchExpression="URI LIKE '/myoldapp'">
<redirectAction location="http://mysite/mynewapp" />
</routingRule>
<routingRule order="500" matchExpression="URI LIKE '/myveryoldapp'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
Die Routing-Regel mit der Angabe -order 100 beschränkt die Ziele, an die Anforderungen für /AppX weitergeleitet werden auf zwei bestimmte Cluster in zwei Verbünden.
Die Routing-Regel mit der Angabe –order 200 zeigt, wie Sie das Failover von einer Endpunktgruppe aus für eine andere Endpunktgruppe aktivieren. Die Regel 200 leitet alle Anforderungen, die mit dem Ausdruck übereinstimmen, an beliebige Server weiter, die die Anforderung in collective1 verarbeiten können. Wenn keiner der Server in collective1, die die Anforderung verarbeiten können, verfügbar ist, werden Server in collective2, die die Anforderung
verarbeiten können, für die Anforderungen ausgewählt, die mit dem Regelausdruck übereinstimmen.
Die Routing-Regel mit der Angabe –order 300 zeigt ein Beispiel für die Weiterleitung von Testanforderungen an einen Server, der sich im Wartungsmodus befindet. Wenn Sie test=true als Abfrageparameter hinzufügen, wird diese Anforderung an server1 in collective1 auch dann gesendet, wenn sich der Server im Wartungsmodus befindet.
Die Routing-Regel mit der Angabe –order 400 zeigt ein Beispiel für eine Umleitungsregel. Die Routing-Regel mit der Angabe
–order 500 zeigt ein Beispiel für eine Ablehnungsregel.