Failover Cluster Scenario - Suggestions?

Question

I am attempting to create a 2 node SQL Server 2012 Failover Cluster and am trying to gather information about what might be a better configuration in my particular case.
This is home lab environment in a single ESXi host and as such there really isn't the need for a cluster to begin with, but I am trying to configure things as close to what I would find in a corporate environment as possible, hence me being so picky about
the configuration.
The SQL servers themselves will be running a few System Center databases, EPO, Exchange, Lync, and a few more smaller products (different instances will be used as per best practice). However, there will be under 10 users in total in the environment, so
the load should be insignificant.
My physical server is rather powerful (2x 6 core Xeon 2.13Ghz - 24 vCPUs -, 72GB ram, 8 x 900GB SAS disks), so VM resource allocation is not too much of a problem.
All my storage is local to the ESXi server so the way I see it there are two ways I can do this:
1. I can create a few shared disks in VMware and assign them directly to the SQL servers and form the cluster from there. These will be seen as local disks by the SQL servers but shared on the VM configuration side.
The advantage of this configuration is that it is easier to setup. It requires less VMs in comparison to method 2 and less administration overhead as far as the cluster is concerned.
However, because I am planning on utilizing multiple instances and each instance has to have it's own disks (one for the data files another for the logs, as per best practices), having to manually create disks in ESXi and add it to the two VMs every time
I want a new instance is a slightly more long winded way of configuring things than the 2nd method.
2. Another method would be to create a server as an iSCSI Target Server, and present the disks to the SQL servers as iSCSI storage. The SQL servers seeing the storage as iSCSI is a lot more similar to what you'd encounter on an corporate environment, so
I am leaning toward this currently, as it would allow me to play around with the iSCSI side of it too.
This would allow me to create just a single volume on the iSCSI Target Server and then multiple iSCSI Target Volumes that get presented to the SQL servers.
However, there is the obvious single point of failure with having a single iSCSI Target Server, so I'd have to create a failover cluster for that too.
Using this method would mean that there are 4 servers to manage instead of 2 (and 2 clusters instead of 1) but I think at least on the SQL side it would be a configuration more similar to what a corporate environment would have, and creating more instances
in SQL would require less steps (no configuration in ESXi required at all, everything done on the iSCSI Target Servers)
I imagine performancewise this will not be as good as all VHDX files (from the iSCSI target server) will be located on the same VMDK and all VMs are on the same host.
Still, for a lab environment with 10 users, I can't really imagine that being too much an issue to the point where I'd actually notice any issues - happy for someone to tell me otherwise.
Would appreciate any recommendations possible, depending on recommendations I do have further questions about the actual setup of it, hence raising this as a question (for example, I started creating it as the second method but am having some issues with
networking on the iSCSI target server cluster).

Answer 1

No problem with running your environment on ESX because you are familiar with it.  But one of the reasons Hyper-V is taking market share from VMware is because the old FUD that VMware used to throw around has all been debunked.  Organizations realize
they are not giving up anything, and are often gaining things, by moving to Hyper-V.
+100500
Few reasons (except already mentioned maturity of Hyper-V that was not true 4-5 years ago)
1) Built-in Windows licensing (esp. Datacenter) that makes sense with many VMs
2) Free features inside free Hyper-V that free (or even paid) ESXi lacks (live migration of a VMs, VM replication etc)
3) "One throat to choke" in terms of support for both hypervisor OS and guest VMs OS
4) MUCH wider HCL for Hyper-V compared to what VMware has
5) Ability to control "kind of" Windows from Windows GUI (same happened before with Windows NT 4.0 takes over NetWare 4.x)
Cheers,
Anton Kolomyeytsev [MVP]
StarWind Software Chief Architect
Profile:  
Blog:  
Twitter:  
LinkedIn:  
Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.