A couple of weeks ago Zerto announced version 4.0 of Zerto Virtual Replication (ZVR). ZVR offers hypervisor based replication for VMware and Microsoft Hyper-V environments. ZVR also integrates with vCloud Director environments and since 4.0 even integration with Amazon Web Services (AWS) is supported.
Time to have a closer look at ZVR 4.0. The ZVR architecture is based on the Windows based Zerto management virtual machine and so called virtual replication appliances:
The VRA is responsible for the replication of virtual machine data and runs on your ESXi or Hyper-V hosts. You will need one VRA per virtualization host. The ZVM manages the VRAs and connects to your vCenter (VMware) or SCVMM (Microsoft) server. The VRAs require your VMs to be powered-on, VMs that are powered-off cannot be replicated by ZVR / the VRAs.
Most of the VMware features are supported by ZVR including storage vMotion. Support for Fault Tolerance is not available. For interconnecting sites you can use a site to site VPN, you can of course also leverage a flat LAN or stretched LAN configuration. NAT configurations are not supported.
Deploying Zerto Virtual Replication is pretty straight forward: Deploy the ZVM and connect it to the vCenter server, connect to the management UI, install the VRAs and configure site pairing.
(Of course this installation is normally preceded by determining the exact requirements for DR and a design which exactly reflects what has to be achieved).
Note that the installation also includes Zerto Powershell Cmdlets and a special Zerto VSS agent.
With ZVR 4.0 you can think of the following disaster recovery scenarios:
- Protecting Virtual Machines to a Recovery Site vCenter Server;
- Protecting Virtual Machines to the Same Site;
- Protecting a vApp (Via the VMware Web Client or Client Console);
- Protecting Virtual Machines to a Recovery Site Microsoft SCVMM;
- Protecting Virtual Machines on a vCenter Server to AWS;
- Protecting Virtual Machines to and From vCloud Director.
Disaster recovery using Zerto Virtual Replication enables recovering from a disaster to any point between the moment just before the disaster and a specified amount of time in the past, up to 5 days. If there is a requirement to extend the recovery ability to more than the 5 days that are available with disaster recovery, Zerto Virtual Replication provides an offsite backup option that enables saving the protected virtual machines offsite for up to one year in a state where they can easily be deployed.
Protecting virtual machines
ZVR works with so-called Virtual Protection Groups (VPG) for protecting virtual machines. A VPG is a group of virtual machines that you group together for recovery purposes. All virtual machines in a VPG are replicated to the remote site. After the initial synchronization, which can take a while depending on the size of the disks, every write is copied to the remote location.
The VPG wizard allows you to set the different replication, storage and recovery options for a particular protection group:
You can also set a virtual machine boot order within the VPG.
One of the settings in the VPG is the “Default journal history”, this is the time for which all write commands are saved in the journal. This allows you to recover to a point in time in case of a failover. The concept of this journal is something specific to the ZVR solution. Each protected virtual machine has its own journal created by a VRA. All writes are sent asynchronously to the recovery site and written to this journal, which are updated with a checkpoint time-stamp (more on that later in this article).
The ZVR dashboard publishes information on the replication status of your VPGs and shows if the SLAs are met.
In this case (taken from my homelab) the dashboard shows that 2 VMs are protected, the SLA is met and we have an average RPO of about 6 seconds. As you can see we have a near synchronous replication running!
Failing over virtual machines
Failing over virtual machines comes in different flavors with Zerto Virtual Replication. If you are familiar with VMware’s Site Recovery Manager, you probably know the options test failover, planned migration and failover. Zero calls these actions failover test, move and failover. On top of this there’s also an option to clone your VPG which results in creating a copy of the VMs in the VPG at the recovery site.
The journal ZVR creates enables recovering virtual machines to a crash-consistent point in time for the period configured in the VPG. An example is shown in the screen dump on the right, there’s a long list of recovery points available. This enables you to select the exact required state for a particular VPG in case of a fail-over.
After starting one of the failover actions, different options are presented such as:
- Which VPGs to failover;
- Which checkpoint to use;
- Shutdown VMs gracefully yes or no;
- and reverse protection after the failover.
If the failover requires a specific boot-order for the virtual machines, you have to configure this on a Virtual Protection Group level. Of course you can initiate a failover from both the protected as well as the failover site.
I hope this was helpful and this article gives you an idea of what ZVR is capable of. Stay tuned for more articles on ZVR and disaster recovery matters in general. Just follow me on twitter to get updated when new articles on published on this site.