10-26 Using Clusters for Oracle WebLogic Server
Cluster Name=testcluster
ClusterAddress=wanclust MulticastAddress=wanclust-multi
MulticastTTL=3
10.2.18.3 Configure Multicast Buffer Size
If multicast storms occur because server instances in a cluster are not processing incoming messages on a timely basis, you can increase the size of multicast buffers.
For information on multicast storms, see Section 3.1.1.1.4, If Multicast Storms Occur.
TCPIP kernel parameters can be configured with the UNIX ndd utility. The udp_ max_buf parameter controls the size of send and receive buffers in bytes for a UDP
socket. The appropriate value for udp_max_buf varies from deployment to deployment. If you are experiencing multicast storms, increase the value of udp_max_
buf by 32K, and evaluate the effect of this change.
Do not change udp_max_buf unless necessary. Before changing udp_max_buf, read the Sun warning in the UDP Parameters with Additional Cautions section in the
Internet Protocol Suite Tunable Parameters chapter in Solaris Tunable Parameters Reference Manual at
http:download.oracle.comdocscdE19253-01817-0404chapter4-7 0index.html
.
10.2.18.4 Configure Multicast Data Encryption
WebLogic Server allows you to encrypt multicast messages that are sent between clusters. You can enable this option by checking Enable Multicast Data Encryption
from the Administration Console by navigating to the Environment Clusters cluster_name
Multicast node and selecting the Advanced options.
Only the data portion of the multicast message is encrypted. Information contained in the multicast header is not encrypted.
10.2.18.5 Configure Machine Names
Configure a machine name if:
■
Your cluster will span multiple machines, and multiple server instances will run on individual machines in the cluster, or
■
You plan to run Node Manager on a machine that does not host an Administration Server
WebLogic Server uses configured machine names to determine whether or not two server instances reside on the same physical hardware. Machine names are generally
used with machines that host multiple server instances. If you do not define machine names for such installations, each instance is treated as if it resides on separate
physical hardware. This can negatively affect the selection of server instances to host
Note: When relying upon the Multicast TTL value, it is important to
remember that within a clustered environment it is possible that timestamps across servers may not always be synchronized. This can
occur in replicated HTTP sessions and EJBs for example.
When the ClusterDebug flag is enabled, an error is printed to the server log when cluster members clocks are not synchronized.
Setting up WebLogic Clusters 10-27
secondary HTTP session state replicas, as described in Section 6.2.1.2, Using
Replication Groups.
10.2.18.6 Configuration Notes for Multi-Tier Architecture
If your cluster has a multi-tier architecture, see the configuration guidelines in Section 9.3.4, Configuration Considerations for Multi-Tier Architecture.
10.2.18.7 Enable URL Rewriting
In its default configuration, WebLogic Server uses client-side cookies to keep track of the primary and secondary server instance that host the clients servlet session state. If
client browsers have disabled cookie usage, WebLogic Server can also keep track of primary and secondary server instances using URL rewriting. With URL rewriting,
both locations of the client session state are embedded into the URLs passed between the client and proxy server. To support this feature, you must ensure that URL
rewriting is enabled on the WebLogic Server cluster. For instructions on how to enable URL rewriting, see Using URL Rewriting Instead of Cookies in Developing Web
Applications, Servlets, and JSPs for Oracle WebLogic Server.
10-28 Using Clusters for Oracle WebLogic Server
11
Clustering Best Practices 11-1
11
Clustering Best Practices
The following topics recommend design and deployment practices that maximize the scalability, reliability, and performance of applications hosted by a WebLogic Server
cluster:
■
Section 11.1, General Design Considerations
■
Section 11.2, Web Application Design Considerations
■
Section 11.3, EJB Design Considerations
■
Section 11.4, State Management in a Cluster
■
Section 11.5, Application Deployment Considerations
■
Section 11.6, Architecture Considerations
■
Section 11.7, Avoiding Problems
11.1 General Design Considerations
The following sections describe general design guidelines for clustered applications.
11.1.1 Strive for Simplicity
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.
11.1.2 Minimize Remote Calls
You improve performance and reduce the effects of failures by minimizing remote calls.
11.1.2.1 Session Facades Reduce 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.
11.1.2.2 Transfer Objects Reduce Remote Calls
EJBs consume significant system resources and network bandwidth to execute—they are unlikely to be the appropriate implementation for every object in an application.
