Introduction to WebLogic Server Clustering

 

The following sections introduce WebLogic Server clusters:

• What Is a WebLogic Server Cluster?

• What Services Are Clustered?

• New Cluster Features in WebLogic Server Version 6.1

 

---

What Is a WebLogic Server Cluster?

A WebLogic Server cluster is a group of servers that work together to provide a more scalable, more reliable application platform than a single server. A cluster appears to its clients as a single server but is in fact a group of servers acting as one. A cluster provides two key features above a single server:

• Scalability: The capacity of a cluster is not limited to a single server or a single machine. New servers can be added to the cluster dynamically to increase capacity. If more hardware is needed, a new server on a new machine can be added. If a single server cannot fully utilize an existing machine, additional servers can be added to that machine.

• High-Availability: A cluster uses the redundancy of multiple servers to insulate clients from failures. The same service can be provided on multiple servers in the cluster. If one server fails, another can take over. The ability to failover from a failed server to a functioning server increases the availability of the application to clients.

WebLogic Server clusters are designed to bring scalability and high availability to J2EE applications. They provide these features in a way that is transparent to the application writer and to clients. It is important, however, for application programmers and administrators to understand the issues inherent in clustering in order to maximize the scalability and availability of their applications.

 

---

What Services Are Clustered?

A clustered service is an API or interface that is available on multiple servers in the cluster. HTTP session state clustering and object clustering are the two primary cluster services that WebLogic Server provides. WebLogic Server also provides cluster support for JMS destinations and JDBC connections, as described in the sections that follow.

HTTP Session States

WebLogic Server provides clustering support for servlets and JSPs by replicating the HTTP session state of clients that access clustered servlets and JSPs. To benefit from HTTP session state clustering, you must ensure that the session state is persistent, either by configure in-memory replication, filesystem persistence, or JDBC persistence. Understanding HTTP Session State Replication describes in-memory replication for clustered servlet and JSPs. See "Making Sessions Persistent" in Programming WebLogic HTTP Servlets for more information about file persistence and JDBC persistence.

EJBs and RMI objects

Load balancing and failover for EJBs and RMI objects is handled using special, replica-aware stubs, which can locate instances of the object throughout the cluster. You create replica-aware stubs for EJBs and RMI objects by specifying the appropriate deployment descriptors or providing command-line options to rmic. When you deploy a clustered object, you deploy it to all the server instances in the cluster (homogeneous deployment). Understanding Object Clustering describes object clustering in more detail.

JMS

The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to destinations from any server in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, JMS Queues and Topics are still managed by individual WebLogic Server instances in the cluster.

The advantages of clustering WebLogic JMS include:

• Establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers.

• Load balance destinations across multiple servers instances in the cluster by configuring multiple JMS servers and using targets to assign them to the defined WebLogic Servers. Each JMS server is deployed on exactly one WebLogic Server instance and handles requests for a set of destinations.

For more information about WebLogic JMS and cluster support for JMS, see "Introduction to WebLogic JMS" in Programming WebLogic JMS.

JDBC Connections

WebLogic Server allows you to cluster JDBC objects, including data sources, connection pools and multipools, to improve the availability of cluster-hosted applications. Each JDBC object you configure for your cluster must exist on each managed server in the cluster—when you configure the JDBC objects, target them to the cluster.

• Data Sources—In a cluster, external clients must obtain connections through a JDBC data source on the JNDI tree. The data source uses the WebLogic Server RMI driver to acquire a connection. The cluster-aware nature of WebLogic data sources in external client applications allows a client to request another connection if the server instance hosting the previous connection fails. Although not strictly required, BEA recommends that server-side clients also obtain connections via a data source on the JNDI tree.

• Connection Pools—Connection pools are a collection of ready-to-use database connections. When a connection pool starts up, it creates a specified number of identical physical database connections. By establishing connections at start-up, the connection pool eliminates the overhead of creating a database connection for each application. BEA recommends that both client and server-side applications obtain connections from a connection pool through a Data Source on the JNDI tree. When finished with a connection, applications return the connection to the connection pool.

• Multipools—Multipools are multiplexers for basic connection pools. To the application they appear exactly as basic pools, but multipools allow you to establish a pool of connection pools, in which the connection attributes vary from connection pool to connection pool. All of the connections in a given connection pool are identical, but the connections in each connection pool in a multipool should vary in some significant way such that an expected failure of one pool will not invalidate another pool in the multipool. Usually these pools will be to different instances of the same database.

  Multipools are only useful if there are multiple distinct database instances that can equally handle an application connection, and the application system takes care of synchronizing the databases when application work is distributed among the databases. In rare cases it may be valuable to have the pools to the same database instance, but as different users. This would be useful if the DBA disabled one user, leaving the other user viable.

  By default, a clustered multipool provides high availability (DBMS failover). A multipool can be optionally configured to also provide load balancing.

