Author: admin

One VDS vs Multiple VDS in vSphere DC

What is the benifit of using one or multiple VDS (Virtual Distributed Switch) per cluster? What value do each approach bring? And what tasks can each approach solve? Lets discuss it in more detail, because this can be a very tricky desicision and in my practice i faced with it already multiple times.

Using one VDS per vCenter for all clusters

Decision:

Signle VDS per workload domain with multiple clusters in one vCenter

Justification:

  • Uniform and identical configuration across whole workload domain and all clusters
  • Convenience and easy management, as well as keeping the configuration up to date for all specific use cases
  • Simlification from integration perspective. External solutions, like AVI (NSX Adv LB) or F5, that need to be integrated with vSphere/vCenter will discover only one port-group that is stratched between all clusters in workload instead on multiple (if it will be multiple its really hard to discover what port-group should be used for VMs provisioning and port-binding)

Impact:

  • Inflexibility of configuration in the case of heterogeneous servers in different virtualization clusters. Each server types can have different number of ports/uplinks and could have differen connections to underlying infrastructure

Using multiple VDS per vCenter for each cluster

Decision:

Multiple VDS per workload domain with multiple clusters in one vCenter. Each cluster has its own VDS

Justification:

  • Flexible configuration. Ablity to adopt most of the needs and configuration to different types of servers in each cluster
  • Independent configuration of each cluster, separation of management failure domain
  • Ability to create granular NIOC policies for each cluster based on its type/enviroment/purpose

Impact:

  • Hard to manage and provision configuration. External automation is needed to overcome this limitation
  • Uncommon problems that are related to the integration with external/3rd party problems that can threat each port-group/configuration on different VDS and separate one, even if its uses same VLAN/Overlay segment.

To summarized there is no best solution what to choose, each option could be used in different cases in order to maximum satisfy for certain type of requirements in customer enviroment. Need to choose the best one!

Networking. To LAG or not to LAG

There are o lot of debates about using LAG (MLAG) vs No LAG for Compute, Management and Edge VMware nodes. Short answer to this dilemma is – It depends:) But in this article I want to make a bit clarification for each solution and make pros and cons for them. The explanation will be done in VCDX way.

Using LAG/MLAG

Decision:

  • Use channel aggregation on ToR switches in order to connect your Compute, Management and Edge nodes

Justification:

  • Low bandwidth ISL. Traffic that enters downlink on the switch will not traverse (expect servers that are connected using one link on one switch) ISL ad will exit on the same switch.Advanced mechanism to control link status on Layer 2 using LACP.
  • LACP control plane has on board special BPDU packet (fast/slow) in order to exchange information between aggregation devices and also to control status between peers. This control packets can help detect problems on Layer 1/2 and also problems on switch itself (e.g physical link is up, but switch cannot process packet due to software or hardware error)
  • Higher port capacity utilization and ability to use different load balancing hashing algorithms

Impact:

  • Higher complicated design, configuration and operational procedures

Using No LAG

Decision:

  • Use No MLAG/LAG on ToR switches in order to connect your Compute, Management and Edge nodes

Justification:

  • Ability to physically separate different types of traffic – Data, Storage, vMotion and control on ESXi level load balancing for each traffic – Active/Active, Active/Standby
  • Simplified design and independence from network infrastructure/hardware. No need to additionally config network equipment and also ability to use different vendors i ToRs pair.
  • Operational overhead due to necessity of support different MLAG implementation. Each vendor has its own MLAG technology (VPC, MCLAG, MLAG, VLAG)

Impact:

  • High bandwidth ISL utilization, more port needed in order to satisfy capacity requirements.