Sun Cluster includes a concept of horizontal scalability for data services called scalable service. Ip based load-balancing algorithms are integrated in this concept. Because of this reason you can scale horizontally without using hardware loadbalancers. For a more detailed discussion of this scalable service see the Sun Cluster Concepts Guide.
Before using the Sun Cluster HA for Apache Tomcat in a scalable configuration, it is necessary to have a closer look at the infrastructure of the cluster and the clients.
If your clients access your application using proxies, determine whether the used proxy stays the same during a session context. This is true for an intranet.
If the proxy changes during a session context it means, from the load-balancing point of view, that the source ip address is changing. This will spoil every ip based load-balancing, wether it is hardware or software.
Especially when your client acesses the server over the Internet, it is not guaranteed, that the source ip address remains the same during a session context.
Sun Cluster HA for Apache Tomcat can be configured two ways to get horizontal scalability.
Using Sun Cluster HA for Apache Tomcat in a purely scalable configuration.
Using Sun Cluster HA for Apache Tomcat in a multiple masters configuration.
Multiple masters configurations and scalable configurations are configured as a scalable data service. The difference between the two configuration is in the way of accessing the nodes.
A client accesses the scalable configuration by its shared address. In this case, Sun Cluster does the load-balancing.
A client accesses a multiple masters configuration using each node's physical address. Load-balancing must be done outside of the cluster.
For more information about scalable data services, see the Sun Cluster Concepts Guide.
Both configuration options are discussed in the sectionsSun Cluster HA for Apache Tomcat as a scalable configuration and Sun Cluster HA for Apache Tomcat as a multiple master configuration.
You can use Sun Cluster HA for Apache Tomcat in a scalable configuration if it is guaranteed, that the source ip address remains the same during a session context. This guarantee is achieved in example in an intranet.
If the source ip address might change during a session context and a scalable configuration is required, Apache Tomcat needs to be configured with session replication. This can be done by the application using a global file system or a database.
You will get a performance penalty from this approach.
You will get better performance using Tomcats inbound memory session replication for a scalable configuration with changing source ip addresses.
You can achieve the session replication for Apache Tomcat 4.x by following the instructions at http://www.theserverside.com/resources/article.jsp?l=Tomcat.
For Apache Tomcat 5.x, inbound memory session replication as a built-in feature, is on the feature list.
For Apache Tomcat 3.x the inbound memory session replication is not configurable.
You can use Sun Cluster HA for Apache Tomcat in a multiple master configuration in the other scenarios. External load-balancing is required. A typical configuration uses the scalable Apache web server as a load balancer and configures one physical host name of an Apache Tomcat instance behind each instance of the Apache web server. Another option is to use a hardware load balancer, which handle the session context.
The difference between scalable and multiple masters configuration is only in the way the clients access the cluster nodes. In a scalable configuration, they access the shared address. Otherwise the clients access the physical hostnames. In items of Sun Cluster point of view there is no difference between the two configurations.