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.