|
|
The following 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 11-2.
Use EJBs to model logical groupings of an information and associated business logic. See Transfer Objects Reduce Remote Calls.
|
Configure clusterable homes
|
|||
|
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.
|
Configure clusterable homes
Configure in-memory replication for EJBs
|
|||
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).
|
||||
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.
|
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.
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 following table lists key behaviors that you can configure for a cluster, and the associated method of configuration.
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. The cluster address can be assigned explicitly, or generated automatically by WebLogic Server for each request. For more information, see Cluster Address.
|
|
Use
home-call-router-class-name in weblogic-ejb-jar.xml to specify the name of a custom class to use for routing bean method calls for these types of beans. This class must implement weblogic.rmi.cluster.. For more information, see
The WebLogic Cluster API.
|
|
Use
stateless-bean-call-router-class-name in weblogic-ejb-jar.xml to specify the name of a custom class to use for routing stateless session bean method calls. This class must implement weblogic.rmi.cluster.CallRouter(). For more information, see
The WebLogic Cluster API.
|
|
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 11-3 summarizes how Java EE and WebLogic support different each of these categories of service.
| Note: | In Table 11-3, support for stateless and conversational services is described for two types of clients: |
Deploy clusterable objects to the cluster, rather than to individual Managed Servers in the cluster. For information and recommendations, see Deploying Applications to WebLogic Server.
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. |
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.”
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.
|