• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Using FT in a stretched cluster environment

Duncan Epping · Jul 17, 2012 ·

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.

Related

BC-DR 5.0, ft, metro cluster, vmsc, vSphere

Reader Interactions

Comments

  1. Viktor says

    18 July, 2012 at 10:57

    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…)

  2. Doug says

    18 July, 2012 at 16:50

    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.

  3. Scott says

    18 July, 2012 at 17:13

    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.

  4. Duncan says

    18 July, 2012 at 17:22

    @Doug/Scott : Bandwidth is a huge concern of course indeed. And it could monopolize the link easily.

  5. Forbes Guthrie says

    19 July, 2012 at 09:10

    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.

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
June 1st – VMUG Belgium
Aug 21st – VMware Explore
Sep 20th – VMUG DK
Nov 6th – VMware Explore
Dec 7th – Swiss German VMUG

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in