
	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

About clustering technology in WebLogic

Contents Introduction Clustering architectures Failover topologies Replication and clustering Persistence and clustering How clusters are connected WebLogic Clusters Architecture Clustered naming service Features for writing clustered applications Summary

Introduction

WebLogic Servers can operate in groups of interdependent servers, called WebLogic Clusters. WebLogic Servers in a cluster coordinate their actions to provide scalable, available, and fault-tolerant services.

Let's define those concepts. With WebLogic, "scalability" doesn't mean that the service speed increases to any one client, but it does provide faster service to more clients by balancing requests (load-balancing) across the cluster, and by adding more servers to the cluster as needed. And WebLogic's "fault tolerance" -- which is a requirement of high "availability" -- means that a WebLogic Server continues to provide services transparently, even in the face of such failures as:

"Fail-stop" crashes (a server stops operating entirely). Most clustering technology currently available is limited to recovery from a fail-stop crash.
"Byzantine failure" (a server behaves erroneously out of error or intruder malice).
Lost messages, due to an unreliable transport protocol such as UDP multicast.
Lost network connections, so that partitions of the cluster continue to function in isolation and interact with the environment until the complete cluster is reconnected.

Clustering also offers ease of maintenance, so that an administrator can selectively shutdown individual servers in a cluster to perform maintenance on each, while continuing to provide uninterrupted service to all clients.

Clustering architectures

There are three general categories of traditional clustering architectures, based on how each server in the cluster accesses memory and disks, and whether servers share a copy of the operating system and the I/O subsystem. These three categories are:

Shared-memory. In the shared-memory model, all servers in the cluster use the same primary memory, through which all traffic to the cluster is routed. The servers also share a single copy of the operating system and the I/O subsystem.
Shared-disk. In the shared-disk model, each server has its own memory but the cluster shares common disks. Since every server can concurrently access every disk, a distributed lock manager is required.
Shared-nothing. In the shared-nothing model, every server has its own memory and its own disks. Systems based on disk mirroring often use the shared-nothing model.

In addition, there is also the hybrid common-disk shared-nothing model, which uses a shared-nothing architecture on top of shared-disk hardware. Only one server at a time can access a disk, but if that server fails, another can provide uninterrupted service.

There are other common attributes that help define how a cluster operates.

In an active/active cluster, each server runs its own workload, and can assume responsibility for another cluster member in the event of a failure. Commonly, this functionality means that cluster servers are paired, although it may work more generally.
In a cluster that provides failover/failback, the workload of a failed server is automatically transferred to another server until the first server recovers, at which time its workload is automatically transferred back.
A cluster may use IP switchover to allow clients to find the replacement for a failed server with a minimum of service disruption. IP switchover causes a replacement server to change its IP address to match that of a failed server; it requires support for DHCP (Dynamic Host Configuration Protocol) and ARP (Address Resolution Protocol) to dynamically register an IP address change and then to update the physical network address translation caches of other systems attached to the cluster subnet.
Like switchover, IP impersonation allows clients to find a replacement server. Instead of dynamically assigning a new IP address, however, IP impersonation reroutes network traffic intended for the failed server to the replacement server.

Failover topologies

What happens when a server in the cluster fails -- how one server takes over for another -- varies according to the cluster model. There are several common failover topologies.

A common topology is one-to-one, in which a pair of tightly linked servers act for each other in the event of a failure. This topology is supported by the notion of the active/active cluster, where one server can automatically assume the workload for another in the event of a failure. IP switchover/IP impersonation is also a likely attribute of a one-to-one failover topology.

Another topology is one-to-many, in which any of several servers in the cluster may assume the workload for a failed server in the group. Also common is many-to-one, in which one server in a cluster may assume the workload for any number of servers in the cluster that fail.

No matter whether a server is in a cluster or stands alone, the server should be able to perform application restarts to automatically restart failed application process. Studies have shown that a large majority of server failures are caused by software, not hardware, faults, and that software problems cause as much as 4 times more downtime than hardware.

Replication and clustering

