[17.0.0.1 und höher]

Routing-Regeln für dynamisches Routing in Liberty

Sie können Routing-Regeln für das dynamische Routing in Liberty verwenden, um exakt anzupassen, welche Server für die Verarbeitung bestimmter Anforderungen verwendet werden.

Standardmäßig gleicht dynamisches Routing Anforderungslasten über alle die Server hinweg aus, die die Anforderung verarbeiten können. Wenn Sie das Standardverhalten außer Kraft setzen möchten, müssen Sie Routing-Regeln konfigurieren. Routing-Regeln können Anforderungen an bestimmte Serverressourcen weiterleiten, Anforderungen umleiten oder Anforderungen zurückweisen.

  1. Wenn Sie dieselbe Anwendung in zwei unterschiedlichen Clustern implementieren, können Sie Routing-Regeln dazu verwenden, Anforderungen von einer bestimmten Gruppe von Client-IP-Adressen an einen der Cluster und die restlichen Anforderungen an den anderen Cluster weiterzuleiten.
  2. Wenn Sie dieselbe Anwendung in mehreren Verbünden implementieren, können Sie Routing-Regeln dazu verwenden, die Anforderungen nur an den ersten Verbund zu senden. Wenn im ersten Verbund keine Server verfügbar sind, werden die Anforderungen anschließend an Server im zweiten Verbund gesendet.
Wichtig: Wenn Sie Anforderungen an mehrere Verbünde weiterleiten, werden Routing-Regeln nur von einem der Verbünde gelesen. Intelligent Management für Web-Server liest nur Routing-Regeln aus dem Verbund, der über die Eigenschaft RoutingRulesConnectorClusterName der Zeilengruppe <IntelligentManagement> in der Datei plugin-cfg.xml angegeben ist. Der Wert der Eigenschaft RoutingRulesConnectorClusterName beginnt mit dem Namen des ersten Verbunds, der mit der Option collectives des Befehls dynamicRouting angegeben wird, der die Datei plugin-cfg.xml erstellt hat. Fügen Sie Ihre Routing-Regeln den Verbundcontrollern in dem Verbund hinzu, der über die Eigenschaft RoutingRulesConnectorClusterName der Zeilengruppe <IntelligentManagement> in der Datei plugin-cfg.xml angegeben ist.

Abgleichausdrücke und Aktionen

Routing-Regeln stellen einen Abgleichausdruck und eine Aktion bereit. Der Abgleichausdruck wird auf jede Anforderung angewendet. Wenn eine Anforderung dem Abgleichausdruck entspricht, wird für die Anforderung die Aktion ausgeführt, die in der Regel angegeben wurde. Abgleichausdrücke untersuchen verschiedene Eigenschaften der Anforderung, wie z. B. URI, Header, Cookies, Parameter und Client-IP-Adresse. Die Aktion besteht entweder darin, die Anforderung zurückzuweisen, umzuleiten oder zuzulassen.

Routing-Regeln müssen eine order-Zahl haben, die jeder Regel zugeordnet ist. Bei der Auswertung der Regeln wird der niedrigste order-Wert zuerst ausgewertet. Die erste Regel, bei der es in der Auswertung der Anforderung eine Übereinstimmung gibt, 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.

Wenn der Aktionstyp einer Regel darin besteht, die Anforderung zurückzuweisen, wird der entsprechende HTTP-Rückgabecode angegeben. Der Zurückweisungscode muss vom Web-Server unterstützt werden.

Wenn der Aktionstyp einer Regel darin besteht, die Anforderung umzuleiten, wird die Umleitungsposition angegeben.

Wenn der Aktionstyp einer Regel darin besteht, die Anforderung zuzulassen, werden die Ziele angegeben, an die die Anforderung gesendet werden kann. Die Ziele geben die Gruppe aller Server an, die zur Verteilung der Anforderungslast verwendet werden können. Aus der Gruppe der Ziele werden nur die Server verwendet, die die Anforderung am besten verarbeiten können. Es können auch Failover-Ziele angegeben werden. Server in einem Failover-Ziel werden nur verwendet, wenn in einem primären Ziel keiner der Server verfügbar ist. Es können Cluster oder Server als Ziele angegeben werden.

Hat eine Anforderung Sitzungsaffinität, basiert die Serverauswahl standardmäßig auf Affinität. Wenn ein Affinitätsserver gefunden wird, werden Routing-Regeln nicht verwendet. 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. Weitere Informationen hierzu finden Sie unter Routing-Regeln für dynamisches Routing in Liberty konfigurieren.

Clusterziel

Ein Clusterziel wird mit einem Verbundnamen und einem Clusternamen angegeben. Jeder Teil des Clusterziels kann Platzhalterzeichen (*) verwenden. Wenn ein Clusterziel zum Beispiel als cluster=collective1,* angegeben wird, können Server in jedem beliebigen Cluster in collective1 verwendet werden. Wenn ein Clusterziel als cluster=*,cluster1 angegeben wird, können Server in cluster1 in einem beliebigen Verbund verwendet werden.

Serverziel

Ein Serverziel wird mit einem Verbundnamen, einem Hostnamen, einem Benutzerverzeichnis und einem Servernamen angegeben. Für alle Teile des Serverziels können Platzhalterzeichen verwendet werden. Wenn beispielsweise ein Serverziel als server=collective1,*,*,* angegeben wird, können beliebige Server in collective1 verwendet werden. Wenn ein Serverziel als server=*,*,*,server1 angegeben wird, kann server1 in jedem beliebigen Verbund verwendet werden.

Routing-Regeln auswerten

Vor der Anwendung von Routing-Regeln ermittelt Intelligent Management für Web-Server die beste Zielgruppe, um eine Anforderung zu bedienen. Die beste Zielgruppe sind die Server mit Webanwendungen, deren virtueller Host, Kontextstammverzeichnis und Servletzuordnungen die größte Übereinstimmung mit der Anforderung haben. Routing-Regeln können die Ziele beschränken, die für die Weiterleitung einer Untergruppe der vollständigen Zielgruppe verwendet werden. Routing-Regeln können kein Ziel außerhalb der ursprünglichen Gruppe mit den besten Zielen auswählen.

Angenommen, es gelten die folgenden Bedingungen:

  • ApplicationA hat das Kontextstammverzeichnis /A/* und ist in clusterA installiert.
  • ApplicationAB hat das Kontextstammverzeichnis /A/B/* und ist in clusterAB installiert.

Bei diesen Bedingungen werten die Routing-Regeln Anforderungen wie folgt aus:

  • Beide Anwendungen können die Anforderung /A/B/myservlet bedienen. Da jedoch die Kontextstammverzeichnisangabe /A/B/* der Angabe /A/B/myservlet eher entspricht als die Kontextstammverzeichnisangabe /A/*, werden Anforderungen für /A/B/myservlet immer an clusterAB weitergeleitet.
  • Eine Routing-Regel, die einer Anforderung für /A/B/myservlet entspricht, kann verwendet werden, um Ziele auf eine Untergruppe von Servern in clusterAB zu beschränken, sie kann jedoch nicht verwendet werden, um Server in clusterA auszuwählen, da sie nie als Entsprechnung für diese Anforderung ausgewählt wird.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Dateiname: cwlp_wve_routing_rules.html