I've been reading up on running a SQL Cluster in a Hyper V environment and there seems to be a couple of options:
Install guest cluster on 2 VMs that are themselves part of a fail over cluster.
Install SQL cluster on 2 VMs but the VMs themselves are not part of an underlying cluster.
With option 1, it's little more complex as there's effectively two clusters in play but this adds some flexibility in the sense that I'm free to migrate the VMs between and physical blades in their cluster for physical maintenance without affecting the status of the SQL guest cluster that's running within them.
With option 2, the set-up is a bit simpler as there's only 1 cluster in the mix but my VMs are anchored to the physical blades that they're set-up on (I'll ignore the fact I could manually move the VHDs for the purposes of this question).
Are there any other factors that I should consider here when deciding which option to go for?
I'm free to test out both options and probably will do but if any one has working experience of these set-ups and can offer some input that would be great.
Good points raised about adding mirroring to the mix to add a second copy of the database. I'm considering whether to just go with 2 SQL instances and use mirroring alone since this backend will be used for a single application since it will be a fairly stable set-up with regards to users etc.
The main point of this question though was specifically to do with the cluster set-up. i.e. is it better to
a) On the Hyper V hosts, build a failover cluster of the VMs and then, within the VMs themselves set up a second cluster and install the SQL Cluster - guest cluster on top of the host cluster
b) Just set-up the SQL cluster within the VMs and don't have the underlying failover cluster setup on the host Hyper V machines themselves.
I've seen advocates of both options but I don't really understand the pros and cons of each approach.