Kshitiz Saxena

---

Brief Overview of Converged Load-Balancer

Converged Load-Balancer, is designed to provide high-availability to applications deployed on Sun Communication Application Server, aka sailfin. It will distribute requests across the instances in cluster to increase throughput of the system. It will also fail-over request from unhealthy/inaccessible instances to healthy and available instances.

Features of Converged Load-Balancer

1. It can handle both SIP(S) and HTTP(S) requests.
2. It can load-balance converged application (application having web and sip components) and pure web applications
   
3. It will distribute the load across healthy and available instances in cluster, thus enabling a higher throughput from the system
4. It maintains stickiness of requests in a session to single instance till serving instance is healthy, available and enabled
5. It will fail-over request from unhealthy/unavailable/disabled instances to instances which are healthy, available and enabled
6. It supports round-robin and consistent-hash algorithm for load-balancing
7. It supports Data-Centric-Rule(DCR) to extract hash-key used in consistent-hash algorithm

Deployment Topology

Converged load-balancer currently supports only self load-balancing cluster. Below figure illustrates self load-balancing topology.


The above deployment contains:

• Hardware IP sprayer : This distributes request evenly across all instances in sailfin cluster.
• Sailfin Cluster : Sailfin cluster having converged load-balancer component.

In case user does not have Hardware IP sprayer, the request can be forwarded to any one instance in sailfin cluster. The converged load-balancer component on that instance will ensure that requests are distributed across the cluster. However that instance will be single point of failure. The presence of Hardware IP sprayer ensures high availability.

Note : Sailfin does not support two-tier deployment as of now. However there is no such restriction put on admin commands. User can still create two tier deployment using admin commands. Two-tier deployment may not function correctly.

Functioning of Converged Load-Balancer

• Step 1 : Client request comes to IP Sprayer
• Step 2 : IP sprayer selects any of the sailfin instances in the cluster and forwards request to that instance, which in above illustration is instance X.
• Step 3 : CLB on Instance X based on configured algorithm selects an instance to service the request. Then it forward the request to that instance, which in above illustration is instance Y. This can be same instance, i.e. instance X, as well. In such case Step 3 and 4 are bypassed.
• Step 4 : CLB on Instance Y receives the request. It finds out that request is already proxied from another instance. Without any further processing, it passes the request to the container so that it can be serviced. CLB then sends the response back to CLB on Instance X.
• Step 5 : CLB on Instance X in turn sends the response back to IP sprayer
• Step 6 : IP sprayer sends the response back to the client

Algorithms

Converged load-balancer currently supports two load-balancing algorithm

1. Round-robin : Instance to service new request are selected in a round robin fashion. 
2. Consistent-hash : Instance to service new request is selected based on hash-key extracted from request.

In both cases, once a session is established, sticky information is set on response. Subsequent requests will have that sticky information. Thus subsequent requests part of same session will stick to same instance.

There are two possible configuration:

• Configuration 1: This should be used when only pure web applications are deployed. The user does not provide a dcr-file.
• Round-robin algorithm for all http requests
• Consistent-hash algorithm for all sip requests, in case converged/pure-sip applications are deployed. The hash-key used to select instance is extracted using from-tag,to-tag,call-id parameters of the request.
• Configuration 2: This should be used when converged/pure-sip applications are deployed on the application server. The user must provide a dcr-file in this case, to extract hash key from sip and http requests. If dcr-file is not provided, sip and http requests part of same session may be serviced by different instances.
• Round-robin algorithm for http requests belonging to pure web applications
• Consistent-hash algorithm for http requests belonging to converged applications
• If any dcr rule matches http request, hash-key is extracted using that rule
• If none of the rules matches http request, hash key is extracted using remote host and port of the http request
• Consistent-hash algorithm for sip request belonging to converged/pure-sip applications
• If any dcr rule matches sip request, hash-key is extracted using that rule
• If none of the rules matches sip request, hash key is extracted using from-tag,to-tag,call-id parameters of the sip request

Note : For complete details of converged load-balancer, please go through functional specifications of converged load-balancer.

---

How to configure converged load-balancer

Some common points to remember before a user start with configuration of converged load-balancer

