IBM WebSphere Application Server Network Deployment V5.0 - Workload Management Policies
Web Doc
Note: This is publication is now archived. For reference only.
Abstract
This tip provides information about the two Web server plug-in workload management policies "Weighted Round Robin" and "Random", available with IBM WebSphere Application Server Network Deployment V5.x.
Contents
Workload management policies
In WebSphere Application Server V5.0, the Web server plug-in has two options for the load distributing algorithm:
Note: The weighting for the Round Robin approach can be turned off by giving the application servers equal weights.
The default value is Round Robin. It can be changed by editing the plugin-cfg.xml file and amending each ServerCluster tag to:
<ServerCluster Name="PluginCluster" LoadBalance="Random">
In WebSphere Application Server V5.0, the Web server 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 application servers equal weights.
The default value is Round Robin. It can be changed by editing the plugin-cfg.xml file and amending each ServerCluster tag to:
<ServerCluster Name="PluginCluster" LoadBalance="Random">
or:
<ServerCluster Name="PluginCluster" LoadBalance="Round Robin">
When the plugin-cfg.xml file is initially generated, the ServerCluster tag will not have a LoadBalance attribute defined.
There is also a new feature in WebSphere Application Server V5.0 for the plug-in called ClusterAddress which can be used to suppress load balancing. For more information about this feature, please see TIPS0238, IBM WebSphere Application Server Network Deployment V5.0 - Workload Management Policies - ClusterAddress.
Weighted Round Robin for WebSphere Application Server V5.0
When using this algorithm, the plug-in selects a cluster member at random from which to start. The first successful browser request is routed to this cluster member and its weight is then decremented by 1. New browser requests are then sent in a round robin to the other application servers 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 have requests routed to them. The only cases which would be exceptions to this pattern are if the chosen cluster member cannot process the request or if the browser request is associated by a session to a different cluster member.
Notes:
The following explanations and table will show you how Weighted Round Robin is performed. To begin with, we have a weight of 4 for PluginMember1 and a weight of 1 for PluginMember2:
Important:
Random
Requests are passed to cluster members randomly. Weights are not taken into account as with the round robin approach. The only time the application servers 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.
<ServerCluster Name="PluginCluster" LoadBalance="Round Robin">
When the plugin-cfg.xml file is initially generated, the ServerCluster tag will not have a LoadBalance attribute defined.
There is also a new feature in WebSphere Application Server V5.0 for the plug-in called ClusterAddress which can be used to suppress load balancing. For more information about this feature, please see TIPS0238, IBM WebSphere Application Server Network Deployment V5.0 - Workload Management Policies - ClusterAddress.
Weighted Round Robin for WebSphere Application Server V5.0
When using this algorithm, the plug-in selects a cluster member at random from which to start. The first successful browser request is routed to this cluster member and its weight is then decremented by 1. New browser requests are then sent in a round robin to the other application servers 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 have requests routed to them. The only cases which would be exceptions to this pattern are if the chosen cluster member cannot process the request or if the browser request is associated by a session to a different cluster member.
Notes:
- The first request goes to a random application server 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 application server weight is reduced to the lowest common denominator. For example, let us say that 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.
The following explanations and table will show you how Weighted Round Robin is performed. To begin with, we have a weight of 4 for PluginMember1 and a weight of 1 for PluginMember2:
- When the first request comes in, PluginMember1 is randomly chosen. The request is OK. PluginMember’s weight is decremented by 1 to 3.
- Second request is sent to PluginMember2. The request is OK. PluginMember2’s weight is decremented by 1 to 0.
- The third request has a cookie that specifies a server affinity to PluginMember2. The request is sent to PluginMember2 but its weight is not decremented because sessioned requests do not decrement the weight.
- The fourth request is sent to PluginMember1. The request is OK. PluginMember1’s weight is decremented by 1 to 2.
- The fifth request has a cookie that specifies a server affinity to PluginMember1. The request is sent to PluginMember1 but its weight is not decremented because sessioned requests do not decrement the weight.
- The sixth request is sent to PluginMember1. The request is OK. PluginMember1’s weight is decremented by 1 to 1.
- The seventh request is sent to PluginMember1. The request is OK. PluginMember1’s weight is decremented by 1 to 0.
- On the eighth request, the weights are reset to 4 for PluginMember1 and 1 for PluginMember2.
- The next request is sent to PluginMember1. After resetting the weights, the sequence is repeated with the same starting point (no random server selection this time).
Number of Requests | PluginMember1 Weight | PluginMember2 Weight |
0 | 4 | 1 |
1 | 3 | 1 |
2 | 3 | 0 |
3 (Request with session affinity to PluginMember2) | 3 | 0 |
4 | 2 | 0 |
5 (Request with session affinity to PluginMember1) | 2 | 0 |
6 | 1 | 0 |
7 | 0 | 0 |
8 RESET | 4 | 1 |
Important:
- In WebSphere Application Server V5.0.1, the handling of weights for session-based requests has changed compared to V5.0.0. The application server weight will also be decremented by one for each session-based request to that application server.
- When there are no marked up servers with positive weights, the weights of the servers will be changed as follows: 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.
For example, let us assume that 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).
Random
Requests are passed to cluster members randomly. Weights are not taken into account as with the round robin approach. The only time the application servers 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.
Special Notices
The material included in this document is in DRAFT form and is provided 'as is' without warranty of any kind. IBM is not responsible for the accuracy or completeness of the material, and may update the document at any time. The final, published document may not include any, or all, of the material included herein. Client assumes all risks associated with Client's use of this document.