I recently showed you how to get vSphere Replication working in your environment. That is something that many of you have already due to the VMware package you purchased. But if you need more functionality and scalability, including more then replication, you can (and should) look at Zerto Virtual Replication. In this article I will show you how to get it working.
Zerto is a software product for replication but also more oriented to Business Continuity (BC) and Disaster Recovery (DR), therefore they talk of protecting a virtual machine or failing it over rather then replicating it. While this is important functionality, I think it important also to work with and understand Zerto as a replication product as well. In this article we are not going to cover off the DR side but rather get up and going with replication in a PofC situation. If there is need or interest I will do remote replication in a separate article, followed by the DR aspect of things.
BTW, when our storage array (remember I work for DataGravity) ships it will be 1.0 and so will not have replication. What I am showing here is a very good way for you to get replication for your virtual machines on the array when it first ships.
- Documentation can be found in the support portal accessed via here. In particular the Zerto Virtual Replication Installation PDF is very useful – it got the infrastructure all done but nothing on the act of replication. So then we used the Zerto Virtual Manager Administration Guide for the rest.
- Bits can come from the same support portal mentioned above.
- We need a Windows VM, where I will use Win2K12 and it needs a static IP. I suggest making sure it is patched completely current. The machine should have two vCPU and at least 8 GB of RAM.
- We need a service account that is a Domain User as well as a vC admin. It will also run the ZVM service and it needs to have local admin rights (on the VM where ZVM is installed).
- While Zerto supports a range of vSphere hosts and vC I am using the current GA of vSphere 5.5 Update 2.
- Zerto can work a variety of models such as replication between sites (and vCenters), or within a site from a host to a host. In this article we will cover off host to host replication.
- Time is critical for Zerto as it is for VMware and Microsoft too so make sure you have first consistent time and second correct time.
- Each of the Virtual Replication Adapters can use DHCP but in fact should use a static IP – which I am doing so need IPs for each – as you will learn below I suggest one VRA per host in a cluster so static IP for each which in my case is four.
- Component info (and acronyms too) that are useful
- Zerto Virtual Manager (ZVM) – Windows server that manages almost everything except the actual replication. It talks to vC as well.
- Virtual Replication Appliance (VRA) – this is a virtual appliance that is installed on each ESXi host that is protecting (or replicating) virtual machines. It manages the replications.
- Virtual Backup Appliance (VBA) – this is a Windows service, which manages backup-ups within Zerto Virtual Replication. It runs on the same machine as the ZVM and manages repositories where offsite backups are stored. This would be local or a shared network location.
Installation – Zerto Virtual Manager
This will get the main management of Zerto up and running and allow us to start doing things like preparing for replication. It this article we are doing local replication so we have only one vC, and will have both the ZVM and VBR on the same machine.
- We will use the Zerto Virtual Replication Installer.exe file to start things off.
- We see a welcome screen (as always you can click on the images for a larger version).
- We will skip some screens that are less then interesting. The next one we see is Destination.
- Nothing so far too different or even that interesting. But it does get a little more interesting next.
- Now it turns out I have read the manual, and thought about things, and we really only need the Express choice. But, we are still going to do Custom as it is likely a little more interesting. And this has nothing to do with how in the image it said this choice was only for advanced users – insert smile here.
- We are not going to make any port changes. Advanced we are but not silly.
- Now we add the info that the ZVM service will run as.
- I think normally you should use the embedded database.
- Now we connect Zerto to the vC. The install guide shows a nice vSphere Web UI for Zerto. Not sure if it will work as there is some indication it will work but break other things. I will test and see how it goes.
- Next up is if you want vCD to be protected by Zerto. Pretty cool but I have no vCD.
- We next have a nice Check Prerequisites screen that shows everything good. Interestingly it is not true for me. But more on that later.
- It would be nice if we had links to more detail on these rules but I do like the idea and presentation.
- Now it configures the product.
We now have Zerto installed. I did have an issue. I created the service account as a domain user, and as a vCenter admin. I used it for the ZVM service and it could not stay running. Once I added that service account to the local administrators group it ran fine.
Post Install Configuration
We need to do a number of things as part of the post install steps. The first is license. But lets get started.
- Connect to the ZVM service. It is https://fqdn:9669 if you have DNS done and did not change the ports.
- You will authenticate with a vC account. That caught me by surprise but it worked. I used my normal vC account which is in fact a vC admin account and it worked fine. The first thing that happened was it asked me to license. Now where is that damn license?
- Need to take a break to find the license. Found it.
- Once we hit the Update we actually get something unexpected.
- Yes, a video. Not bad one but is marketing oriented. Once you select it to not show on start-up – bottom left corner, and put it away what you see is what we need.
Installing a Virtual Replication Appliance
This appliance is actually an ovf template and it must be installed on each ESXi host that is protecting (read replicating) virtual machines as well as the destination hosts in recovery site. This very small appliance can handle a max of 500 protected virtual machines and it can do data compression through the WAN connection.
The VRA has a very small footprint of 12.5 GB in disk, and 1 GB of memory. It needs an ESX/ESXi 4.o U1 host or greater. It will enable – during the install – ports 22 and 443 on the host – I can confirm they were not open when we were done.
We need to install the VRA on each host so that if DRS triggers any vMotion that the protected virtual machines are still protected.
BTW, watch the Alarms area for anything you should be aware of. It is seen in the top left corner of the screen where you work. You see it below showing No Alerts and the site name.
But lets get started, as I am eager to replicate my first machine!
- You likely are still on the main screen.
- Click on the Manage VRAs button.
- You will end up on the Setup \ VRAs screen.
- Now we need to highlight the hosts in our cluster and use the Actions \ Install option so we can install the VRA. See what that looks like below. It does look like you can work on multiple hosts at a time but that is not correct.
- We now need to fill in a variety of information.
- Once you hit Install something happens.
- So lots of things in progress. When it is done it looks like below.
The VRA is now installed on each host so a protected virtual machine will still be protected after vMotion activities so that is good! I had small green circles during the install but once things were done it is was yellow for each of the VRA.
I check the Alerts and Events tab to see if I could learn something. I also see the the No Alerts now shows four alerts.
So this makes sense to me – sort of. The VRA expect to be paired with another site but I am only going to do local replication this time. Which is a supported used case. Wait – the VRA status are all green again. Oh well. Think I may have been moving to fast?
Back on the Setup screen if you click on the VRA you will get an interesting screen.
If we change back to the Summary screen it looks different now.
Nice overview screen. We will now move on to replication!
Since we are not doing remote replication but rather local replication at this time we need to enable that functionality within Zerto.
Starting at the Summary screen we need to access the settings.
It can be found in the top right corner as a gear.
Once you click on it you will see the following settings screen.
We need to select Advanced Settings.
Once there look for Enable replication to self. It needs to be enabled.
Once enabled hit the Save button and then close the Site Settings window. We are now ready to replicate within a data-center.
As background information you should understand that you can protect (or replicate) a single virtual machine, or you can replicate several virtual machines together. This is an important concept. An application is often composed of a variety of services and it is best to protect – if possible – those services that compose an application together. When multiple virtual machines are protected together that is called virtual protection group (VPG).
We start on the summary page.
- We use the New VPG button near the top right. We see something like the following.
- We need to fill in this screen. Remember that Zerto is a DR product so there is more information required then in other replication products as they are capable of doing more. The VPG SLA likely should stay the same, as too the DR Properties, but you should fill in the Settings as that will determine where your VM will end up. See below for an example.
- We need to add a virtual machine to this VPG. I will only select one at this time so I can more quickly see how this application will work. Use the +Add button to locate and attach a VM to this VPG.
- I like how there is a search bar at the top in case you have lots of virtual machines.
- Once you select a virtual machine you will see something like below.
- There is a lot of interesting things on the screen. You can see the parameters of where your VM(s) will end up, as well as do things like set boot order, and even pre / post scripts. That is all part of the BC/DR aspect of Zerto. Make sure to fill in the Test network field properly. It will allow you to test your replication without impact to your production copy of the VM(s).
- Once you hit save you will see a new screen.
- We will start with creating the VPG, but then see it start with an initial sync on the VM(s).
- We start to see things a little better as more of the copy is done. ETA is available at the top but also it is interesting to see the recovery data size in this case as it is only 11.1 GB when the original VM is 120 GB provisioned. Once the replication is finished we will see the previous screen updated.
- This shows that our VM is replicated and that is good. It shows a lot of other info too that would be very good if this was a DR project.
Testing replicated VM
We need to make sure the VM we have replicated is in fact replicated properly – right? So we need to test it.
You can test in a test network or you can test in the production network. It is a very important difference but with a very small impact on the process. Being able to test during production work time is very handy but of course you cannot impact production applications. That is why when we protected the applications – or rather configured VMs for replication we had a test network selected. This would allow us to do a very realistic test but on a private and non – routed network.
- Lets start on the VPG group tab. In the bottom corner of it you will see a Failover arrow.
- Notice how it is set for test currently? That is good for us as that is what we want to do. Lets start the test with a push on the Failover button.
- Once pushed a wizard starts.
- In my simple lab there is only one VPG so it is an easy choice.
- We only see one checkpoint but that makes sense as I have not had the VPG for long.
- We see the Summary screen and use the Failover button in the middle of it.
- It doesn’t take long and now I see a number of red items.
- The red is to tidy up after a test. We need to change out to the vSphere Web Client and look for the VM that was in our VPG.
- Number of things to notice here so I have highlighted them. Notice the suffix added to the VM name. Better then a prefix so it is easy to find. Notice the network it is on? The production copy of this VM is on the VM Network 10 G but this one is on the Storage network so no conflict. Also note that there is no tags? This is a VMware issue since they are not kept with the VM but outside the VM so they don’t ‘travel’ with the replicated VM.
- If we had several VM’s in the VPG we would be able to test the application and have them talk to each other but no one else. Great way to test.
- We also had a Move option as well. But it is always good to test for DR, or for moves.
- Once we are certain that the VM or VMs are good and the test is successful we can clean up.
- We are going to use the Stop Failover Test button near the top of the screen. Once pushed we will see the follow.
- This is a handy screen as we might have a variety of tests on the go. I also like seeing how long the test was on.
- I will use the Stop Selected button in the bottom left corner.
- It doesn’t take long to clean up.
- Once done, you can check the vSphere Web Client and see the test VM gone too.
BTW, you can find the reports on test failovers and in it you can see what we just did. The PDF report that can be generated has a lot of good info in it on the test.
This means we can test a replicated VM and prove it. Nice.
Things to be aware of
- Don’t use VMware Snapshots with the ZVM machine or Zerto appliances. It interferes with the operation of Zerto – according to the manuals.
- If you are doing site to site you will need a minimum of 5 Mb/s for bandwidth.
- The C# client is integrated with Zerto right after the install. Here is what it looks like when I select a VM (Admin-1) and change to the Zerto tab. BTW, it was hard to get this to work. It needs flash, but it had to be flash installed via IE for the C# client to be able to see it and use if for Zerto.
- You can use PowerShell to interact with Zerto and you can find more about that near the end of Chapter 1 in the Zerto Virtual Replication Installation Guide. It turns out there is also a REST API you can use to work with Zerto which opens up some seriously interesting possibilities.
- I suggest you enable email notification in Zerto and get daily at first, and weekly later backup reports to help you be proactive about managing Zerto.
- The replication we have done through this article is crash consistency which is pretty good for many applications. Zerto has an agent that will provide a higher level of consistency but it is not true application consistent as it doesn’t do things like manage logs. For the ‘average’ VMs you may not need the agent but certainly you should test to confirm where it is needed.
- It is important to understand that when testing, or moving, you have a 5 day journal of checkpoints to utilize. If this is not good for you there is a way to change that – using Offsite Backups that I will provide the info on implementation in another article if there is need, or interest.
This is an interesting product. It has a good UI, and it seems to replicate well too. It even has some DR capabilities built in and they are nice. There is a lot more to Zerto then what we looked at here and that is pretty good too. For DG users who need replication and a bit more, then Zerto is a good choice for them. This article was written with the source storage of a DG appliance. Thanks very much to Zerto (and thanks to Shannon) for the help and license.
Thanks for checking out this article – and let me know if you have any questions or comments.
Update 10/23/14 – made several things more clear.
Update: 9/19/14 – forgot to mention the 5 day journal of checkpoints so added above.
=== END ===