|
|
|
|
| |
How do stubs work in a WebLogic Server cluster?
Clients that connect to a WebLogic Server cluster and look up a clustered object
obtain a replica-aware stub for the object. This stub contains the list of available server
instances that host implementations of the object. The stub also contains the load
balancing logic for distributing the load among its host servers.
What happens when a failure occurs and the stub cannot connect to a WebLogic
Server instance?
When the failure occurs, the stub removes the failed server instance from its list.
If there are no servers left in its list, the stubb uses DNS again to find a running server
and obtain a current list of running instances. Also, the stub periodically refreshes its
list of available server instances in the cluster; this allows the stub to take advantage of
new servers as they are added to the cluster.
How does a server know when another server is unavailable?
WebLogic Server uses two mechanisms to determine if a given server instance is
unavailable.
First, it uses a heartbeat mechanism with an internal timeout to monitor the status of instances in a cluster. The heartbeat mechanism is based on the cluster's multicast address. Once a given server instance receives a set number of heartbeats, it is dropped from the cluster.
Second, WebLogic Server monitors socket errors to determine when server instances become unavailable. For example, if server instance A has an open socket to server instance B, and the socket unexpectedly closes, server A assumes that server B is offline.
How are notifications made when a server is added to a cluster?
The WebLogic Server cluster broadcasts the availability of a new server instance
each time a new instance joins the cluster. Cluster-aware stubs also periodically
update their list of available server instances.
How do clients learn about new WebLogic Server instances?
Once a client has done a JNDI lookup and begins using an object reference, it finds
out about new server instances only after the cluster-aware stub has updated its list of
available servers.
How do clients handle DNS requests to failed servers?
If a server fails and DNS continues to send requests to the unavailable machine,
this can waste bandwidth. For a Java client application, this problem occurs only
during startup. WebLogic Server caches the DNS entries and removes the unavailable
ones, to prevent the client from accessing a failed server twice.
Failed servers can be more of a problem for browser-based clients, because they always use DNS. To avoid unnecessary DNS requests with browser-based clients, use a third-party load-balancer such as Resonate, BigIP, Alteon, and LocalDirector. These products mask multiple DNS addresses as a single address. They also provide more sophisticated load-balancing options than round-robin, and they keep track of failed servers to avoid routing unnecessary requests.
How many WebLogic Servers can I have on a multi-cpu machine?
There are many possible configurations and each has its own advantages and
disadvantages. For performance reasons, the number of WebLogic Servers should
always be equal to or less than the number of processors (CPUs) on the machine.
For example, if the machine has four processors, the maximum number of WebLogic Servers on that machine is four. Running more servers than the number of processors on a single-machine could lead to software failure.
Should I use a separate network for multicast in a cluster?
No. Multicast traffic is not heavy enough to require a separate network.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|