Clustering

Clustering creates an illusion it permits the deployment of application components and services to several machines while presenting only a single face to the client. There are good reasons to support this illusion. When a client requests a service, it should make no difference if the service runs on a single server or across a number of servers. The clustering abstraction provides you with a clear route to improving the performance and scalability of your applications, albeit with increased administration of hardware and network resources. WebLogic's clustering offers three important benefits:

Scalability

A solution that allows you to create additional capacity by introducing more servers to the cluster, thereby reducing the load on existing servers.

Load balancing

The ability to distribute requests across all members of the cluster, according to the workload on each server.

High availability

A mix of features that ensure applications and services are available even if a server or machine fails. Clients can continue to work with little or no disruption in a highly available environment. WebLogic achieves high availability using a combination of features: replication, failover, and migratable services.

Clearly, WebLogic's support for clustering impacts all aspects of J2EE development, deployment, and application security. In previous chapters, we encountered several instances in which WebLogic allows you to improve the scalability and availability of your applications: HTTP session state replication, load balancing HTTP requests across web servers, JMS distributed destinations, JDBC multipools, load balancing and failover for calls to EJB homes and EJB objects, and more. These all fall under the broad umbrella of WebLogic clustering. This chapter aims to put all of these WebLogic features into perspective, and looks at their impact on a clustered solution.

Architecting a clustered solution requires you to understand three concepts: the clustering features that WebLogic provides for the various J2EE resources, the communication infrastructure that is imposed by WebLogic on any clustered solution, and the different ways to logically and physically partition the various WebLogic server instances and applications. This chapter examines all of these aspects of WebLogic clustering by using a running example of a multi-tiered architecture. We begin by taking a closer look at clusters and tiers, consolidating the facts and examining the two most important benefits of WebLogic clustering: load balancing and failover. We then cover the various configuration issues involved in setting up a WebLogic cluster and how to physically construct the various application tiers. We also examine important issues affecting the front tier, including replication of HTTP session state and the use of a load balancer. Next, we see the impact of adding an object tier, the role of JNDI and replicated stubs in the communication between the two tiers, and how EJBs, RMI objects, and JMS resources behave in a WebLogic cluster.

Finally, we look at how to protect your cluster configuration, how to set up replication groups, and how to configure the underlying communication infrastructure according to the needs of your cluster. By the end of this chapter, you will be able to architect a multi-tiered framework for your J2EE applications, and understand the implications of this framework in terms of network, server, and application resources.

There is no best way to architect a clustered solution a good solution will adapt to the design of your application and meet your requirements regarding scalability, availability, and security. The goal of this chapter is to emphasize the framework options that WebLogic provides so that you can better architect your clustered solutions to take advantage of them.