SQL Failover server on ESX

Question

SQL Failover server on ESX

Wilfred van Dijk

SSCrazy Eights

Points: 9003
More actions
September 16, 2008 at 7:19 am

#193615

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

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

Michael Earl-395764 SSC Guru Points: 53873 More actions · Answer 1

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.

Steve Jones - SSC Editor SSC Guru Points: 736280 More actions · Answer 2

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.

Wilfred van Dijk SSCrazy Eights Points: 9003 More actions · Answer 3

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

Luke L SSC-Dedicated Points: 35547 More actions · Answer 4

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.

To help us help you read this[/url]For better help with performance problems please read this[/url]

Steve Jones - SSC Editor SSC Guru Points: 736280 More actions · Answer 5

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.

Luke L SSC-Dedicated Points: 35547 More actions · Answer 6

Great Thanks!

To help us help you read this[/url]For better help with performance problems please read this[/url]

Ewan Hampson SSCrazy Points: 2780 More actions · Answer 7

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?

Steve Jones - SSC Editor SSC Guru Points: 736280 More actions · Answer 8

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.

Ewan Hampson SSCrazy Points: 2780 More actions · Answer 9

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.

CrazyMan SSChampion Points: 12560 More actions · Answer 10

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

🙂