In last post of this series we had a look at various dashboards from where we can monitor zerto. Also we learned how to create custom dashboards as per requirement to view very specific details.
In this post we will learn about some advance configuration settings that we can do with zerto. These advance settings are skipped while performing an express install.
If you have landed directly on this page by mistake, then I encourage you to read earlier posts of this series from below links:
1: Zerto Architecture and Components
2: Installing Zerto Virtual Manager
3: Installing Zerto Virtual Replication Appliance
4: Creating Virtual Protection Group
6: Move VPG from Protection Site to Recovery Site
Lets get started.
1: To configure advance settings, login to ZVM interface and from top right corner select “Site Settings”
2: Cloud Settings: If you have a vCloud Director based cloud in your on-prem or if you have a vcloud based cloud subscription, then you can configure the settings here so that you can use zerto to replicate your workloads on a vCD based cloud.
3: Bandwidth Throttling: In case where you do not have a dedicated bandwidth reserved for your DR workloads, and you are using shared network infrastructure and network team is only allowing to use a specific percentage of total bandwidth, then you can configure those settings here.
Say for example, out of 100 MBPS, you are only allowed to use 15 MBPS for zerto replication, you can uncheck the unlimited checkbox and enter a value here.
Note: Minimum supported bandwidth is 5 MBPS.
If you are going to protect virtual machines on this site as well as recover virtual machines to this site, for example via failback, you also have to set the bandwidth on the peer site out to this site.
Time-based Bandwidth Throttling
Bandwidth throttling can be made more granular by enabling time based throttling. Here you can define the time period when bandwidth throttling is actually needed.
Example: You can set the max bandwidth that zerto replication can use to 10 MBPS during business hours (09:00 AM to 06:00 PM). Post business hours, whatever bandwidth is available can be used for replicating workloads.
4: Site Policies
Failover/Move commit policy: You have 3 options available for comminting the uncommited transaction when you test recover a VM or move a VPG from one site to another:
- 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, unless manually committed or rolled back by the user before the time-out value is reached. During the specified time you can check the recovered VPG virtual machines.
- Rollback: After the time specified in the Default Timeout field the failover or move operation is rolled back, unless manually committed or rolled back by the user before the time-out value is reached. During the specified time you can check the recovered virtual machines in the VPG.
The value set here applies as the default for all failover or move operations from this point on but can be changed when defining a failover or move operation.
Default Timeout: Duration after which a Commit or Rollback commit policy is performed. A value of zero indicates that the system will automatically perform the commit policy, without waiting for any user interaction.
Script Execution Timeout field: Timeout in seconds for a script to run before or after a failover or move operation.
5: Replication Pause Time: This is the amount of time for which synchronization is paused when the number of checkpoints in the journal becomes too small. During this time, transfer of data from the protected site to the journal on the recovery site is paused.
Why you need this?
During synchronization, the latest changes in the protection site are added to the journal and older data in the journal is moved to the mirror virtual disk managed by the VRA for the virtual machine. As the synchronization continues and more old data is moved out of the journal, the checkpoints associated with the data are also removed from the journal and new checkpoints are not added to the journal.
If the synchronization continues for too long, all the checkpoints can be removed from the journal meaning all recovery operations, test failover, move, and live failover, can no longer be performed. By defining replication pause time, administrators can resolve the above mentioned issue.
6: Email Settings: By configuring email settings, you can send the alerts produced by zerto to your monitoring DL so that the monitoring team are immidiately informed when your environment is experiencing issues with replication etc.
You need to define your smtp server name and default port used for sending email. Also you need a “To and From id” for sender and recipient. Make sure to checkmark the box “enable sending alerts”
And that’s it for this post.
I hope you find this post informational. Feel free to share this on social media if it is worth sharing. Be sociable 🙂