Migration Coordinator is a fully supported free tool, that is built into NSX Data Center, that is designed to help customers migrating from NSX for vSphere to NSX (aka NSX-T). NSX-T 2.4, was the first release, about three years back, to introduce Migration Coordinator with couple of modes to enable migrations. Today, migration coordinator supports over 10 different ways to migrate from NSX for vSphere to NSX.
The last three blogs in this series covered the various modes available along with the pros and cons of each mode.
- Migration Coordinator: Approaches and Modes
- Migration Coordinator – In Place Migration Modes
- Migration Coordinator – Lift and Shift Migration Modes
This blog will focus on selecting the migration mode based on your requirements.
Terms, Tools and Modes
Before digging into how to go about selecting the right mode for the migration, let’s take a quick look at some of the terms, tools and high-level view of the modes available for migration, when leveraging Migration Coordaintor.
The following table summarizes some of the key terms used in regard to migrations:
Terms | Description |
In-place | Migrate using the same hardware |
Lift and Shift | Migrate to either new or repurposed hardware. |
DFW Only | Only the firewall configuration is migrated using Migration Coordinator |
Config Migration | Migration of the NSX for vSphere configuration to NSX (NSX-T) |
Workload Migration | Moving the workloads (VMs) from NSX for vSphere to NSX (NSX-T) |
Bridging | For migrations that may take some time to finish and need connectivity between the workloads on V and the workloads on T, during the migration. |
The following table is a summary of various tools that can be leveraged to help migrate from NSX for vSphere to NSX-T.
Tool | Description |
Migration Coordinator (MC) | For config migration for all modes and workload migration for some modes. Migration Coordinator is built into NSX (-T). |
NSX (-T) Bridge | Deployed on NSX for vSphere host to bridge logical switches to segments on NSX / NSX-T. Bridging is a feature of NSX (-T) platform. |
HCX L2 Extension | Alternate bridging solution from HCX |
MC’s Built-in Bridge | A distributed bridging solution built into migration coordinator. This mode is available in all fixed topology modes and in one user defined topology – config and edge migration mode. |
vSphere vMotion | For moving workloads (VMs) from NSX for vSphere to NSX / NSX-T |
HCX Migration with MC | To move the workloads (VMs) from NSX for vSphere to NSX (NSX-T) Only available in one mode (Edge and config migration modes)
Exception: May be leveraged in some cases where DFW is not used |
Migration Coordinator supports many different modes. The following table summarizes the modes.
Fixed Topology | User Defined Topology | Lift and shift (Any) | |
Supported Topologies | Fixed – 5 | Any | Any |
Workflow | Simple | Requires some prep work | Requires some prep work |
NSX-T Install | Install manager and edges | Install manager and edges | Install manager and edges
Optionally bridging |
NSX-T Config | None | N/S Connectivity & T0s | N/S Connectivity & T0s |
Workload migration | Built-in / Auto | vMotion or HCX * | vMotion |
Timing workload move | No control / Auto | No control / Auto | Full Control |
Bridging | MC’s Built-in Bridge | MC’s Built-in Bridge | NSX / HCX / MC’s Built-in Bridge* |
* Only User Defined Topology’s Config and Edge migration mode, supports built-in bridge and HCX for workload migration
Check out the previous blogs for a more detailed look at the modes.
The rest of this blog will focus on selecting the migration mode, starting with single sites.
Control over Workload Migration
One of the critical requirements to consider, is whether granular control is required over the workload migration. All the in-place migration modes are designed to simplify the migration process by taking full control over all aspects of migration. Hence, in-place migration modes don’t support granular control over workload migration. Customers who need granular control over workload migration, must leverage lift and shift modes for migration.
* Only User Defined Topology ‘s Config and Edge Migration mode, supports HCX for workload migration
In-Place Migration – Customization
In-place migration is supported by two migration modes. One is the fixed topology mode that supports 5 topologies and does a 1 to 1 mapping of all the supported config. Customers whose topologies are supported, may find that this is the simplest approach for migration. However, if certain customization of N/S connectivity is desired, User Defined Topology would be a better approach.
Lift and Shift Migration Options
Lift and shift migration modes enable granular control over the workload migration. Within these modes, there are three different options that one can leverage. Some customers may only want to migrate the firewall rules. Distributed Firewall migration mode allows migrating only the DFW related config. If customers also need to migrate other config and not just DFW, then there are two options available under user defined topology mode. One option, Config and Edge Migration Mode, will automatically setup Migration Coordinator’s built-in bridge and also allows leveraging HCX to drive the workload migration. For smaller deployments where bridging may not be required or if the customer would like to leverage other bridging methods such as NSX-T Bridge, then the Config Migration Mode is the recommended option. Please note: Both of these user defined topology modes support workload migration using vMotion.
Cross-VC
Finally, coming to the Cross-VC side, customers have the option to leverage Cross-VC to Federation migration modes. Please note, these modes are available from the Global Manager. Therefore, a Global Manager needs to be deployed and configured with local managers, before leveraging this option. Apart from that, the workflow is the same as we saw with the single sites. Customers have the flexibility to choose the mode that works best for them, based on whether they need granular control over the workload migration.
Exceptions:
The following section covers some exceptions to consider.
Cross-VC
Some Cross-VC deployments either may have only one site with all the workloads or may be able to accommodate moving all the workloads to a single site. In such cases, if needed, customers have the option to disconnect the secondary site and leverage one of the single site migration modes against the primary NSX for vSphere site. This method is often used in cases where customers prefer to move to a single site model.
HCX
During migration in all of the modes, Migration Coordinator uses various techniques such as temporary IP sets and pre-created virtual ports to ensure there is no compromise in security during and post migration. Migration Coordinator only supports one mode (User Defined Topology: Config and Edge Migration Mode) where HCX is integrated into this process and maintains the security posture.
However, customers may leverage HCX for other lift and shift modes, if preserving security posture during and after the migration, is not a concern. This exception is for those customers who may not have leveraged DFW in NSX for vSphere or planning to rewrite the DFW config in NSX post migration.
Conclusion
In conclusion, Migration Coordinator supports many modes to help migrate from NSX for vSphere to NSX. The previous blogs in this series showed the pros and cons of the modes. In this blog, we looked at some of the criteria to consider when selecting a particular migration mode.
Resources
Want to learn more? Check out the following resources:
- Migration Coordinator Documentation:
- Design Guide
- Try out NSX
Comments
0 Comments have been added so far