As title, we experiencing during snapshot timestamp for VMs in a protection group.
Meaning a group with database servers, apps and other servers, when we do drill test to start up the VMs in recovery site, the files timestamp in VMs are varies.
Is the snapshot job run concurrently for all VMs in the group when the replication schedule hit?? Or it is because some VMs (like DB) talk longer time to complete the snapshot while other like apps VM completed early??
Anyone hit this issue?? We are using vSphere Replication instead of array based replication.
Thanks/
Dylan
Hi,
This is expected behavior with the current releases of vSphere Replication - the source host replication scheduler is unaware of any grouping of VMs and starts replica instance to satisfy RPO requirements. The decision when to start a new instance is based on load and transfer time for a few of the previous instances.
Multi-vm consistency is on the roadmap for a future release and will address the exact issue you describe.
If using VR 5.5, perhaps you can leverage the multiple point in time feature (MPIT) and after failover revert some of the machines to older instances (represented as VM snapshots) to match the state of the other machines.
Regards,
Martin
Hi,
This is expected behavior with the current releases of vSphere Replication - the source host replication scheduler is unaware of any grouping of VMs and starts replica instance to satisfy RPO requirements. The decision when to start a new instance is based on load and transfer time for a few of the previous instances.
Multi-vm consistency is on the roadmap for a future release and will address the exact issue you describe.
If using VR 5.5, perhaps you can leverage the multiple point in time feature (MPIT) and after failover revert some of the machines to older instances (represented as VM snapshots) to match the state of the other machines.
Regards,
Martin
Thanks.. even all VMs have same NTP source, it also cannot make it same snapshot time?
Correct. NTP is not relevant. The replication scheduler simply does not coordinate replica instance creation for different VMs order than to not overload the source ESXi and network.
Thanks. We will wait then.