How to use the Load Balancing feature in Sun Cluster

Do you know that Sun Cluster provides a Load Balancing feature in addition to High Availability? This is a cool feature where you can configure the applications/data services to run on multiple systems simultaneously with existing cluster hardware. Yes, there is no need to add extra hardware for achieving this IP-based load balancing.

Most of the applications that can be highly-available can also be configured as scalable with a few extra requirements described in this document. If your application meets the above requirements, then you are ready to configure the scalable application with few simple steps

Here are the instructions:

Apache is used as an example application to demonstrate how easily the Load Balancing feature can be enabled with Sun Cluster.  Below examples show the new CLI available in sc3.2, however the same can be achieved with equivalent old CLI available in previous releases.

Register the Resource Type:

To configure a scalable resource, the RTR file should declare the Scalable property and also set FAILOVER property to false . If you are using existing data service packages to configure the scalable resource, make sure the above settings are true. Otherwise, reset the values and update the packages.

# clrt register SUNW.apache

Configure the Shared Address resource:

# clresourcegroup create shared-rg
# clressharedaddress create -g shared-rg octet-1
# clresourcegroup online -M apache-rg

This example assumes that IP address is already configured for host name octet-1.

Create the scalable resource group:

# clresourcegroup create -S apache-rg

Create the scalable resource:

Here are the descriptions of few properties of interest: 

  • Scalable: TRUE specifies the resource to be scalable, which enables the network framework responsible for load balancing.
  • Port_list: List of port numbers where the server is listening.
  • Load_balancing_policy: This value is used in deciding how the load will be distributed across the nodes. The options are: 
    • LB_WEIGHTED: Load will be distributed based on weights specified using the Load_balancing_weights property.
    • LB_STICKY: Load will be distributed based on the client's IP address. In this case, the set of ports is known during the configuration and all the requests coming from the same client IP address will be distributed to the same node listening on this predefined port.
    • LB_STICKY_WILD: Load will be distributed based on the client's IP address and in this case the ports are not known in advance and are assigned dynamically. Here, all the requests coming from the same client will go to the same node regardless of the port number to which that IP address is coming.

# clresource create -g apache-rg -t SUNW.apache \\
-p resource_dependencies=octet-1 -p Port_list=80/tcp \\
-p scalable=true  -p bin_dir=/usr/apache/bin \\
-p Load_balancing_policy=LB_STICKY apache-rs

For detailed descriptions of the above properties or other scalable properties, see this document.

Bring the resource group online

# clresourcegroup online -M apache-rg

Check the status of the resources:

# clresource status

=== Cluster Resources ===

Resource Name       Node Name      State        Status Message
---------------------      ------------------    --------      ---------------------
shared-ip                     poctet1            Online       Online - SharedAddress online.
                                    poctet2            Offline      Offline
                                    poctet3            Offline      Offline
                                    poctet4            Offline      Offline

apache-rs                     poctet1            Online       Online - Service is online.
                                    poctet2            Online       Online - Service is online.
                                    poctet3            Online       Online - Service is online.
                                    poctet4            Online       Online - Service is online.

That's it, you are ready to use Sun Cluster with Load balancing.
Now, you can observe the client requests  getting distributed across the nodes according to the load_balancing_policy.

Prasanna Kunisetty
Sun Cluster Engineering 


Hello, I'm confused to how the incoming connections are actually load balanced, are you using dns to send requests to the different servers in the cluster? Or is there a "master" in the cluster that requests get sent to initially and then redistributed round the cluster. oh and can you explain what happens when a node/application dies to ensure requests don't get sent to that server? ta, jason.

Posted by jason arneil on February 06, 2007 at 12:11 AM PST #

Good questions. Here are the responses for both of your questions: 1) The incoming requests are distributed by a "master" node model that you mentioned. We call this as the Global interface (GIF) node. Basically, one of the cluster nodes will be designated as the GIF node that accepts requests from the clients and forwards it to an appropriate node based on the load_balancing_policy. 2) If the application/node dies, the forwarding algorithm that was mentioned above will remove this node from the list of the nodes where the client requests can be forwarded. If any new request comes, it will be only forwarded to the node which is up and running. Hope this answers your questions. Feel free to check out the sun cluster documentation to find out the various load balancing schemes it offers.

Posted by Prasanna Kunisetty on February 06, 2007 at 05:03 AM PST #

So what happens if the GIF node dies ? Isn't the GIF itself a SPOF ?

Posted by Jeroen on February 06, 2007 at 08:35 AM PST #

As you can see from the configuration steps, we are first configuring an HA IP address called Shared Address in the failover resource group before configuring the scalable resource apache. The node where this shared IP address is plumbed on the primary interface becomes the GIF node. In case of this GIF node failure, the Shared IP address will failover to the other node of the cluster and that will become the new GIF node. So, in summary, the shared IP address is configured as failover resource which will failover to new node and will not be a SPOF. Hope that answers your question and thanks for your interest in Sun Cluster.

Posted by Prasanna Kunisetty on February 06, 2007 at 09:41 AM PST #

The link to document does not work. Please update.

Posted by Sunny on February 20, 2007 at 09:45 AM PST #

Hi, I just verified both the links and they seem to work fine. It' supposed to open up the doc links in another window, so just make sure that you did not block the pop-up windows. Meanwhile, you can use the following links to access the information: For the information related to suitability of the applications for scalability, see the doc at: For information related to resource properties, see the doc at: Thanks, Prasanna Kunisetty

Posted by Prasanna Kunisetty on February 21, 2007 at 02:54 AM PST #

Hi My understanding with SC3.1 is that only iSCSI LUNS from at NetAPP filer are supported as Quorum devices. Are or when will Sun NAS appliances (5xxx) be supported as quorum devices ? Thanks Mick

Posted by Mick on March 19, 2007 at 09:55 AM PDT #

Currently Sun NAS as a quorum device is supported for Oracle RAC and details are available at General support for Sun NAS on Sun Cluster is being worked on and will be available in the next Sun Cluster release.

Posted by Prasanna Kunisetty on March 26, 2007 at 04:00 AM PDT #

Hi, I would like to know if you can use the same storage configuration with LB and HA clustering.

Thanks, Patrick

Posted by Patrick de Ruiter on November 21, 2007 at 05:31 PM PST #

Posted by guest on May 13, 2008 at 11:44 PM PDT #

thanks really very nice article.

Posted by usman on March 19, 2009 at 10:05 AM PDT #

I have created a scalable data service for an application server written in Java. I have used agent builder to create the RTR file and registered the resource type. During the creation I selected scalable TRUE. Also verified the RTR file. But the load balancing feature does not work (i.e. all the soap/http requests not distributed between two nodes in the cluster). Here is the setting:
policy ' LB_WEIGHTED' load_balancing_weights 'null'

Where am I going wrong? I am setting port_list property with application server port, but sending requests to a different port . Is load balancing strictly port dependent?


Posted by Srinivas Erukulla on April 17, 2009 at 07:58 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Oracle Solaris Cluster Engineering Blog


« June 2016