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.
See Configuring Intelligent Management for web servers to set up routing from the Intelligent Management enabled WebSphere plug-in to applications in multiple cells. By default, multi-cell routing balances load requests across all servers that can handle the requests. To override the default behavior, you must configure routing rules.
- If you deploy the same application to two different clusters, you 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 you deploy the same application in multiple cells, you 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.
<IntelligentManagement>
stanza in the plugin-cfg.xml file.
The value of the property is initialized with the name of the cell in the
plugin-cfg.xml file. To change this behavior, add your routing rules to the
cell that is specified by the RoutingRulesConnectorClusterName property of the
<IntelligentManagement>
stanza in the plugin-cfg.xml file.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 that is 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 that is 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 that are 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
by
using the setWebServerRoutingRulesProperty
AdminTask.
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 that are 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.
- ApplicationA has context root
/A/*
and is installed on clusterA. - ApplicationAB has context root
/A/B/*
and is installed on clusterAB.
/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.