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?
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.