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.
- 1 Physical and Logical Design
- 2 Naming Conventions
- 3 Sections In Progress
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|
|VM_PNetwork-v150||VM-DSwitch||4,5,6,7||Load Based Teaming (LBT)||150||Unconfigured|
|VM_DNetwork-v151||VM-DSwitch||184.108.40.206||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 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
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.
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
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