September 16, 2008 at 7:19 am
Hi,
My manager heard about a "briljant idea" 😀 . He suggested to implement the failover server in a SQL 2005 Cluster on an ESX server, thus making it really virtual. The idea is to keep the failover server in a minimum configuration, until it's becoming the active node. We add memory dynamically if that's the case (sacrificing other virtual servers)
I'm not sure if I'm happy with this idea (I can't image how to implement a heartbeat)
So does somebody have experience with this configuration? Is is recommended? Suggestions?
Wilfred
The best things in life are the simple things
September 16, 2008 at 1:02 pm
What is the point? A failover cluster is for hardware redundancy. Are you trying to ensure you don't have a "virtual hardware failure" on just one of the virtual machines?
If both servers are on the same host, a hardware failure will take down both nodes anyway. If the servers are both virtual, but on different host machines the configuration makes sense and can actually be done just like you were clustering two physical servers.
September 16, 2008 at 1:32 pm
I have some friends that do this, HOWEVER, they have each VM on separate physical nodes (blades in this case). You must have separate physical hardware, and separate IO paths to the SAN. Otherwise it's not a very smart way to implement HA.
If you think about it, it makes sense as you can spend less on overall hardware and you don't have to worry about matching the physical hardware. Need more horsepower, assign more, assuming the underlying physical resources are there.
Another thing is that you cannot allow the VMs to float. Float all other VMs (file servers, print servers, etc.), but not the SQL Server.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 16, 2008 at 1:36 pm
Forgot to tell you:
The Active server will be a dedicated server (no VMware), only the passive node wil be virtual.
Thanks for your replies
Wilfred
The best things in life are the simple things
September 16, 2008 at 1:53 pm
Sorry about the slight thread hijack, but hey it happens...
Steve I'd be interested to hear about the VM's floating and your recommendation that they not.
I'm just attempting to get up to speed on VMware and I was looking at Vmotion and their HA solution to deal with some issues that we are seeing. Though I don't have the Hardware available for testing, I was curious about the pros and cons from a DBA's perspective, i.e. not the sales guy from VMWare's perspective. Perhaps you could talk your folks who are actually doing it into writing an article or two for you?
Thanks.
-Luke.
September 16, 2008 at 2:31 pm
I'm trying to get them to. If I get the time, I might go spend some time with them and see what I can document.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 17, 2008 at 6:11 am
September 18, 2008 at 7:38 am
Steve, you say
you cannot allow the VMs to float. Float all other VMs (file servers, print servers, etc.), but not the SQL Server
I am using VM Workstation to run my own VM, but I haven't got my hands on an ESX server of my own (yet), so I'm not clear what's floating here. Licenses? Instances?
September 18, 2008 at 8:11 am
Ewan,
The way ESX works is that it's like a cluster of VMWare hosts. The "floating" means that your VM could migrate to another physical machine, WHILE it's running, and without you being aware of it. You can make the decision to move a VM as well, live, users still use it, and move it from PhysicalServerA to PhysicalServerB.
For most VMs, this works OK. File servers, print servers, DCs, etc. can float around as needed. ESX can automatically move them to a new host if they need more or less resources, or if it's easier to move them and allow another VM to have more physical resources.
It's very, very cool technology.
http://www.vmware.com/products/vi/vc/vmotion.html
For SQL Server instances, IO is a big issue. This might be one of the biggest reasons that SQL Server fails on VMs. People don't plan the IO out, assuming VMWare will do it the same as a physical server. You need to build good IO paths from the physical machine to your SAN and then ensure that your SQL VM uses those. By preventing that instance from floating, you keep the IO up.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 18, 2008 at 8:29 am
Thanks, Steve, I've heard of but never seen the magic of dragging an entire machine across hardware, without anyone noticing very much. Cool technology indeed.
It makes sense that, while it is one thing to move a client user session that lives mostly in memory, it is rather more complicated for an RDBMS that is optimised for performance and efficiency, which will be more closely coupled to the connections to the physical resource it manages.
Thanks for the explanation, and the link.
October 8, 2008 at 7:45 am
Hi Guys
I am using V- Motion on my ESX hosts, i have disabled that feature due to shortage of hardware resources, i have tried to V-Motion one of my produciton machines across other storage, Its not really what i expected, there was a performance degrade on SQL server on the time of V-Motions, considering Iam only using a basic model of SAN
🙂
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply