A Deep Dive on the vSphere Distributed Switch Jason Nash VCDX #49, vExpert Data Center Solutions Principal Varrow

The purpose of this session is to give you a good understanding of the vSphere Distributed Swtich (vDS) – That includes complexity, features, cost, deployment considerations, and management My goal is for you to see how this could fit your environment and decide if you want to migrate This is a very open presentation so feel free to ask questions What We’ll Cover

Standard vSwitches are not all bad – Easy to understand – Very easy to troubleshoot – Great deal of flexibility But they are also not all good – No advancement of features – Can become very cumbersome Quickly Discuss vSwitches

vDS is the second vSwitch included with vSphere Easier administration for medium and larger environments – Add a Port-Group once and all servers can use it Provides features that standard vSwitches don’t – Network I/O Control (NIOC) – Port mirroring – NetFlow – Private VLANs – Ingress and egress traffic shaping Not JUST for large environments – Many can take advantage of the advanced features Why Bother With the vDS?

Right now you have two distributed options (Well, 3 counting the non-existent IBM vSwitch) – vDS (vSphere Distributed Switch) – Cisco Nexus 1000v With the release of vSphere 5 the vDS now stacks up pretty well to the 1Kv – NetFlow v5 (1Kv is v9) – Port Mirroring (not as flexible as 1Kv) – 802.1p QoS tagging Though, the 1Kv still has many things going for it Compared to Others?

The Good – Innovative features such Network I/O Control (NIOC) Load-based Teaming – Very low complexity No external components to deploy or manage – Included in Enterprise Plus licensing – No special hardware (NICs or switches) required The Bad – Doesn’t include some advanced features of the N1Kv NetFlow v9 ACLs vPath for vWAAS and VSG Other security features (ARP Inspection, DHCP Snooping, etc) – Requires Enterprise Plus licensing Let’s Look at the vDS

The vDS architecture has two main components – Management or Control plane – Integrating in to vCenter – I/O or Data plane – Made up of hidden vSwitches on each vSphere host that is part of the vDS The Control plane is responsible for all configuration and management The I/O plane handles data flow in and out of each vSphere host No extra modules or components to install, manage, or upgrade Terms and Ideas

Controlled and managed by vCenter, so making VC resilient becomes important – Backup that database! – vCenter outage won’t affect general VM operation Virtual vCenter or Physical vCenter? – Both fully supported just a few things to think about Couple of ways to physically separate traffic – DMZ or other SSLF (Specialized Security Limited Functionality) environments – NAS or iSCSI traffic Confirm standard physical switch port config – Make them all the same! vDS Deployment Considerations

Designing the deployment of your vDS can be simple or a bit more involved – Depends on depth of features you plan to use Can get a bit more complex if you want to physically separate traffic – Storage on its own set of NICs – DMZ or other network with different security requirements Suggested to start with basic deployment and then start adding in other features such as NIOC Design Considerations

Simple process, just a few steps (video to follow) 1.Navigate to Inventory -> Networking in vCenter 2.Right-click, Create New vSphere Distributed Switch 3.Choose vDS version 4.Provide a name and number of uplinks 5.Optionally add vSphere hosts 6.Optionally create a port-group 7.Done Deploying the vDS

A single vDS can only have one uplink configuration – This means all pNICs added to the vDS must trunk the same VLANs What if you want to physically separate traffic? Two options: – Active/Standby/Unused – In each Port-Group configure Active/Standby/Unused configurations for NICs – Multiple vDS Switches – Yes, you can have more than one vDS in a cluster, each with their own uplinks Which you choose depends on which you think is easier to manage Traffic Separation with vDS

vDS Uplink Diagram – Multiple vDS vSphere Host vDS - DMZ vDS - Prod DMZ Network Prod Network

vDS Uplink Table – Single vDS with 1Gb This is a suggested configuration for a server with 8 NICs showing multi-link vMotion and iSCSI

vDS Uplink Table – Single vDS with 10Gb This is a suggested configuration for a server with 2 10Gb NICs. The idea is to balance traffic types across the two NICs.

Some configuration items are set on the main vDS (video to follow) – Names and number of uplinks – Private VLAN designations – NetFlow collector configuration – Port-mirror sessions – vDS MTU size – Discovery protocol (CDP or LLDP) configuration Configuring the Main vDS

The vDS only allows you to have one uplink configuration – This is in contrast to the Nexus 1000v, as we will see later Only a few settings in the uplink configuration, most set on port- group – Which VLANs to trunk through these physical NICs – NetFlow status (enabled or disabled) – Allow you to block all ports Configuring the Uplink

Since the vDS allows for only one uplink, how do we physically separate traffic? Two options: – Single vDS – Add all physical adapters to a single uplink and then do individual port-group configuration using Active/Standby/Unused – Multiple vDS – Deploy multiple vDS (Yes, you can do that!). You can deploy a vDS for each different environment. Partitioning Traffic

Creating port-groups is very straight forward Few key decisions – Port-group Name – I’m a fan of using the VLAN number – Number of virtual ports – Default is 128 but size as needed – VLAN Type which specifies who does the VLAN tagging Creating Port-Groups

SettingWho Tags the Frame NonePhysical switch tags the frame. This assumes the physical NIC(s) in the uplink are connected to access ports. VLANThe vDS will tag the frame. When you choose VLAN you must also specify which VLAN tag for this port-group. VLAN TrunkingPass frames through to/from the VM with VLAN tags in place. You will define which range of VLANs are allowed. Private VLANSelect corresponding Private VLAN as defined in the main vDS configuration. Selecting the Right VLAN Type

Most settings are done at the port-group level – Security (Promisc/MAC Changes/Forged Transmits) – NIC Teaming – Traffic Shaping – Monitoring – Resource Allocation (New for NIOC) – Port Binding Type (Static, Dynamic, Ephemeral) One big change with vDS is the availability of Load-Based Teaming Configuring Port-Groups

Once you have created all necessary port-groups the last tasks are: – Move hosts in to the vDS – Wizard makes migrating a host very easy. It will also migrate things such as vmkernel interfaces. – Move VMs to vDS port-groups – Another wizard automates this task. You simply choose the “source” and “destination” port-groups. Finishing the Deployment

Let’s get away from slides and in to the lab In this lab we’ll try and show a full vDS deployment – Create new switch – Configure uplink and main vDS – Create port-groups – Migrate hosts and VMs – Show advanced options Lab Time!

Use static port binding unless absolutely necessary – Especially if you have a virtual vCenter Try and let physical switches do tagging and trunk all VLANs – Not a fan of using native VLAN Recommended to use Load Based Teaming as it is simple and works about anywhere Best Practice Recommendations

Both dVS options are very flexible and powerful The vSphere 5 vDS adds a lot of features that close the gap with the 1Kv with reduced complexity and cost The Nexus 1000v is still king of features, especially with the integration of vWAAS and Virtual Security Gateway – In addition to more complexity and higher financial cost Consider all variables when deciding which meets your requirements Let’s Recap

My Blog: Twitter My Louis Watta’s Preso: Questions?