Cluster Best Practices

The law of diminishing returns applies to clustering. Each new server added to the cluster means that the original servers must synchronize their HTTP sessions and replicate their stubs on one more server. The replication messages being exchanged can build up pretty quickly to the point where I/O traffic begins to impede performance. You might find that it is better to have, say, four clusters with two nodes apiece, than to have two clusters with four nodes. In this section, well talk about several options when working with clusters and how to best optimize the way that an application is deployed on a cluster.

Single-Tier Clustering Architecture

A simple way to set up a cluster is to have the entire application deployed on each server instance. BEA calls this the combined tier architecture. The benefits of this architecture are

• Easy to set up— Deploying the entire application on each server is easy and can be easily automated as part of a deploy process.

• Easy to administer— Because the entire application is on each machine, you do not need to set up a separate bank of Web servers or worry about configuring proxy plug-ins.

• Load balancing— You need only one load balancer in front of your application servers.

• Security— Placing a firewall in front of your load balancer enables you to set up security with minimal firewall policies and administration.

• Performance— A cluster of this type is optimal when the presentation tier (JSPs, HTML, and so on) is lightweight, and accesses objects such as EJBs, JDBC, and so forth.

The major drawback of this sort of clustering architecture is that you add the load of processing HTML content and other presentation content on the more expensive application server. You can get better load balancing and performance by separating the servlet and HTML content onto the Web tier.

This architecture also prevents load balancing between method calls to clustered EJBs. This is generally a good idea: The container tries to use the local object's instance of making remote calls. However, if the load on one server becomes uneven, it can eventually become more efficient to take the network hit of using a remote object, rather than processing the methods using the local object.

Multitier Clustering Architecture

The concept here is to split the static HTTP content and servlets on one cluster and use another cluster for the EJBs. The advantages of this concept are

• Load balancing for method calls to clustered EJBs.

• You can have two load balancers, one for each cluster.

• Overall, this improves the availability of the system.

• You can use WebLogic Express or Tomcat to serve servlets.

• Security— You can have separate security for each cluster to further protect access to your objects by untrusted clients.

Proxy Clustering Architecture

This is probably the most commonly used architecture that we have seen. Here, we split the static content onto a Web server such as the Apache Web Server, but leave the JSPs, servlets, EJBs, and so forth on the application server. We need to configure a proxy plug-in between the Web server and the application server.

We can also combine the multitier architecture with the proxy architecture to have an MVC-like deployment architecture. In this case, the static content is on a cluster of Web servers, followed by a cluster of servlet containers that host the JSPs and servlets. Lastly, there is a cluster of application servers that run the EJBs and so on.

For more information about various clustering architectures and details on how to work with proxies, please refer to the WebLogic Server documentation at http://edocs.bea.com/wls/docs81/cluster/planning.html#1118661.