• 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

Can I still provision VMs when a VSAN Stretched Cluster site has failed?

Duncan Epping · Apr 13, 2016 ·

A question was asked internally if you can still provision VMs when a site has failed in a VSAN stretched cluster environment. In a regular VSAN environment when you don’t have sufficient fault domains you cannot provision new VMs, unless you explicitly enable Force Provisioning, which most people do not have enabled. In a VSAN stretched cluster environment this behaviour is different. In my case I tested what would happen if the witness appliance would be gone. I had already created a VM before I failed the witness appliance, and I powered it on after I failed the witness, just to see if that worked. Well that worked, great, and if you look at the VM at a component level you can see that the witness component is missing.

Next test would be to create a new VM while the Witness Appliance is down. That also worked, although I am notified by vCenter during the provisioning process that there are less fault domain than expected as shown in the below screenshot. This is the difference with a normal VSAN environment, here we actually do allow you to provision new workloads, mainly because the site could be down for a longer period of time.

Now next step would be to power on the just created VM and then look at the components. The power on works without any issues and as shown below, the VM is created in the Preferred site with a single component. As soon though as the Witness recovers the the remaining components are created and synced.

Good to see that provisioning and power-on actually does work and that behaviour for this specific use-case was changed. If you want to know more about VSAN stretched clusters, there are a bunch of articles on it to be found here. And there is a deepdive white paper also available here.

Related

BC-DR, Software Defined, Storage, vSAN 6.1, 6.2, stretched, virtual san, vsan

Reader Interactions

Comments

  1. René says

    15 April, 2016 at 14:13

    Hi Duncan,

    i´ve got another question about vsan 6.2 stretched cluster. we´ve got a really tiny configuration (two nodes in two seperate locations + witness-appliance in a third location, all on the same campus, gbit-lan connection between all locations). we are testing some failover/desaster-scenarios right now…everything works as expected or described in the guides 🙂

    if one node + withness fails at the same time, the vsan-datastore isn´t accessible anymore, the vm´s are “killed” and can´t be powered on. is there any option or “console-magic” to get the vsan-datastore accessible on the last surviving host? i´ve seen some “one-host-vsan”-constructs around, is this a possible option to get it running again?

    regards
    René

    • Duncan Epping says

      18 April, 2016 at 18:12

      I have never tested it, will see if I can find some time to see how I can get that working… if at all, as it is not supported.

  2. Virtualisation says

    18 April, 2016 at 12:15

    Hi Duncan,

    Another great article written on the blog.

    Could you please also let me know about René’s questions? I will also be very interested.

    Many thanks!

  3. Tim Verbist says

    25 April, 2016 at 19:29

    Hi Duncan,

    So to be clear, does this mean that when you create a VM when the witness is down, the host will allow it but will not mirror the data to a secondary node at the secondary site as it waits for the witness to be back?

    So as long as the witness is down, you don’t have a copy of your data when the primary node fails?

    Thanks!

    • Duncan Epping says

      26 April, 2016 at 09:52

      That is correct, and yes I ave already asked for this to be changed in terms of functionality.

      • Tim Verbist says

        26 April, 2016 at 10:59

        Cool, thanks for the feedback Duncan!

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