This solution demonstrates how to migrate existing workloads to the PowerOne system, including all VMs attached to the VLAN. The net result is that the workload IP gateway, in the guise of VXLAN IP anycast gateways, is migrated to the PowerOne top-of-rack (ToR) switches.
The migration of existing workloads to a PowerOne system does not require the application of new IP addresses to the workload VMs, which simplifies the overall workload network architecture and management. Thus, migrating workloads is much simpler process and one that eliminates unnecessary re-IP risks. Keeping the VM IP addresses the same in both the source and destination workload clusters is all-important. Keeping intact the application identity, including the IP address, allows you to avoid making changes at the DNS level. By using industry-standard tools and procedures for migrations, you can overcome the potential challenges.
This solution also demonstrates the migration of a portion of workloads. This use case occurs when some components, such as nonvirtualized storage, physical Layer 2 firewalls, and load balancers, cannot be migrated or are not good candidates for migration.
PowerOne networking is based on Layer 3 principles because of the system’s inherent ability to:
This solution provides a process by which a Layer 2 infrastructure can be configured, in tandem with the Layer 3 architecture, to facilitate Layer 2 communication between virtual devices on the PowerOne system and legacy nonvirtualized systems on the existing network. In our use case, the default gateway for these networks remains on the existing network, even for virtualized traffic within the PowerOne domain, although the gateway could reside on the PowerOne system.
The software, hardware, and configurations described in this paper have been tested inside a dedicated lab environment that used a “customer environment” running Cisco NXOS software, version 7.0.(3).I4(2), alongside the PowerOne system. Environments, hardware, and software in your data center might be different. Consult the vendors’ documentation for interoperability and configuration best practices before further configuration.