Today, Zerto released a field notice for customers running Zerto 5.0 or 5.5 in VMware vSphere environments. The issue pertains to duplicate MoRef entries residing in the Zerto Virtual Manager database. These duplicate entries are being created by the ZVM or by the installer during an installation. Alone the presence of duplicate MoRefs doesn’t cause the issue. However, certain tasks or changes on the duplicated object can cause disruptions to synchronization or replication. This could force VPGs into an error state; consequently, rendering them unrecoverable. Zerto states that some environments may contain duplicated MoRefs, but not be impacted. Regardless, they recommend users on ZVR version 5.0 or 5.5 to upgrade to version 5.5U2P2. P2 will identify and delete duplicate entries. If you are unable to upgrade, Zerto Support can aid in identification and further mitigation of the issue.
ZVR Affected Versions: 5.0, 5.0 U1, 5.0 U2, 5.0 U3, 5.0 U4, 5.5, 5.5 U1, 5.5 U2
What is a MoRef?
Managed Object References are unique identifiers given to all objects in a vSphere environment for identification and tracking purposes. MoRef’s are designated by the object type followed by an identification number. For example, vm-110 or host-95.
Earlier this month, Zerto announced the release of ZVR 5.5. Today, Zerto hosted a keynote webinar to kick off the release. They keynote introduced some valuable new features, but where version 5.5 excels is in the further development of existing offerings; namely cloud continuity. Several enhancements to Azure and AWS offerings highlight Zerto Virtual Replication 5.5.
Azure and Zerto 5.5
In Zerto 5.0, the ability to replicate to Microsoft Azure was introduced. In version 5.5, bi-directional replication possible as you can now replicate back on-prem from Microsoft Azure. Replication with Azure now supports an array of features, including failovers, offsite clones, 30-day journals, and file restores from Azure journals.
Amazon Web Services and Zerto 5.5
Zerto 5.5 improves on their AWS offering by boosting recovery times. With the new zImporter feature, RTOs can be increased by up to 6x. Import Options now include:
Here is an issue more on the obscure side; nevertheless, it may prove beneficial to someone, somewhere, at some point. The issue pertains to a SQL database going Suspect after a Zerto Failover. To adequately explain the cause, we will first look at Microsoft SQL Server best practices for both VMware and Zerto.
Let’s start with VMware best practices. Assuming the back-end storage is spinning disks and the virtual disks reside on VMFS volumes, VMware recommends separating SQL files. Meaning, SQL Server binaries, SQL data (mdf), SQL transaction logs (ldf), and tempdb files are placed on separate VMDKs. Since SQL Server accesses all that data in different I/O patterns, separating their files helps minimize disk head movements and limits I/O contention; thus optimizing storage performance. The disk configuration in the affected environment looked like this:
In the past, I’ve discussed a few of my favorite features in Zerto; however, a recent feature that flew under my radar was the support for Host Remediation using VMware Virtual Update Manager. If you utilize Zerto in your VMware environment, you may have run into an issue using maintenance mode on hosts with Virtual Replication Appliances (VRA).
First, a quick background. Zerto VRAs are virtual appliances deployed to handle the continuous replication between protected and recovery sites. These VRA’s are typically installed on each ESXi host to perform data compression and transportation across your WAN.
Versions prior to 5.0 required VRAs to be manually shut down for a host to successfully enter maintenance mode. As you can probably tell, this manual shut down process posed an issue for admins who were automating maintenance mode tasks across their environments; notably remediation through Update Manager.
To address this matter, Zerto has incorporated support for host remediation in release 5.0 U1. Now, when a host is put in maintenance mode, Zerto monitors the host’s workload to ensure all machines have been migrated or powered down. Once the workload fits maintenance criteria, Zerto will signal the VRA to shut down; thus, allowing the host to enter maintenance mode. Conversely, once the host exits maintenance mode, Zerto automates the power on of the VRA. As machines are migrated back to the host through further remediation, the powered on VRA is prepared to handle their replication.
Enabling this feature is simple and can be done directly from the Zerto Virtual Manager.
Update – Big thanks to vBrownBag for guest posting this article on their blog!
A few weeks back, we discussed Zerto’s ability to perform point-in-time file level restores directly from the replication journal. However, what if the data you need from 30 minutes ago isn’t readily compiled into a file or requires manual intervention to produce; such as a database backup or a PST export of Exchange mailbox items? Introducing Zerto Failover Tests for data recovery.
A Zerto Failover Test has the ability to spin up a virtual machine from a specific point-in-time to an isolated network. From there, data can be manually compiled and exported.
Although the failover test process is more step intensive than a File Restore, it still addresses a vital need for many organizations; having that ability to restore application data from a specific moment. When compared to traditional backups, the ability to restore data seconds before corruption or loss is critical.
In this walkthrough, we will focus on a database backup and recovery. To do so, we will perform a failover test to an isolated network, backup the database, and finally, extract the SQL database to our production location. As this particular test network is completely isolated, we will be using VMware PowerCLI to extract the backup file.