Replication, which mirrors data and/or state from one server to another, is essential for all clustering architectures. Replication facilitates both scalability and availability.

Although replication may be used internally in the cluster, the bulk of a replicating server's work is for client requests, which is either a query (read) or an update (write). The hardest part of replication is maintaining consistency across multiple copies of the data, which means tradeoffs between:

Number of replicas that must be kept consistent, which directly affects scalability.
Computational consistency, or the extent to which the replication affects the semantics of the computation. Being computationally consistent is a requirement for any distributed object model, whether or not it operates in a cluster or is replicated.
Quality of service, which includes response time, concurrency between clients, and overall throughput.

To reduce the number of replicas and still allow scaling, replication implementations often distinguish between primary (queries and updates) and secondary (query-only) servers. Primary servers are entrusted to be the authority on data, and an update operation is considered complete as soon as the primary server(s) acknowledges it; then updates are propagated to secondary servers.

There are a wide range of replication architectures. At one end of the design spectrum is the model in which each item of data is entrusted to a single primary server, which simplifies consistency. But this approach may not work well if many clients want to update data on the same primary server, or if updates take an unusually long time to propagate to the secondary server. This model is most appropriate when the ratio of queries to updates is high.

At the other end of the architecture spectrum are those models designed for a relatively low ratio of queries to updates. This is most commonly handled by using only primary servers.

Many applications have a relatively low query-to-update ratio but still require strong computational consistency. Of particular interest are implementations in which replicated information is kept in memory rather than on disk. In many clusters, portions of the state of a failed server can be recovered only if it was written to disk.

Replication may not include the internal state of an object. If the cluster doesn't support internal state replication, it can be used only to support scalability and availability of "stateless" services, that is, of services that do not require any knowledge of a client's previous work to continue to provide services to that client. Distributing workload for stateless services may be based on a variety of factors, including server load, server characteristics, application data partitioning, time of day, and request priority.

Replicating internal state is generally very expensive; most commonly, replication of internal state is to support availability. For example, a worldwide financial corporation organization might replicate its trading services from a cluster in a London office to a cluster in a Tokyo office as the sun rises in Asia and sets in Europe, automatically and transparently transferring all transactions from one office to another for 24-hour service. Or a worldwide service organization might replicate its call tracking application continuously to multiple clusters strategically located to provide faster access and to reduce long-distance network traffic. Some failsafe applications might replicate continuously to provide an emergency backup.

Most clustering products make data accessible for a replicated process only at the point at which it is written to disk; this holds for all cluster architectures except the shared-memory model. And except for the pure shared-nothing model, all cluster architectures rely on replicated processes to access the same disks, rather than actually copying data. Most commercially available clustering solutions support only process pairs, which consist of a primary that does all the work and a secondary that can take over in the event of a failure of the primary.

Some uses of replicated state of internal objects are clearly useful, particularly managing the transient bookkeeping information needed by the distributed system itself.

Persistence and clustering

Replication isn't necessarily the best -- or the only -- choice if a cluster must support scalability of stateful objects. Many industry leaders and analysts believe -- even if the current replication technology were not so immature -- that replication is overly complex and too inefficient to consider it as a real solution for keeping up with an object's state.

One alternatives to keeping in-memory replicas of objects with internal state, particularly user data, is to keep stateful components of a distributed system in an underlying persistent datastore, preferably a transaction-backed database.

How clusters are connected

Cluster communications are often via a high-speed, exclusive connection -- an interconnect or a system area network that is used only for cluster-related communications. Interconnects may be based on Fast Ethernet or FDDI, and there are even more specialized solutions that provide high bandwidth, low overhead, low latency, and more reliability. These may depend on special hardware.

Cluster communications support both internal management functions as well as the transport of user traffic. Some of the internal management functions include:

