stretched

Can all VSAN Witness VMs for ROBO be in the same VLAN?

Duncan Epping · Jun 9, 2016 ·

Yesterday I received the question if all VSAN Witness VMs for ROBO can be in the same VLAN? The excellent VSAN 2 node and Stretched Cluster guide for VSAN describes an example of how things can be implemented with different VLANs for the VSAN Witness, which would look like this:

Now the question came in from a customer implementing ROBO at scale if it was possible to have all VSAN Witness VMs for ROBO in the same VLAN. The answer in short is: yes. Keep in mind that the ROBO locations access the Witness VM over L3 and there is no multicast needed between the ROBO location. Only thing you need to do is set up the routes from the ROBO location to the main site with the central Witness VMs. All of them can be in the same VLAN, fully supported!

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.

Removing stretched VSAN configuration?

Duncan Epping · Dec 15, 2015 ·

I had a question today around how to safely remove a stretched VSAN configuration without putting any of the workloads in danger. This is fairly straight forward to be honest, there are 1 or 2 things though which are important. (For those wondering why you would want to do this, some customers played with this option and started loading workloads on top of VSAN and then realized it was still running in stretched mode.) Here are the steps required:

Click on your VSAN cluster and go to Manage and disable the stretched configuration
- This will remove the witness host, but will leave 2 fault domains in tact
Remove the two remaining fault domains
Go to the Monitor section and click on Health and check the “virtual san object health”. Most likely it will be “red” as the “witness components” have gone missing. VSAN will repair this automatically by default in 60 minutes. We prefer to take step 4 though asap after removing the failure domains!
Click “repair object immediately”, now witness components will be recreated and the VSAN cluster will be healthy again.
Click “retest” after a couple of minutes

By the way, that “repair object immediately” feature can also be used in the case of a regular host failure where “components” have gone absent. Very useful feature, especially if you don’t expect a host to return any time soon (hardware failure for instance) and have the spare capacity.

Virtual SAN Stretched Clustering demo

Duncan Epping · Sep 10, 2015 ·

I posted about HA/DRS settings for VSAN Stretched Clustering yesterday and posted an intro to 6.1 and all new functionality which includes stretched clustering. As part of our VMworld session Rawlinson Rivera recorded a nice demo. We figured we should share it with the world, so I added the voice-over so at least it is clear what you are looking at and why certain things are configured in a specific way. I hope this demo shows how dead simple it is to configure VSAN stretched clustering, and how it handles a full site failure. Enjoy,

HA/DRS configuration with Virtual SAN Stretched Cluster environment

Duncan Epping · Sep 9, 2015 ·

This question is going to come sooner or later, how do I configure HA/DRS when I am running a Virtual SAN Stretched cluster configuration. I described some of the basics of Virtual SAN stretched clustering in a what’s new for 6.1 post already, if you haven’t read it then I urge you to do so first. There are a couple of key things to know, first of all the latency between data sites that can be tolerated is 5ms and to the witness location ~100ms.

If you look at the picture you below you can imagine that when a VM sits in Fault Domain A and is reading from Fault Domain B that it could incur a latency of 5ms for each read IO. From a performance perspective we would like to avoid this 5ms latency, so for stretched clusters we introduce the concept of read locality. We don’t have this in a non-stretched environment, as there the latency is microseconds and not miliseconds. Now this “read locality” is something we need to take in to consideration when we configure HA and DRS.