1. The converged load-balancer uses xml file converged load-balancer xml to get cluster information. If this file is not present, CLB will not initialize and will return error. The request will not be serviced.
2. The converged load-balancer xml is generated when auto-commit attribute of converged-load-balancer element under availability-service is set to true. Till it set to false, no xml file is generated.
3. It is recommended that attribute auto-commit should be set to true, once user is done with complete configuration of cluster. This includes instances creation and application deployment. Otherwise it will result in unnecessary reconfiguration with any change to cluster.
4. It is recommended to start cluster after auto-commit is set to true and all cluster configuration is done. Please refer to point 1 above to understand why this is recommended.
5. Only instances with lb-enabled attribute set to true will participate in load-balancing. The disabled instances are not considered for load-balancing. The command to enable/disable instance is still not available. It will be provided shortly. Till then user can do it using set command. Any new instance created in cluster will have lb-enabled set to false. User has to set this attribute to true.
6. The cluster heartbeat-enabled attribute must be set to true. This is set to true by default, when user creates a cluster.

Using default-cluster

A default-cluster already exists in the domain created using cluster profile. The default-cluster is pre-configured as self load-balancing cluster. User has to just create instances and deploy applications and a self load-balancing cluster is ready for use. Please follow steps below :

1. User must ensure that all instances are created in cluster and all applications are deployed to cluster. This is not a mandatory step. However this is a recommended step.
2. Set lb-enabled attribute for all instances of default-cluster to true
• Command : asadmin> enable-converged-lb-server default-cluster
3. Set auto-commit attribute to true
• Command : asadmin > set default-cluster.availability-service.converged-load-balancer.auto-commit=true
4. Start default-cluster. If it was already running, it will now have working converged load-balancer. There is no need to restart the cluster

Creating converged-load-balancer on already existing cluster

The converged-load-balancer element does not exist under cluster config and user is starting afresh with converged load-balancer configuration. Please follow steps below :

Option 1 : A single step process

1. User must ensure that all instances are created in cluster and all applications are deployed to cluster. This is not a mandatory step. However this is a recommended step.
2. Create converged load-balancer using a single command
• Command : asadmin > create-converged-lb --target <cluster-name> --autocommit=true --selfloadbalance=true --lbenableallinstances=true --configfile <converged-load-balancer-xml> <converged-load-balancer-name>
3. Start the cluster. If cluster was already running, please restart the cluster.

Option 2 : Multi-step process with details about what exactly happens in background with Option 1

1. User must ensure that all instances are created in cluster and all applications are deployed to cluster. This is not a mandatory step. However this is a recommended step.
2. Create a converged load-balancer config
• Command : asadmin> create-converged-lb-config <clb-config-name>
• For example : asadmin> create-converged-lb-config test-clb-config
3. Create a converged load-balancer reference to the cluster
• Command : asadmin> create-converged-lb-ref --clbconfig  <clb-config-name>  --selfloadbalance=true --lbenableallinstances=true <cluster-name>
• For example : asadmin> create-converged-lb-ref --clbconfig  test-clb-config  --selfloadbalance=true --lbenableallinstances=true test-cluster
4. Create converged load-balancer for the cluster
• Command : asadmin> create-converged-lb --clbconfig <clb-config-name> --configfile <converged-load-balancer-xml-for-cluster> --autocommit=true --target <cluster-name> <converged-load-balancer-name>
• For example : asadmin> create-converged-lb --clbconfig test-clb-config --configfile converged-load-balancer.xml --autocommit=true --target test-cluster test-cluster-clb
3. Start the cluster. If cluster was already running, please restart the cluster.

Note:

1. The above command does not show the default options to be provided with each command, for example user name, password file etc.
2. Above mentioned way of configuration is just one way of configuring converged load-balancer. The used commands has many more options. Please look at man page of each command for all possible options.

---

Data Centric Rules(DCR)

Data centric rules are used extract the hash-key from the request. The extracted hash-key is used to select an instance to service the request under consistent-hash algorithm.

Sample DCR file

Below is a sample DCR file :
Above sample DCR file define following rules :

1. For SIP(S) request, for an originating request look for header named ConferenceName, and value of that header will be used as hash key.
2. For HTTP(S) request, look for parameter named ConferenceName, and value of that parameter will be used as hash key.

Configuring DCR 

A user can setup DCR in following manner :

1. At the time of converged load-balancer creation using a single command.
• Command : asadmin > create-converged-lb --target <cluster-name> --autocommit=true --selfloadbalance=true --lbenableallinstances=true --configfile <converged-load-balancer-xml> --dcrfile <dcr-file-name> <converged-load-balancer-name>
2. At the time of converged load-balancer config creation
• Command : asadmin> create-converged-lb-config --dcrfile <dcr-file-name> <clb-config-name>
3. After creation of converged load-balancer config
• Command :  asadmin> set-dcr-file --dcrfile <dcr-file-name> <clb-config-name>

Note:

1. The above command does not show the default options to be provided with each command, for example user name, password file etc.

---