With 2 Node and Stretched Cluster vSAN, a vSAN Witness Host is used. This can be a physical vSphere host or a VMware provided virtual appliance. Using the vSAN Witness Appliance is easy, does not require any additional licensing, and has much of the configuration standardized (sizing, disks, tagged ports).
A second VMkernel port (vmk1) on the witnessPg port group is tagged for “vSAN Traffic” just like any other vSAN data node might have. In vSAN 6.1 and 6.2, the vmk1 VMkernel interface needed to be able communicate with the backend vSAN data network just like any other vSAN data node might. Connectivity had to be considered to allow the vSAN Witness Host to communicate with the data nodes using “vSAN Traffic.”
In vSAN 6.5 (as well as back ported to vSAN 6.2 w/vSphere 6.0 Update 3), VMware added support for Witness Traffic Separation (WTS) in 2 Node vSAN configurations.
What this did, was remove the requirement for the backend data node network to communicate with the vSAN Witness Host. A mechanism of offloading traffic destined for the vSAN to a different VMkernel interface was added. This could be an existing VMkernel, or a dedicated VMkernel, and it had to be tagged for “Witness” traffic.
Here’s an illustration from the Stretched Cluster and 2 Node Guide, showing WTS.
Notice that the data nodes have the following configuration:
- vmk0 – Management
- vmk1 – Witness Traffic
- vmk2 – vSAN Traffic
- vmk3 – vMotion Traffic
The vSAN Witness Host has the following configuration:
- vmk0 – Management
- vmk1 – vSAN Traffic
In a 2 Node Direct Connect configuration (using WTS) data nodes have a VMkernel interface tagged with “vSAN Traffic” and one tagged with “Witness” traffic. The vSAN Witness Host only has “vSAN Traffic” enabled on a VMkernel interface.
Again, for clarity: The vSAN Witness Host will only have a VMkernel interface tagged for “vSAN Traffic”. It will not have traffic tagged as “Witness”.
In vSAN 6.7, VMware extended WTS support to vSAN Stretched Clusters as well. And again, in this case, the vSAN Witness Host will only have “vSAN Traffic”.
Another item to keep in mind when designing/deploying 2 Node or Stretched vSAN Clusters, is IP addressing of the vSAN Witness Host VMkernel interfaces. If both the Management (vmk0) and witnessPg (vmk1) VMkernel interfaces are on the same IP segment, a multi-homing issue (https://kb.vmware.com/s/article/2010877) will occur. All vSAN Traffic on the vSAN Witness Host will flow out of vmk0, resulting in Health Check errors.
If both the Management (vmk0) and witnessPg (vmk1) interfaces have to be on the same IP segment, the witnessPg VMkernel interface must have “vSAN Traffic” untagged and the Management VMkernel (vmk0) must have “vSAN Traffic” tagged. Tagging vmk0 (only) for “vSAN Traffic” in this situation is fully supported.
For more information about vSAN 2 Node or Stretched Clusters, be sure to check out StorageHub for more information.
Can’t get enough of vSAN? Follow us on Twitter and Facebook! 
