|
|
|
|
| |
Overview of WebLogic Server Clustering
What is a WebLogic Server Cluster?
A WebLogic Cluster is a group of servers that work together to provide a more powerful, 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. It 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. 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 Clusterable?
A clustered service is an API or interface that is available on multiple servers in the cluster. WebLogic Server enables clustering for both HTTP session states and for RMI and EJB objects. Each object instance or session state that appears on multiple WebLogic Servers in a cluster is referred to as a replica of the clustered service. WebLogic Server uses slightly different methods to facilitate load balancing and failover for clustered HTTP session state replicas and object replicas, as described below.
HTTP session state clustering
WebLogic Server provides clustering for servlets and JSPs by replicating the HTTP session state of clients that access servlets and JSPs. To benefit from HTTP session state clustering, you must use a WebLogic proxy plug-in on a standalone web server, or use the HttpClusterServlet with one or more WebLogic Servers that act as web servers. You must also use in-memory session state replication for the servlet or JSP. How Servlet Clustering Works describes HTTP session state clustering in more detail.
WebLogic Server also provides the ability to maintain the HTTP session state of a servlet or JSP using file-based or JDBC-based persistence. These persistence features enable you to recover a client's HTTP session state with load balancing and automatic failover capabilities.
Object clustering
WebLogic Server provides clustering support for EJBs and RMI objects using special, replica-aware stubs for those objects. EJBs can be clustered simply by compiling them with deployment descriptors that create the replica-aware stubs. You create replica-aware stubs for RMI objects by providing the necessary options to rmic. How Object Clustering Works describes object clustering in more detail.
JDBC connections in a cluster
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.
Non-clustered services and APIs
Several APIs and internal services are not clusterable in WebLogic Server versions 4.5 and 5.1. 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.
High-Level Cluster Features
WebLogic Server provides the following high-level features for clustered objects and HTTP session states.
Cluster-Wide JNDI Tree
Clients access the objects (RMI classes and EJBs) provided by a WebLogic server using JNDI. The JNDI tree lists all of the public objects offered by a server. A server offers a new object by binding a stub representing that object into the JNDI tree. Clients obtain the stub by connecting to a server and looking up the object by name.
WebLogic Server clusters provide a JNDI tree that contains all of the objects hosted by servers in the cluster. Clients simply connect to a server in the cluster and look up the desired object by name. From the clients' point of view, the lookup procedure is the same regardless of whether or not the object is clustered. For clustered objects, however, the JNDI tree contains replica-aware stubs, which represent object instances that are clustered across multiple servers. See Cluster-wide JNDI naming service for more information on how the cluster-wide JNDI tree works.
Load Balancing
In order for a cluster to be scalable, it must ensure that each server is fully utilized. The standard technique for accomplishing this is load-balancing. The basic idea behind load balancing is that by distributing the load proportionally among all the servers in the cluster, the servers can each run at full capacity. The trick to load-balancing is coming up with a technique that is simple yet sufficient. If all servers in the cluster are the same power and offer the same services, it is possible to use a very simple algorithm that requires no knowledge of the servers. If the servers vary in power or in the kind of services they deploy, the algorithm must take into account these differences.
For HTTP session state clustering, the WebLogic Server proxy plug-ins provide only a round-robin algorithm for distributing requests to servlets and JSPs in a cluster. This load balancing method is described below.
WebLogic Server clusters support several algorithms for load balancing clustered objects. The particular algorithm you choose is maintained within the replica-aware stub for the clustered object. Available algorithms for load balancing clustered objects are:
WebLogic Server uses the round-robin algorithm as the default load balancing strategy for clustered object stubs when no algorithm is specified. Round-robin is the only load balancing strategy used by WebLogic proxy plug-ins for HTTP session state clustering.
The round-robin algorithm cycles through a list of WebLogic Server instances in order. For clustered object, the server lists consists of WebLogic Server instances that host the clustered object. For proxy plug-ins, the list consists of all WebLogic Servers that host the clustered servlet or JSP.
Upon reaching the end of the list, the proxy plug-in or replica-aware stub starts again at the beginning. The starting point for accessing the list is chosen at random to ensure that all stubs and proxies do not begin with the same server instance. This algorithm tends to distribute the load evenly among the WebLogic Server instances. For object clustering purposes, it is recommended only in a homogeneous cluster.
The advantages of this algorithm are that it is simple, cheap and very predictable. The primary disadvantage is that there is some chance of convoying. Convoying occurs when one server is significantly slower than the others. Because replica-aware stub or proxy plug-ins access the servers in the same order, one slow server can cause requests to "synchronize" on the server, then follow in order for future requests.
Weight-based round-robin
This algorithm applies only to object clustering. The algorithm improves on the round-robin algorithm by taking into account a pre-assigned weight for each server. Each server in the cluster is assigned a weight in the range (1-100) using the property weblogic.system.weight. This is a declaration of what proportion of the load the server will bear relative to other servers. If all servers have either the default weight (100) or the same weight, they will each bear an equal proportion of the load. If one server has weight 50 and all other servers have weight 100, the 50-weight server will bear half as much as any other server. This algorithm makes it possible to apply the advantages of the round-robin algorithm to clusters that are not homogeneous.
If you use the weight-based algorithm, you should spend some time to accurately determine the relative weights to assign to each server instance. Factors that could affect a server's assigned weight include:
If you change the specified weight of a server and reboot it, the new weighting information is propagated throughout the cluster via the clustered object stubs. See Cluster-wide JNDI naming service for more information.
Random
This algorithm applies only to object clustering. The algorithm chooses the next replica at random. This will tend to distribute calls evenly among the replicas. It is only recommended in a homogeneous cluster (i.e., where each server has the same power and the same services). The advantages are that it is simple and relatively cheap. The primary disadvantage is that there is a small cost to generating a random number on every request, and there is a slight probability that the load will not be evenly balanced over a small number or runs.
Parameter-based routing
It is also possible to gain finer grain control over load-balancing. Any clustered object can be assigned a CallRouter. This is a class that is called before each invocation with the parameters of the call. The CallRouter is free to examine the parameters and return the name server to which the call should be routed.
Fail-over
In order for a cluster to provide high availability it must be able to recover from service failures. With HTTP session state clustering, the WebLogic proxy plug-in handles failover transparently to the client. HTTP Session State Replication and How Servlet Clustering Works describe the fail-over procedure for replicated HTTP session states in more detail.
For clustered objects, failover is accomplished using the object's replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica.
Idempotent objects
With clustered objects, automatic fail-over occurs only in cases where there the object is idempotent. An object is idempotent if any method can be called multiple times with no different effect than calling the method once. This is always true for methods that have no permanent side-effects. Methods that do have side effects have to be written specially with idempotence in mind.
Consider a shopping cart service call addItem() that adds an item to a shopping cart. Suppose a client C invokes this call on a replica on server S1. After S1 receives the call, but before it successfully returns to C, S1 crashes. At this point the item has been added to the shopping cart, but the replica-aware stub has received an exception. If the stub were to retry the method on server S2, the item would be added a second time to the shopping cart. Because of this, replica-aware stubs will not, by default, attempt to retry a method that fails after the request is sent but before it returns. This behavior can be overridden by marking a service idempotent.
One approach to making addItem() idempotent is to add a sequence number as an extra parameter. Whenever a new item is added to the cart, it is accompanied by a sequence number. No item with the same sequence number can be added twice. If the addItem() call fails on S1, the replica-aware stub can now retry on S2. Since the retry sends the same sequence number, the service will only add the item if it has not already been added. Otherwise it will ignore the call.
HTTP Session State Replication
To support automatic failover for HTTP session states, WebLogic Server replicates the session state of a clustered servlet in memory. This process creates a primary session state, which resides on the WebLogic Server to which the client first connects and a secondary replica of the session state on another WebLogic Server instance in the cluster. The replica is always kept up-to-date so that it may be used if the server that hosts the servlet fails. The process of copying state from one instance to another is called in-memory replication.
To utilize in-memory replication for HTTP session states, you must configure a collection of web servers as a front-end to a WebLogic Server cluster that hosts the servlets. Supported web server software includes:
The HttpClusterServlet or proxy plug-in is required to communicate with the WebLogic Server cluster; the servlet or plug-in contains the logic required to load balance calls to the cluster, and to locate a replica of the HTTP session state in the event of a failure.
See How Servlet Clustering Works for more details on how WebLogic Server maintains clustered servlets and JSPs.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|