0

In a deployment I'm considering, we have a production sQL server that needs to be highly available. It will be set up on a Server 2008R2 Cluster. Hyper-V will be set up already. I'm worried that running SQL in a VM wont provide enough of a High availability solution vs. SQL clustering on the root partitions. SQL performance running in a VM isnt an issue, I'm just worried in the case of a hard failover, the VM will reboot, causing a larger downtime than the failover period for a normal SQL cluster.

There are several aspects I'm interested in. Will the VM downtime be any different than the downtime of an SQL cluster? How long is the average failover in an SQL cluster? Is there some hidden advantage of an SQL cluster, such as a shared queue that transactions get sent to, so if one node is down the transactions will apply to the database once it comes back online? Or does it not make a difference?

Right now, Hyper-V looks pretty good, because planned failovers can be run without interrupting any client access.

Steve Butler
  • 1,016
  • 9
  • 19

1 Answers1

2

SQL Server failover involves running a primary server that owns the database with a backup server that is ready to own the database. At the moment of failover, the backup server takes ownership of the storage, replays the logs and then brings the database on line. That's followed by a period where the hot parts of the database are brought into memory as needed. The biggest bound on the failover time is the replaying of the logs, as that needs to happen before the database can begin responding to queries.

If you cluster the VM rather than the SQL server, you add the VM reboot time along with any filesystem checks. These tend not to dominate the total recovery time.

Jake Oshins
  • 5,116
  • 17
  • 15