setup custer - one node already in production -- sql server clustering

Claudia
1/25/2007 12:11:03 PM

Thank Geoff and Russ for quick response.

The second hardware set for the second node is the same as the first one,
and both are cluster compatible.

Both of your responses tell me that keeping the current sql instance is
impossible. I have to build a single node cluster first and migrate dbs +
replication.

Thanks again for the direction.

Claudia

[quoted text, click to view]

Geoff N. Hiten
1/25/2007 2:00:09 PM

First, I am assuming you rushed a single host node from a cluster purchase
into production as an emergency measure. You cannot take random hardware
and build a stable production cluster, even if those components are
otherwise OK for clustering. They have to be purchased as a clustered
configuration.

Start with the node NOT in production and build a single node cluster. Then
you can migrate the databases to the single-node cluster. Finally, you can
add the existing system into the cluster. As always, test the process and
work out a procedure befor doing anything on the production platform.

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

[quoted text, click to view]

Anthony Thomas
1/29/2007 8:37:41 PM

You could just install MSCS and form a cluster between the to nodes.

Then, you could use SQL Server setup to upgrade the stand alone instance to
a single-instanced clustered instance.

http://msdn2.microsoft.com/en-us/library/ms191295.aspx

By the way, why do you want to consider Active/Active (a.k.a.,
multi-instanced) clustering when single-instanced will provide sufficient
high availability?

Sincerely,

Anthony Thomas

--

[quoted text, click to view]

Claudia
1/30/2007 8:36:03 AM

Anthony,
Because one node is already in production, and it also involves replication
which will break with new virtual name, I will not try MSCS directly and
upgrade sql between the two nodes.

Active-active setup is to fully use the hardware.

[quoted text, click to view]

Anthony Thomas
1/31/2007 7:55:57 AM

So, you are going to use replication and make the second instance a
reporting server? How do you plan on "fully using" the hardware?

Keep in mind, that either due to server failure or during maintenance, you
will move all instances to a single host and will degrade performance if you
have not pre-limited the configuration. In this case, then you would
specify to use only 1/2 of the resources on any node, but then, logically,
you have the same thing as an Active/Passive configuration where you fully
used the hardware on 1 node.

You would be better off creating a 2 x 1 N + I cluster configuration, then
you would have 2 fully utilized nodes with one passive giving you 2/3
utilization overall (which is better than 1/2), but still maintain full
functionality during sever failure and maintenance. It would take a
concurrent 2 server failure before you would be back in the same performance
condition as the Active/Active configuration.

Sincerely,

Anthony Thomas

--

[quoted text, click to view]

Claudia
1/31/2007 4:49:00 PM

The current production node has replication setup. The second node to be
built will has its own replication setup with has nothing to do with the
first node.

Using active-active mode saves money - that's the only reason to go this way.

Your suggestion of 2 x 1 N + I cluster configuration caught my interest.
Have you done this? I have experience with 2-node cluster, but know nothing
about 2+ cluster. Currently trying to find info on this.

Claudia

[quoted text, click to view]

Anthony Thomas
1/31/2007 9:06:24 PM

Yes, but you can replicate, or mirror, one database to another, even on the
same instance, although in that case, database snapshots would probably make
more sense.

Now, as far as saving money goes, there are a few got'chas that you should
consider.

First, in a single-instance configuration, you only have to license the
processors on the box with the largest number of cpu sockets. The passive
node, acting like a stand-by server, does not have to be licensed as long as
you use it only for failover support and maintenance for the primary node
(basically, Microsoft allows you to run operations on the passive node for
approximately 30 days, plenty of time to do maintenance or repairs on the
primary node).

Now, for multi-instanced installations, because you are running at least on
instance on both nodes, Microsoft requires you to license all processors.

In an N + I configuration, however, only the "active" nodes need to be
licensed. The inactive node is performing passive failover support. Now,
you can run all of the nodes symmetrically (that is, the same hardware, the
same number of cpu sockets); however, although the probability of
multi-server failure is lower than single-server, there is still a finite
probability. So, some installations beef-up the passive node to be able to
withstand multi-server failures. In this case, you have to license each
"active" node as if each of them had the same number of processors as the
passive, even if they have fewer.

For both Enterprise Edition and Data Center Edition for Windows 2003 you can
build up to 8-node clusters. Although you could configure a 7 x 1, most
configure 4 x 4 (which would be similar to 4 independent 2-node clusters), 5
x 3, or 6 x 2, with the 6 x 2 configuration most common. The difference
between a 4 x 4 and 4 2-node and 6 x 2 versus 2 3 x 1 clusters is that by
having multiple passive nodes allows you flexibility regarding failover
partners. For the independent, single passive node versions, you only get
one choice.

To run SQL Server 2000 x86 editions, unfortunately, you can only run on up
to 4-node cluster configurations. However, for Liberty (SS2K IA64) and
Yukon (SS2K5), 8-node cluster configurations are supported.

Lastly, because of the licensing costs between single-instanced and
multi-instanced, you would want to consider running everything on a single
node, again which reduces the system resource capacity for any single
instance, which gets you right back to the Active/Passive (or 1 x 1 N + I)
configuration. Furthermore, the VLDB Microsoft site has quite a few white
papers that indicate that multi-hosted databases on a single instance
outperforms a multi-instanced configuration (trying to save money utilizing
a single host to server multiple SQL Server installations). So,
single-instancing is still the better way to go.

So, N + I is the only practical way to reduce the passive server costs and
boot overall server utilization. There is also a Round-Robin configuration.
Where N + I is like a triangle, with all active nodes targeted to one or
more passive nodes in common, the Round-Robin configuration partners nodes
so that failover happens in a daisy-chain, circular fashion. Regardless of
the configuration, multi-node clusters are the way to reduce passive node
costs, not strictly Active-Active.

If you are willing to risk the reduced performance during failover
scenarios, then Active-Active could be viable solution, but you haven't
demonstrated that sort of need yet, unless you just like to spend money.

Sincerely,

Anthony Thomas

--

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about sql server clustering

sql server clustering : setup custer - one node already in production