For more information about JDBC, see "JDBC Components—Connection Pools, Data Sources, and MultiPools" in the WebLogic Server Administration Guide.

Getting Connections with Clustered JDBC

To ensure that any JDBC request can be handled equivalently by any cluster member, each managed server in the cluster must have similarly named/defined pools and, if applicable, multipools. Data sources, if intended for use in external clients, should be targeted to the cluster so they are cluster-aware and their connections can be to any cluster members.

• External Clients Connections—External clients that require a database connection perform a JNDI lookup and obtain a replica-aware stub for the data source. The stub for the data source contains a list of the server instances that host the data source—which should be all of the Managed Servers in the cluster. Replica-aware stubs contain load balancing logic for distributing the load among host server instances.

• Server-Side Client Connections—For server-side use, application code can use a server-side pool driver directly instead of a JNDI lookup and a data source, but if a data source is used, it will be a local object. A server-side data source will not go to another cluster member for its JDBC connections. The data source obtains a connection from the pool it references. The connection is pinned to the local server instance for the duration of the database transaction, and as long as the application code retains it (until the connection is closed).

Failover and Load Balancing for JDBC Connections

Clustering your JDBC objects does not enable failover of connections but it can ease the process of reconnection when a connection fails. In replicated database environments, multipools may be clustered to support database failover, and optionally, load balancing of connections. See the following topics for more information:

• To understand the behavior of clustered JDBC objects when failures occur, see Failover and JDBC Connections.

• To learn more about how clustered multipools enable load balancing of connections, see Load Balancing and JDBC Connections.

Non-Clustered Services and APIs

Several APIs and internal services cannot be clustered in WebLogic Server. These include:

• File services

• Time services

• WebLogic Events (deprecated in WebLogic Server 6.0)

• Workspaces (deprecated in WebLogic Server 6.0)

• ZAC

You can still use these services on individual WebLogic Server instances in a cluster. However, the services do not make use of load balancing or failover features.

 

---

New Cluster Features in WebLogic Server Version 6.1

WebLogic Server version 6.1 introduces the following new features and improvements when configured as a cluster of server instances, compared to Weblogic Server version 5.x.

Integrated Support for Load Balancing Hardware

WebLogic Server now supports load balancing and failover for clustered servlets and JSPs when clients connect directly to a cluster via supported load balancing hardware. Clustered systems are no longer required to proxy HTTP requests to a cluster using the HttpClusterServlet or WebLogic Server proxy plug-ins. Understanding HTTP Session State Replication describes this in more detail.

Stateful Session EJB Clustering

WebLogic Server now supports clustering the EJBObject for stateful session EJB instances (as well as the EJBHome object). WebLogic Server replicates the state of stateful session EJBs in memory, in a manner similar to HTTP session state replication. See Understanding Object Clustering for more information.

Clustered JMS

WebLogic Server now supports distributing JMS destinations and connection factories throughout a cluster. JMS topics and queues, however, are still managed by individual WebLogic Server instances in the cluster.

HTTP Session State Replication Changes

WebLogic Server version 6.1 introduces a more robust mechanism for replicating servlet session states across clustered server instances. As with previous server versions, WebLogic Server maintains two copies of the servlet session state (a primary and secondary) on different server instances in the cluster. Version 6.1 improves the replication system by:

• Providing administrative control over where WebLogic Server creates session state replicas.

• Enabling clients to failover to a secondary session state regardless of where in the WebLogic Server cluster those clients connect.

These changes provide more opportunities for addressing failover scenarios, and also make it possible for WebLogic Server to operate directly in conjunction with load balancing hardware. See Understanding HTTP Session State Replication for more information.

 

---

Administration Changes in WebLogic Server Version 6.1

The following changes affect the way you administer clusters in WebLogic Server 6.1, compared to WebLogic Server version 5.x.

Multicast Message Changes

Multiple WebLogic Server version 6.1 clusters can now "share" a single multicast address without causing broadcast message conflicts. You do not need to assign a dedicated multicast address for each cluster.

You should still ensure that no other applications utilize the WebLogic Server multicast address. When other applications broadcast on the cluster multicast address, all servers in the cluster must deserialize those messages to determine that they are not cluster-related messages. This introduces unnecessary overhead, and may cause servers to miss actual cluster broadcast messages.

Homogeneous Deployment

WebLogic Server version 6.1 supports only homogeneous deployment of clustered objects. If an object is compiled as clusterable (if it has a replica-aware stub), you must deploy the object to all members of the cluster.

Non-clustered objects (EJBs and RMI classes) may deployed to individual servers in the cluster.

Administration Server Configuration

You perform all configuration for a WebLogic Server 6.1 cluster using the Administration Console. The Administration Console stores all configuration information for the cluster in a single XML configuration file. The Administration Console also manages deployment of objects and Web applications to members of the cluster.

For general information about configuring WebLogic Server 6.1, see the Administration Guide. See Administering WebLogic Clusters for specific instructions about using the Administration Console to configure a cluster.