Protecting Workloads with Global Network Backing

Many thanks to Dimitri Desmidt from VMware, NSBU for providing the Design details of Multi-Location and Federation.

Preface

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.

Pre-requisite

• 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.

Limitations

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.

Fig.1 Paris-App-VM1 and London-App-VM1 with global segment “global_app_seg” at Paris and London DC

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.

Fig.2 Connectivity check between Paris-App-VM1 and London-App-VM1

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.

Fig.3 Network, Folder, Resource and Storage Policy Mappings

Replication, Protection Group and Recovery Plan can be setup for the Paris-App-VM1 with global network as shown in Fig.4

Fig.4 Replications, Protection Groups and Recovery Plans

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).

Fig.5 Workload VM Recovery using Planned Migration

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.

Fig.6 Paris-App-VM1 at London DC and quick connectivity check between Paris-App-VM1 and London-App-VM1

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.