Differences between Azure site Recovery (AZR) & Zerto Virtual Replication (ZVR)

Cloud consumers generally ask “What are the differences between Azure site Recovery (AZR) and Zerto Virtual Replication (ZVR)?’” The very first reason consumer ask this potential question is because they are familiar with one of the technologies and not the other and on the surface, they sound similar.

Here’s our step by step guide, why ASR and ZVR are very different from each other and meet different levels of performance and usability. 

scott-webb-247900-unsplash

Azure Site Recovery (ASR)  and Zerto Virtual Replication (ZVR) are both great products that can help any IT organization to improve the success rate of their disaster recovery plan. The purpose of this document is not to be a kill sheet for one or another product, but rather to highlight the pros and cons of each product in relation to VMware virtual machine replication in the public cloud of Microsoft Azure.

Both products are very capable of fulfilling the above-mentioned task at a high level, but as this article will show, each product has advantages over the other depending on the workload that needs to be protected.

For example, while it takes a little more time to initially configure Zerto Virtual Replication, it includes more time – saving workflows not only for disaster recovery but also for migration and testing. Failback is also another area where Zerto shines above ASR as the required networking is already configured and a single check mark can be used to enable reverse replication.

One of ASR’s major advantages is that it can protect Azure’s physical workloads. Zerto has no support for physical workload and is limited in terms of supported workloads from the source. Today only the source is supported by VMware vSphere and Microsoft Hyper – V. In theory, if the operating system is supported in Azure, any physical or virtual machine can be replicated with ASR. This is because both physical workloads and workloads based on VMware are based on ASR. 

The installation requirements for each product are unique and ASR is a clear winner in terms of ease of installation and speed for customers who only need to protect some VMs on a single Hyper – V host. But as the number of protected workload increases, the necessary ASR infrastructure can become overwhelming and the scalability ease of ZVR becomes much more evident.

When compared to a monthly subscription bases, ASR and ZVR are very similar in terms of costs. ASR’s list price is $ 25/month per protected VM and ZVR is approximately $ 21/month per protected VM. Both solutions also require you to pay for the storage that your replicated workload consumes, but for Zerto there are a few additional costs that ASR does not need.  One such cost is the compute instance running the Zerto Cloud Appliance, and the other is the cost of connecting to a VPN or ExpressRoute. So, remember that ZVR may be richer in features, but it may also cost a little more than ASR as well.

Azure Site Recovery

Four major components are needed to replicate the Azure Public Cloud from Azure Site Recovery on – site. These components are downloaded and installed on a Windows machine in your on-site datacenter from the Azure Vault configuration wizard.

A Config Server is the first server you install. A Config Server is a central administration server that communicates with the Azure Vault and performs on-site jobs. Two other components, a Process Server and a Master Target Server, will also be installed on your main Config Server by default.

The component of the Process Server is what processes and transports the protected data to the Azure Vault. Depending on the size of the workload to be protected, process servers have CPU, memory and disk requirements. If a single Process Server is unable to scale up large enough to protect your workload, it is possible to take a scale-out approach and deploy additional process servers.

Master Target Servers are required only during operations of failback. It should be noted that a Master Target Server can only fail servers of the same type of operating system so that a Windows Master Target Server cannot fail Linux servers. A Linux Master Target server also needs to be installed for Linux servers.

A Mobility Services Agent is the last component of the ASR topology. This agent is installed on each virtual machine that is protected and is responsible for sending changed data to the Process Server so it can be shipped to the Azure Vault. In summary, ASR installs multiple premise components that differ depending on what workloads you are planning to protect. The amount of planning and the number of components may be acceptable for small to medium-sized deployments. A customer may have to invest large amounts in planning for larger deployments as it will require more than one process server and more than one master target server. This can make deployment more complex and means you have to maintain multiple machines.

Zerto Virtual Replication

Zerto has two main components, Zerto Virtual Manager (ZVM) and Zerto Virtual Replication Appliances (VRA). Each physical host in your environment receives a VRA if it contains protected VMs or receives data for protected VMs. This usually means that all hosts in a cluster will receive VRAs.

For multi-site deployments, each site receives a ZVM and for each of the physical hypervisor hosts, clusters with protected data receive one VRA.

Zerto leverages a combined ZVM / VRA architecture called a ZCA or Zerto Cloud Appliance for public cloud sites such as Azure and AWS.  For Azure, the ZCA can be deployed from the Azure Marketplace or you can build a MyZerto installation package from scratch with a Windows VM and Zerto for Azure.  Since the ZCA uses an embedded VRA, the only way to scale Azure’s replication capacity is in a fashionable scale. So an additional ZCA will have to be deployed once a ZCA has reached its maximum (about 100MB / s throughput).

In summary, the architecture of Zerto contains the same number of components regardless of how many on-site VMs you protect. Planning is also straightforward because it scales along with your environment, which means that if you add an ESXi host or a Hyper – V host, you also add a VRA.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s