The Blog

Reference Design: vSphere Distributed Switch with 1Gbe NICs /IP Storage

This design is a baseline scenario and likely assumes you are using a rack-mount server with 6-8 1GBe NICs. This setup was most popular before the proliferation of 10Gbe networking at the server level. Although this type of configuration can be simulated to various degrees by blade server network abstraction techniques, 10Gbe and blade server designs will be discussed separately. This page servers as a working document to describe the baseline design of vSphere distributed switches based on best practices, or at least my take on current best practices.

Physical and Logical Design

The physical design makes the assumption that we will be using 1Gbe physical network adapters , network storage, either iSCSI or NFS and of course the distributed switch. All physical switch ports are trunking required VLANs across each servers physical NICs.

Port Group dSwitchVMNICNIC Teaming VLAN TagNIOC Shares
ManagementManagement-DSwitch0,1Originating Port ID20Unconfigured
vMotion-01Management-DSwitch0Originating Port ID21Unconfigured
vMotion-02Management-DSwitch1Originating Port ID21Unconfigured
iSCSI-01Storage-DSwitch2N/A30Unconfigured
iSCSI-02Storage-DSwitch3N/A30Unconfigured
VM_PNetwork-v150VM-DSwitch4,5,6,7Load Based Teaming (LBT)150Unconfigured
VM_DNetwork-v151VM-DSwitch4.5.6.7Load Based Teaming (LBT)151Low

This design can be easily scaled to support different requirements such as allowing iSCSI to consume more than 2 uplinks and scaling down the VM traffic to only 2 uplinks for example.

NFS could be used instead of iSCSI in this design but for now the focus is on iSCSI. vSphere 5.X uses NFS v3 therefore there is no native multi-pathing capability. There are other options, the best of them being to simply upgrade to 10Gbe which is beyond the scope of this design.

Naming Conventions

Naming conventions are important to have a manageable environment. Beyond satisfying the need for order and symmetry, which I am personally a big fan of, having clear naming conventions streamlines management especially in a multi-administrator environment, reduces the need to relearn or to reference diagrams when making changes which ultimately leads to less mistakes and better reliability.

More important than the specifics of the following examples is to ensure you have any logical naming convention.

Distributed Switch Names

%Function%-DSwitch

Management-DSwitch or Storage-DSwitch or VM-DSwitch

The key here is to make it extremely clear what the function of the switch is and to note that it is a distributed switch.

%Switch_Name%-Uplinks

Management-DSwitch-Uplinks or Storage-DSwitch-Uplinks or VM-DSwitch-Uplinks

This one is straight forward. The only thing of note is I like to remove the numbers appended to the default name of the uplinks.

Distributed Port Group Names

Distributed port group names will be high variable depending on the purpose, environment and administrator. They directive is to be descriptive and consistent.

Virtual Machine Port Groups

VM_%Environment%Network-v%VLAN ID%

VM_PNetwork-v150 (P=Production)

VMKernel Port Group Names

The key to VMKernel Port Group naming is to keep it simple, consistent and use number series when appropriate.

Management
vMotion-01
vMotion-02
iSCSI-01
iSCSI-02

Sections In Progress

  • Network IO Control (NIOC)

  • iSCSI MPIO Configuration with vDS

  • Multiple Distributed Switches vs Single Distributed Switch

  • Choosing NIC Teaming Policies

  • Distributed Switch Resiliency and Backup

Neil Bryan
IT Consultant & Technical Trainer
Neil Bryan is an IT consultant and technical trainer specializing in VMware, Citrix and Microsoft virtualization and infrastructure.

Leave a Reply

Skip to toolbar