Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Architecture Guide—VMware Cloud Foundation 5.1 on VxRail
Executive summary Architecture overview Workload domain architecture VxRail virtual network architecture
VxRail virtual network architecture
VxRail virtual distributed switch system (vDS)
VxRail vDS NIC teaming
Additional VCF NSX networks
VxRail vDS with NSX networks
NSX vDS
Secondary System and NSX network topologies
Two system vDS
Network Virtualization NSX WLD Design Enabling VCF with Tanzu Features on workload domains Physical network design considerations Storage options Multi-site design considerations Operations management architecture Lifecycle management Cloud management architecture

Two system vDS

Home > Integrated Products > VxRail > Guides > Architecture Guide—VMware Cloud Foundation 5.1 on VxRail > Two system vDS

Two system vDS

  • Starting with VCF 4.3.0, you can have two VxRail system vDS to separate system traffic onto two different vDS. For example, vMotion and external management traffic can be on one vDS and vSAN on another vDS. Either one of the two VxRail vDS can be used for NSX traffic. Alternatively, you can use a dedicated NSX vDS, which results in three vDS in the network design. Sometimes physical separation is needed for management/vMotion, vSAN, and NSX traffic. The three-vDS design provides this capability. This section describes sample topologies.

    Two system vDS – four pNIC

    In this first example, two system vDS are used. The first vDS is used for management and NSX traffic, the second system vDS is used for vMotion and vSAN traffic. This design also incorporates NIC-level redundancy.

    This figure shows two-system design vDS with four pNICs

    Figure 22.     Two-system vDS design with four pNIC

    In the next example, vSAN is isolated to a dedicated network fabric. This design might be needed if there is a requirement for physical separation of storage traffic from management and workload production traffic.

    This figure shows two-system design vDS with four pNICs and isolated vSAN.

    Figure 23.    Two-system vDS design with four pNIC and isolated vSAN

    Two system vDS – six pNIC

    Another option is to deploy the first system vDS with four uplinks. This option allows separation of vMotion from management and workload production traffic and allows vSAN on its own dedicated vDS. This option requires six pNICs per host. With VCF 4.3, you can pin the NSX traffic to the same NICs using either management, vMotion, or vSAN on either vDS. In this example, management NICs have been selected on system vDS1, which is the default behavior in the previous release.

    This figure shows two-system vDS with six pNICs

    Figure 24.    Two-system vDS design with six pNIC

    Note: VCF 4.3 provides the option to place NSX traffic onto the same two pNICs used for external management, vMotion or vSAN on either system vDS.

    A third vDS is required if there is a requirement to isolate NSX traffic and vSAN traffic. In this case, two system vDS and an NSX vDS are required. The first system vDS is used for management and vMotion, the second system vDS is used for vSAN, and the third vDS is dedicated for NSX traffic. This design results in six pNICs per host.

    This figure shows two system vDS and NSX vDS.

    Figure 25.    Two system vDS and NSX vDS