We are currently implementing a Zerto 7.5 Build-1 environment on ESXi 6.7.0.3. Managing in the neighborhood of 300+ Production Level VM’s and wanted to get feed back from environment implementations of larger scale.
What you’re doing that works, how your building out VPG’s, Pit falls, Nice to Knows, and the like.
As a Nice to Know for a VM in any size environment – if you revert the source machine to a snapshot you must run the force sync command on the VPG or else you’ll have trouble failing over to it. Zerto is not snapshot aware.
• As reverting a protected VM from a VMware snapshot renders it inconsistent, ZVM now automatically
detects such events and automatically force-syncs the VPG.
Replicating 120 VMs from 17 Prod ESXi hosts to 13 DR ESXi 6.5 hosts at our warm site (OKC -> NJ).
Read up on LFNs (Long Fat Networks) if you have large bandwidth with latency (spread your replicating VMs across more hosts on both sides = more IPs source/destination IPs used therefore more TCP streams created)
No encryption built-in to the product – gotta do that yourself
The Long Term Retention (LTR) feature was refactored about a year ago – still doesn’t work great and needs work
If you turn on LTR for a VPG and that LTR becomes disconnected, the VPG will show as failed in the interface even though normal replication may be happening perfectly fine.
Make sure you backup the directory where the XML config files are on the ZVM server
If you need to do maintenance on a host at the recovery site, you have to manually evacuate the VMs replicating to that target hosts to other hosts. I had a private meeting with a Zerto product engineer and a feature request to make this fully automated is in the works I believe (hope!) (see: https://www.zrto-dev.com/myzerto/support/feature-requests/)
Some reports are garbage (I’ve told Zerto this) and some come out fine. (The VPG -> Export report is cold garbage…HOT garbage would be an upgrade)
Jim M.
