3-2 Using Clusters for Oracle WebLogic Server
3.1.1 Using IP Multicast for Backward Compatibility
IP multicast is a simple broadcast technology that enables multiple applications to subscribe to a given IP address and port number and listen for messages.
IP multicast broadcasts messages to applications, but it does not guarantee that messages are actually received. If an applications local multicast buffer is full, new
multicast messages cannot be written to the buffer and the application is not notified when messages are dropped. Because of this limitation, WebLogic Server instances
allow for the possibility that they may occasionally miss messages that were broadcast over IP multicast.
WebLogic Server uses IP multicast for all one-to-many communications among server instances in a cluster. This communication includes:
■
Cluster-wide JNDI updates—Each WebLogic Server instance in a cluster uses multicast to announce the availability of clustered objects that are deployed or
removed locally. Each server instance in the cluster monitors these announcements and updates its local JNDI tree to reflect current deployments of clustered objects.
For more details, see
Section 3.2, Cluster-Wide JNDI Naming Service.
■
Cluster heartbeats—Each WebLogic Server instance in a cluster uses multicast to broadcast regular heartbeat messages that advertise its availability. By
monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. Clustered server instances also monitor IP sockets as a
more immediate method of determining when a server instance has failed.
■
Clusters with many nodes—Multicast communication is the option of choice for clusters with many nodes.
3.1.1.1 Multicast and Cluster Configuration
Because multicast communications control critical functions related to detecting failures and maintaining the cluster-wide JNDI tree described in
Section 3.2, Cluster-Wide JNDI Naming Service
it is important that neither the cluster configuration nor the network topology interfere with multicast communications. The
sections that follow provide guidelines for avoiding problems with multicast communication in a cluster.
3.1.1.1.1 If Your Cluster Spans Multiple Subnets In a WAN In many deployments, clustered
server instances reside within a single subnet, ensuring multicast messages are reliably transmitted. However, you may want to distribute a WebLogic Server cluster across
multiple subnets in a Wide Area Network WAN to increase redundancy, or to distribute clustered server instances over a larger geographical area.
Note: When creating a new cluster, Oracle recommends that you use
unicast for messaging within a cluster. For WebLogic Server versions 9.2 and earlier, you must use multicast for communications between
clusters.
Note:
A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. The default multicast value used by
WebLogic Server is 239.192.0.0. You should not use any multicast address within the range x.0.0.1.
Communications In a Cluster 3-3
If you choose to distribute a cluster over a WAN or across multiple subnets, plan and configure your network topology to ensure that multicast messages are reliably
transmitted to all server instances in the cluster. Specifically, your network must meet the following requirements:
■
Full support of IP multicast packet propagation. In other words, all routers and other tunneling technologies must be configured to propagate multicast messages
to clustered server instances.
■
Network latency low enough to ensure that most multicast messages reach their final destination in 200 to 300 milliseconds.
■
Multicast Time-To-Live TTL value for the cluster high enough to ensure that routers do not discard multicast packets before they reach their final destination.
For instructions on setting the Multicast TTL parameter, see Section 10.2.18.2,
Configure Multicast Time-To-Live TTL.
3.1.1.1.2 Firewalls Can Break Multicast Communication Although it may be possible to
tunnel multicast traffic through a firewall, this practice is not recommended for WebLogic Server clusters. Treat each WebLogic Server cluster as a logical unit that
provides one or more distinct services to clients of a Web application. Do not split this logical unit between different security zones. Furthermore, any technologies that
potentially delay or interrupt IP traffic can disrupt a WebLogic Server cluster by generating false failures due to missed heartbeats.
3.1.1.1.3 Do Not Share the Cluster Multicast Address with Other Applications Although
