2 Understanding WebLogic Server Clustering

This chapter provides a brief introduction to Oracle WebLogic Server clusters.

This chapter includes the following sections:

• What Is a WebLogic Server Cluster?
  A WebLogic Server cluster consists of multiple WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability.
• What Are Dynamic Clusters?
  Dynamic clusters consist of server instances that can be dynamically scaled up to meet the resource needs of your application. A dynamic cluster uses a single server template to define a configuration for a specified number of generated (dynamic) server instances.
• How Does a Cluster Relate to a Domain?
  A cluster is part of a particular WebLogic Server domain.
• What Are the Benefits of Clustering?
  A WebLogic Server cluster provides the benefits of scalability and high-availability.
• What Are the Key Capabilities of a Cluster?
  The key clustering capabilities that enable scalability and high availability are application failover, server migration, and load balancing.
• What Types of Objects Can Be Clustered?
  A clustered application or application component is one that is available on multiple WebLogic Server instances in a cluster. Failover and load balancing is available for the clustered object. Deploy objects homogeneously to every server instance in your cluster to simplify cluster administration, maintenance, and troubleshooting. Learn the types of objects that can be clustered in a WebLogic Server deployment.
• What Types of Objects Cannot Be Clustered?
  Certain APIs and internal services cannot be clustered in WebLogic Server.

What Is a WebLogic Server Cluster?

A WebLogic Server cluster consists of multiple WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability.

A cluster appears to clients as a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or a different machines.

You can increase a cluster's capacity by either of the following procedures:

• By adding additional server instances to the cluster on an existing machine.
• By adding machines to the cluster to host the incremental server instances.

Each server instance in a cluster must run the same version of WebLogic Server.

What Are Dynamic Clusters?

Dynamic clusters consist of server instances that can be dynamically scaled up to meet the resource needs of your application. A dynamic cluster uses a single server template to define a configuration for a specified number of generated (dynamic) server instances.

When you create a dynamic cluster, the dynamic servers are preconfigured and automatically generated for you, enabling you to easily scale up the number of server instances in your dynamic cluster when you need additional server capacity. You can start the dynamic servers without manual configuration and add them to the cluster.

See Dynamic Clusters and Create dynamic clusters in the Oracle WebLogic Server Administration Console Online Help.

How Does a Cluster Relate to a Domain?

A cluster is part of a particular WebLogic Server domain.

A domain is an interrelated set of WebLogic Server resources that are managed as a unit. It includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances. It can include multiple clusters. It also contains the application components deployed in the domain, and the resources and services required by those application components and the server instances in the domain. Examples of the resources and services used by applications and server instances include machine definitions, optional network channels, connectors, and startup classes.

You can use a variety of criteria for organizing WebLogic Server instances into domains. For instance, you might choose to allocate resources to multiple domains based on logical divisions of the hosted application, geographical considerations, or the number or complexity of the resources under management. See Understanding Domain Configuration for Oracle WebLogic Server.

In each domain, one WebLogic Server instance acts as the Administration Server—the server instance which configures, manages, and monitors all other server instances and resources in the domain. Each Administration Server manages one domain only. If a domain contains multiple clusters, each cluster in the domain has the same Administration Server.

All server instances in a cluster must reside in the same domain; you cannot "split" a cluster over multiple domains. Similarly, you cannot share a configured resource or subsystem between domains.

Clustered WebLogic Server instances behave similarly to non-clustered instances, except that they provide failover and load balancing. The process and tools used to configure clustered WebLogic Server instances are the same as those used to configure non-clustered instances. However, to achieve the load balancing and failover benefits that clustering enables, you must adhere to certain guidelines for cluster configuration.

To understand how the failover and load balancing mechanisms used in WebLogic Server relate to particular configuration options, see Load Balancing in a Cluster, and Failover and Replication in a Cluster.

Detailed configuration recommendations are included throughout the instructions in Setting up WebLogic Clusters.

