As you might expect there’s been a raft of additional features added to the Distributed vSwitch – and that’s on top of changes within vCloud Director and “vCloud Network and Security” (or vCNS the new moniker that includes the vShield range of technologies and).
Increased Scalability & Functionality
The vSphere5.1 Distributed vSwitch introduces new scalability and capacity (you will be pleased I didn’t say cloud-scale. I could have. But I didn’t. But your getting the message now aren’t you?). So the number of portgroups goes up from 5k to 10k, as do the number of DvPorts from 20k to 60k. The number of hosts that can be members of the same distributed vSwitch goes up from 200 to 600 hosts, as well as the number of supported Distributed vSwitches from 32 to 128. So that’s easily a doubling of the scalability numbers within a product major release.
There’s some of nuggets as well. So…
- Netdump support has been extended to include stateless ESXi host with auto-deploy.
- There are improvements in MAC address assignments as well with the ability to add your own prefix or range of MAC address assigned from vCenter.
- SNMP has been upgraded to now offer support for version 3
- Whilst static port binding still exists – its been enhanced with some thing called “auto port expand” which means that when you run out of ports the system will generate more as needed. So you don’t face an issue of not being able to power on a VM because there are no ports left
Network Health Check
This is new component to the Distributed vSwitch. If you think about it the vSwitch is something that is quite tightly bound to the physical switch. That’s something we want to address in the various software-defined networking strategies that we have. With that said its not as if the “old” or “legacy” ways managing the network are about to disappear or change overnight. We still need to invest in the technology that customers are already using out there in the field. And I guess that’s what “network health check” is all about. It looks for potential incompatibilities between the virtual world and the physical world. It checks a number potential pain-points such as:
- Mismatched LAN Trunks
- MTU Settings (which could cause fragmentation of the Ethernet frame – remember MTU settings could well need adjusting for other technologies such as vCD or VXLAN)
- Teaming Settings (where the portgroup maybe configured for IP Hash, but the underlying physical either isn’t configured or enabled for a format of load-balancing that’s not supported)
The outcome of the health check could result in two outcomes. The VMware Admin reconfiguring the vSwitch to match the physical world, or potentially in the other direction – spotting an inconsistency at the physical layer, and then escalating that into the network team. As well as helping in the initial config and setup phase I believe it might be helpful in trapping configuration drift. Where changes occur at either layer that subsequently cause an issue.
Network Health Check works by sending out a L2 Echo Ethernet broadcast frame every minute (configurable), and then analysing the data from the packet to discover configuration issues. It can be disabled if you so wish, and just enabled for troubleshooting purposes. There are some requirements but I think most people will meet those by virtue of practical realities – you need a distributed vSwitch and it needs to be backed by two vmnics.
Backup & Restore/Rollback and Restore
As you might know the primary location for the Distributed vSwitch is the vCenter database. You protected from the outage of the vCenter service by the fact that the host holds its own configuration locally, and that data is also resides on shared storage accessible to the cluster. The question then is what if something untoward happens to the vCenter database. Of course, that should be part of your regular backup strategy. That goes without saying. What the backup and restore feature of vSphere5.1 allows for is to create snapshot of your configuration that can be exported out. The export file can either be restored into an existing vSphere environment or even be imported into a brand-new vCenter instance. Another usage of the back and restore feature could be for porting your configuration from one environment to another for testing purposes. Again the option to backup your Distributed vSwitch is available only in the web-client.
There’s another less frequently experience “catch22” that you might confront if you run vCenter in a VM on top of the environment its managing. Now in most large environment most folks would run vCenter and all the other management services on a dedicated management cluster – separate and distinct – from the ESX hosts it manages. In my lab environment I can’t. I don’t have enough ESX hosts to do that. So what if you do run vCenter patched into Distributed vSwitch, but then make a configuration changed that stops ESX host communicating to the vCenter? There is now an “automatic rollback” feature that checks your configuration changes. If it detects that your administrative task runs the risk of disconnecting or upset the communication between vCenter/ESX the system will self-repair and rollback that configuration change. The feature is enabled by default in the advanced vCenter setting at “config.vpxd.network.rollback”. The change is on the ESX host side of the house, the DCUI now has a “Recover VDS” option. This resets the configuration of the ESX host enough to return to a manageable state.
