Intelligent Management for web servers and routing rules

(Dist) (ZOS)
Intelligent Management for web servers and routing rules

Intelligent Management for web servers routes HTTP requests to multiple WebSphere Application Server cells without regeneration of the plug-in configuration file after environment changes. When servers, cluster members, applications, or virtual hosts are added, removed, started, stopped, or modified, the up-to-date information is dynamically delivered to the WebSphere plug-in.

By default, multi-cell routing balances load requests across all servers that can handle the requests. To override the default behavior, configure routing rules.

Routing rules can route requests to specific server resources, redirect requests, or reject requests. Use routing rules in WAS to customize exactly which servers are used to handle specific requests.

If we deploy the same application to two different clusters, we can use routing rules to direct requests from a particular set of client IP addresses to one of the clusters and the rest to the other cluster.
If we deploy the same application in multiple cells, we can use routing rules to send the requests only to the first cell, unless no servers are available, then send requests to servers in the second cell.

Important: When routing to multiple cells, routing rules are read from only one of the cells. Intelligent Management for web servers reads routing rules only from the cell specified by the RoutingRulesConnectorClusterName property of the <IntelligentManagement> stanza in plugin-cfg.xml. The value of the property is initialized with the name of the cell in plugin-cfg.xml. To change this behavior, add routing rules to the cell specified by the RoutingRulesConnectorClusterName property.

Match expression and actions

Routing rules provides a match expression and an action. The match expression is applied to each request. When a request matches the match expression, the action specified by the rule is performed for that request. Match expressions examine various properties of the request such as the URI, headers, cookies, parameters, and client IP address. The action taken is to either reject, redirect, or permit the request.

Routing rules assigns an order to each rule and rules are evaluated from the lowest to the highest priority. The first rule that matches a request determines how the request is handled. If no rule is matched, the request load is balanced across all available servers that can handle the request.

If the action type of a rule is to reject the request, then the applicable HTTP return code is specified. The reject code must be one of the rejection codes supported by the web server.

If the action type of a rule is to redirect the request, then the redirection location is specified.

If the action type of a rule is to permit the request, the destinations where the request can be sent are specified. The destinations specify the set of all servers to choose when balancing the request. From the set of destinations, only the servers that can handle the request are used. Failover destinations can also be specified. Servers in a failover destination are only used if all servers in a primary destination are not available. Destinations can be specified as either clusters or servers.

By default, when a request has session affinity, server selection is based on affinity. If an affinity server is found, routing rules are not used. To allow routing rules to override affinity selection, the overrideAffinity property must be set to true using...
AdminTask setWebServerRoutingRulesProperty

Application Edition routing rules always override affinity if the affinity server is not among the permit destinations of the application edition rule.

Cluster destination

A cluster destination is specified with a collective name and a cluster name. Either part of the cluster destination can use wildcard (*) characters. For example, if a cluster destination is specified as cluster=collective1,*, then servers in any cluster in collective1 can be used. If a cluster destination is specified as cluster=*,cluster1, then servers in cluster1 in any collective can be used.

Server destination

A server destination is specified with a collective name, a host name, a user directory, and a server name. All parts of the server destination can use wildcard characters. For example, if a server destination is specified as server=collective1,*,*,*, then any servers in collective1 can be used. If a server destination is specified as server=*,*,*,server1, then server1 in any collective can be used.

How Routing Rules are evaluated

Before any routing rules are applied, Intelligent Management for web servers determines the best set of destinations to serve a request. The best set of destinations are those servers with web applications whose virtual host, context root, and servlet mappings best match the request. Routing rules can restrict the destinations used for routing to a subset of the full set of best destinations. Routing rules cannot cause a destination to be chosen that is outside of the original set of best destinations.

See the following examples:

ApplicationA has context root /A/* and is installed on clusterA.
ApplicationAB has context root /A/B/* and is installed on clusterAB.
Both applications can serve the request /A/B/myservlet. However, since /A/B/* context root is a better match for /A/B/myservlet than /A/* context root, requests for /A/B/myservlet are always routed to clusterAB.
A routing rule that matches a request for /A/B/myservlet can be used to restrict destinations to a subset of servers in clusterAB, but cannot be used to select servers in clusterA, since clusterA are never chosen as a match for this request.