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

dSwitch

VMNIC

NIC Teaming

VLAN Tag

NIOC Shares

Management

Management-DSwitch

0,1

Originating Port ID

20

Unconfigured

vMotion-01

Management-DSwitch

0

Originating Port ID

21

Unconfigured

vMotion-02

Management-DSwitch

1

Originating Port ID

21

Unconfigured

iSCSI-01

Storage-DSwitch

2

N/A

30

Unconfigured

iSCSI-02

Storage-DSwitch

3

N/A

30

Unconfigured

VM_PNetwork-v150

VM-DSwitch

4,5,6,7

Load Based Teaming (LBT)

150

Unconfigured

VM_DNetwork-v151

VM-DSwitch

4.5.6.7

Load Based Teaming (LBT)

151

Low

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-DSwitchorStorage-DSwitchorVM-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.