Intergraph WebScale User Manual page 57

WebScale™
registry) to change its MAC address to the cluster's MAC address on all cluster
hosts. (Note that some low-end NIC's do not support changing their MAC
addresses.)
Multicast support has several advantages, such as eliminating the single network
interface card limitations and enabling WebScale to work properly with switches.
However, it requires that WebScale handle the resolution of the cluster IP address to its
associated multicast cluster MAC address within the Address Resolution Protocol
(ARP). WebScale automatically provides this capability. In rare cases, you may want
to disable WebScale's ARP support for multicast addresses. To do this, set the
MulticastARPEnabled registry parameter to 0. By default, this parameter is set to 1 and
is only used when multicast support is enabled.
The use of a multicast MAC address may not be supported by the ARP implementation
on some routers. If this problem arises, the cluster will not be reachable from outside the
local subnet, and it is necessary to create a static ARP entry within the router. Please
refer to the documentation for your router to determine how to create a static ARP entry.
Intergraph Computer Systems, Inc. has observed that some NIC drivers experience
increased CPU load percentages (by 5% or more depending on network traffic) when
handling multicast MAC addresses instead of unicast addresses. These NIC drivers do
not appear to use the advanced pipelining features available in the NDIS 4.0
specification. If your cluster hosts have unusually high CPU load percentages when
using WebScale's multicast support, you may want to disable this feature (using the
multicast enable button in the WebScale Setup dialog) to see if this is the source of the
problem.
Handling LAN Failures
The inadvertent subnetting of the cluster network due to a local area network failure
presents a special problem, and the WebScale cluster attempts to handle it as gracefully
as possible. If the cluster splits into multiple subnets that cannot communicate with
each other, each part will re-converge as an individual cluster ready to handle all of the
traffic for the cluster IP address. (This problem is distinct from a networking failure in
which a single host goes offline, in which case the host just leaves the cluster.) If both
subnets remain active (that is, they continue to handle incoming Internet requests), a
conflict arises when the networking failure is corrected and the cluster rejoins. In this
case, some outstanding connections may have to be closed in order to establish a
consistent state for the rejoined cluster. This situation occurs infrequently. It is far
more probable that only one subnet will have access to the Internet, in which case no
conflict arises because the other subnets do not provide service during the network
outage.
53
User's Guide