W2K3 Network Failure Behavior

[John Toner [MVP]]

Has anyone else experienced this?

I'm testing W2K3 server cluster behavior, specifically messing around with
IP communications failures and expected behaviors. I've read the following
KB article about what I should expect in W2K3:

Network Failure Detection and Recovery in Windows Server 2003 Clusters
http://support.microsoft.com/default.aspx?scid=kb;EN-US;286342

Under normal operating conditions, I suspect that this article is accurate.
In my clusters, of course I'm seeing something slightly different. In my
cluster, I've setup a third NIC so that it is NOT enabled for cluster's use.
So my config looks like this on both nodes:

NIC 1 - Not enabled for Cluster
NIC 2 - All Cluster Communications
NIC 3 - Heartbeat Only Communication

I've got a 2-node, W2K3 cluster with 4 groups as follows:

Group1 - Owned by Node1
Group2 - Owned by Node1
Group3 - Owned by Node2
Cluster Group - Owned by Node2

According to this article, when I disable NICs 2 & 3 on Node2, I should
expect to see the new behavior in W2K3 where it finds no viable interfaces
for cluster's use and Node2 voluntarily drops out of Quorum arbitration, so
all groups should fail over to Node1, correct? Instead, I'm seeing the same
old W2K behavior where all groups are failing to the node that is the owner
of the quorum disk, Node2.

If I run the same test again but I disable all three NICs in this test, I DO
see this new behavior and all groups actually fail over to Node1. This leads
me to believe that cluster is using a NIC that it should not be using.

So, I guess I'd like to know why cluster is using a NIC that's not
designated for cluster use. Is this a bug, or is there something extra that
needs to be done in order to disable this NIC from cluster's use?

Regards,
John

[David Dion [MS]]

In this case, the KB article is not quite accurate. The criteria to
arbitrate or not to arbitrate for the quorum resource is not actually as
intelligent as described. Specifically, the cluster node does not
distinguish networks based on their role. It only checks to see if there is
any network connectivity at all.

The rationale is that this check needs to be as quick as possible, because
it blocks the quorum arbitration path (from a code-development perspective,
think "try to avoid locks"). Moreover, this check is a best-effort - any
time you have multiple simultaneous failures that cause all communication to
be lost between nodes, it may be impossible for the cluster to determine the
"right" answer quickly enough to implement it. In such cases, the cluster
defaults to the conservative approach (protect the disks, quorum owner
wins).

--
David Dion
Windows Server Group, Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
© 2004 Microsoft Corporation. All rights reserved.

"John Toner [MVP]" <jto...@mvps.DIE.SPAM.DIE.org> wrote in message
news:%23HmvGPt...@TK2MSFTNGP09.phx.gbl...

[John Toner [MVP]]

Thanks, that makes sense.

Regards,
John

"David Dion [MS]" <davi...@online.microsoft.com> wrote in message
news:##QY8e9BE...@TK2MSFTNGP09.phx.gbl...