WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


HTTP session rebalancing

You can dynamically and actively balance the distribution of HTTP sessions among application servers by using HTTP session rebalancing.

WebSphere® Application Server assigns HTTP sessions based on application server affinity. After a session is established in a particular application server, subsequent requests that belong to the same session are assigned to the application server that has the established session affinity.

Session affinities cause the session load to balance out for a cluster in the long term, and generally any imbalances that occur are short-lived and tolerable. However, you can use session rebalancing to help some of the shorter term imbalances that can occur, without modifying the performance benefits of session affinities.

WebSphere Extended Deployment uses session rebalancing to expedite the balancing of sessions across a cluster. You can use session rebalancing if you use distributed sessions and track your sessions with cookies. By default, WebSphere Extended Deployment application servers are configured with Session tracking enabled using cookies, but without distributed sessions.

The steps that you use for configuring servers in static clusters can also be used for servers in dynamic clusters. If you are configuring dynamic clusters, leave the dynamic cluster in manual mode initially so that the servers in the cluster are not started automatically. After the distributed environment settings of all the servers in the cluster are changed, switch the dynamic cluster to automatic mode. If you do not switch modes, you must stop and restart the servers that are already started in the dynamic cluster to pick up the distributed environment setting changes.

When a new server becomes available in a dynamic cluster, that server does not have any assigned HTTP sessions. However, the existing servers in the dynamic cluster have sessions with assigned affinity.

Version 6.0 session rebalancer

With WebSphere Extended Deployment Version 6.0, the goal of session rebalancing is to reassign sessions so that each server has an equal proportion of all the existing sessions. The number of sessions that are assigned to the new application server is determined from the number of sessions on each existing application server and the weight of each application server. The session rebalancing function runs in each application server. Each application server is made aware of new application servers that become available and the weights and number of sessions for each server. With these numbers, the application server can determine how many sessions to move from the current application server to the new application server. The number of sessions to move is then passed to an HTTP servlet filter that is dynamically added on the server start to intercept and redirect session requests.

Version 6.0.1 and later session rebalancer [Version 6.0.1 and later]

[Version 6.0.1 and later] With WebSphere Extended Deployment Version 6.0.1 and later, the goal of session rebalancing is to reassign sessions so that the number of sessions that are running in each server in the dynamic cluster is proportional to the assigned weight of the servers. The dynamic workload manager (DWLM) performs the session rebalancing function. DWLM decides how many sessions to move and where to move the sessions based on the knowledge about the entire dynamic cluster. The DWLM component factors in the session location and can initiate session moves in addition to changing the weight on specific servers. Any events that DWLM monitors can initiate the moves, such as new servers starting, overloaded servers, and so on.

[Version 6.0.1 and later] DWLM often picks a very uneven distribution of routing weights. This approach is allowed because the only objective DWLM has is equalizing service times. With WebSphere Extended Deployment Version 6.0.1 and later, a secondary goal is added to DWLM. DWLM attempts to even out the routing weights when possible without significant degradation of the primary objective of equalizing service times.

[Version 6.0.1 and later] If you are using ObjectGrid-based HTTP session support instead of the normal WebSphere Application Server session management, HTTP session rebalancing is not supported.

[Version 6.0.1 and later] If you are using sessions that are maintained by Uniform Resource Locator (URL) rewriting or Secure Sockets Layer (SSL) IDs, no rebalancing is performed. Rebalancing is also not performed on HTTP POST requests. Sessions are not rebalanced if the session is accessed by issuing the HTTP request directly to the application server HTTP port, bypassing the on demand router. The PMI counter for memory sessions reflects the moving sessions. Specifically, the PMI counter decreases on existing servers as sessions move and increases on the new servers that are recently started. However, new sessions are load balanced across any of the servers in the cluster. See the WebSphere Application Server Network Deployment Information Center for more information about analyzing PMI data and best practices for using HTTP sessions.

Session rebalancer configuration

You can enable or disable session rebalancing by adjusting the HttpSessionRebalanceOff custom property on the dynamic cluster in the administrative console.

Example [Version 6.0 only]

With session rebalancing enabled, and new server starts in the dynamic cluster, the following actions redistribute the session requests to the new server:

  1. A new application server becomes available in the dynamic cluster.
  2. The session rebalancing component in each existing server receives notification of the addition, with the weights of each server and the number of sessions on each existing server. Based on that information, the session rebalancing component in each server calculates the number of sessions to move to the new server.
  3. Meanwhile, the client generates a request for an existing session, sending the cookie that is established in the client browser.
  4. The cookie contains a session ID and a server ID, and is assigned to an existing application server that has an established session affinity.
  5. On the server with session affinity, if the number of sessions to move to the new server is not met, the servlet filter modifies the response to the request. Instead of sending the actual response, the servlet filter sends a redirect back to the client that contains the server ID for the new application server. If the application server does not move the session to the new application server, the servlet filters the request forward to the servlets.

The following diagram illustrates this process:

Figure 1. HTTP session rebalancing in WebSphere Extended Deployment Version 6.0
Version 6.0 session rebalancing scenario

Example

The following example illustrates session rebalancing in a WebSphere Extended Deployment Version 6.0.1 and Version 6.0.2 environment:

  1. In the dynamic cluster, a new server becomes available or an existing server becomes overloaded.
  2. The dynamic workload manager (DWLM) calculates the number of sessions to move. If a new server is available, DWLM can assign sessions to the new server from existing servers. If an existing server becomes overloaded, DWLM can move sessions from the overloaded server to other servers in the dynamic cluster.
  3. Meanwhile, the client generates a request for an existing session, sending the cookie that is established in the client browser.
  4. The cookie contains a session ID and a server ID, and is assigned to an existing application server that has an established session affinity.
  5. If DWLM indicates that a number of sessions from the target server need to move to other servers in the cluster, the servlet filter sends a redirect back to the client that contains the new server ID. If the number of sessions that DWLM recommends to move to other servers have already been moved, the servlet filter forwards the request to the server that is identified by the server ID.

The following diagram illustrates this process:

Figure 2. HTTP session rebalancing in WebSphere Extended Deployment Version 6.0.1 and later
Version 6.0.1 session rebalancing scenario

Example

The following example illustrates session rebalancing in a WebSphere Extended Deployment Version 6.1 environment. In this example, both Version 6.0.1and Version 6.1 dynamic clusters exist in the configuration. The Version 6.0.1 servers continue to perform session rebalancing within the server. The Version 6.1 server performs session rebalancing by sending information from DWLM to the ODR. The ODR then routes the HTTP sessions to the appropriate server.

Figure 3. HTTP session rebalancing in WebSphere Extended Deployment Version 6.1
Version 6.1 rebalancing scenario



Related concepts
Dynamic clusters
Related tasks
Creating dynamic clusters
Configuring for database session persistence
Configuring memory-to-memory replication for the peer-to-peer mode (default memory-to-memory replication)
Related reference
Related information
Dynamic cluster custom properties
Concept topic    

Terms of Use | Feedback

Last updated: Oct 16, 2009 11:06:12 AM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/odoe_task/codrsessionbalance.html