- The Motivations for Clustered Infrastructure Solutions: Scalability and High Availability
- Understanding WebLogic Clusters
- Understanding How WebLogic Servers Communicate within a Cluster
- Designing the Architecture of a WebLogic Cluster
- Creating and Configuring a WebLogic Cluster
- Implementing a Load-Balancing Mechanism for Your Clustered Servlets and JSPs
- Implementing a Failover Mechanism for Your Clustered Servlets and JSPs
- Clustering Enterprise JavaBeans
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding How WebLogic Servers Communicate within a Cluster
Network communication between WebLogic Servers within a cluster is serviced by IP Multicast for all one-to-many broadcast type communications and IP sockets for all peer-to-peer messages and data transfers. The following sections describe how WebLogic Server uses these communication types.
IP Multicast Communication
IP Multicast is a network bandwidth-conserving broadcasting technology that reduces network traffic by efficiently delivering a single stream of information to a group of servers, known as a multicast group. In the context of the WebLogic cluster, the cluster itself is the multicast group, and the group's membership or subscription to receive broadcast information is determined by the IP Multicast address specified for the cluster. For this reason, all WebLogic Server instances that constitute a WebLogic cluster share the same IP Multicast address. The Internet Assigned Numbers Authority (IANA), which controls the assignment of IP Multicast addresses, specifies an IP Multicast address must fall in the range of 224.0.0.0 to 239.255.255.255.
You specify the IP Multicast address when you create or configure a WebLogic cluster, as described later in this chapter.
Clustered WebLogic Servers use the IP Multicast address in conjunction with their TCP listen port to announce and listen for clusterwide communications, such as the following:
The availability of clustered objects that are either deployed or removed locally. This information is updated in the clusterwide JNDI tree, which is created and maintained locally by each WebLogic Server instance in a cluster. A clusterwide JNDI tree is similar to a single server instance JNDI tree, except that it also stores the services offered by clustered objects from other WebLogic Server instances in the cluster. Hence, through the combination of IP Multicast and JNDI, WebLogic Servers in a cluster are aware of the availability and location of all deployed clustered objects.
Cluster heartbeats, which are broadcast by each WebLogic Server instance in the cluster to uniquely advertise their availability to participate in load-balancing and failover operations. Each managed server in a WebLogic cluster broadcasts heartbeat messages approximately every 10 seconds and marks a peer clustered server as "failed" if it has not received a heartbeat from it within 30 seconds or three heartbeats. Upon marking a peer clustered server as "failed," a managed server will update its local JNDI tree to avoid any failover mechanisms from leveraging that server in any way.
Because IP Multicast communications are critical to the operation of a WebLogic cluster, BEA recommends the following guidelines for avoiding transmission and reception problems with Multicast communication in a cluster:
-
Avoid spanning a WebLogic cluster over multiple subnets. However, if this is a requirement for your clustering topology, ensure your network meets the following requirements:
-
The network has complete and reliable support for IP multicast packet propagation.
-
The network latency allows multicast messages to be received at their destination within 200 to 300 milliseconds.
-
The value of the Multicast Time to Live (TTL) parameter for the WebLogic cluster is high enough to guarantee network routers do not discard multicast packets before they reach their final destination.
Do not share the IP Multicast address for the WebLogic cluster with other applications in the same subnet.
Avoid distributing a cluster between different network security zones.
Ensure a firewall between clusters does not lead to false failures from missed clustered heartbeats.
NOTE
The Multicast TTL parameter specifies the number of network hops a multicast message will make before the packet can be discarded. You should test which TTL value ensures safe reception of multicast messages, especially in WAN or multiple subnet network scenarios.
IP Socket Communication (Peer-to-Peer)
In general, WebLogic Server uses IP sockets for all Remote Method Invocation (RMI) communications. However, in the context of a WebLogic cluster, WebLogic Server also uses IP sockets for the following types of inter-cluster communications:
Replicating HTTP session and session bean states between two clustered servers during a failover operation
Accessing nonclustered and clustered objects that reside on another clustered server
NOTE
WebLogic Server also uses the unexpected closure of an IP socket during the transmission of data as an indication that a server in the peer-to-peer communication has failed.
Because these activities are critical, the type of IP socket reader you use has to be performance based. WebLogic Server can be configured to use the following IP socket reader implementations:
The pure-Java socket reader implementation, where the socket reader threads continually poll all opened sockets to determine whether they contain data to be read, even if the sockets have no data to read.
The native IP socket reader provided by the host machine's operating system, where the socket reader threads target only active sockets that contain data to be read. Native socket readers never poll sockets because they are immediately notified when a socket needs to be serviced.
In general, for best performance, you should always use the native socket reader if possible. You should do so because, with the Java socket reader, you will always have to assess the potential socket usage of each managed server in a cluster based on peak usage of your cluster and then set the number of socket reader threads accordingly.
You can configure WebLogic Server easily to use the native socket reader thread implementation by following these steps in the Administration Console:
Select the Servers node in the left pane.
Select the WebLogic Server to configure.
In the right pane, select the Configuration, Tuning tab.
Check the Enable Native IO attribute and click Apply.
TIP
If you do use the pure-Java socket reader implementation, you can still improve the performance of socket communication by configuring the proper number of socket reader threads for each server instance. For best performance, the number of socket reader threads in WebLogic Server should equal the potential maximum number of opened sockets.
If you are using Java clients to access a WebLogic cluster, they will use the Java implementation of socket reader threads. In this case, to ensure high performance, you should configure enough socket reader threads in the Java Virtual Machine (JVM) that runs the client.
For a better understanding of the performance implications of the socket reader implementations available in WebLogic Server, see "Tuning the Core Server Performance: The Thread Pool."