The quickest solution is to set up StarWind Virtual SAN in HA mode on 2 VMs, one on each host (make sure HA doesn't try to move the VMs onto the same host using policies). It's free, even in production mode. You will need to deploy two more Windows VMs to install StarWind Virtual SAN into, and you will need a NIC for replication. I assume you have at least one 10Gbps NIC on each host, since you're wanting to do FT (you DO have a 10Gbps NIC on each host, right? FT is completely worthless without it, even with only 1 VM using it. See other threads on the forum about people trying to use 1Gbps links for FT traffic and the speed issues it results in), so you could use that (FT won't suck up the entire pipe, and neither will the replication, so that should be ok).
In a failure scenario, if host 1 goes down and takes one StarWind Virtual SAN instance with it, and your FT master, that's ok - host 2 can still get to the data via the second StarWind Virtual SAN instance, and all is well. No single point of failure.
To get StarWind's Virtual SAN for 2 nodes on VMWare, you have to email them. Once you get to their site, you'll be able to download a 1 node version, and there's reference to having to email them to get a 2 node license for free. I've done it, it's painless.
You only need to put the VM's basics on the HA storage StarWind provides, which will keep HA replication traffic to a minimum, thus not messing with FT's traffic (the need for shared storage in FT is only for a tiny file to keep things in sync, not the whole VM). Put the VM's VMDKs on your local storage and let FT deal with replicating it between the hosts as writes occur, rather than let the HA storage replicate that traffic (FT6 will replicate it either way, even if the VMDK is on shared storage that both hosts can see, from what I understand). That means your HA storage doesn't need to be very big. In fact, it can be exceedingly tiny, since very little is actually stored on it. That will reduce the load on the whole HA storage setup (the smaller it is, the less likely it'll have any problems, too).
My only final note is that RAID5 with 2TB drives is slow suicide. I assume this will be used for file shares, since it's slower storage. RAID5 on large drives is fine, until a drive fails. The rebuild process takes a fair bit of time with large drives, and if another drive is found bad during that rebuild, your array is toast. The larger the drives, the more likely you'll find a bad sector that wasn't used before (thus not detected previously) during a rebuild. Worse, when a drive fails, it's likely just at that age when all of them are near failure, since they're all wearing at the same rate. RAID6 would have been a better choice here.
All of this gets even worse if you've used desktop-class drives, rather than enterprise storage, since a failed drive will likely bork the array for 30-60 seconds while the desktop drive's firmware messes around trying to get the data - in the meantime, the controller takes the drive offline and things time out out because the array is non-responsive for that time frame. Your host will stall during this delay, too, causing the VMs to freeze and possibly crash, if the delay is too long (Windows will only wait so long before it decides it lost it's disk). Some controllers don't know what's happening and take all of the drives offline, leaving you in the dark as to which drive has an issue. Enterprise drives not only fail less, but when they do, they give up faster to avoid time outs and all the associated nastiness.
.png "PaulWestNet"){kind=avatar}
