I had a discussion around using FT in a stretched cluster (vSphere Metro Storage Cluster) environment. The main discussion point was around the use of “Host-VM” affinity rules. Some people appear to be under the impression that a Host-VM affinity rule can be created to ensure the primary and the secondary FT are divided between sites.
As I heard multiple people mentioning that this was possible I decided to test it. Unfortunately it is not possible. As soon as you enable FT on a VM and that secondary is started you will not see that secondary in the DRS Rules UI? Yes you can see the secondary if you look on a host level, but not in the DRS Rules workflow, this means it is not possible to ensure the secondary VM is bound to the second site.
If you can exclude the secondary FT VM from DRS and place it manually on the second side, you’re done right? (don’t if it’s possible…)
Don’t we also have the issue of latency? Since FT synchronizes CPU instructions, the latency requires is typically sub-1ms, meaning that your second site must be very close and your connectivity must be very good (high bandwidth, low latency, minimal hops).
Even if it isn’t a technical limitation of VMware FT itself, your exposure increases with distance: greater runtime state drift between primary and secondary means more of a chance that the ‘failover’ will be less than seamless.
I was presenting on FT on stretched clusters in Sydney just this morning. One bit of information I added for consideration is the bandwidth usage between FT VMs. Krishna’s paper on FT performance (http://www.vmware.com/files/pdf/perf-vsphere-fault_tolerance.pdf) cited a couple workloads whose FT-protected VMs generated near or over 1 Gbps traffic. Given that inter-site bandwidth is generally limited in stretched cluster, a 2500 IOPS workload spike could monopolize the connective link.
@Doug/Scott : Bandwidth is a huge concern of course indeed. And it could monopolize the link easily.
You could do something nasty like move the VM’s vNIC onto an individually created Port Group and only make the Port Group available to one host in each room. That way when FT was turned on it would have to create the secondary in the other room. Or probably worse you could only present that VM’s LUN to one host in one room and one host in the other.
Lots of impacts if you restrict things like this, e.g DRS has less options, HA can only recover the primary to secondary’s host which means a new secondary can’t be created until the failed host comes back online, restricts DPM, etc. I said it was nasty. But it should work.