December 24, 2008 at 8:50 am
Hi All,
Is there any testing methodology to test a SQL Server Failover Clustering solution.
I set up OS and SQL Server as a cluster but now, it is time to test. Which methods can i try to test it.
December 24, 2008 at 2:07 pm
Start with a simple failover test and ensure that you can force failover the active node to a passive node. Then test the connectivity of each of the clustered services from a workstation. Then test failover for each additional passive node and the fail back as well.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
December 24, 2008 at 11:27 pm
The best way to test....unplug stuff
No seriously, walk over to the servers, unplug the network from one, check the state of the cluster. Power one down, check the state of the cluster. Test failovers and failbacks after each scenario and look at the windows event logs, the SQL error logs and the cluster logs for any gotchas.
And it does feel oh so good to rip an ethernet cable out, or hold your finger on the power button for a few seconds and hear the server power down (kinda reminds me of the moment before firing the planet buster from the death star) 😀
December 25, 2008 at 8:47 am
Nicholas Cain (12/24/2008)
The best way to test....unplug stuff
at the end of the day this is exactly what clustering is designed to protect against so yes its the best way. Fail over does have some latency though so be aware
Nicholas Cain (12/24/2008)
And it does feel oh so good to rip an ethernet cable out, or hold your finger on the power button for a few seconds and hear the server power down (kinda reminds me of the moment before firing the planet buster from the death star) 😀
confidence inspiring as well
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 26, 2008 at 9:36 am
Nicholas said it all quite succinctly - his outline has been mine since NT 4.0 and SQL v7.0 !!!
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
July 17, 2012 at 12:06 pm
So how about if our cluster nodes are virtual machines and there are no power cords to yank on? Can I just go into vSphere and power down a node or disable a NIC? I'm a DBA and not very familiar yet with the hardware side...
July 17, 2012 at 12:08 pm
ok, just realized this post is four years old.... 🙂 I looked at the last login date of the poster, not the actual postind date... sorry..
July 17, 2012 at 12:24 pm
tmagney (7/17/2012)
Can I just go into vSphere and power down a node or disable a NIC?
Yes that is exactly what you'd do
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 17, 2012 at 12:27 pm
tmagney (7/17/2012)
So how about if our cluster nodes are virtual machines and there are no power cords to yank on? Can I just go into vSphere and power down a node or disable a NIC? I'm a DBA and not very familiar yet with the hardware side...
Yes, just push the power button virtually and it will do the same thing.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
July 17, 2012 at 12:28 pm
Question is why would you cluster on virtual hardware? (other than for cheap QA & validation)
I'm interested to know what this is providing you.
July 17, 2012 at 12:32 pm
The ability to do rolling upgrades of the Windows OS and SQL Server is a big reason. VMware HA doesn't provide the same capabilities as a failover cluster does for SQL Server. I have a number of clients that have VM clusters for patching downtime reasons alone. I wrote a blog post that discusses the differences in HA for VMs and SQL a few years ago:
Back then I wasn't big on the idea, but I've built a number of them since then and they work great.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
July 17, 2012 at 12:39 pm
Good question, and one of endless debate. For us, virtualization is mostly a means of replacing outdated physical hardware, maximizing our memory and cpu, and the benefits of being able to move guests around as needed. Clustering may seem redundant in a virtual environment, but it gives us improved HA by being able to switch sql server between nodes when doing patches, upgrades, etc, without having to bring the sql instance down.
July 17, 2012 at 2:46 pm
Nicholas Cain (7/17/2012)
Question is why would you cluster on virtual hardware? (other than for cheap QA & validation)I'm interested to know what this is providing you.
Ordinarily you'd be right, but improvements in the mainstream hyper visors have led to more efficient use of virtual machines in clusters. One area in particular is the clustering of VMs with "physical tin" servers. Using a VM as a partner node cuts down on hardware costs (both initial purchase and ongoing maintenance). Since your VM partner node is an emergency standby it's better to have something rather than nothing 😉
Virtual clusters also make great QA and test systems and they're good for educating your DBAs in deployment and configuration too.
For more info, see my excellent guide for deploying virtual clusters at this link[/url]
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply