We use Zerto to keep a replica copy of the core servers we have running at our backup site. In the case of an outage, we are able to flip over to our backup location. Zerto keeps these servers up to date within seconds and in the case of an outage at our core data center, we can flip over services with little to no data loss.
Mostly what Zerto gives us is peace of mind.
We do the normal backups and that data gets stored offsite, but unlike backups, Zerto gives us the ability to be back up and running within minutes on a copy of our servers that is an identical copy of what is no longer accessible.
The features we found most valuable is site-to-site replication. This is what we purchased the product for and what we use it primarily for. We are in the process of switching over our production data center and Zerto has been a true time-saver that has cost us zero downtime.
Some features are not up to what we need, although we have found alternatives and aren't really looking for Zerto to handle those items today.
The setup process is time-consuming.
We have been using Zerto for around four years.
With its built-in notifications and reporting, Zerto will alert you if there is anything wrong before it can become a problem.
Zerto works for one or one thousand machines and scaling out is an easy process. Zerto also seems to better support the major cloud vendors, with updates as well.
Zerto technical support has been very responsive and has always been able to help. They are available 24x7 and always have someone to contact you right away.
Prior to using Zerto, we were using VMware's SRS. It was not keeping a close enough copy of our servers.
The initial setup was very straightforward, but also a lot of information was needed. A fair bit of time was spent setting things up, but it was really just time-consuming. There was nothing that needed to be done by the vendor.
As far as setup and maintenance are concerned, you need to be sure to set it up properly, test it, and occasionally perform updates. For the most part, once it is in place it is pretty hands-off.
We implemented with the help of Zerto, who was very helpful in explaining the process and how everything works.
Zerto is not cheap but is an invaluable asset.
If you have the need for what Zerto can do for you then the cost really isn't a factor.
We only had experience with VMware's product and didn't know of anything other than Zerto. Once we tried the product we were hooked and never had a reason to look at anything else.
When we implemented Zerto, we only utilized some of the features. This was mostly because of our needs at the time and partially because the other parts were not up to what we needed. They have since greatly improved on these parts, like the backups features, but we aren't really looking for Zerto to handle those items today.
We have never regretted implementing Zerto and I would not trade it for any other product.
Zerto has been a great product for companies looking to deploy an easy to use disaster recovery solution. One of the limitations of the product was that it only worked with VMware vSphere, but not any more. Version 4 just dropped and it’s got a myriad of new goodies.
The most appealing new capability was the ability to fail over a vSphere environment to Amazon Web Services (AWS). This could save small businesses A LOT of money. Small businesses that have a disaster recovery requirement no longer need to have a dedicated co-lo and spend money on equipment when they may never use it. AWS provides compute, storage and network on an as-needed basis and most of the time, the disaster recovery site is not needed which correlates to savings.
Lets take a look at the Zerto architecture for vSphere to AWS. It requires a Zerto Virtual Manager (ZVM) at each site which manages the environment. The vSphere side also requires a Virtual Replication Appliance (VRA) for each ESXi host that will have virtual machines to replicate. The AWS side does not require a VRA.
One thing to be aware of is that the vSphere side and the AWS side will have two separate installers.
The AWS site requires the Zerto Cloud Appliance installer. This can be installed on a Windows-based host inside an EC2 instance. Most of the installation screens here are a basic information and the opportunity to change ports etc so I’ve left them out. The screen below however is some of the meat and potatoes of the installation. You’re asked for an IP/Hostname of the Cloud Appliance which it will populate for you. If you have multiple NICs on your EC2 instance, you could change it. The second part of the screenshot below is the Access Key ID which is a unique ID for an AWS owner. You can find these in the Identity and Access Management Section (IAM) in the AWS portal.
Once you click next, the installer will check to ensure windows firewall rules are open and the AWS Access Keys are valid.
The vSphere site hasn’t changed much from the previous versions. The Zerto Virtual Manager needs to be installed on a Windows server.
Once the ZVMs have been installed, we need to pair the local vSphere site with the Amazon site.. To do this we can login to the ZVM by using a web browser and navigating to https://ZVMFQDN:9669 . Here we see that we still need to install VRAs and pair to another site. Click on the “Sites” tab at the top of the screen to pair the vSphere site, with the AWS Site.
Enter the IP Address of the Cloud ZVM and the port and click “PAIR”. Note: for this to work properly, network connectivity must already exist to the Amazon Networks. In my case a Site-Site VPN tunnel was created.
Now you can see that a site is listed in the “Sites” section and that we still need to install VRAs. Click the “Setup” tab at the top to install the VRAs.
Select all of the ESXi hosts that will need virtual machines replicated and enter information to install the VRAs. Each of the VRAs is a small virtual machine that will reside on the ESXi host. Enter the root password for the ESXi host, a datastore to house the virtual machine, a network that has access to the AWS Site and the amount of VRA RAM needed. You will also need to enter the network information for the VRA so that it can communicate with the ZVM and the remote site.
When done, your “Setup” tab should look similar to the one below.
Now we need to setup our Virtual Protection Groups (VPG) this is the group of virtual machines that you are protecting. Click the “VPGs” tab at the top of the menu and add a VPG. A wizard will walk you through this as seen below.
I created a simple VPG called AmazonVPG.
Select one or more virtual machines to protect. You can define which order they should boot in if necessary.
Decide where the protected VMs should be replicated. I’ve only setup one other site, so it was automatically selected. Journal history determines how far back in time you can go to restore a virtual machine and “Test Reminder” just sends you an email if you haven’t tested the recovery in a while. The target RPO alert is only for alerting purposes. Zerto tries to replicate as fast as possible, so this is not a desired RPO setting, but rather an alarm to let you know that your RPO is not being met, probably due to too much replication traffic, or possibly a down WAN link.
The recovery menu allows you to define a failover network and a test network. The test network will allow you to have a completely separate environment for testing the failovers of virtual machines without affecting the production machine. These two networks can be the same or different depending on your preference.
When you’re finished with the wizard, you’ll notice that the VPG shows initializing and the Initial sync is taking place. Go grab a cup of coffee, the sync could take a while.
Notice that when the sync takes place, Zerto is utilizing an Amazon S3 bucket to house the virtual machine files. This should be cheap storage that can be used to dump the files until you need them.
You’ve done all the hard work. Our VPG is set up and its meeting it’s SLA. Now lets fail that server over to AWS. Click the “FAILOVER” button at the bottom right hand corner of the ZVM screen. NOTE: there is a toggle to change from a real failover which is disruptive to the protected virtual machine, and a test failover which is not disruptive.
Select the VPG to be failed over.
On the execution parameters screen you can change the checkpoint to which you fail over. Click Next.
When you’re ready, click “Start Failover Test”.
You’ll see the ZVM will have an action item taking place. When it’s finished you’ll notice that your EC2 screen has an additional virtual machine listed. Note: The failover process could take some time so be sure to test your RTO. The Cloud ZVM performs an import from the S3 bucket into EC2 and this process can take time.
When you’re finished with a “Test Failover” you can click the Stop button and you’ll be prompted with a window to enter a note about the test for record keeping. If this is a real failover scenario, there is no current failback built into Zerto 4 at the time of release. Failing back from AWS to your vSphere environment can be accomplished by exporting the VM and importing into vSphere. Look for this to change in future updates from Zerto.
I’m a big fan of Zerto and even more so now that they can replicate to Amazon. This product is very easy to use and administer and doesn’t require any sort of hardware appliance to handle replication traffic. It even does WAN optimization to cut down on the amount of bandwidth needed. If you’re looking for a orchestration tool for disaster recovery, you should check them out.
Good/accurate review of the product. As a fellow Zerto user, I concur with the findings.