VMware Cloud Community
HFMudd
Enthusiast
Enthusiast
Jump to solution

Config Assist and vSAN/vMotion on same DS/uplinks

In training it was said vMotion and vSAN should not share the same network/uplinks. Can someone help me understand why in 6.7 Config Assist when setting up a vmotion kernel adapter that it will only presents the vSAN DS and vSAN port group and no longer has the vmotion port group pre-defined and selectable? If it's intentional that they share the same DS/PG and uplinks does that mean there is no longer a concern about port saturation? Thanks.

Reply
0 Kudos
1 Solution

Accepted Solutions
GreatWhiteTec
VMware Employee
VMware Employee
Jump to solution

HFMudd,

This is more of a design decision based on many variables. If you have 2 interfaces of 25GB or more, and do something like LACP, sharing vSAN and vMotion is totally fine. Even if you didn't have that much bandwidth there is nothing stopping you from doing that. The concern is that when there is network contention, and there is a possibility of vMotion kicking in, then you may see some performance hit if the network was configured correctly.

When  designing traditional storage, rarely anyone puts any other traffic on those interfaces, right?! Well, vSAN is still storage traffic, and we want to do a similar configuration such as separate VLANs, dedicated interface (if possible). The difference is that we don't need dedicated switches or FC.

In the event that vSAN, and vMotion are on the same interface, then we highly recommend to use vDS and NIOC. Network IO Control (NIOC) allows you set shares in order to give storage traffic preference over vMotion, as vMotion traffic is very "bursty" and can take over the network bandwidth. This is why we include vDS with every license of vSAN, regardless of the vSphere license you have. See NIOC example in storagehub NIOC Configuration Example

View solution in original post

Reply
0 Kudos
2 Replies
GreatWhiteTec
VMware Employee
VMware Employee
Jump to solution

HFMudd,

This is more of a design decision based on many variables. If you have 2 interfaces of 25GB or more, and do something like LACP, sharing vSAN and vMotion is totally fine. Even if you didn't have that much bandwidth there is nothing stopping you from doing that. The concern is that when there is network contention, and there is a possibility of vMotion kicking in, then you may see some performance hit if the network was configured correctly.

When  designing traditional storage, rarely anyone puts any other traffic on those interfaces, right?! Well, vSAN is still storage traffic, and we want to do a similar configuration such as separate VLANs, dedicated interface (if possible). The difference is that we don't need dedicated switches or FC.

In the event that vSAN, and vMotion are on the same interface, then we highly recommend to use vDS and NIOC. Network IO Control (NIOC) allows you set shares in order to give storage traffic preference over vMotion, as vMotion traffic is very "bursty" and can take over the network bandwidth. This is why we include vDS with every license of vSAN, regardless of the vSphere license you have. See NIOC example in storagehub NIOC Configuration Example

Reply
0 Kudos
HFMudd
Enthusiast
Enthusiast
Jump to solution

Thanks - The added detail was helpful. I decided in my case to reconfigure the port groups and uplinks to separate the traffic. One of my complaint about the latest VSAN training was the lack of technical deep dive that I expected and a lot of questions got left on the table.

Reply
0 Kudos