Cluster vs Non-Cluster Load Balancing
search cancel

Cluster vs Non-Cluster Load Balancing


Article ID: 36113


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On


What is the difference in the Policy server load balancing mechanism when they are configured in Cluster vs Non-Cluster configuration


Component: SMPLC
Release: Applicable to all the supported releases.


The load-balancing in web-agent takes into account the capability of the servers when distributing the requests over the group of policy servers.

Instead of distributing the requests evenly over a set of policy servers (traditional round robin load distribution), this method distributes the load dynamically depending on the response time of the policy servers. This is more efficient in heterogeneous environments, where computing powers differ, since each server is expected to receive the number of requests depending on its computing power.

Another problem with efficiency can occur when data centers are located in different geographical regions. Sending requests evenly to servers outside a certain region can lead to the increased network communication overhead, and in some cases to the network congestion.

The web agent dynamically distributes the requests between the policy servers using the best server algorithm. The best server algorithm decides which policy server will be serving the current request from web agent. The algorithm compares the current capacity of all the policy servers and one with the highest value is considered to be the best.

The Policy Server supports both non-clustered and clustered environments.


When clusters are configured

The policy servers can be configured to work in groups or clusters. In this case, one can have groupings of policy servers which essentially means that suppose there are four policy servers (PS1,PS2,PS3,PS4) then one can have Cluster 1(PS1,PS2) and Cluster 2(PS3,PS4).

The geographical conditions or some other factors can decide which policy server is to be grouped with which other server.

Like if PS1 and PS2 lie in same geographic area then we can have cluster grouping both these PS.

Now, when clusters are configured failover and load balancing mechanism will work in the following manner:

The failover mechanism will happen between different clusters and load balancing mechanism will occur between policy servers inside a particular cluster.

The failover between clusters will occur depending on the value of failover threshold. A cluster can fail-over to another cluster if the number of available policy servers in the cluster falls below a configurable threshold.

Now, when the request comes, it would be served by Cluster 1(going by failover mechanism). Now, which PS in Cluster 1 will serve the request is determined dynamically by best server algorithm based on the performance capabilities of each policy server. As discussed above, load is dynamically distributed between policy servers in a cluster based on server response time.


Now, agent will failover to Cluster 2, if number of active policy servers in Cluster 1 falls below the configured threshold value. The default failover threshold is zero, which means that all policy servers in Cluster 1 must fail before failover occurs to Cluster 2. Once failover occurs to Cluster 2, then the subsequent requests will be served by policy servers in Cluster 2.


When clusters are not configured


Even when clusters are not configured, it is possible to implement load balancing mechanism by setting 'EnableFailOver' parameter "NO" in the Host Configuration Object (HCO).

The load balancing mechanism will work in the following manner while using this setup:


Failover mechanism

The same algorithm (explained in above section) is followed even if clusters are not configured. The web agent will internally add policy servers to the clusters and this offers 2 advantages:

1) Need to maintain only a single dynamic load balancing algorithm for both clustered and non-clustered environments.

2) Provides backward compatibility to 5.x web agents as concept of clusters was introduced in 6.x web agent onwards.


To enable failover between a set of policy servers, the web agent will add each policy server in a different cluster. Going by the clustering mechanism explained above (failover happens between different clusters), this will effectively lead to failover between different policy servers. This means that in this mode, every request is delivered to the first Policy Server (or cluster) in the list. If that Policy Server does not respond, then that PS is marked unavailable and failover will happen to second cluster i.e. effectively the request is redirected to the secondary policy server in the list (since each cluster will contain only single policy server in this configuration). If a previously failed policy server recovers, the web agent fails back to that PS.


Load balancing mechanism

Again, so as to use the same algorithm – the web agent will internally add the clusters in this case.

In load balancing scenario, the web agent will add all the policy servers in a single cluster. Going by the clustering mechanism explained above, this will effectively lead to the request being served by the different policy servers. Due to dynamic nature of the algorithm, the requests will be distributed between the set of policy servers in a single cluster depending on the response time of different policy servers as explained previously.

Note : Traditionally in web agent version prior to 6.x , when the cluster concept was not introduced, the load balancing used to be round-robin fashion such that all the request is distributed evenly across all the Policy servers. This is no more the case, in any of the cluster/non-cluster configuration post version 6.x web agent as explained above.

Additional Information

Related Documentation Links
CA Single Sign-On - 12.52 SP1
Clustered Policy Servers Introduced ​
Cluster Configuration

CA Single Sign-On - R12.6
Clustered Policy Servers Introduced
Cluster Configuration

CA Single Sign-On - R12.7
Clustering Policy Servers​

CA Single Sign-On - R12.8
Clustering Policy Servers