Workload management policies
In WAS V5.1, the plug-in has two options for the load distributing algorithm:
- Round robin with weighting
- Random
Note: The weighting for the round robin approach can be turned off by giving the appservers equal weights.
The default value is Round Robin. It can be changed by editing the plugin-cfg.xml file and amend each ServerCluster tag to:
<ServerCluster CloneSeparatorChange="false"
LoadBalance="Round Robin"
Name="PluginCluster" PostSizeLimit="-1"
RemoveSpecialHeaders="true"
RetryInterval="60">
or:
<ServerCluster CloneSeparatorChange="false"
LoadBalance="Random"
Name="PluginCluster"
PostSizeLimit="-1"
RemoveSpecialHeaders="true"
RetryInterval="60">
There is also a feature in WAS V5.1 for the plug-in called ClusterAddress that can be used to suppress load balancing. See ClusterAddress for more details.
For examples of how to see these workload management policies in action, refer to 5.7.1, Normal operation.
Weighted round robin for WAS V5.1
When using this algorithm, the plug-in selects a cluster member at random from which to start. The first successful browser request will be routed to this cluster member and then its weight is decremented by 1. New browser requests are then sent round robin to the other appservers and subsequently the weight for each application server is decremented by 1. The spreading of the load is equal between application servers until one application server reaches a weight of 0. From then on, only application servers without a weight of 0 will be routed requests to. The only exception to this pattern is when a cluster member is added or restarted.
The first request goes to a random appserver to avoid multiple Web servers and/or multi-process Web servers directing initial requests to the same application server.
When starting the HTTP Server, the appserver weight is reduced to the lowest common denominator. For example: PluginMember1's weight is 8 and PluginMember2's weight is 6. When you start the HTTP Server, the weight of PluginMember1 will be set to 4 and the weight of PluginMember2 will be set to 3.
Using Table 5-2 and the following explanations will show you how weighted round robin is performed. To begin with, we have a weight of 4 for PluginMember1 and a weight of 3 for PluginMember2:
- When the first request comes in, PluginMember1 is randomly picked. The request is OK. PluginMember's weight is decremented by 1 to 3.
- The second request is sent to PluginMember2. The request is OK. PluginMember2's weight is decremented by 1 to 2.
- The third and fourth requests are sent to PluginMember1 and PluginMember2 respectively. So PluginMember1 now has a weight of 2 and PluginMember2 now has a weight of 1.
- The fifth request has a cookie that specifies a server affinity to PluginMember1. The request is sent to PluginMember1 and its weight is decremented by 1 to 1.
- The sixth request is again sent to PluginMember1 because of server affinity. The request is OK. PluginMember1's weight is decremented by 1 to 0.
- The seventh request again has a cookie that specifies server affinity to PluginMember1. The request is sent to PluginMember1 and its weight is decremented by 1 to -1.
- The eighth to eleventh request all have server affinity to PluginMember1. The weight is decremented by 1 for each request. After the eleventh request, PluginMember1 now has a weight of -5 while PluginMember2 still has a weight of 1.
- The twelfth request has no server affinity so it is sent to PluginMember2. PluginMember2's weight is decremented by 1 to 0.
- When processing the thirteenth request, the plug-in decides to reset the weights because there are no servers marked up having positive weights. A multiple of the lowest common denominator of the servers' maximum weight is added back to the current weights to make all weights positive again. See the Important box below for a detailed description on how the weights are reset.
After resetting the weights, the sequence gets repeated with the same starting point (no random server selection this time), in our case, this means that the thirteenth request is sent to PluginMember1 (after the weights have been reset) and PluginMember1's weight is decremented by 1 to 2.
In our example the current weight of PluginMember1 is -5 because many session-based requests have been served. PluginMember2 has a weight of 0. The plug-in checks how many times the maxWeight should be added to make the current weight positive. The starting weight for PluginMember1 was 4 and 3 for PluginMember2. Because PluginMember1's current weight is -5, adding 4 (the lowest common denominator) would not set it to a positive weight. Thus the plug-in decides to add the starting weights * 2, which is 8 for PluginMember1 and 6 for PluginMember2. So the new current weights are 3 for PluginMember1 (-5 + 2 * 4) and 6 for PluginMember2 (0 + 2 * 3).
Number of Requests PluginMember1 Weight PluginMember2 Weight 0 4 3 1 3 3 2 3 2 3 2 2 4 2 1 5 1 1 6 - Request with session affinity to PluginMember1 0 1 7 - Request with session affinity to PluginMember1 -1 1 8 - Request with session affinity to PluginMember1 -2 1 9 - Request with session affinity to PluginMember1 -3 1 10 - Request with session affinity to PluginMember1 -4 1 11 - Request with session affinity to PluginMember1 -5 1 12 - No session affinity for this request -5 0 13 RESET - no session affinity for this request 2 6
Request handling using weighted round robin server selection
Random
Requests are passed to cluster members randomly. Weights are not taken into account as per round robin. The only time the appservers are not chosen randomly is when there are requests with sessions associated with them. When the random setting is used, cluster member selection does not take into account where the last request was handled. This means that a new request could be handled by the same cluster member as the last request.
ClusterAddress
As mentioned earlier, the plugin-cfg.xml tag called ClusterAddress can be used to suppress plug-in based load balancing. So you define a ClusterAddress when you do not want the plug-in to perform any type of load balancing because you already have some type of load balancer in between the plug-in and the appservers - which can be a software or a hardware solution. The ClusterAddress specified is the IP address of your external load balancing solution. When doing so, the plug-in will only focus on route determination and session affinity. Once ClusterAddress is defined, if a request comes in that does not have session affinity established, the plug-in routes it to the ClusterAddress. If affinity has been established, then the plug-in routes the request directly to the appropriate application server, bypassing the ClusterAddress entirely. If no ClusterAddress is defined for the ServerCluster, then the plug-in load balances across the PrimaryServers list.
The ClusterAddress tag has the same attributes and elements as a Server element. The difference is that you can only define one of them within a ServerCluster. An example of how to configure the plugin-cfg.xml is shown in Example 5-4.
Example 5-4 Extract of plugin-cfg.xml showing ClusterAddress
<ServerCluster CloneSeparatorChange="false"
LoadBalance="Round Robin"
Name="PluginCluster"
PostSizeLimit="-1"
RemoveSpecialHeaders="true"
RetryInterval="60">
<ClusterAddress Name="LoadBalancer">
<Transport Hostname="lb.itso.ibm.com"
Port="80"
Protocol="http"/>
</ClusterAddress>
<Server CloneID="v544d031"
ConnectTimeout="0"
ExtendedHandshake="false"
LoadBalanceWeight="8"
MaxConnections="-1"
Name="was1node_PluginMember1"
WaitForContinue="false">
<Transport Hostname="app1.itso.ibm.com"
Port="9088"
Protocol="http"/>
</Server>
<Server CloneID="v544d0o0"
ConnectTimeout="0"
ExtendedHandshake="false"
LoadBalanceWeight="2"
MaxConnections="-1"
Name="was2Node_PluginMember2"
WaitForContinue="false">
<Transport Hostname="app2.itso.ibm.com"
Port="9086"
Protocol="http"/>
</Server>
<PrimaryServers>
<Server Name="was1node_PluginMember1"/>
<Server Name="was2Node_PluginMember2"/>
</PrimaryServers>
</ServerCluster>
A plug-in trace showing how the plug-in handles the ClusterAddress element is shown in Example 5-5, using the plugin-cfg.xml shown in Example 5-4.
Example 5-5 Plug-in trace showing the ClusterAddress functionality
ws_common: websphereHandleSessionAffinity: Checking for session affinity
ws_common: websphereHandleSessionAffinity: Checking the SSL session id
lib_htrequest: htrequestGetCookieValue: Looking for cookie: 'SSLJSESSION'
lib_htrequest: htrequestGetCookieValue: No cookie found for: 'SSLJSESSION'
ws_common: websphereHandleSessionAffinity: Checking the cookie affinity: JSESSIONID
lib_htrequest: htrequestGetCookieValue: Looking for cookie: 'JSESSIONID'
lib_htrequest: htrequestGetCookieValue: No cookie found for: 'JSESSIONID'
ws_common: websphereHandleSessionAffinity: Checking the url rewrite affinity: jsessionid
ws_common: websphereParseSessionID: Parsing session id from '/snoop'
ws_common: websphereParseSessionID: Failed to parse session id
ws_common: websphereFindServer: Have a cluster address server so using it: LoadBalancer
ws_common: websphereFindTransport: Finding the transport
ws_common: websphereFindTransport: Setting the transport(case 2): lb.itso.ibm.com on port 80
ws_common: websphereExecute: Executing the transaction with the app server
ws_common: websphereGetStream: Getting the stream to the app server
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.