http://searchnetworking.techtarget.com/tip/vSwitch-architecture-best-practices
In the first part of this series on vSphere vSwitches, we outlined three types of vSphere vSwitches, as well as how to assign port groups for redundancy, segmentation and security. In part two, we address best practices for vSwitch architecture.
vSwitch architecture can vary depending on the type of traffic being managed. The following are vSwitch architecture options:
- For ESX, isolate the Service Console port group onto its own vSwitch. Make sure this vSwitch has redundant pNICs; alternately you can create a second Service Console port group on another vSwitch for redundancy. It’s OK to share this vSwitch with the VMkernel port group.
- For ESXi, isolate the VMkernel port group onto its own vSwitch. Make sure this vSwitch has redundant pNICs; alternately, you can create a second VMkernel port group on another vSwitch for redundancy.
- If using iSCSI/NFS storage, dedicate a vSwitch with its own VMkernel port. It’s best to separate the storage traffic from other VMkernel traffic on a host. Storage connections are critical, so always use redundant pNICs.
- For VM traffic, you can mix multiple VLANs on a vSwitch as long as the traffic is on a private network. Always isolate DMZ traffic onto its own vSwitch. Make sure you have enough pNICs in the vSwitch to handle the number of VMs connected to it. Having 50 VMs on a vSwitch with only two pNICs could create a lot of contention and only one pNIC would be available in case of a failure. The more pNICs you have in a vSwitch, the more the load can be spread across them. Never combine VM traffic with VMkernel/Service Console traffic on the same vSwitch.
- Network traffic between VMs on the same vSwitch and port group should never leave the host and should travel in the memory of a host. This allows for much faster communication between the VMs. Typical memory speeds are around 24 Gbps. This can boost the performance of VMs that send large amounts of data between each other, such as VMs running multi-tier applications.
Sample vSwitch configurations
vSwitch configuration can vary based on the number of NICs on a host server. Here are sample configurations:
Scenario 1 – Four pNICs in your host; multiple VLANs needed for VMs and non-IP based shared storage. Provides redundancy for Service Console/VMkernel by using Active/Standby NICs, and provides redundancy for your VM vSwitch:
- vSwitch0 – Service Console port group – vmnic0 (active) – vmnic1 (standby)
- vSwitch0 - VMkernel port group – vmnic1 (active) – vmnic0 (standby)
- vSwitch1 - VM port groups – vmnic2 (active) – vmnic3 (active)
Scenario 2 – Six pNICs in your host; multiple VLANs needed for VMs, including an external DMZ and non-IP based shared storage. Provides redundancy for Service Console/VMkernel by using Active/Standby NICs, and provides redundancy for your VM vSwitch. Also provides redundancy for a second vSwitch to isolate DMZ traffic on for your VMs:
- vSwitch0 – Service Console port group – vmnic0 (active) – vmnic1 (standby)
- vSwitch0 - VMkernel port group – vmnic1 (active) – vmnic0 (standby)
- vSwitch1 – Internal VM port group – vmnic2 (active) – vmnic3 (active)
- vSwitch2 – External VM DMZ port group – vmnic4 (active) – vmnic5 (active)
Scenario 3 – Eight pNICs in your host; multiple VLANs needed for VMs and using IP-based shared storage. Provides redundancy for Service Console/VMkernel by using Active/Standby NICs, and provides redundancy and extra bandwidth for your VM vSwitch:
- vSwitch0 – Service Console port group – vmnic0 (active) – vmnic1 (standby)
- vSwitch0 - VMkernel port group – vmnic1 (active) – vmnic0 (standby)
- vSwitch1 – VMkernel2 port group (IP storage) – vmnic2 (active) – vmnic3 (active)
- vSwitch2 – VM port group – vmnic4 (active) – vmnic5 (active) – vmnic6 (active) – vmnic7 (active)