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

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.

Zerto

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.

SRM

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

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.

SRM

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.

Zerto

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.

SRM

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

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.

SRM

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.

Zerto

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.

8 comments on “5 Differences Between Zerto and SRM

  1. Pingback: 5 Differences Between SRM and Zerto | Virtualization Information

  2. Mohammad
    Reply

    Thanks for the detailed comparative analysis.
    I am impressed with Zerto’s benefits, precisely the multi-storage vendor replication approach.

    I have quick questions,
    1. What is the overhead of the facilitating data replication (block level) on hosted hosting ESX host? Can you share some data on that?

    2. Well, my understanding after watching all the videos and going through the documentation is the product is only compliant to VMWare hypervisor. This is a limitation when we look at Zerto for public and hybrid cloud centric DR solution for in-house hosted VMs. The target environment has to be VMWare hypervisor. Therefore, I cannot use AWS EC2 as it is Xen hypervisor.

    What’s the workaround?

  3. Reply

    Thanks for your comments Mohammad. The host overhead depends on the number of volumes that are being replicated, but a general range would be 2-5% overhead at the host level.

    We are currently focused on the VMWare hypervisor, but have other hypervisors on our product roadmap. Zerto has enabled Cloud Service Providers to offer very competitive private, hybrid or public clouds for DR. Take a look at http://zerto.com/cloud-service-providers/ and you will see a portion of the growing number of Zerto-powered DR clouds.

  4. Nandakumar
    Reply

    Hi Shannon,
    How soon can we expect support for Xen/other hypervisors and integration with platforms such as Openstack/Cloudstack, I hope its there in your roadmap.

  5. Matt Thomas
    Reply

    What is the specific maximum number of VMs supported by Zerto? I am looking for the exact maximum number, not “dozens” or “hundreds” or “thousands”. Thank you.

  6. Zerto
    Reply

    Thanks Matt – the specific maximum number of VMs supported by Zerto Virtual Replication 3.0 would be 5,000 VMs per vCenter.

  7. Nestor Urquiza
    Reply

    I am wondering how consistency is achieved for applications running non VSS compatible systems?

    Typical examples are couchdb and mysql running in Linux or applications relying heavily in Linux file system (ext3) r/w and Solaris ufs hosting proprietary memory databases which swap whole segments to disk every so often.

    Thanks for your time. It is highly appreciated,
    – Nestor

  8. Zerto
    Reply

    Hi Nestor,

    Thanks for your comment. We have a Linux script that gets an application consistent checkpoint once the application is quiesced. For example, we have customers with large Oracle DBs running on Linux and when Oracle Backup quiesces the DB, ZVR gets an application consistent checkpoint.
    I hope that helps.

    Thanks,
    Shannon

Leave a Reply

Your email address will not be published. Required fields are marked *


*