Heartbeats. Servers -- and sometimes the applications themselves if restarts are supported -- may send out regular heartbeats; the absence of the heartbeat triggers a failover or restart.
Replicated internal cluster data, so that servers in the cluster know what other cluster members are doing and whether recovery or replacement for a failing cluster member is necessary.
Application commands, for example to collect the results of a distributed computation, might be issued from one server to another.
Internal cluster commands from one server to another may initiate some action, such as going offline for maintenance.
Replicated application data may support scalability or availability.

WebLogic Clusters

With release 4.0, WebLogic provides clustering of RMI and EJB objects via a single replicated cluster-wide JNDI naming tree, and HTTP Servlets via a DNS round-robin, without code changes. All WebLogic services, including RMI and EJB, JDBC, Events, File services, Servlets, and others, will be supported in a clustered environment in future releases. WebLogic Clusters provide:

Scalability, by balancing the load of requests across the cluster for faster service to more clients.
High availability even during failure, (failover) by continuing to provide services even when an individual server fails.
Location transparency, so that resources distributed throughout the network are available by name in a consistent and transparent manner that does not require the client to know the location of the resource, or the connect to the local network machine that hosts that resource. This is particularly important for applets, which must load all files from a single source.

Future releases will include support for more administrative features to make tuning, configuration, and upgrades as easy as possible.

How WebLogic Clusters differ from traditional cluster models

WebLogic Clusters descend from a fundamentally different set of constraints than those that define more traditional cluster architectures. Traditional clustering models generally depend on homogeneous hardware, that is, a set of machines that all run the same operating system and may take advantage of proprietary protocols and communication mechanisms, like shared disks, multitailed disks, and high-speed interconnects. A hardware-homogeneous cluster may also offer a single-system image across traditional operating system services, so that clustering can be transparently exploited by a wide range of applications.

Because WebLogic is written completely in Java, it is also completely platform independent. You might run a WebLogic Cluster on an arbitrary mixture of HP, Sun, NT, and IBM servers. The great advantages of such a clustering model -- that the cluster is no longer constrained by its hardware -- also poses some challenges in building efficient networking and server-to-server communications. Although WebLogic Clusters must use commodity networking, network file systems, and database technology for server-to-server communications, it exploits these basics with a sophisticated, high-performance, multiple-personality architecture that delivers its standards-compliant services in an easy-to-use framework that runs, literally, anywhere.

Architecture

WebLogic Clusters are designed to work across a network topology that may include a variety of heterogeneous hardware and operating systems. Technically, such a cluster environment conforms to a shared-nothing architecture made up of a set of independent, networked machines. However, given that there is probably a database that is part of the WebLogic environment, in practice a WebLogic Cluster is likely to be operated as a shared-disk cluster architecture.

WebLogic clusters may host EJB, RMI, and servlet services. EJB and RMI have different expectations about server architecture, and WebLogic is modeled for both: a multitier architecture, required by transactional, server-side component services like EJB, and a peer-to-peer architecture, which is required by RMI.

In a multitiered architecture, clients handle direct interaction with end users, while application servers host the business logic and coordinate communications, synchronization, and transactions. Supporting these operations is one or more persistent storage devices to provide durable, transactional management of the underlying data. In a peer-to-peer architecture, however, each node may host and/or invoke objects, in various distributed computing models (including CORBA and DCOM). Peer-to-peer services on the client must be provided without adding heavyweight server machinery.

WebLogic is based on a lightweight message-passing kernel that supports both multitier and peer-to-peer functionality. WebLogic's kernel offers a Remote Java Virtual Machine (RJVM) abstraction to the layers above it. Messages pass from RJVM to RJVM using a variety of different protocols, including TCP, SSL, HTTP, and IIOP tunneling. The RJVMs create and maintain the sockets underlying these protocols and share them between all objects in the upper layers.

The RJVM also supports routing (forwarding messages through an intermediate server). One use of routing is session concentration, or acting as a gateway from frontend clients to backend servers. Another use of routing allows WebLogic to operate within the constraints of the applet security model, to traverse firewalls, etc.

Clustered naming service

