Do Not Share the Cluster Multicast Address with Other Applications Although If Multicast Storms Occur If server instances in a cluster do not process

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

multiple WebLogic Server clusters can share a single IP multicast address and port, other applications should not broadcast or subscribe to the multicast address and port used by your cluster or clusters. That is, if the machine or machines that host your cluster also host other applications that use multicast communications, make sure that those applications use a different multicast address and port than the cluster does. Sharing the cluster multicast address with other applications forces clustered server instances to process unnecessary messages, introducing overhead. Sharing a multicast address may also overload the IP multicast buffer and delay transmission of WebLogic Server heartbeat messages. Such delays can result in a WebLogic Server instance being marked as failed, simply because its heartbeat messages were not received in a timely manner. For these reasons, assign a dedicated multicast address for use by WebLogic Server clusters, and ensure that the address can support the broadcast traffic of all clusters that use the address.

3.1.1.1.4 If Multicast Storms Occur If server instances in a cluster do not process

incoming messages on a timely basis, increased network traffic, including negative acknowledgement NAK messages and heartbeat re-transmissions, can result. The repeated transmission of multicast packets on a network is referred to as a multicast storm, and can stress the network and attached stations, potentially causing end-stations to hang or fail. Increasing the size of the multicast buffers can improve the Note: Distributing a WebLogic Server cluster over a WAN may require network facilities in addition to the multicast requirements described above. For example, you may want to configure load balancing hardware to ensure that client requests are directed to server instances in the most efficient manner to avoid unnecessary network hops. 3-4 Using Clusters for Oracle WebLogic Server rate at which announcements are transmitted and received, and prevent multicast storms. See Section 10.2.18.3, Configure Multicast Buffer Size.

3.1.2 One-to-Many Communication Using Unicast