|
|
|
|
| |
Introduction to WebLogic Server Clustering
This topic includes the following sections:
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:
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. These services are introduced below and are described in more detail in Understanding HTTP Session State Replication and Understanding Object Clustering.
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.
JDBC Connections
WebLogic Server provides limited load balancing support for managing JDBC connections in a cluster. If you create an identical JDBC DataSource in each clustered WebLogic Server instance and configure those DataSources to use different connection pools, the cluster can support load balancing for JDBC connections. Note, however, that WebLogic Server provides no special load balancing policies for accessing connection pools. If one of your connection pools runs out of JDBC connections, the load balancing algorithm may still direct connection requests to the empty pool.
JMS
Although JMS destinations (message Queues and Topics) are each managed by a single WebLogic Server instance, connection factories, which clients use to establish a connection to a destination, they can be deployed on multiple servers in a cluster. Distributing destinations and connection factories throughout a cluster gives administrators the ability to manually balance the load for JMS services.
Non-clustered Services and APIs
Several APIs and internal services cannot be clustered in WebLogic Server version 6.0. These include:
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.0
WebLogic Server version 6.0 introduces the following new features and improvements when configured as a cluster of server instances.
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 Queues and Topics are still managed by individual WebLogic Server instances in the cluster.
HTTP Session State Replication Changes
WebLogic Server version 6.0 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.0 improves the replication system by:
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.0
The following changes affect the way you administer clusters in WebLogic Server 6.0.
Multicast Message Changes
Multiple WebLogic Server version 6.0 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.0 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.0 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.0, see the Administration Guide. See Administering WebLogic Clusters for specific instructions about using the Administration Console to configure a cluster.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|