What Are the Benefits of Clustering?

A WebLogic Server cluster provides the benefits of scalability and high-availability.

• Scalability

  The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service. The application continues to run without impact on clients and end users.

• High-Availability

  In a WebLogic Server cluster, application processing can continue when a server instance fails. You can cluster application components by deploying them on multiple server instances in the cluster. So, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.

The choice to cluster WebLogic Server instances is transparent to application developers and clients. However, understanding the technical infrastructure that enables clustering will help programmers and administrators maximize the scalability and availability of their applications.

What Are the Key Capabilities of a Cluster?

The key clustering capabilities that enable scalability and high availability are application failover, server migration, and load balancing.

• Application Failover

  Failover means that when an application component (typically referred to as an "object" in the following sections) doing a particular "job"—some set of processing tasks—becomes unavailable for any reason, a copy of the failed object finishes the job.

  For the new object to take over the failed object:

  • There must be a copy of the failed object available to take over the job.

  • There must be information, available to other objects and the program that manages failover, defining the location and operational status of all objects—so that it can be determined that the first object failed before finishing its job.

  • There must be information, available to other objects and the program that manages failover, about the progress of jobs in process—so that an object taking over an interrupted job knows how much of the job was completed before the first object failed, for example, what data has been changed, and what steps in the process were completed.

  WebLogic Server uses standards-based communication techniques and facilities— including IP sockets and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine that an object stopped before finishing its job, and where there is a copy of the object to complete the job that was interrupted.

  Note:

  For backward compatibility with previous versions, WebLogic Server allows you to use multicast for communications between clusters.

  Information about what has been done on a job is called state. WebLogic Server maintains information about state using techniques called session replication and replica-aware stubs. When a particular object unexpectedly stops doing its job, replication techniques enable a copy of the object to pick up where the failed object stopped and finish the job.

• Server Migration

  WebLogic Server supports automatic and manual migration of a clustered server instance from one machine to another. A Managed Server that can be migrated is referred to as a migratable server. This feature is designed for environments with requirements for high availability. The server migration capability is useful for:

  • Ensuring uninterrupted availability of singleton services—services that must run on only a single server instance at any given time, such as Java Messaging Service (JMS) and the Java Transaction API (JTA) transaction recovery system, when the hosting server instance fails. A Managed Server configured for automatic migration will be automatically migrated to another machine in the event of failure.

  • Easing the process of relocating a Managed Server and all the services it hosts, as part of a planned system administration process. To initiate the migration of a Managed Server, you can use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server.

  The server migration process relocates a Managed Server in its entirety—including IP addresses and hosted applications—to one of a predefined set of available host machines.

• Load Balancing

  Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment.

  For load balancing to occur:

  • There must be multiple copies of an object that can do a particular job.

  • WebLogic Server allows objects to be clustered—deployed on multiple server instances—so that there are alternative objects to do the same job. WebLogic Server shares and maintains the availability and location of deployed objects using unicast, IP sockets, and JNDI.

    Note:

    For backward compatibility with previous versions, WebLogic Server also allows you to use multicast for communications between clusters.

    Information about the location and operational status of all objects must be available.

A detailed discussion of how communications and replication techniques are employed by WebLogic Server is provided in Communications In a Cluster.

What Types of Objects Can Be Clustered?

A clustered application or application component is one that is available on multiple WebLogic Server instances in a cluster. Failover and load balancing is available for the clustered object. Deploy objects homogeneously to every server instance in your cluster to simplify cluster administration, maintenance, and troubleshooting. Learn the types of objects that can be clustered in a WebLogic Server deployment.

Web applications can consist of different types of objects, including Enterprise Java Beans (EJBs), servlets, and Java Server Pages (JSPs). Each object type has a unique set of behaviors related to control, invocation, and how it functions within an application. For this reason, the methods that WebLogic Server uses to support clustering—and hence to provide load balancing and failover—can vary for different types of objects. The following types of objects can be clustered in a WebLogic Server deployment:

