Problem(Abstract)
After setting up the HTTP plug-in for load balancing in a clustered IBM WebSphere environment, the request load is not evenly distributed among back-end WebSphere Application Servers.
Cause
In most cases, the preceding behavior is observed because of a misunderstanding of how HTTP plug-in load balancing algorithms work or might be due to an improper configuration. Also, the type of Web server (multi-threaded versus single threaded) being used can effect this behavior.
Resolving the problem
The following document is designed to assist you in understanding how HTTP plug-in load balancing works along with providing you some helpful tuning parameters and suggestions to better maximize the ability of the HTTP plug-in to distribute load evenly.
Note: The following information is written specifically for the IBM HTTP Server, however, this information in general is applicable to other Web servers which currently support the HTTP plug-in (for example: IIS, SunOne, Domino, and so on).
Note: The following information is written specifically for the IBM HTTP Server, however, this information in general is applicable to other Web servers which currently support the HTTP plug-in (for example: IIS, SunOne, Domino, and so on).
Also, The WebSphere plug-in versions 6.1 and later offer the property "IgnoreAffinityRequests" to address the limitation outlined in this technote. In addition, WebSphere versions 6.1 and later offer better facilities for updating the configuration through the administrative panels without manual editing.
For additional information regarding this plug-in property, visit IgnoreAffinityRequests
Load Balancing
For additional information regarding this plug-in property, visit IgnoreAffinityRequests
Load Balancing
- Background
In clustered Application Server environments, IBM HTTP Servers spray Web requests to the cluster members for balancing the work load among relevant application servers. The strategy for load balancing and the necessary parameters can be specified in the plugin-cfg.xml file. The default and the most commonly used strategy for workload balancing is ‘Weighted Round Robin’. For details refer to the IBM Redbooks technote, Workload Management Policies.
Most commercial Web applications use HTTP sessions for holding some kind of state information while using the stateless HTTP protocol. The IBM HTTP Server attempts to ensure that all the Web requests associated with a HTTP session are directed to the application server who is the primary owner of the session. These requests are called session-ed requests, session-affinity-requests, and so on. In this document the term ‘sticky requests’ or ‘sticky routing’ will be used to refer to Web requests associated with HTTP sessions and their routing to a cluster member.
The round robin algorithm used by the HTTP plug-in in releases of V5.0, V5.1 and V6.0 can be roughly described as follows: - While setting up its internal routing table, the HTTP plug-in component eliminates the non-trivial greatest common divisor (GCD) from the set of cluster member weights specified in theplugin-cfg.xml file.
For example, if we have three cluster members with specified static weights as 8, 6, and 18, the internal routing table will have 4, 3, and 9 as the starting dynamic weights of the cluster members after factoring out 2 = GCD(4, 3, 9). <ServerCluster CloneSeparatorChange="false" LoadBalance="Round Robin"
Name="Server_WebSphere_Cluster" PostSizeLimit="10000000" RemoveSpecialHeaders="true" RetryInterval="60">
<Server CloneID="10k66djk2" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="8" MaxConnections="0" Name="Server1_WebSphere_Appserver" WaitForContinue="false">
<Transport Hostname="server1.domain.com" Port="9091" Protocol="http"/>
</Server>
<Server CloneID="10k67eta9" ConnectTimeout="0" ExtendedHandshake="false"
LoadBalanceWeight="6" MaxConnections="0" Name="Server2_WebSphere_Appserver" WaitForContinue="false">
<Transport Hostname="server2.domain.com" Port="9091" Protocol="http"/>
</Server>
<Server CloneID="10k68xtw10" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="18" MaxConnections="0" Name="Server3_WebSphere_Appserver" WaitForContinue="false">
<Transport Hostname="server3.domain.com" Port="9091" Protocol="http"/>
</Server>
<PrimaryServers>
<Server Name="Server1_WebSphere_Appserver"/>
<Server Name="Server2_WebSphere_Appserver"/>
<Server Name="Server3_WebSphere_Appserver"/>
</PrimaryServers>
</ServerCluster>
| ||||||||||
 |
댓글 없음:
댓글 쓰기