How the Converged Load Balancer Works

The load balancer attempts to evenly distribute the workload among multiple instances (either stand-alone or clustered), thereby increasing the overall throughput of the system.

The Converged Load Balancer enables high availability of services deployed on Java EE application servers. While doing so, it fails over a session request to another server instance in the same cluster if the original servicing instance is detected to be unavailable or unhealthy to service a request.

The load balancer does not handle URI/URLs that are greater than 8k.

The following illustration depicts the working of a load balancer:

1. IP sprayer receives the client request.

   ---

   Note –

   The IP sprayer could be a hardware IP sprayer, which distributes requests evenly across all instances in a cluster. A network element such as the IP sprayer can front the converged load balancer and , at the transport level, distribute traffic over the cluster.

   ---

2. IP sprayer selects any of the SailFin instances in the cluster and forwards request to that instance. This example and illustration shows the request being forwarded to Instance1.

3. The converged load balancer on Instance1 selects an instance (Instance2, in this case) to service the request.

   The selection of the server instance to forward the request, is based on the configured Converged Load Balancing Algorithms. This key is added to the request as a header or parameter for maintaining stickiness.

4. In this example, the converged load balancer on Instance1 forwards the request to Instance2. If the converged load balancer chooses Instance1 to service this request, step 5 is bypassed.

5. The converged load balancer on Instance2 receives the request and detects that the request is already proxied from another instance. Without any further processing, Instance2 passes the request to the container so that it can be serviced. The converged load balancer on Instance2 sends the response back to the converged load balancer on Instance1.

6. The converged load balancer on Instance1 sends the response back to the client

7. Once a session is established, sticky information is set on the response and subsequent requests will carry this sticky information. Subsequent requests from the client will have the sticky information in the header/parameter. Even if Instance1 receives this request, it detects the sticky information and forwards the request to the converged load balancer on Instance2.

   To maintain HTTP and HTTPS session stickiness the load balancer uses cookies or , if the browser does not support cookies, uses URL rewriting. For SIP/SIPS sessions, the load balancer uses parameters such as the BEKeyand BERoute. For example, the converged load balancer stamps the BERoute parameter on the VIA header as part of the outgoing request.

Converged Load Balancing Algorithms

The load balancer automatically uses one of the following algorithms:

• Round-robin algorithm — The load balancer selects the instance for servicing new message in a round robin fashion.

• Consistent hash — The load balancer selects the instance for servicing new message based on hash-key extracted from request. The hash key is extracted by using the rule specified in the DCR file, if provided. If a DCR file is not provided, hash key is extracted using default headers.

  A DCR file, data-centric-rules.xml, provides rules for applying consistent hashing on both HTTP/HTTPS and SIP/SIPS messages from converged or pure SIP applications. If this file is specified, the instructions in this file override the mechanism to extract hash key using default headers. If a DCR file is not provided, SIP and HTTP messages that are part of the same session may be serviced by different instances. Ensure that you provide a DCR file when you are deploying a converged application. The default header used may not provide a correct load distribution for SIP messages either. Therefore, even for pure sip applications, it is recommended that you provide a DCR file. For more information about this file, see Editing Configuration Settings and The Data Centric Rules File.

  In addition to this XML, it is possible to configure DCR by using a plug-in in the form of a Java class.

Converged Load Balancing Algorithm for Web Applications

HTTP and HTTPS messages belonging to pure web applications, the converged load balancer uses a sticky round robin algorithm, by default. When a new request is sent to the load balancer, it is forwarded to an application server instance based on a simple round robin scheme. If the request is for a session-based application, it may result in creation of a session. In such a case, response will have sticky information, which is sent back on subsequent messages. Subsequent messages from the same client for the same session-based application are considered assigned or sticky messages and are routed by the load balancer to the same instance if that instance is found to be healthy. Hence, the name sticky round robin. Requests to a non-session-based application and the first request for a session-based application are new requests.

Converged Load Balancing Algorithm for SIP Applications

For SIP and SIPS messages belonging to pure SIP applications, the converged load balancer uses a consistent hash algorithm, by default. If any of the rules in the DCR file match the SIP/SIPS request, a hash key is extracted using that rule. If none of the instructions or rules in the DCR file match the SIP or SIPS request, a hash key is generated using the from-tag,call-id parameters of the request.

Converged Load Balancing Algorithm for Converged Applications

Converged load balancer applies appropriate algorithms for HTTP/HTTPS and SIP/SIPS messages from converged applications, as follows:

• If no DCR file is specified, applies the sticky round robin algorithm for HTTP/HTTPS messages and the consistent hash algorithm for SIP/SIPS messages.

• If a DCR file is specified, applies the consistent hash algorithm for both HTTP/HTTPS messages and SIP/SIPS messages.

  For HTTP and HTTPS messages belonging to converged applications, if any of the rules in the DCR file match the HTTP/HTTPS request, a hash key is extracted using that rule. If none of the instructions or rules in the DCR file match the HTTP/HTTPS request, a hash key is extracted using remote host and port of the HTTP request.

  For SIP and SIPS messages, if any of the rules in the DCR file match the SIP/SIPS request, a hash key is extracted using that rule. If none of the instructions or rules in the DCR file match the SIP or SIPS request, a hash key is generated using the from-tag,call-id parameters of the request.

Converged Load Balancer Deployments

You can configure your load balancer in different ways, depending on your goals and environment, as described in the following sections:

• Using Self-Load-Balancing Clusters

• Using Dedicated Load Balancing Server Instances

Using Self-Load-Balancing Clusters

In a development or production environment, you can designate that all server instances in a cluster participate in both redirecting and servicing requests, without using any dedicated load balancing instances. This is a self-load-balancing cluster, in which the target and the LB target are the same cluster.

A front-end hardware IP sprayer distributes request evenly across all instances in the cluster. If you do not use a hardware IP sprayer, a request can be forwarded to any server instance in the cluster. The converged load balancer component on that instance ensures that requests are distributed across the cluster. However, that instance is a single point of failure. The presence of a hardware IP sprayer ensures high availability.

Using Dedicated Load Balancing Server Instances

In a development environment, you can designate one or more stand-alone server instances as dedicated load balancers, which redirect requests to clusters or to other stand-alone instances that service those requests. These dedicated load balancers are called the targets of the load balancer.

The clusters or instances that service requests are called the LB targets of the load balancer. The LB targets of a specific load balancer can be clusters or stand-alone instances, but not a mixture of clusters and instances.

• Using Clustered Server Instances as LB Targets — The most common way to deploy the load balancer is with a cluster or clusters of server instances as the LB target or LB targets. By default all the instances in a cluster have the same configuration and the same applications deployed to them. The load balancer distributes the workload between the server instances and requests fail over from an unhealthy instance to a healthy one. If you have multiple clusters, requests can be load balanced across clusters but are only failed over between the instances in a single cluster.

• Using Multiple Stand-Alone Instances as LB Targets — It is also possible to configure your load balancer to use multiple stand-alone instances as LB targets, and to load balance and failover requests between these LB targets. However, in this configuration, you must manually ensure that the stand-alone instances have homogenous environments and the same applications deployed to them. Because clusters automatically maintain a homogenous environment, for most situations it is better and easier to use clusters.

  All instances in a cluster must have similar view for each other's IP address. For example, consider a cluster with two instances, say instance1 and instance2. When instance1 looks up instance2's IP address, it gets a.b.c.d. When instance2 looks up its own IP address, it should also see a.b.c.d, which is the same IP viewed by instance1. Ensure that the hosts file on your machine is correctly set up.

Dedicated load balancers are not supported in a production environment.