|
|
|
|
| |
WebLogic Frequently Asked Questions: Clustering
How do stubs work in a WebLogic Server cluster?
Initially, a client does a DNS lookup to determine what server to connect to for the
JNDI lookup. After it obtains an object reference, the cluster-aware stub for the object
contains a list of available servers in the cluster.
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, it 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 is 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.
Client performance during failover
After a server fails, won't DNS continue to send requests to the unavailable
machine? Doesn't this waste bandwidth? How can I address this problem from
client-side applications?
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, 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.
WebLogic Servers on multi-CPU machines
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.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|