by: VMware Lead Cloud Infrastructure Administrator Gaurav Pruthi and VMware Director, Cloud Infrastructure Operations Zaigui Wang
The VMware vSphere® Standard Switch (vSS) contains both data and management planes at the individual host level. This configuration lacked overall management efficiency and hindered integration with other advanced tools and applications. That’s why the decision was made to migrate to vSphere Distributed Switch (vDS).
vDS architecture logically separates the data and management planes. The management plane is the control structure that configures the data plane functionality that implements packet switching, filtering, tagging, and numerous other features. By separating these components, vDS enables centralized management and reduces administrative overhead, while maintaining a consistent configuration across the systems. IT teams can now more effectively oversee the crucial networking component in a virtualized infrastructure.
A host of reasons to migrate
Numerous business & technology aspects were considered, and they became the main drivers behind the migration decision. For example, vDS is the essential construct where VMware NSX® logical switches are built upon. NSX is the foundation of our on-demand DR testing bubble. vDS also provides insight and visibility into traffic flowing through our network. That helps facilitate our security efforts, such as micro-segmentation. And the centralized management of virtual distributed switch and its advanced features offer benefits that a virtual standard switch simply could not match.
Simplified migration
Migration required extensive planning and meticulous forethought, with the goal being zero downtime. When it comes to tools of choice, some users may prefer using the UI for its ease of operation while others prefer CLI for its power of automation. These two approaches complement each other.
We followed a five-step process:
- Create vDS and duplicate port groups
1a. Set vDS port groups to load-based policy. This gives us the ability to balance utilization among the NICs to accommodate our heavy I/O workload.
- Add hosts to vDS
- Assign redundant network interface controllers (NICs) from vSS to vDS
- Migrate workloads to vDS
- Move remaining NICs to vDS, configure, and clean up!
But there were challenges
As with any undertaking of this magnitude, there were challenges both predicted and unforeseen.
- We became victims of our own security protocols. Some appliances and applications may depend on the less secure vSS security settings to function, creating an “I’m sorry, Dave, I can’t do that” scenario after migration. For example, vSS allows MAC address changes and forged transmits by default, whereas vDS rejects both. The solution is to create a separate vDS port group for such applications and allow the new security settings to duplicate those found in vSS.
- The virtual machine (VM) may lose network connectivity intermittently. The solution is to upgrade the legacy VM/appliance network adapter to VMXNET3 per VMware best practices, or work with the application owners closely during migration.
- The MSSQL cluster is highly sensitive to changes and may require teams to work on primary and secondary nodes sequentially, something that can potentially extend deployment timelines. Similarly, Oracle Real Application Clusters (RAC) and other applications are sensitive to port group and network changes. Again, this require some close teamwork so that redundant nodes are identified and worked on first.
- There are vMotion restrictions between vSS and vDS. With vSS as a source, there is support for both vSS and vDS as the migration destination. But vDS-to-vSS migration is not supported, and vDS-to-vDS migration is supported only if both switches are at the same version. Migration between different versions of vDS using vMotion is possible but requires that the restriction be relaxed at the VC level with this advanced setting: config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig = true.
At the end of the day, we accomplished our goal, successful migration with zero downtime! In fact, since APIs helped with all the heavy lifting, we also realized significant time and effort savings.
If you have any questions or comments about how to do a vDS implementation, please use the comment feature and we’ll respond as soon as we can.
VMware on VMware blogs are written by IT subject matter experts sharing stories about our digital transformation using VMware products and services in a global production environment. Contact your sales rep or [email protected] to schedule a briefing on this topic. Visit the VMware on VMware microsite and follow us on Twitter.
