Policies Dialog
In the Disaster and Recovery area:
|
•
|
Failover/Move Commit Policy: The commit policy to use during a failover or move operation. The value set here is the default for all failover or move operations from this point on but can be changed when defining a failover or move operation. The following options are available: |
|
•
|
None: The failover or move operation must be manually committed or rolled back by the user. |
|
•
|
Commit: After the time specified in the Default Timeout field, the failover or move operation is committed. During the specified time you can check the recovered VPG virtual machines, and you can manually commit or roll back. |
|
•
|
Rollback: After the time specified in the Default Timeout field the failover or move operation is rolled back, unless you manually commit it or roll it back before the time out value is reached. During the specified time you can check the recovered VPG virtual machines. |
|
•
|
Default Timeout: The time-out in minutes after which a Commit or Rollback is performed. A value of zero indicates that the system automatically performs the commit policy, without waiting for any user interaction. |
In the Pre/Post Recovery Operations Scripts area:
|
•
|
Default Script Execution Timeout: The length of time in seconds after which a script times out. |
In the Replication area:
|
•
|
Enable Replication to Self: Enable the same site to be used as both the protected and recovery site. |
|
•
|
Replication Pause Time: The time to pause when synchronizing a VPG if continuing the synchronization will cause all the checkpoints in the journal to be removed. |
|
•
|
For incoming replication, copy the BIOS UUID of the protected VM to the recovered VM: Select this to preserve the BIOS UUID of the protected VM after recovery operations, in the recovery ZVM Site Settings window. |
|
•
|
Preserving of the BIOS UUID is not supported in Clone and Self-Replication recovery operations. |
|
•
|
Preserving of the BIOS UUID is not supported in Public Cloud. |
|
•
|
Cross replication is not supported. |
|
•
|
Allow SDRS for Recovery VRAs: Select this to allow SDRS for Recovery VRAs, so as to automate load balancing for Recovery Storage, including Journal and Recovery volumes. |
By default, Zerto activated specific VM override rule in the SDRS settings, for each VRA installed on a Datastore Cluster.
When this checkbox is selected, Zerto will actively remove the SDRS overrides for all the Recovery VRAs, and instead, the Recovery VRAs will be included in the SDRS policy configured in the cluster.
When SDRS in allowed in Zerto, for each VRA VM the following SDRS levels from vSphere are applied:
|
•
|
Automation Level: Fully Automated |
|
•
|
Keep VMDKs together: No |
!
Important:
When SDRS is enabled for Recovery VRAs, SDRS could automatically trigger a VMware Storage vMotion operation for disks which are attached to the VRAs, including Recovery disks and Journals.
During an svMotion, VMware prevents any volume attach/detach operation from being performed on the VM, to which the migrating disks are attached.
Therefore, if the Recovery VRA undergoes an svMotion, those VPGs targeting that VRA cannot be failed over until the operation is complete or manually canceled from the vSphere client.
Best Practice:
If you allow SDRS in Zerto, and if there are sensitive times when you cannot afford an automatically triggered svMotion interfering with a potential Recovery operation we recommend you exclude this sensitive timeframe from SDRS by configuring SDRS Scheduling in vCenter, at the Datastore Cluster level.
|
•
|
Recovery and journal volumes that reside on the host are not automatically migrated to another host in the cluster. |