Date post: | 29-Jan-2018 |
Category: |
Technology |
Upload: | scott-lowe |
View: | 21,983 times |
Download: | 0 times |
Before we start
• Get involved!
• If you use Twitter, feel free to tweet about this session (use
hashtag #DenverVMUG)
• I encourage you to take photos or videos of today’s session
and share them online
• This presentation will be made available online after the
event
An Eye For(Network) DesignFive questions that get asked when
creating a vSphere network design
Scott Lowe, VCDX 39
vExpert, Author, Blogger, Geek
http://blog.scottlowe.org / Twitter: @scott_lowe
Agenda
• First, some assumptions
• Next, a caveat
• Question #1: How many vSwitches should I use?
• Question #2: Should I use a distributed vSwitch?
• Question #3: What traffic types can/should share uplinks?
• Question #4: How many uplinks do I need?
• Question #5: When should I use link aggregation?
First, some assumptions
• Throughout this discussion I’ll assume that the following is
true:
• You are using at least two (2) physical switches
• You’ve enabled PortFast/disabled STP on vSphere-facing
ports
• You’ve enabled CDP/LLDP
Next, a caveat
• All of these recommendations are just that:
recommendations
• Ultimately you need to understand the impact of your
networking design decisions and react accordingly
• Be sure to keep the functional requirements in mind—does
the network configuration meet the functional requirements?
• Your vSphere networking design might violate “general
recommendations” because of your specific needs or
requirements. That’s OK.
Question #1:How many vSwitches should I use?
Number of vSwitches
• A separate vSwitch is only required when you need
different sets of uplinks
• Without VLANs, separate uplinks (and thus separate
vSwitches) would be necessary
• I generally recommend as few vSwitches as possible (more
vSwitches don’t add redundancy)
• I strongly advocate the use of VLANs wherever possible
• Separate vSwitches are necessary for disjointed L2 domains
VLAN handling
• With regard to VLANs, here are some additional
recommended practices:
• Avoid the use of VLAN 1 where possible (although this
recommendation is a bit dated)
• Set an unused VLAN as the native VLAN on your trunks
• Understand the behavior of the native VLAN with
vSwitches and port groups
Question #2:Should I use a distributed vSwitch?
Using distributed vSwitches
• vSwitches require more manual effort (duplicate effort), but
offer fewer points of failure and fewer dependencies
• Distributed vSwitches (dvSwitches) offer streamlined
administration but with additional dependencies
• Most of the advanced features are found only in dvSwitches
Using distributed vSwitches
• Each option has its advantages and disadvantages
Feature vSwitch dvSwitch
Continues to operate even in the absence
of an external control plane (vCenter, VSM)Yes No
Supports all key networking features
(VLANs, vMotion, FT, link aggregation, etc.)Yes Yes
Offers simplified network mgmt and
potential mgmt offload to network teamNo Yes
Using distributed vSwitches
• My recommendation:
• Use both in a hybrid configuration (minimum 4 uplinks)
• Run management traffic on a vSwitch, run VM/VM-related
traffic on a dvSwitch
• When using a dvSwitch, appropriately protect the control
plane (VSM or vCenter Server)
• If it must be “or” not “and,” then go back to your functional
requirements
Question #3:What traffic types can/should share uplinks?
Mixing traffic
• Above all, you need to provide redundancy for all types of
network traffic
• Try to understand the network traffic in terms of:
• Consistency: Is it bursty traffic? Or is it constant?
• Bandwidth: How much bandwidth does it use?
• Scope: Is this traffic for one VM, or will it affect multiple
VMs?
Mixing traffic
• Some information on traffic types:
• Management traffic is generally low bandwidth
• vMotion is generally bursty and inconsistent
• Fault Tolerance logging is consistent; bandwidth usage
depends on number of FT-protected VMs
• IP-based storage traffic is high-bandwidth, large scope,
consistent traffic
Mixing traffic
• My recommendations:
• Don’t mix IP-based storage traffic with other traffic types
unless absolutely necessary
• Mix FT traffic with bursty traffic with small number of FT-
protected VMs
• Management and vMotion are OK to mix
• Try to keep VM-facing traffic segregated from “back end”
traffic
Question #4:How many uplinks do I need?
Number of uplinks
• Many different factors come into play:
• vSwitch/dvSwitch arrangement (separate vSwitch means
more uplinks)
• VLAN configuration (no VLANs means more uplinks)
• Traffic mixing (separate traffic streams means more
uplinks)
• Upstream network configuration (disjointed L2 networks
means separate vSwitches)
Number of uplinks
• For 1 GbE environments, I recommend:
• Minimum of 4 uplinks for non-IP-based storage
• Minimum of 6 uplinks for IP-based storage
• For 10 GbE environments, only 2 uplinks are necessary
unless functional requirements dictate otherwise
• Minimum of 4 uplinks for hybrid vSwitch/dvSwitch
configuration (can use “virtual NICs” if necessary)
Question #5:When should I use link aggregation?
Deciding on link aggregation
• Link aggregation refers to bonding multiple links together for
greater aggregate throughput (e.g., EtherChannel)
• NIC teaming refers to use multiple physical NICs as uplinks
on a vSwitch or dvSwitch
• Both techniques offer redundancy
Deciding on link aggregation
• Let’s compare
link aggregation
and NIC teaming
Feature Link Aggr NIC Team
Supports multiple
physical switches
Only with
MLAGYes
Requires physical
switch configYes No
Per-flow load
balancingYes No
Increased throughput
for each traffic flowNo No
Deciding on link aggregation
• My recommendation:
• NIC teaming is fine for most implementations
• Use link aggregation only if physical switches support
MLAG (otherwise can’t use multiple physical switches)
• Don’t use link aggregation for IP-based storage traffic (it’s
generally useless)
Questions &Answers
Thank You