• Servlets

• JSPs

• EJBs

• Remote Method Invocation (RMI) objects

• JMS destinations

• Batch applications

Different object types can have certain behaviors in common. When this is the case, the clustering support and implementation considerations for those similar object types may be same. In the following sections, explanations and instructions for the following types of objects are generally combined:

• Servlets and JSPs

• EJBs and RMI objects

The following sections briefly describe the clustering, failover, and load balancing support that WebLogic Server provides for different types of objects.

• Servlets and JSPs
  
• EJBs and RMI Objects
  
• JMS and Clustering
  
• Batch Applications
  

Servlets and JSPs

WebLogic Server provides clustering support for servlets and JSPs by replicating the HTTP session state of clients that access clustered servlets and JSPs. WebLogic Server can maintain HTTP session states in memory, a file system, or a database.

To enable automatic failover of servlets and JSPs, session state must persist in memory. For information about how failover works for servlets and JSPs, and for related requirements and programming considerations, see HTTP Session State Replication.

You can balance the servlet and JSP load across a cluster using a WebLogic Server proxy plug-in or external load balancing hardware. WebLogic Server proxy plug-ins perform round-robin load balancing. External load balancers typically support a variety of session load balancing mechanisms. See Load Balancing for Servlets and JSPs.

EJBs and RMI Objects

Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the object compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster.

Failover for EJBs and RMI objects 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. To understand failover support for different types of objects, see Replication and Failover for EJBs and RMIs.

WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity. By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the WebLogic Server Administration Console. The method you select is maintained within the replica-aware stub obtained for clustered objects. See Load Balancing for EJBs and RMI Objects for details.

JMS and Clustering

The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to destinations from any WebLogic Server instance in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, the same JMS topic or queue is still managed separately by each WebLogic Server instance in the cluster.

Load balancing is supported for JMS. To enable load balancing, you must configure targets for JMS servers. For more information about load balancing and JMS components, see Load Balancing for JMS. For instructions on setting up clustered JMS, see Configure Migratable Targets for Pinned Services, and Deploying_ Activating_ and Migrating Migratable Services.

Batch Applications

WebLogic Server supports the ability to deploy batch applications in a cluster, and also the ability to have an individual batch runtime instance running on each Managed Server in that cluster. Scaling up the number of servers in the cluster will generally increase the overall batch processing capability of the application deployed to the cluster. However, the processing of any individual batch job is executed on a single managed server within the cluster and cannot be distributed across managed servers in the cluster.

To deploy and run batch applications in a cluster, note the following:

• An individual batch runtime must be configured on each Managed Server instance in the cluster. When a batch job has been started on a Managed Server instance, the job runs on that instance to completion. See Use of Multiple Batch Runtime Instances in Administering Server Environments for Oracle WebLogic Server for important considerations regarding the implications of this behavior on load balancing.

• The batch runtime reference implementation (RI) uses a database to model the job repository, which contains details about the past and current jobs. Configuring the job repository to use it in a clustered environment requires the following:

  1. Configuring a data source to access the database that holds the job repository

  2. Targeting the preceding data source to the cluster

  3. Configuring each batch runtime instance to use that data source

  For details about configuring the job repository, and configuring the data source that is used by both the job repository and a batch runtime instance, see Configuring the Batch Runtime to Use a Dedicated Database in Administering Server Environments for Oracle WebLogic Server.

• State replication is not available in the batch runtime, so conventional failover is not available. Consequently, a failed batch job cannot be resumed on a backup copy that is running on a different Managed Server instance. However, if all batch runtime instances in a cluster point to the same job repository, and the data source for the database that contains the job repository is also targeted to the cluster. Any batch job that fails on a Managed Server instance can be queried and restarted on any other Managed Server instance in that cluster.

What Types of Objects Cannot Be Clustered?

Certain APIs and internal services cannot be clustered in WebLogic Server.

• File services including file shares

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.