I run a SQL2k/win2k adv active/passive 2 node cluster

If I manually failover the cluster both the SQL resource group and the CLUSTER resource group move to the passive node without incident. Recently we had a network hiccup that triggered the failover process. The result has the CLUSTER resource group (cluster name, ip, Quorum Drive and MSDTC) on one node and the SQL resource group (Log Drive, SQL Data, SQL name, SQL ip, SQL Server, Agent and Full Text Search) on the other node

The strange part is everything seems to be working. The only reason I noticed is because MSDTC seemed to not work, however connecting to the virtual server name and starting the service cleared the problem up. How can this be

What I want to know is: Is it acceptable to have the two resources groups controlled by different nodes in an active/passive setup? Also, can I manually failover the server that owns the CLUSTER resources to the node that owns the SQL resources without screwing up the quorum

Thanks
Moblex

Answers Inline
"moblex" <anonymous (AT) discussions (DOT) microsoft.com> wrote

we had a network hiccup that triggered the failover process. The result has
the CLUSTER resource group (cluster name, ip, Quorum Drive and MSDTC) on one
node and the SQL resource group (Log Drive, SQL Data, SQL name, SQL ip, SQL
Server, Agent and Full Text Search) on the other node.
cluster node. That is the essence of a cluster. The entire notion of a
resource group is to identify the elements that must be together for a group
to function. Therefore, any elements NOT in a resource group are not
required to be on the same physical node.

virtual server name and starting the service cleared the problem up. How
can this be?
instance of MSDTC instead of a local instance (Remember comclust.exe?
Running that executable flipped the switch from local to clustered). The
actual host node for the resource is irrelevant. As to why it didn't start,
maybe the network outage was long enough to prevent the resource from coming
back online. That has happened to me before.

manually failover the server that owns the CLUSTER resources to the node
that owns the SQL resources without screwing up the quorum?
Yes, and Yes. Again, the two resource groups are independant. Use the
'Move Group' option in the cluster tool. It is the preferred method for
controlled movement of groups.

Note: Here is another example where the 'Active/Passive' nomenclature is
confusing. 'Single-Instance' is the newer term. Any instance can live on
any node. The only time that node ownership is important is when performing
upgrades, and then all you need is who is the CURRENT owner.

You are Welcome.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

Geoff,
Thanks for the info, very helpful. The only question is how can I keep this from happening? The problem is now the event logs are split between the nodes. I know I can consolidate the two resource groups back to a single node, but that is a manual operation. The challenge is that as it stands Cluster event information is show on one machine, SQL information on another and Windows events split on both. More over, the MSDTC didn't keep working. It had to be manually started on the node that took control of the SQL resource group. You suggested that the outage might be long enough that MSDTC didn't come online, but it didn't fail over either. Since MSDTC is in the cluster group, the cluster IP should have tried to switch nodes when the SQL resource group (with its IP) did, right? The outage was quite brief by all accounts (I wasn't here). My concern is that if the point of a cluster is limited downtime, having to manually turn on MSDTC seems silly, since my apps require transaction support.

Any thoughts?
moblex

The following article shows how to enable cluster-wide logging of events:

HOW TO: Configure Event Log Replication in Windows 2000 Cluster Servers
http://support.microsoft.com/default...roduct=win2000

The timeout, retry, failure, recovery times, and failure rules are likely
different between the groups. Since SQL and Cluster groups have different
functions, this is correct. I would add a startup procedure to SQL that
emails you whenever the service starts. That way, you have a warning that
something happened and you may need to look at it. Imperfect, but better
than nothing.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com


"moblex" <anonymous (AT) discussions (DOT) microsoft.com> wrote

the nodes. I know I can consolidate the two resource groups back to a
single node, but that is a manual operation. The challenge is that as it
stands Cluster event information is show on one machine, SQL information on
another and Windows events split on both. More over, the MSDTC didn't keep
working. It had to be manually started on the node that took control of the
SQL resource group. You suggested that the outage might be long enough that
MSDTC didn't come online, but it didn't fail over either. Since MSDTC is in
the cluster group, the cluster IP should have tried to switch nodes when the
SQL resource group (with its IP) did, right? The outage was quite brief by
all accounts (I wasn't here). My concern is that if the point of a cluster
is limited downtime, having to manually turn on MSDTC seems silly, since my
apps require transaction support.