Using WebLogic Server Clusters
These topics recommend design and deployment practices that maximize the scalability, reliability, and performance of applications hosted by a WebLogic Server Cluster.
The following sections describe general design guidelines for clustered applications.
Distributed systems are complicated by nature. For a variety of reasons, make simplicity a primary design goal. Minimize "moving parts" and do not distribute algorithms across multiple objects.
You improve performance and reduce the effects of failures by minimizing remote calls.
Avoid accessing EJB entity beans from client or servlet code. Instead, use a session bean, referred to as a facade, to contain complex interactions and reduce calls from web applications to RMI objects. When a client application accesses an entity bean directly, each getter method is a remote call. A session facade bean can access the entity bean locally, collect the data in a structure, and return it by value.
EJBs consume significant system resources and network bandwidth to execute—they are unlikely to be the appropriate implementation for every object in an application.
Use EJBs to model logical groupings of an information and associated business logic. For example, use an EJB to model a logical subset of the line items on an invoice—for instance, items to which discounts, rebates, taxes, or other adjustments apply.
In contrast, an individual line item in an invoice is fine-grained—implementing it as an EJB wastes network resources. Implement objects that simply represents a set of data fields, which require only get
and set
functionality, as transfer objects.
Transfer objects (sometimes referred to as value objects or helper classes) are good for modeling entities that contain a group of attributes that are always accessed together. A transfer object is a serializable class within an EJB that groups related attributes, forming a composite value. This class is used as the return type of a remote business method.
Clients receive instances of this class by calling coarse-grained business methods, and then locally access the fine-grained values within the transfer object. Fetching multiple values in one server round-trip decreases network traffic and minimizes latency and server resource usage.
Avoid transactions that span multiple server instances. Distributed transactions issue remote calls and consume network bandwidth and overhead for resource coordination.
The following sections describe design considerations for clustered servlets and JSPs.
To enable automatic failover of servlets and JSPs, session state must persist in memory. For instructions to configure in-memory replication for HTTP session states, see Requirements for HTTP Session State Replication and Configure In-Memory HTTP Replication.
Failures or impatient users can result in duplicate servlet requests. Design servlets to tolerate duplicate requests.
See Programming Considerations for Clustered Servlets and JSPs.
The following sections describe design considerations for clustered RMI objects.
It is not always possible to determine when a server instance failed with respect to the work it was doing at the time of failure. For instance, if a server instance fails after handling a client request but before returning the response, there is no way to tell that the request was handled. A user that does not get a response retries, resulting in an additional request.
Failover for RMI objects requires that methods be idempotent. An idempotent method is one that can be repeated with no negative side-effects.
The following table summarizes usage and configuration guidelines for EJBs. For a list of configurable cluster behaviors, see Table 8-2 on page 6.
Table 8-1 EJB Types and Guidelines
Use EJBs to model logical groupings of an information and associated business logic. See Transfer Objects Reduce Remote Calls. |
Configure clusterable homes |
|
Recommended for high volume, heavy-write transactions. Remove stateful session beans when finished to minimize EJB container overhead. A stateful session bean instance is associated with a particular client, and remains in the container until explicitly removed by the client, or removed by the container when it times out. Meanwhile, the container may passivate inactive instances to disk. This consumes overhead and can affect performance. Note: Although unlikely, the current state of a stateful session bean can be lost. For example, if a client commits a transaction involving the bean and there is a failure of the primary server before the state change is replicated, the client will fail over to the previously-stored state of the bean. If it is critical to preserve bean state in all possible failover scenarios, use an entity EJB rather than a stateful session EJB. |
Configure clusterable homes Configure in-memory replication for EJBs |
|
Scale better than stateful session beans which are instantiated on a per client basis, and can multiply and consume resources rapidly. When a home creates a stateless bean, it returns a replica-aware stub that can route to any server where the bean is deployed. Because a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean. |
Configure clusterable homes. Configure Cluster Address. Configure methods to be idempotence to support failover during method calls. (Failover is default behavior if failure occurs between method calls.or if the method fails to connect to a server). The methods on stateless session bean homes are automatically set to be idempotent. It is not necessary to explicitly specify them as idempotent. |
|
Recommended whenever stale data is tolerable—suitable for product catalogs and the majority of content within many applications. Reads are performed against a local cache that is invalided on a timer basis. Read-only entities perform three to four times faster than transactional entities. Note: A client can successfully call setter methods on a read-only entity bean, however the data will never be moved into the persistent store. |
Configure clusterable homes. Configure Cluster Address. |
|
Best suited for shared persistent data that is not subject to heavy request and update.If the access/update load is high, consider session beans and JDBC. Recommended for applications that require high data consistency, for instance, customer account maintenance. All reads and writes are performed against the database. Use the For read-mostly applications, characterized by frequent reads, and occasional updates (for instance, a catalog)—a combination of read-only and read-write beans that extend the read-only beans is suitable. The read-only bean provides fast, weakly consistent reads, while the read-write bean provides strongly consistent writes. |
Configure clusterable homes Configure methods to be idempotence to support failover during method calls. (Failover is default behavior if failure occurs between method calls.or if the method fails to connect to a server). The methods on read-only entity beans are automatically set to be idempotent. |
The following table lists key behaviors that you can configure for a cluster, and the associated method of configuration.
Table 8-2 Cluster-Related Configuration Options
At bean level, set At method level, set |
|
The cluster address identifies the Managed Servers in the cluster. The cluster address is used in entity and stateless beans to construct the host name portion of URLs. If the cluster address is not set, EJB handles may not work properly. It is defined in the |
|
Set If |
|
Load balancing algorithm for entity bean and entity EJBs homes |
|
Custom load balancing for entity EJBs, stateful session EJBs, and stateless session |
Use |
Use |
|
Set |
|
Use |
|
The WebLogic Server Machine resource associates server instances with the computer on which it runs. For more information, see Configure Machine Names. |
|
Replication groups allow you to control where HTTP session states are replicated. For more information, see Configure Replication Groups |
Different services in a WebLogic Server cluster provide varying types and degrees of state management. This list defines four categories of service that are distinguished by how they maintain state in memory or persistent storage:
Table 8-3 summarizes how J2EE and WebLogic support different each of these categories of service.
Note: In Table 8-3, support for stateless and conversational services is described for two types of clients:
Table 8-3 J2EE and WebLogic Support for Service Types
All J2EE APIs are either stateless or may be implemented in a stateless manner by writing state information to a shared persistent store between invocations. J2EE does not specify a standard for load balancing and failover. For loosely coupled clients, load balancing must be must be performed by external IP-based mechanisms |
WebLogic Server increases the availability of stateless services by deploying multiple instances of the service to a cluster. For loosely-coupled clients of a stateless service, WebLogic Server supports external load balancing solutions, and provides proxy plug-ins for session failover and load balancing. |
|
These J2EE APIs support tightly coupled access to stateless services: |
WebLogic Server increases the availability of stateless services by deploying multiple instances of the service to a cluster. For tightly-coupled clients of a stateless service, WebLogic Server supports load balancing and failover in its RMI implementation. The WebLogic Server replica-aware stub for a clustered RMI object lists the server instances in the cluster that currently offer the service, and the configured load balancing algorithm for the object. WebLogic Server uses the stub to make load balancing and failover decisions. |
|
These J2EE APIs support loosely-coupled access to conversational services: J2EE does not specify a standard for load balancing and failover. Load balancing can be accomplished with external IP-based mechanisms or application server code in the presentation tier. Because protocols for conversations services are stateless, load balancing should occur only when the session is created. Subsequent requests should stick to the selected server. |
WebLogic Server increases the reliability of sessions with:
|
|
The J2EE standard provides EJB stateful session beans to support conversational services with tightly-coupled clients. |
WebLogic Server increases the availability and reliability of stateful session beans with these features:
For more information, see Stateful Session Beans. |
|
J2EE does not specify a standard for cached services. Entity beans with Bean-Managed-Persistence can implement custom caches. |
Weblogic Server supports caching of: For a list of WebLogic features that increase scalability and reliability of stateful session beans, see description in the previous row. Weblogic Server supports these caching features for entity beans.
Consistency between the cache and the external data store can be increased by: WebLogic Server supports the "read-mostly pattern" by combining read-only and read-write EJBs. WebLogic Server provides custom JSP tags to support caching at fragment or page level. |
|
J2EE APIs used to implement singleton services include: Scalability can be increased by "partitioning" the service into multiple instances, each of which handles a different slice of the backing data and its associated requests |
WLS features for increasing the availability of singleton services include: |
Deploy clusterable objects to the cluster, rather than to individual Managed Servers in the cluster. For information and recommendations, see:
For information about alternative cluster architectures, load balancing options, and security options, see Cluster Architectures.
The following sections present considerations to keep in mind when planning and configuring a cluster.
For guidelines for how to name and address server instances in cluster, see Identify Names and Addresses.
To start up WebLogic Server instances that participate in a cluster, each Managed Server must be able to connect to the Administration Server that manages configuration information for the domain that contains the cluster. For security purposes, the Administration Server should reside within the same DMZ as the WebLogic Server cluster.
The Administration Server maintains the configuration information for all server instances that participate in the cluster. The config.xml
file that resides on the Administration Server contains configuration data for all clustered and non-clustered servers in the Administration Server's domain. You do not create a separate configuration file for each server in the cluster.
The Administration Server must be available in order for clustered WebLogic Server instances to start up. Note, however, that once a cluster is running, a failure of the Administration Server does not affect ongoing cluster operation.
The Administration Server should not participate in a cluster. The Administration Server should be dedicated to the process of administering servers: maintaining configuration data, starting and shutting down servers, and deploying and undeploying applications. If the Administration Server also handles client requests, there is a risk of delays in accomplishing administration tasks.
There is no benefit in clustering an Administration Server; the administrative objects are not clusterable, and will not failover to another cluster member if the administrative server fails. Deploying applications on an Administration Server can reduce the stability of the server and the administrative functions it provides. If an application you deploy on the Administration Server behaves unexpectedly, it could interrupt operation of the Administration Server.
For these reasons, make sure that the Administration Server's IP address is not included in the cluster-wide DNS name.
If your configuration includes a firewall, locate your proxy server or load-balancer in your DMZ, and the cluster, both Web and EJB containers, behind the firewall. Web containers in DMZ are not recommended. See Basic Firewall for Proxy Architectures.
If you place a firewall between the servlet cluster and object cluster in a multi-tier architecture, bind all servers in the object cluster to public DNS names, rather than IP addresses. Binding those servers with IP addresses can cause address translation problems and prevent the servlet cluster from accessing individual server instances.
If the internal and external DNS names of a WebLogic Server instance are not identical, use the ExternalDNSName
attribute for the server instance to define the server's external DNS name. Outside the firewall the ExternalDNSName
should translate to external IP address of the server. Set this attribute in the Administration Console using the Server—>Configuration—>General tab. See Server—>Configuration—>General in Administration Console Online Help.
In any cluster architecture that utilizes one or more firewalls, it is critical to identify all WebLogic Server instances using publicly-available DNS names, rather than IP addresses. Using DNS names avoids problems associated with address translation policies used to mask internal IP addresses from untrusted clients.
Notes: Use of ExternalDNSName
is required for configurations in which a firewall is performing Network Address Translation, unless clients are accessing WebLogic Server using t3 and the default channel. For instance, ExternalDNSName
is required for configurations in which a firewall is performing Network Address Translation, and clients are accessing WebLogic Server using HTTP via a proxy plug-in.
Do not specify an IP address for ExternalDNSName.
ExternalDNSName
must be an actual domain name.
The following figure describes the potential problem with using IP addresses to identify WebLogic Server instances. In this figure, the firewall translates external IP requests for the subnet "xxx" to internal IP addresses having the subnet "yyy."
Figure 8-1 Translation Errors Can Occur When Servers are Identified by IP Addresses
The following steps describe the connection process and potential point of failure:
If there was no translation between external and internal IP addresses, the firewall would pose no problems to the client in the above scenario. However, most security policies involve hiding (and denying access to) internal IP addresses.
The architecture of your cluster will influence the capacity of your system. Before deploying applications for production use, evaluate performance to determine if and where you may need to add servers or server hardware to support real-world client loads. Testing software such as LoadRunner from Mercury Interactive allows you to simulate heavy client usage.