Clustered services are advertised from within a cluster-wide replicated name tree. WebLogic implements the JavaSoft Enterprise standard for naming, JNDI (Java Naming and Directory Interface), to provide transparent naming and directory services. Access to clustered services is gained through a cluster-wide JNDI-compliant naming service, which is itself replicated across the cluster so there is no single point of failure. To offer a clustered service, a server advertises a provider at a particular node in the replicated naming tree. Each server adds a stub for the provider to a service pool stored at the node in its copy of the tree.

The client finds a service object for use by first obtaining an initial context. This context grants complete location transparency, so that the client does not need to know or care that resources it will use may be located on many servers across the cluster. In fact, if a server providing a service fails while it is servicing the client request, that request will be transparently redirected. The JNDI initial context also allows more servers to be added to the cluster to service clients in a completely transparent manner.

WebLogic Servers can dynamically join and leave a cluster with the WebLogic Service Advertisement Protocol (TSAP). TSAP supports the processes that keep track of which services are available from which Server at any moment in time; it also tracks and mediates conflicts of different services that may be offered at the same node in the cluster-wide JNDI naming tree. Because TSAP currently uses IP multicast, the hosts in a WebLogic Cluster should be in the same LAN.

A cluster is configured by a system administrator by setting certain properties. Each individual server is assigned a set of properties, including its cluster membership and which service providers it hosts. The members in the WebLogic Cluster exchange such information with each other as each server starts up, and as the information changes dynamically. There is no notion of "cluster startup," since servers may join and leave while the cluster continues to operate smoothly.

Features for writing clustered applications

WebLogic Clusters offer a variety of features that make writing clustered applications easy. Objects that are bound into the cluster-wide JNDI naming tree, even if they are not replicated, are available to any client using the cluster's services, so long as the WebLogic Server hosting that object is available.

In addition, stateless RMI and stateless EJB objects -- objects that can be grouped under the rubric "stateless services" -- may be bound so that each is automatically replicated in the logical cluster-wide JNDI naming tree, thus making a service highly available for clients even in the face of high load or failure. A stateless service can be performed by any instance in the cluster; there is no need for a continuing "conversation" to take place, that is, for the object instance to "remember" its history.

WebLogic automatically produces intelligent, failover stubs for stateless services that, when in use by a client application, provide completely transparent failover and load-balancing. WebLogic supports the notion of a load handler, which determines the process by which a stub's implementation is migrated around the cluster during heavy load or failure. A developer may use one of a set of default load handlers or may provide one specifically tailored for the application. How clustering occurs is controlled at deployment time by a service deployment descriptor that provides flexibility on how objects are replicated, maintained, accessed, and how and when failover occurs.

For HTTP Servlets, load-balancing, scalability, and failover are supported by a DNS round-robin or other network-based technologies. The session state of a servlet is cluster-wide, and any invocation of a servlet can be handled by any instance available in the cluster. By definition, servlets are a stateless service unless the servlet takes advantage of WebLogic's servlet session management feature. WebLogic's HTTP Servlets use the standard JavaSoft Session Management API to handle persistence for servlet sessions, which provides standards-based, non-proprietary solution for such applications as web shopping baskets and user-preference-driven web applications.

Stateful (session or entity) Enterprise JavaBeans may also be clustered, although it is necessary to rely on the client to protect its conversational state through a transaction and to make its state persistent through some sort of file- or database-based persistence mechanism. The bean home/factory may be bound into the cluster-wide JNDI naming tree so that multiple WebLogic Servers offer the service. Any call to create the bean will perform automatic load balancing and failover, and if more than one instance of a bean home is bound within the WebLogic Cluster, the underlying stub will make a load-balancing decision before the action bean creation takes place, with a pluggable strategy that chooses from among all the instances of the service available. The client application will always find service if it is available anywhere in the cluster.

Clustering of other "conversational services," like JDBC connection pools, will be offered in a future release.

Summary

This paper presents an overview of clustering technology, including a brief discussion of cluster architectures, failover topologies, and the use of replication and persistence in a clustered environment. In addition, this paper summarizes how WebLogic Clusters fit into the clustering universe and a general overview of the WebLogic Cluster model.