SQL clustering or VM images

Question

We currently have a failover sql cluster with two nodes. For a new large project which we have determined to be business critical, our development team is requesting a new 2 node failover sql cluster.

Our server department has responded saying that they do not want to implement a cluster for us, and instead employee multiple virtual machines, each with SQL server installed, pointing to the same disk, so if one fails, they either move it to a new host, or the bring the other image up instead, and because it's pointing to the same disk the data will remain intact.

I'm no sql server expert, and only understand clustering on a basic level, but something tells me that this VM 'idea' they came up with is not exactly an enterprise solution. It sounds pretty Micky Mouse to me. Am I out to lunch here? What kind of arguments can I use to support my view?

Answer 1

I would agree with you - if they point to the same disk, what happens if (when) that disk fails?

If they are talking about a SAN though rather than an actual disk, then it might be an OK solution if you assume that the SAN is properly fault-tolerant.

Answer 2

It's all about money! VM's are usually also on a SAN with several cluster nodes as well, if you have, say, an ESX server with a lot of VMs. So, if you have a 4 node VM cluster with a SAN backend, you might be able to fit 40 VMs on there. You're still fault tolerant, etc.

BUT, having gone through virtualization of SQL Server, it was slow, pure and simple. We weren't getting the IOPS or enough memory and CPU. If you need decent performance, say, for high volume stress testing, go for the cluster. Keep in mind that you need 2 servers, SAN storage plus SQL/Windows licensing, so you have an uphill battle. :-(

I guess I'm torn on the subject. As a DBA, I like my servers to perform. Our test servers still need this, but our dev servers aren't usually too busy. Do you need the performance? (Granted, who would say no)

Answer 3

Actually this is quite common and feasible. Cluster solutions on virtual machines are cheap to deploy. Even more, SQL Server is actually officially supported on Hyper-V:

SQL Server 2008 is supported in virtual machine environments running on the Hyper-V role in Windows Server 2008 R2 and Windows Server 2008 Standard, Enterprise and Datacenter editions.

The only question is performance. Obviously a Hyper-V based deployment will be slower than one on bare metal, but I've seen many sites running just fine on VMs.

Answer 4

In order to determine whether to go with a virtual or clustered solution the requirements for fault tolerance need to be detailed. Does the solution need to accommodate for hardware failure, storage failure, or instance failure? If the server goes down how simple/complex should the recovery process be? What is the planned hardware resource utilization?

Both virtual and clustered solutions will offer hardware failure tolerance. SAN storage will likely cover the storage tolerance.

Does the application need to come up immediately after a failure? If it fails in the middle of the night what level of interaction is needed to bring the application back up. Should it be automatic or manual? If it needs to be automatic, should this be built into the technology or something that gets coded around?

Depending on the answers to the questions above either the virtual or clustered solution may fit the needs for high availability. I'd recommend laying out the requirements and often that will point to the solution that fits.

Sorry the answer is mostly questions but they'll point you to the appropriate solution.