Examples of load balancing between the web servers and AR System servers

Best practice
We recommend that you configure the load balancer between the web servers and AR System server without setting a sticky bit. This allows a session from any web server to be distributed to any AR System server.

If you use other BMC products that also support load balancing without setting the sticky bit, make sure your AR System server and other BMC products use the same version. For example, BMC Helix CMDB supports configuring the load balancer without setting a sticky bit for version 7.6.04 Service Pack 1 or later, and does not support it for version 7.6.04. If you configure load balancing without setting a sticky bit for both of these products, your AR System server must also use the matching 7.6.04 SP1 or later version.

This section describes the configuration for a load balancer between the web servers and AR System server without setting a sticky bit for version 7.6.04 or later. As a starting point, the configuration for setting a sticky bit for the load balancer for versions earlier than 7.6.04 is first discussed.

Load balancing between the web servers and AR System servers by setting a sticky bit

In versions earlier than 7.6.04, BMC recommended configuring the load balancer between the web servers and AR System server by setting a sticky bit. In this configuration, the load balancer between the web servers and the AR System server routed all connections from one web server to the same AR System server, resulting in session affinity.

The following figure illustrates session affinity between the web servers (WS) and the AR System server (ARS) when the load balancer (LB) is configured with a sticky bit. For example, session affinity is established between WS1 and ARS1, WS 2 and ARS2, and WS3 and ARS3. The load balancer routes all connections from WS1 to ARS1.

Load-balancer configured with the sticky bit between the web servers and AR System servers

LoadBalStickyBit.gif

Adding a AR System server without setting a sticky bit

The following figure shows an example AR System with three web servers and two AR System servers where session affinity has been established between WS1 and ARS1, WS2 and ARS2, and WS3 and ARS1.

Load-balancer configuration with three web servers and two AR System servers with session affinity established

LoadBalConfig.gif

If a new AR System server (ARS3) is added to this AR System, ARS3 is never considered as available because WS1, WS2 and WS3 have already established session affinity to either ARS1 or ARS2 (the following figure).

Load-balancer configuration with a new Remedy AR System server added to three web servers and two AR System servers with session affinity established

LoadBalConfig2.jpg

In version 7.6.04 or later, you can route connections from a web server to a new AR System server on the fly by selecting the Enable Lifespan setting on the Connection Settings page of the Mid Tier Configuration Tool (the following figure). This setting enables load balancing without setting a sticky bit.

Enable Lifespan setting on the Connection Settings page of the Mid Tier Configuration Tool

Connection_settings_LB1.png

With Enable Lifespan selected, the load balancer distributes sessions from any web server (in this case, WS3) across the AR System server group according to its scheduling policy (round robin or least connections). The newly-available AR System server (ARS3) is considered within that distribution, as shown in the following figure. Connections may or may not get routed to ARS3 depending on the scheduling policy.

Load-balancer configuration with a new AR System server added without setting a sticky bit for the load balancer

LoadBalConfig2b.gif

Reestablishing a AR System server after fail-over with the sticky bit set

In AR System versions earlier than 7.6.04 (the following figure), suppose that ARS3 fails. If a sticky bit is configured for the load balancer, the following occurs:

  • The load balancer no longer uses ARS3 as an active resource.
  • The ARS3 end user receives an error.
  • The connection from WS3, which was previously routed to ARS3, is routed to ARS1 or ARS2. In this example, WS3 sessions go to ARS1.

The following figure illustrates the resulting unbalanced connections between the web servers, load balancer, and AR System servers.

Load-balancer configuration with web servers and AR System servers with the sticky bit set for the load balancer when a AR System server fails

LoadBalConfig3.gif

When ARS3 recovers and is recognized as an active resource by the load balancer, it does not receive connections from any of the three web servers because session affinity has been established between the web servers and either ARS1 or ARS2. To rebalance the servers in versions earlier than 7.6.04, you need to shut down the AR System servers, load balancer, and web servers and then restart them in the proper sequence.

In version 7.6.04 or later, make sure the Enable Lifespan check box is selected on the Connection Settings page of the Mid Tier Configuration Tool (the following figure). If a sticky bit is not set, the load balancer distributes sessions from any web server to any AR System server, including a recovered or new AR System server.

Limiting idle session connections

In AR System versions earlier than 7.6.04, the idle connections between a web server and AR System server can stay open indefinitely. Performance problems from this can occur under certain circumstances. For example:

  • An AR System server is removed from the server group.
  • The maximum number of sessions for a AR System server is reached during a resource spike.
  • AR System server users leave their sessions open for extended period, such as during a lunch break or at the end of the day.

The source from these open idle sessions connections is not redistributed. 

To avoid problems from idle connections in version 7.6.04 or later, you can configure the fields in the Connection Pool Settings section on the Connection Settings page in the Mid Tier Configuration Tool (the following figure). The Idle Connections per Server setting allows you to limit the number of idle connections per server. The Connection Timeout field allows you to specify how long the connections exceeding that limit will remain open before being terminated.  

Lowering the Idle Connections per Server value minimizes the number of idle connections that can stay open until their sessions ends. If the Idle Connections per Server field is set to 0, then the connection pool will be closed when all connections are closed.

Lowering the Connection Timeout value minimizes the time that idle session-based connections can stay connected before being closed, resulting in better load redistribution. The number of current idle connections is determined by whether the Connection Time or Connection Lifespan setting is first met.

Connection Pool Settings on the Connection Settings page of the Mid Tier Configuration Tool

Connection_settings_LB1.png

Configuring the Connection Pool Settings allows idle sessions to be used again in a timely manner. The AR System server end users see no change in behavior because their connections are not dropped.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*