The vSphere Distributed Switch (VDS) extends the features and capabilities and features of virtual networks while simplifying provisioning and the ongoing process of configuration, monitoring, and management.
With ESX 3.5 and prior releases, virtual networks were constructed using virtual switches. Each ESX host would use one or more virtual switches to connect the VMs with the server NICs and the outside physical network. With the release of vSphere 4.0, VMware introduced an additional choice for VMware virtual networking with the vSphere Distributed Switch. VDS eases the management burden of per host virtual switch configuration by treating the network as an aggregated resource. Individual host-level virtual switches are abstracted into a single large vSphere Distributed Switch that spans multiple hosts at the Datacenter level. Management plane and Proxy switch are two main components of VDS. Management plane is part of the vCenter server and helps manage virtual network infrastructure at scale through a single pane of glass. Proxy switch on the other hand manages VM traffic flows on the local host. Each vCenter can support up to 32 VDSs and each VDS can manage up to 350 hosts. Many of the concepts involved in configuring and managing a Standard Switch are carried forward with the VDS. Port Groups become Distributed Virtual Port Groups (DV Port Groups) that span multiple hosts and ensure configuration consistency for VMs and virtual ports necessary for such functions as VMotion.
Distributed Virtual Port Groups (DV Port Groups) are port groups associated with a vDS and specify port configuration options for each member port. DV Port Groups define how a connection is made through the vDS to the Network. Configuration parameters are similar to those available with Port Groups on Standard Switches. The VLAN ID, traffic shaping parameters, port security, teaming and load balancing configuration, and other settings are configured here. Each VDS supports up to 5000 static port groups.
Distributed Virtual Uplinks (dvUplinks) are a new concept introduced with VDS. dvUplinks provide a level of abstraction for the physical NICs (vmnics) on each host. NIC teaming, load balancing, and failover policies on the VDS and DV Port Groups are applied to the dvUplinks and not the vmnics on individual hosts. Each vmnic on each host is mapped to a dvUplinks, permitting teaming and failover consistency irrespective of vmnic assignments.
vSphere Distributed Switch features
Private VLAN (PVLAN) support enables broader compatibility with existing networking environments using Private VLAN technology. Private VLANs enable users to restrict communication between virtual machines on the same VLAN or network segment, significantly reducing the number of subnets needed for certain network configurations.
Network vMotion is the tracking of virtual machine networking state (e.g. counters, port statistics) as the VM moves from host to host on a vSphere Distributed Switch. This provides a consistent view of a virtual network interface regardless of the VM location or vMotion migration history. This greatly simplifies network monitoring and troubleshooting activities where vMotion is used to migrate VMs between hosts.
Bi-directional Traffic Shaping
vDS expands upon the egress only traffic shaping feature of Standard Switches with bi-directional traffic shaping capabilities. Egress (from VM to network) and now ingress (from network into VM) traffic shaping policies can now be applied on DV Port Group Definitions. Traffic shaping is useful in cases where you may wish to limit the traffic to or from a VM or group of VMs to either protect a VM or other traffic in an oversubscribed network. Policies are defined by three characteristics: average bandwidth, peak bandwidth, and burst size.
Third Party Virtual Switch Support with the Cisco Nexus 1000V Series Virtual Switch
The vNetwork Distributed Switch includes switch extensibility for seamless integration of 3rd party control planes, data planes, and user interfaces. Cisco has collaborated with VMware to exploit this extensibility to produce the Cisco Nexus 1000V Series Virtual Switch. The Cisco Nexus 1000V uses the same distributed switching model as the VMware vNetwork Distributed Switch. Virtual Ethernet Modules (VEMs) are the switching data planes on each ESX host and provide the frame forwarding capabilities. The VEMs leverage the ESX host APIs and so can leverage the same physical NICs and HCL (Hardware Compatibility List) as the VMware Standard Switch and vNetwork Distributed Switch. Virtual Supervisor Modules (VSMs) are implemented on the Cisco NX-OS operating system. They provide the control plane function for the VEMs and can exist as a guest VM or standalone appliance.
VSMs provide a familiar Cisco CLI (Command Line Interface) for management and configuration. They also communicate with vCenter Server for optional management and configuration through a vSphere Client.
The Cisco Nexus 1000V has an expanded feature set similar to that provided by physical Cisco Catalyst and Nexus switches.
Network I/O Control
Many virtualized datacenters are shifting to using 10 Gigabit Ethernet (10GbE) network adapters. The use of 10GbE adapters replaces configuring multiple 1GB network cards. The historical practice of deploying a large number of 1GB network adapters to accommodate peak bandwidth requirements has a number of shortcomings:
- Limited bandwidth: Network flows from an individual source (virtual machine, vMotion interface, etc.) are limited and bound to the bandwidth of a single 1GB interface even if more bandwidth is available within a NIC team
- Excessive complexity: Use of large numbers of 1GB adapters per server leads to excessive complexity in cabling and management, with an increased likelihood of misconfiguration
- Higher capital costs: Large numbers of 1GB adapters requires more physical switch ports, which in turn leads to higher capital costs including additional switches and rack space
- Lower utilization: Static bandwidth allocation to accommodate peak bandwidth for different traffic flows means poor average network bandwidth utilization
10GbE provides ample bandwidth for multiple traffic flows to coexist and share the same physical 10GbE link. Flows that were limited to the bandwidth of a single 1GbE link are now able to use as much as 10GbE.
While the use of a 10GbE solution greatly simplifies the networking infrastructure and addresses all the shortcomings listed above, there are a few challenges that still need to be addressed to maximize the value of a 10GbE solution. One primary challenge is to ensure that latency-sensitive and critical traffic flows can access the bandwidth they need.
vSphere Network I/O Control (NetIOC) enables the convergence of diverse workloads on a single networking pipe. The NetIOC concept revolves around resource pools that are similar in many ways to the ones already existing for CPU and Memory. It provides sufficient controls to the vSphere administrator, in the form of limits and shares parameters, to enable and ensure predictable network performance when multiple traffic types contend for the same physical network resources. NetIOC is only supported with the vSphere Distributed Switch (vDS).
NetIOC provides users with the following features:
- Isolation: Ensure traffic isolation so that a given flow will never be allowed to dominate over others, preventing drops and undesired jitter
- Shares: Allow flexible networking capacity partitioning to help users to deal with over commitment when flows compete aggressively for the same resources
- Limits: Enforce traffic bandwidth limit on the overall vDS set of dvUplinks
- Load-Based Teaming: Efficiently use a vDS set of dvUplinks for networking capacity
NetIOC classifies traffic into six predefined resource pools as follows:
- FT logging
- Virtual machine traffic
A user can specify the relative importance of a given network resource-pool using shares that are enforced at the dvUplink level. The underlying dvUplink bandwidth is then divided among resource-pool flows based on their relative shares in a work-conserving way. This means that unused capacity will be redistributed to other contending flows and won’t go to waste.
A user can specify an absolute shaping limit for a given resource-pool flow using a bandwidth capacity limiter. As opposed to shares that are enforced at the dvUplink level, limits are enforced on the overall vDS set of dvUplinks, which means that a flow of a given resource pool will never exceed a given limit for a vDS out of a given vSphere host.
Load-Based Teaming (LBT)
vSphere 4.1 introduced a load-based teaming (LBT) policy that ensures vDS dvUplink capacity is optimized. LBT reshuffles port binding dynamically based on load and dvUplinks usage to make an efficient use of the bandwidth available. LBT only moves ports to dvUplinks configured for the corresponding DV Port Group’s team. LBT will only move a flow when the mean send or receive utilization on an uplink exceeds 75 percent of capacity over a 30-second period. LBT will not move flows more often than every 30 seconds. LBT is not the default teaming policy in a DV Port Group so it is up to the user to configure it as the active policy.
vSphere 5.0 NetIOC improvements
User-Defined Network Resource Pools
User-defined network resource pools in vSphere 5.0 provide an ability to add new traffic types beyond the standard system traffic types that are used for I/O scheduling. When customers are deploying critical applications, they can utilize this advanced feature to reserve I/O resources for the important, business-critical application traffic and provide SLA guarantees.
vSphere Replication Traffic
vSphere replication is a new system traffic type that carries replication traffic from one host to another. NetIOC now supports this new traffic type along with other system and user-defined traffic types. Customers implementing a disaster recovery (DR) solution with VMware vCenter Site Recovery Manager (Site Recovery Manager) and vSphere replication can use this vSphere replication traffic type to provide required network resources to the replication process.
IEEE 802.1p Tagging
IEEE 802.1p is a standard for enabling QoS at MAC level. The IEEE 802.1p tag provides a 3-bit field for prioritization, which allows packets to be grouped into seven different traffic classes. In the vSphere 5.0 release, network administrators now can tag the packets going out of the host for proper handling by physical network resources.