An Eye for (Network) Design

21,615 views
21,493 views

Published on

This presentation focuses on design considerations for vSphere networking. I presented this content at the Denver full-day VMUG on June 28, 2011.

Published in: Technology, Business
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
21,615
On SlideShare
0
From Embeds
0
Number of Embeds
10,693
Actions
Shares
0
Downloads
275
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • An Eye for (Network) Design

    1. 1. 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• Thispresentation will be made available online after the event
    2. 2. An Eye For(Network) DesignFive questions that get asked whencreating a vSphere network design Scott Lowe, VCDX 39 vExpert, Author, Blogger, Geek http://blog.scottlowe.org / Twitter: @scott_lowe
    3. 3. 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?
    4. 4. 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
    5. 5. 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• Besure 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.
    6. 6. Question #1:How many vSwitches should I use?
    7. 7. 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•Igenerally 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
    8. 8. 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 • Understandthe behavior of the native VLAN with vSwitches and port groups
    9. 9. Question #2:Should I use a distributed vSwitch?
    10. 10. Using distributed vSwitches• vSwitches require more manual effort (duplicate effort), but offer fewer points of failure and fewer dependencies• DistributedvSwitches (dvSwitches) offer streamlined administration but with additional dependencies• Most of the advanced features are found only in dvSwitches
    11. 11. Using distributed vSwitches• Each option has its advantages and disadvantages Feature vSwitch dvSwitch Continues to operate even in the absence Yes No of an external control plane (vCenter, VSM) Supports all key networking features Yes Yes (VLANs, vMotion, FT, link aggregation, etc.) Offers simplified network mgmt and No Yes potential mgmt offload to network team
    12. 12. 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)• Ifit must be “or” not “and,” then go back to your functional requirements
    13. 13. Question #3:What traffic types can/should share uplinks?
    14. 14. Mixing traffic• Aboveall, 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?
    15. 15. 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-basedstorage traffic is high-bandwidth, large scope, consistent traffic
    16. 16. 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
    17. 17. Question #4:How many uplinks do I need?
    18. 18. Number of uplinks• Many different factors come into play: • vSwitch/dvSwitch arrangement (separate vSwitch means more uplinks) • VLAN configuration (no VLANs means more uplinks) • Trafficmixing (separate traffic streams means more uplinks) • Upstream network configuration (disjointed L2 networks means separate vSwitches)
    19. 19. 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• For10 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)
    20. 20. Question #5:When should I use link aggregation?
    21. 21. Deciding on link aggregation• Link aggregation refers to bonding multiple links together for greater aggregate throughput (e.g., EtherChannel)• NICteaming refers to use multiple physical NICs as uplinks on a vSwitch or dvSwitch• Both techniques offer redundancy
    22. 22. Deciding on link aggregation Feature Link Aggr NIC Team Supports multiple Only with Yes physical switches MLAG• Let’scompare Requires physical Yes No link aggregation switch config and NIC teaming Per-flow load Yes No balancing Increased throughput No No for each traffic flow
    23. 23. Deciding on link aggregation• My recommendation: • NIC teaming is fine for most implementations • Uselink aggregation only if physical switches support MLAG (otherwise can’t use multiple physical switches) • Don’tuse link aggregation for IP-based storage traffic (it’s generally useless)
    24. 24. Questions &Answers
    25. 25. Thank You

    ×