Many thanks to Dimitri Desmidt from VMware, NSBU for providing the Design details of Multi-Location and Federation.
Starting NSX-T version 3.0.2 workloads with NSX-T global network backing (L2 stretched segment) can be protected and recovered using Site Recovery Manager (SRM). More details on Multi-Locations with Federation are available here.
Note: This post does not contain the installation and configuration details of NSX-T federation, vSphere Replication and Site Recovery Manager. Hence, it is necessary to meet the following pre-requisite to achieve the goal of protecting workloads with global segments using SRM.
- Understanding of NSX-T Federation and its configuration is necessary.
- Understanding the installation and configuration of vSphere Replication and Site Recovery Manager (SRM) is necessary.
SRM is not currently supported with Federation with VM Tags, Segment Ports, or Segment Ports Tags. As mentioned in the Design Guide for Multi-Locations here:
- Currently recovered VMs via SRM does not recover their NSX VM Tags.
- Recovered VMs will receive new Segment Ports on the new LM.
- If the Federation Security is based on VM Tags, Segment Ports or Segment Ports Tags then the recovered compute VMs in another location (London in our example here) do not have their DFW Rules.
Workloads with NSX-T global segments as network backing
In this article, 2 datacenters viz., Paris and London, are paired using SRM. Fig.1 shows Paris-App-VM1 and London-App-VM1 with global segment as global_app_seg.
A quick connectivity check from Paris-App-VM1 to London-App-VM1 before recovering Paris-App-VM1 at London DC reveals that both VMs can talk to each other with span across the DCs as shown in Fig.2.
SRM configuration for workload protection and recovery
Login to SRM and navigate to Site Pair. Pair the London and Paris vCenters. Configure network mapping, folder mapping, resource mapping and datastore mapping as per the configuration of data center (vsan datastore with vSphere Replication is used in this post) as shown in Fig.3.
Replication, Protection Group and Recovery Plan can be setup for the Paris-App-VM1 with global network as shown in Fig.4
Protecting and recovering a workload VM
Now that replication, protection group and recovery plan is set up for Paris-App-VM1, trigger planned migration with recovery plan RP1 is shown below (this is based on the use case since this post talks about workload protection and recovery. A simple example of planned migration is shown below).
This will power off the VM in the Paris site and restart it in London. Ensure you exercise this option carefully on production workloads during a proper maintenance window.
All that’s left is to ensure that Paris-App-VM1 is recovered from Paris to London site and test the connectivity between Paris-App-VM1 and London-App-VM1 after recovery.
As you can see, using SRM to pair two sites is easy with NSX-T. This allows you to migrate or protect and recover workloads between the data centers for disaster recovery or planned migration purposes.