Re: Failover cluster question/problem

Ok fine, I was going for humor on the hidden documentation, but quite
honestly, I have YET to find something specifically stating some real
justifiable reason to NOT put things into the default cluster group. I've
installed/uninstalled clusters (failover thereof) more times than i care to
recall. Both on 2000 enterprise and 2003. So, the lecture on reading up on
clusters is a bit mute. I didn't come here in ignorance and I didn't post
specifically looking for anything more than justification to the documented
"best practice", "recommended", "you shouldn't do this" types of info I could
find.

Here's the whole scenario. The clusters that run my particular software
will be dedicated machines to ONLY run my software. They aren't to be used
for additional things, else no support. One application runs on Objectivitiy
DB and the other runs on SQL (don't ask that's the way it is). Both apps
share a licenseing third party app called SentinelLM. Since our customer
wants the multiple groups (away from what we've been doing, since our
applications are NOT cluster aware), we're trying it. Everything installs
just dandy as I would expect, since both resource groups are on the same
node. When we failover the resource group with our apps in it, that's when
things start to go wrong. First, sentinel doesn't recognize the licenses.
Well, it sorta does sorta doesnt. The apps on the other hand can NOT get
licenses from sentinel. So, they fail to start obviously. The first app
that uses objectivitiy has a federated database name implanted in it. We
were smart enough to realize that if we are on a cluster then the name in the
database file should NOT be the local nodes, but the clustername. Well, when
the clustername is not on the same node as the application it defaults to the
node name and then doesn't think the application is a database server. So,
we changed a few things, namely adding an additional name and ip. got the
federated db to recognize THAT as our DB name and then some things seemed to
work. Problem is, we're using GetClusterInformation API calls that are
returning the top level cluster name (the one made when we created the
cluster) and NOT the one local to the resource group. This is a problem.
and one that we can't nail down at all. As for application #2, on SQL. We
had to change the ODBC settings for application to point to the correct 2nd
cluster name so that it can start up properly. And we're cheating the
licenseing stuff by adding an evironment variable LSFORCEHOST to point the
sentinel services to the second cluster name. this isn't a perfect fix to
the problem, but atm it's the only way around this.

So, basically, i'm looking for a reason to invest alot of time and effort
into fixing the GetClusterInformation API call that we're currnetly using to
make this stuff work properly. I'm also trying to figure out how to justify
the seemingly WASTEFUL use of addtional name space and IPs for the cluster.
For EVERY group i create i have to use another IP and name? that's
seemeingly very wasteful. AS a matter of fact, the customer i'm dealing with
wants MSDTC in it's own resource group. So, now i have 2 nodes worth of IPs
and names. 3 groups worth of IPs and names AND SQL IP and name. It's
practically it's own forest.

Thanks for the reference point on the clustering web addy, but honestly, so
far I haven't found any information there that I haven't already been reading
elsewhere, setting up and configuring a cluster, best practices, the white
paper, the help files, etc. Yet, I'm still lacking with a good reason to NOT
put them all in one resource group, except that it's good practice. Or it's
recommneded not too. Sure, I want an available cluster, but I also want my
apps to work on it. Seems like the best way to achieve both is to have them
in one group right now and ignore the warning message during the SQL install
about installing to the same location that the quorum drive exists.

Also, I'd like to understand how having multiple resource groups makes this
into an active/passive cluster. Since it is indeed possible to have resource
groups running on different nodes at the same time. That's not
active/passive at all to me. no, it's not load balancing either but now you
have the possibility of two points of failure instead of one.

.

Relevant Pages

  • Re: Time of failover of Microsoft SQL 2000
    ... Resource Group "Cluster Group". ... - NODE01 17:25:30 The Cluster Service brought the Resource Group ... "Cluster Group" online. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Failover cluster question/problem
    ... to the MVPs in here and heed those 'best practices'. ... justifiable reason to NOT put things into the default cluster group. ... When we failover the resource group with our apps in it, ...
    (microsoft.public.windows.server.clustering)
  • SUMMARY: Configuring an application in a SUN CLUSTER 3.0
    ... Then you should create the resource package; the command to do this ... Create the resource group and then the resorce itself in the cluster (to ... We want to configure the same XClock command to run in failover mode in Sun ...
    (SunManagers)
  • Configuring an application in a SUN CLUSTER 3.0 - SCALABLE Mode
    ... Subject: SUMMARY: Configuring an application in a SUN CLUSTER 3.0 ... Then you should create the resource package; the command to do this ... Create the resource group and then the resorce itself in the cluster (to ... We want to configure the same XClock command to run in failover mode in Sun ...
    (SunManagers)
  • Re: Failover cluster question/problem
    ... justifiable reason to NOT put things into the default cluster group. ... When we failover the resource group with our apps in it, ... So, basically, i'm looking for a reason to invest alot of time and effort ... SQL is a Microsoft product and the way to install this is in a seperate ...
    (microsoft.public.windows.server.clustering)