When you create a domain with multiple Managed Servers, all those servers function independently of each other. A cluster, on the other hand, is a group of WebLogic Server instances that work as a single instance from the point of view of a client. The reason you use a cluster is to increase scalability and reliability by taking advantage of a cluster’s workload balancing and failover capabilities that you can’t have with a single server instance. You manage clustered server instances the same as any nonclustered instance. Of course, to avail yourself of the load-balancing and failover capabilities of a cluster, you must configure a few other things as well.
You use clusters to achieve two important goals: high availability and scalability. High availability includes support for both the failover of applications as well as the failure of a server or an essential service such as a JMS service. A cluster maintains copies of application components (objects), so if a component becomes unavailable, the cluster uses the failed object’s copy to complete the processing of the task. WebLogic Server uses session replication to fail over servlets and JSP. Similarly, it uses replica-aware stubs to maintain information about the state of application components such as EJBs and RMIs. Replication allows the copies of the failed objects to finish the job when an application component fails. WebLogic Server also provides for both automatic and manual migration of an entire clustered server instance to a different machine following a server failure. You can use this capability manually for administrative purposes as well.
Clients that connect to a WebLogic Server cluster and look up a clustered object obtain a replica-aware stub for the object. This stub contains the list of available server instances that host implementations of the object. The stub also contains the load-balancing logic for distributing the load among its host servers.