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 CommunicationIP 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:
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:
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:
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 :
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:
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," p. 1016 . |