vRealize Automation Managed VMs Protected by Zerto

[nmshadey]

Hey all

I have recently taken on some work which involves using Zerto to provide Disaster Recovery protection for vRA managed VMs for customers. I guess I am not totally 'satisfied' with how this has been implemented and thought that I'd consult with the community and see if anyone else is using Zerto with vRA in the same vein. I am looking for the most optimal method to fail over a machine to another site. Currently, if a machine is failed over, a new VM is recovered at the recovery site and all the configuration of the protected VM is replayed. This involves capturing all the protected VM config such as Custom Properties, vSphere tags, Custom Attributes, Annotations, NSX security groups / tags, etc.. When the machine is recovered, it is treated as a brand new machine and is imported back into vRA (to the same tenant/reservation) and the stored configuration is replayed.

So I'm wondering if anyone else is doing something similar but in a more efficient manner than simply importing and replaying all the VMs config from all sources?

Thanks,

Gavin

[nmshadey]

No takers?

[daphnissov]

I have used vRA and Zerto but not in concert, although I have used other systems in a DR scenario. I'm not sure what exactly you mean happens when you say "replayed" because in my experience a disconnect often happens in that failed over machines aren't manageable until they're failed back. I do have both in my lab and am willing to do some tests and design work, which is an interesting proposition, but I'm curious to know more of your observations. Could you also list all the versions involved here (vCenter, vRA, Zerto)?

[nmshadey]

Hi daphnissov​

So basically, we're using Zerto with vRA. As it stood when I took this piece of work on was that when a DR protection was enabled for a set of VMs, information about these was captured. This included things such as the blueprint name, reservation, custom properties, etc etc. Then, when these VMs were recovered at the recovery site, the source VM would be destroyed from vCenter (part of the Zerto recovery) but also the vCAC VM would be destroyed, the new VM imported and all the configuration re-applied to the VM (custom props, etc).

I wasn't convinced that this was the best way to go hence my question. However, a few days ago I tried a couple of things as I was sure you could simply update the vCAC entity with the new reservation. I tried this and this worked, which now saves a ton of work in having to capture and re-apply configuration to the VM.

There is still a lot of work that has to be done in between but this now seems like a far more sensible approach. I am now looking at the NSX side of it and how best to manage configuration in one site to be presented at the recovery site (we're not using Universal objects).

vCenter: 6.5

vRA: 7.2

Zerto: 5.x

Thanks,

Gavin

[daphnissov]

Yes, updating the reservation is a must, but everything else should be ok. As far as what gets "captured", it's really nothing from the vRA side. Zerto just recovers the replica partners at the destination side but leaves all the IDs intact (vc.uuid, mainly) which is how vRA tracks systems. Once the reservations are updated, upon next data collection vRA usually finds them and makes them manageable once again.

The NSX thing is another story entirely and there are multiple ways to go about it. That's probably a thread best left created anew in the NSX forum.