ecsaw
Contributor
Contributor

Witness Traffic Separation - Management or Separate Kernel?

Jump to solution

Hi, we are in the midst of deploying vSAN 6.7 on new hardware. We will be utilizing a 2 node stretched cluster (2 separate physical sites) and a L3 route to the Witness Appliance in a 3rd remote site.

Our vendor is helping to install and configure it, but I have a question on the best practice for the Witness Traffic. Previously, the vendor could not get the Witness traffic to work until we suggested to implement WTS to get traffic flowing to the 3rd site.

Right now, we have our 6 hosts in the 2 nodes;

1.) Witness traffic tagged onto the Management vmkernel.

2.) Witness Host in the 3rd site still has 2 vmkernels running Management and Witness.

I believe traffic is flowing via the Management gateway to the witness host. From the Witness Host, it is the same?

So, since we are still building this, is it better to separate out the Witness traffic to a separate vmkernel and implement static routes? Or will the current setup be enough and is supported? Thank you.

0 Kudos
1 Solution

Accepted Solutions
Jasemccarty
Immortal
Immortal

ecsaw

Because vSAN and Management both use the same TCP stack, if vmk0 (Management) and vmk1 (WitnessPg) are on the same subnet, you will observe a multi-homing situation (KB 2010877).

You could tag only vmk0 for "vSAN Traffic" if you desire, as this is a supported configuration. Keep in mind you will want to isolate/protect that network from non-administrative access.

I go into some more detail here: Understanding the vSAN Witness Host - Traffic Tagging - Virtual Blocks

Jase McCarty - Field SA @PureStorage - @jasemccarty

View solution in original post

0 Kudos
4 Replies
Jasemccarty
Immortal
Immortal

ecsaw

Because vSAN and Management both use the same TCP stack, if vmk0 (Management) and vmk1 (WitnessPg) are on the same subnet, you will observe a multi-homing situation (KB 2010877).

You could tag only vmk0 for "vSAN Traffic" if you desire, as this is a supported configuration. Keep in mind you will want to isolate/protect that network from non-administrative access.

I go into some more detail here: Understanding the vSAN Witness Host - Traffic Tagging - Virtual Blocks

Jase McCarty - Field SA @PureStorage - @jasemccarty

View solution in original post

0 Kudos
ecsaw
Contributor
Contributor

Thanks Jase for the info. Since it's a new build, we will request our vendor to split the vmkernels instead of using both Management and Witness traffic on just one vmkernel.

0 Kudos
Jasemccarty
Immortal
Immortal

No worries. Completely supported.

Just remember that you'll need to use Static Routes.

Jase McCarty - Field SA @PureStorage - @jasemccarty
0 Kudos
ecsaw
Contributor
Contributor

Hi Jase,

Some more questions if you don't mind :

If we use the option to "Override default gateway" on the new vmkernel to point to the Witness gateway, do we still need to add the static routes?

Eg. Management Network Gateway : 192.168.15.1

Witness Traffic Gateway : 192.168.118.1 (Newly created)

Remote Witness Appliance : 192.168.28.100

In the VMkernel creation screen, the IP set for example for Host A is 192.168.118.10, Override default gateway is set to 118.1

1.) How do we confirm that it's NOT using the Management network stack, as we are trunking the 2 Vlans (15 and 118) through one physical link.

2.) If the Management network is able to reach the remote witness appliance (eg. 192.168.28.100), does it matter if it goes through the Management stack as it's separated by vlan/IP? (meaning normally 192.168.15.x is able to ping 192.168.28.x anyway)

Thanks!

0 Kudos