5 Differences Between Zerto and SRM
By Zerto, on 21 January, 2013
This post was written by Shannon Snowden, Zerto’s Sr. Technical Marketing Architect. Prior to joining Zerto, Shannon designed and completed many SRM installations.
What are the differences between Zerto and SRM (with Array-Based Replication)?
In a previous blog post we compared Zerto with vSphere Replication. Admittedly, we knew it wasn’t a fair comparison, but it was in response to many questions we received after VMWare announced some changes to vSphere Replication at VMworld 2012.
A better comparison is actually Zerto vs. SRM (VMWare Site Recovery Manager) together with array-based replication. We frequently get asked to compare these two and although there are many more points on both sides, here are what we believe are five significant differences between the products.
1. SRM was built as an orchestration product, Zerto as a replication product.
SRM is an orchestration product that ties together a bunch of disparate components and streamlines workflows for moves and failovers. I often refer to it as the glue between vCenter, ESX, storage replication and storage. That’s what it was designed to do, and frankly, performs that task as well as any orchestration product could.
But, you can actually perform all the steps manually that SRM performs.
In contrast, Zerto was designed to provide replication at the hypervisor level that also provides automation of failovers and recoveries – and we do that better than anyone in the business. Here are more details of what Zerto does.
The workflow and automation configuration steps for moves and failovers are integrated seamlessly and the administration is very straightforward with Zerto since we don’t have to coordinate with other components to perform successfully. So, can you perform all the steps manually with Zerto? No you can’t. Since we are the replication mechanism, you can’t do that manually.
2. Only Zerto can restore from any point in time.
One of the more frustrating things we hear about SRM is the fact that even though an organization paid for storage replication that has point in time capability, SRM does not use points in time in recoveries or moves. If the last bit of data that was replicated is corrupt, you have to use some other mechanism like restore from backups or bypass SRM altogether and restore directly from the storage.
Zerto can be configured to go back as far as 120 hours for point in time recovery. We work with VSS and we can even get application-consistent checkpoints for applications like SQL, Exchange and Oracle on Windows and Linux platforms. You can manually create checkpoints as well.
But we do something else with the points in time that many of our customers love and frequently use. We can perform off-site cloning using any point in time you want to clone a machine or a group of machines in what we call Virtual Protection Groups or VPGs (see here for more information on VPGs). With our VPGs, you can take a whole application that is comprised of multiple VMs and do a point in time clone of the whole group of VMs at the same time and have a new test lab with the VMs ready to test at whatever point in time from which you want to start.
After you get your disaster recovery solution built, you really just want to start protecting virtual machines.
3. Zerto requires no storage configuration or reorganization, SRM does.
Even though SRM is ready to use, the first thing you have to do is either configure the existing production LUNs or volumes with the VMs you want to protect to be replicated, or you have to create new volumes and move the VMs over to the newly created replicated volumes. You need to move these VMs prior to configuring the Protection Groups in SRM because if you storage vMotion the VMs to your new replicated LUN, you have to go into SRM and reconfigure it because SRM doesn’t play well with storage vMotion.
What we find with customers that go from array-based replication either with or without SRM, they usually reduce their LUN count significantly because they don’t have to create extra LUNs specifically for replication. For VMs that are not protected, they are put on non-replicated LUNS and the VMs they want protected have to be moved to replicated LUNs. They often have to match the spindle count, disk speeds and configuration of the current LUNs or volumes in order to keep the performance as expected.
SRM requires a lot of work before you can actually protect the first VM.
For Zerto, underlying storage and LUN configuration is irrelevant, so setup is simple. As soon as you complete the Zerto installation, which usually takes about an hour, all you do is create the above-mentioned VPGs (it’s a couple of clicks to create) and start adding VMs into the VPGs. Once that is done, replication is happening.
If you have several TBs of data to replicate, you probably don’t want to initiate that replication over the wire. Zerto can leverage pre-seeded VMDKs at the target site. Often our customers or our Cloud Partners copy the VMs to a portable disk, take it to the target site and copy the VMs to the datastores where they want the VMs to run when they are failed over. During the VPG creation or editing, you can granularly select an individual VMDK in a VM and pre-seed map it to the VMDK you copied at the remote site.
Once that is done, only the changes are replicated across the wire. You can actually have a VM with TBs of data fully protected with just seconds of RPO between the sites in just a few minutes with the pre-seeding option.
4. SRM requires the same storage arrays and VMWare versions; Zerto does not.
This is where SRM is challenged not necessarily because of the SRM product itself, but by the nature of what it does. Since it’s coordinating multiple components like chain links, (storage, path software, array-based replication, SRAs, SRM, vCenter) at each site and each link in the chain has to be at a matching firmware, driver and software level, there are many opportunities for incompatibility during configuration.
Moreover, after you get it successfully operational, each of these components require updates and patches. It can introduce instability into a functioning SRM solutions. You will find support articles for each of the links in the chain that have caused SRM to fail. You will also find frustrated admins looking for the right throat to choke and they are getting passed between software and hardware vendors.
Zerto is a solution built from the ground up for hypervisor-based replication – and with workflows integrated, we don’t really depend on any other components to perform our core functionality. So that significantly narrows the window of opportunity for incompatibility between our own products working together. When issues do arise, you have only one place to call and our Support team is on it immediately.
But we are very proud of the fact that we often hear the comment, “Your product actually does what you say it does.”
5. Zerto is multi-site, anywhere to anywhere replication; SRM + array based replication is too expensive for many-site replication.
Amongst the additional configuration and ongoing support operations for array-based replication with SRM, it is not a cheap solution. So the companies that have it usually only have two sites in their DR plan. A primary and recovery site. It normally isn’t practical to have more than two sites with SRM.
With Zerto, you are not constrained to what the array can replicate, so you can create an anywhere to anywhere replication scenario. You can go between your own sites or some combination with a cloud service provider. You can easily replicate data to and from a new data center in the environment, for example, new entities from a merger or acquisition. You simply pair a new site by adding in the peer site’s IP address, create a Virtual Protection Group (VPG) and start replicating.
It really doesn’t matter to Zerto where you are replicating as long as you meet some very basic requirements.
1. You need a vCenter at each site.
2. You need ESX 4.x (and up) hosts.
3. You have network connectivity between the sites.
Zerto can go between vCenters and Zerto also is the only fully integrated vCloud Director solution on the market today – including SRM.
We hope you find enough reasons here to go get a free trial of Zerto for your Disaster Avoidance, Disaster Recovery and datacenter moves. We also hope you will find this post treated SRM fairly. Our goal is to highlight the differences between the products. Just as we did with the vSphere Replication post, we invite corrections to any technical errors to points we made in this post.