Communication

In order for there to be a cluster, the servers must communicate among themselves . Member servers use the TCP/IP communication facilities provided by their host operating system to communicate within the cluster. Communication occurs in one of two ways:

• Peer-to-peer sockets

• IP multicast

Peer-to-Peer Sockets

IP sockets are used for all nonbroadcast cluster communication. This includes:

• Transmitting HTTP session states between peer WebLogic Server instances

• Accessing clustered objects on a remote server in some multtier architectures

• RMI communication with the client programs

Because all the members of a cluster need to know how to talk to each other, it is not possible to create a cluster whose member servers rely on DHCP addresses. All servers participating in a cluster, including any non-BEA HTTP servers, must have fixed IP addresses. In addition, the IP address(es) that the outside world uses to request cluster connections and resources must also be fixed. Because the cluster servers rely on multicast communication, all member servers must be reachable via IP multicast, preferably on the same subnet.

You may be surprised to learn that the use of pure Java socket readers is discouraged for performance reasons. By default, each WebLogic server instance creates three socket-reader threads at startup. It is not at all uncommon to have more than three sockets open simultaneously . If so, there is a likely performance drain. The problem is that pure Java socket readers have no way of distinguishing between the active and inactive open sockets. They are forced to assume that all of the sockets are open and monitor them until some timeout threshold is reached. Even if there are enough socket-reader threads to service all the open sockets, this is not ideal, but if there are not, the performance worsens dramatically. The reader threads must poll each of the open sockets in turn , even the inactive ones. Obviously, having an active socket wait while one of the reader threads services an inactive socket is a suboptimal situation. Native TCP/IP mechanisms do not suffer from this limitation.

If you do choose to use native sockets, you should adjust the number of server threads to match the number of sockets that may be open simultaneously. Several factors affect the number of sockets in use:

• Because RMI access is multiplexed across a single socket, allocate one socket for RMI access.

• On each individual server, allocate one socket for each non clustered RMI object which the server may need to access.

The number of sockets is adjusted in the Servers folder in the left pane.

Cluster Address

The field labeled "Cluster Address" is a little misleading; clusters may or may not share a domain name or IP address. This field is where you define to the cluster who its members are and how they are to communicate with each other. It may contain either a single domain name that is configured within DNS to map to one or more servers in the cluster, an IP address, or some combination thereof. Individual entries should be separated with commas.

Once the method of network access is defined for each member of the cluster, you next must tell the cluster how to distribute requests among the servers. The requests are distributed to the individual machines in the cluster according to a load algorithm. There are three choices of load algorithm in BEA clusters:

Round Robin	Requests are routed to the individual machines in sequential order. Choose this algorithm when all the machines in the cluster have roughly equal resources.
Weight Based	Requests are routed to some machines in the cluster more than to others, based on a weight assigned to them.
Random	Requests are assigned to servers in the cluster in random order.

Round Robin or Random should be used when all servers are of roughly equal capability. Weight Based may be used to distribute the bulk of the load to the fastest server.