Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
joelatfnb
Starting Member
1 Post |
Posted - 2010-09-08 : 10:48:15
|
I'm looking at a 3 node cluster setup as n+1 using Windows 2008 and SQL 2008. Where I have two active nodes and one spare. Then run instance A on one and Instance B on the other. I guess my question is can the third node be setup for Instance A and B in the event the primary instance goes down? If so what are the cavets of this setup?thanks,Joel |
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
Bruce Sherwood
Starting Member
12 Posts |
Posted - 2010-09-08 : 12:26:13
|
Tara is right.Any node in the cluster can host any of the instances. The caveat is as stated, the sizing of your nodes. Try an assure that all three nodes are identical and that they have the resources to host all of the instances at once on any single box.In my case, I try and assure that the hardware has the ability to run the normal workload with no more than 40% CPU utilization for any single instance. Then when combined on a single node, the workload should be able to run at the same performance level. (this also requires you have enough memory to host the workloads - otherwise you start having to read for disk a lot more for both instances)If you have an environment that does not care if things slow down during a period where two nodes have failed, then slightly under sizing them would be possible. But in my own environment, with very demanding customers, this isn't a wise decision.However balancing budget versus performance is always a factor to many companies these days. |
|
|
Bruce Sherwood
Starting Member
12 Posts |
Posted - 2010-09-08 : 12:32:20
|
Oh, I can add;You do have the ability to restrict which nodes can host which instances if you want to. You might use this for a workload that needs to try an survive a single node failure, but is acceptable to go offline in a dual node failure. Perhaps that workload sits in a small server that really can't host more than one instance. So it is clustered with a bigger box (in your three way) and it can move back and forth, but you restrict all over sized instances from using the smaller node.Just saying. |
|
|
dinakar
Master Smack Fu Yak Hacker
2507 Posts |
Posted - 2010-09-08 : 19:48:03
|
make sure you cap your SQL Server memory settings so that in the worst case scenario where both instances fail over to the passive node, the node is able to handle the 2 instances..Dinakar Nethi************************Life is short. Enjoy it.************************http://weblogs.sqlteam.com/dinakar/ |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2010-09-08 : 19:51:13
|
We made it a standard to cap it assuming active/active. On a failover, we'll be notified via paging our cell phones so we can then reduce the memory for the SQL instance(s). For instance, we've got a 2-node cluster with 48GB of memory on each node. The cluster has two SQL instances, and the cluster is active/active. We cap each SQL instance at 40GB (reserving 8 for the OS and other things). In our config, if we lost a node, we'd temporarily have a memory issue until a DBA restricts the memory further. That won't be a problem as our monitoring software will catch the failover condition and alert the DBA no matter what time of day. We like this method better as losing a node is very rare, but needing more memory is common.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog |
|
|
|
|
|
|
|