We have a VM running SQL Server on a 6 node cluster of blades. The VM's data files are stored a SAN attached using a direct iSCSI connection.
As this SQL server will be running a number of important databases we're debating whether we should be clustering the SQL Server or will the fact that the VM is running in the cluster itself sufficient to give us high availability. I'm used to running SQL clusters when dealing with physical servers but I'm a bit sketchy on what is best practice when all the servers are just VMs sat on Hyper V.
If a blade running the VM fails I presume the VM will be started up on another load. I'm guessing the only benefit that adding a SQL cluster to the setup will give us it that the recovery time after a failure will be a little quicker? Are there any other benefits?
IMHO you'll still need to use a sql server high availability (HA) option such as clustering/mirroring/replication.
You'll still have an outage when you have to do things like patch your OS. Hyper-v wont help there.
Here is Microsoft's support policy for clustered SQL Server instances on virtualized hardware. They only support it when guests are running Windows Server 2008 or higher. Best case is that the configuration passes the Validate test in the Failover Clusters Management snap-in. This is run inside the virtual machine.
Pretty much. It runs down between "starting a SQL Server" to "boot a SQL Server".
If you are in failover cluster, with Hyper V you could activate live migration on your SQL VM, and migrate your SQL server to another node when you need to update the Hyper V server, and do some maintenance on your HyperV server with not connection lost.
If your server crash, the failover will transfert the SQL service owner to another node and you will lost only 3 - 4 ping, but all your active connection will be lost.