You can use VMware Site Recovery Manager™ (SRM) with NSX Federation for disaster recovery use cases.
Site Recovery Manager supports the following workflows with NSX-T Data Center:
- NSX Federation Global Manager (GM) VMs support full and test recovery of GM VMs (supported with or without NSX Federation management cluster VIP).
- Compute VMs support full and test recovery of compute VMs. Recovered VMs in the disaster recovery site have their NSX-T Data Center tags and firewall rules based on these NSX-T Data Center tags or not such as IP addresses and VM names.
To ensure that groups and firewall rules replicate at the disaster recovery location during recovery, the NSX-T Data Center Local Manager managing the disaster recovery location must have the NSX-T Data Center tags present at recovery time.
Prior to NSX Federation 3.2, there was no support for replication of VM tags between Local Managers in Site Recovery Manager. As a result, NSX-T Data Center did not replicate any security based on VM tags to recovered VMs. Security not based on VM tags, for instance, IP addresses or VM names, could be applied to recovered VMs.
Starting with NSX Federation releases 3.2.3, two new fields are added to support storage array replication: replication _type and tag_delay_delete_time. If you use storage array replication from your primary site to your recovery site in Site Recovery Manager, then create or update the tag replication policy replication type as STORAGE_ARRAY_REPLICATION.
Running a protection plan on Site Recovery Manager to migrate virtual machines using disaster recovery or planned migration options from your primary site to your recovery site will move the virtual machines to the recovery site and delete the virtual machines from primary site. When the concerned virtual machines are deleted from primary site and appear on recovery site within the tag_delay_delete_time setting, then tags from primary site get replicated on the virtual machines on recovery site. For storage array replication, the time for VMs to appear on the recovery site after they are deleted from the primary site depends on the VM count configured to failover, storage array performance, and ESXi host.
How to configure VM tag replication across LMs using GM API
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
"display_name":"vm tag replication policy Paris to London",
"description":"vm tag replication policy1",
"protected_site": "/global-infra/sites/LM_Paris",
"replication_type": "STORAGE_ARRAY_REPLICATION",
"tag_delay_delete_time": 30,
"recovery_sites": [
"/global-infra/sites/LM_London"
],
"groups":[
"/global-infra/domains/default/groups/Web-VM-Group",
"/global-infra/domains/default/groups/DB-VM-Group"
],
"vm_match_criteria": "MATCH_BIOS_UUID_NAME"
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
"display_name":"vm tag replication policy Paris to London",
"description":"vm tag replication policy1",
"protected_site": "/global-infra/sites/LM_Paris",
"recovery_sites": [
"/global-infra/sites/LM_London"
],
"groups":[
"/global-infra/domains/default/groups/Web-VM-Group",
"/global-infra/domains/default/groups/DB-VM-Group"
],
"vm_match_criteria": "MATCH_BIOS_UUID_NAME"
LM_Paris sends the tag information of the VMs for the BIOS UUID of the VMs in the groups Web-VM-Group + DB-VM-Group to LM_London. Before the recovery of the London VMs by Site Recovery Manager, LM_London does not have the VMs with the BIOS UUID and the VMs are not visible in LM_London yet. However, when Site Recovery Manager recovers the VMs in London, LM_London sees those VMs with the BIOS UUID and applies their NSX-T Data Center tags on them. The VMs get their security based on NSX-T Data Center tags.
vm_match_criteria has two possible values MATCH_BIOS_UUID_NAME or MATCH_NSX_ATTACHMENT_ID. At the recovery,
Site Recovery Manager copies both so any configuration is valid with
Site Recovery Manager. However, if another product completes VM replication and copies one, but not the other value, then configure GM with the appropriate vm_match_criteria value.
To estimate how much time it might take for the VM to disappear from the primary site and appear on the protected site, you can perform a test on the protection plan and measure the time interval between the end of the Synchronize storage and completion of the Power on priority X VMs steps. Set your tag_delay_delete_time to be more than this estimated time. Another tip is to run the protection plan in Site Recovery Manager and set the tag_delay_delete_time to always be more than time it takes between the step Shut Down VMs at the protected site and to complete the step to Power on priority X VMs while doing run on protection plan in SRM.
How to check VM tag replication across LMs using GM API
GET https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies
{
"protected_site": "/global-infra/sites/LM_Paris",
"recovery_sites": [
"/global-infra/sites/LM_London"
],
"vm_match_criteria": "MATCH_BIOS_UUID_NAME",
"groups": [
"/global-infra/domains/default/groups/Web-VM-Group",
"/global-infra/domains/default/groups/DB-VM-Group"
],
"resource_type": "VMTagReplicationPolicy",
"id": "policy1",
"display_name": "vm tag replication policy Paris to London",
"description": "vm tag replication policy1",
"path": "/global-infra/vm-tag-replication-policies/policy1",
"relative_path": "policy1",
"parent_path": "/global-infra",
"unique_id": "9ee18586-5480-41d9-8223-690c9226d763",
"marked_for_delete": false,
"overridden": false,
"_create_time": 1638413861377,
"_create_user": "admin",
"_last_modified_time": 1638413861377,
"_last_modified_user": "admin",
"_system_owned": false,
"_protection": "NOT_PROTECTED",
"_revision": 0
}
NSX-T Data Center supports only one entry from recovery sites. For details, see the vm-tag-replication-policies/policy-name API in the NSX Global Manager REST API Guide.
