|
General
|
|
|
- Fully Supported
- Limitation
- Not Supported
- Information Only
|
|
Pros
|
- + Support for stretched clusters
- + Support for storage replication
- + Support for VVOL
- + Support for VMware Cloud on AWS
|
- + Broad on-premises protection scope
- + Profound Azure integration and support
- + Consistency across multiple VMs
|
- + Extensive cross-platform and storage support
- + Consistency across multiple VMs
- + Ease of deployment
|
|
Cons
|
- - No support for native public clouds
- - No support for fan-out topologies
- - No consistency across multiple VMs
|
- - Guest agent required (Physical/VMware)
- - Weak reporting capabilities
- - Singular public cloud support
|
- - High pricepoint and no price tiers
- - No support for stretched clusters
|
|
|
|
Content |
|
|
|
|
WhatMatrix
|
WhatMatrix
|
WhatMatrix
|
|
|
|
Name: Site Recovery Manager
Type: Software-only
Development Start: Unknown
First Product Release: 2008
VMware was founded in 1998 and began to ship its first BC/DR solution, vCenter Site Recovery Manager, in 2008. SRM was designed to exclusively support VMware environments. The initial SRM release, version 1.0, offered VMware ESXi 3.0 support. In 2015 vCenter Site Recovery Manager was rebranded to Site Recovery Manager. The release of SRM 8.1 in 2018 introduced support for VMware Cloud on AWS support.
The worldwide customer install base for VMware SRM is unknown.
|
Name: Azure Site Recovery
Type: Software-only
Development Start: Unknown
First Product Release: 2014
Microsoft, founded in 1975, released its first Disaster Recovery solution, Windows Azure Hyper-V Recovery Manager, in January 2014. The product leveraged Hyper-V Replica to replicate the data from one on-premises data center to another on-premises data center and could orchestrate a failover. Already in June 2014 the name was changed to Azure Site Recovery (ASR) in order to reflect the broader scope of the product. This preview version provided failover support of Hyper-V VMs to the Microsoft Azure public cloud. In October 2014 ASR went GA (Generally Available).
In July 2015 ASR added protection support for VMware vSphere and Physical (Bare Metal) Servers. Finally support for protection of Azure IaaS VMs was introduced in June 2018.
Customer install base and number of employees working on ASR are unknown at this time.
|
Name: Zerto IT Resilience Platform
Type: Software-only
Development Start: Unknown
First Product Release: 2011
Zerto was founded in 2010 and began to ship its first Business Continuity / Disaster Recovery (BC/DR) solution, Zerto Virtual Replication (ZVR), halfway 2011. The first 3 major versions only supported VMware vSphere. ZVR 4.0 introduced support for both Hyper-V and AWS. ZVR 5.0 added Microsoft Azure to the list of supported platforms. In 2018 Zerto rebranded its BC/DR offering to Zerto IT Resilience Platform (IRP).
In April 2019 the company had a customer install base of about 6,000 Zerto customers worldwide and there were more than 700 employees working for Zerto.
|
|
|
|
Assessment |
|
|
|
|
Release Dates:
SRM 8.2: may 2019
SRM 8.1.2: apr 2019
SRM 8.1.1: nov 2018
SRM 8.1: apr 2018
SRM 6.5: nov 2016
SRM 6.1: sep 2015
SRM 6.0: mar 2015
SRM 5.8: sep 2014
SRM 5.5: sep 2013
SRM 5.1: sep 2012
SRM 5.0: sep 2011
SRM 4.1: jul 2010
SRM 4.0: oct 2009
SRM 1.1: dec 2008
SRM 1.0: jun 2008
11th Generation software.
|
Release Dates:
ASR UR40: sep 2019
ASR UR39: aug 2019
ASR UR38: jul 2019
ASR UR37: jun 2019
ASR UR36: may 2019
ASR UR35: mar 2019
ASR UR34: feb 2019
ASR UR33: feb 2019
ASR UR32: jan 2019
ASR UR30: oct 2018
ASR UR27: jul 2018
ASR GA (Azure IaaS): jun 2018
ASR GA (VMware+Physical): jul 2015
ASR GA (Hyper-V): oct 2014
NEW
|
Release Dates:
IRP 7.5: sep 2019
IRP 7.0: apr 2019
IRP 6.5: sep 2018
IRP 6.0: feb 2018
IRP 5.5: july 2017
IRP 5.0: nov 2016
IRP 4.5: mar 2016
IRP 4.0: may 2015
IRP 3.5: may 2014
IRP 3.1: dec 2013
IRP 3.0: jul 2013
IRP 2.0: jul 2012
IRP 1.0: jun 2011
NEW
12th Generation software.
|
|
|
|
Pricing |
|
|
|
Software Pricing Model
Details
|
Per VM
VMware Site Recovery Manager (SRM) counts two editions: Standard and Enterprise.
Both editions are licensed per protected virtual machine (VM).
VMware SRM Standard:
- Protection of up to 75 VMs at each site
- Array-based as well as vSphere Replication
- Centralized recovery plans
- Non-disruptive testing
VMware SRM Enterprise:
- No licensing limit on number of protected VMs
- Array-based as well as vSphere Replication
- Centralized recovery plans
- Non-disruptive testing
- Stretched storage
- Orchestrated cross-vCenter vMotion
- VMware NSX integration
- Storage-profile protection groups
|
Per VM or Physical Server
Azure Site Recovery (ASR) is based on number of instances (VMs and/or Physical Servers) protected. There are two monthly fees:
- From Azure to customer owned sites (less expensive)
- From customer owned sites or Azure region to Azure (more expensive)
The monthly fee is based on the average daily number of instances (VMs and/or Physical Servers) that are protected over a monthly period.
|
Per VM
Zerto IT Resilience Platform (IRP) in essence counts two editions: Standard and Enterprise. The latter is also called Enterprise Cloud Edition (ECE).
Both editions are licensed per protected virtual machine (VM).
Zerto IRP Standard:
- For on-premises deployments.
- Site-to-site replication with the same hypervisor on both sides (VMware to VMware; Hyper-V to Hyper-V), including bi-directional replication.
- Replication of a VM to a single target, either local (same datacenter) or remote (other datacenter).
Zerto IRP Enterprise:
- For on-premises, hybrid cloud and public cloud deployments.
- Cross-hypervisor and cross-cloud replication.
- Multi-site replication up to 3 targets per VM (eg. local + remote datacenter + public cloud).
- Multi-tenancy (Multiple ZVM deployments from a single ZCM).
In addtion to Standard and Enterprise Zerto provides two alternative pricing options:
- Zerto DRaaS with a CSP or MSP (supports Standard capabilities + Multi-tenant CSP Offering)
- Zero to Public Cloud (supports Enterprise capabilities - Multi-tenant CSP Offering)
ZCM = Zerto Cloud Manager
ZVM = Zerto Virtual Manager
CSP = Cloud Service Provider
MSP = Managed Service Provider
|
|
|
Support Pricing Model
Details
|
Per VM
VMware offers 2 Maintenance and Support contract options: Basic and Production.
Basic:
- Support Window: 12 x 5
- Target Response Time: Severity 1 = 4 hours, Severity 2 = 8 business hours, Severity 3 = 12 business hours, Severity 4 = 12 business hours
- Support Requests: Unlimited
Production:
- Support Window: 24 x 7 x 365
- Target Response Time: Severity 1 = 30 minutes, Severity 2 = 4 business hours, Severity 3 = 8 business hours, Severity 4 = 12 business hours
- Support Requests: Unlimited
|
Per Account
Azure Support is a flat monthly fee that covers one account, regardless of how many subscriptions or users there are on this account. All subscriptions under an account will share the same support plan, and all users with admin/owner access to any of the subscriptions under the account with a Support Plan will also be entitled to support for those specific account’s subscriptions they have access to.
Microsoft offers 4 support plans: Developer, Standard, Professional Direct, Premier.
Developer:
- Trial and non-production environments
- Business hours access to support engineers via e-mail
- Unlimited contacts and cases
- Target Response Time: Severity C =
|
Per VM
Zerto offers 2 Maintenance and Support contract options: Standard and Premium.
Standard:
- Support Window: Mo-Fr 9AM -5PM (Office Hours)
- Target Response Time: Severity 1 = 4 hours, Severity 2 = 1 business day, Severity 3 = 3 business days, Severity 4 = 5 business days
- Support Requests: Unlimited
- Priority Queing: No
Premium:
- Support Window: 24 x 7 x 365
- Target Response Time: Severity 1 = 1 hour, Severity 2 = 5 hours, Severity 3 = 1 business day, Severity 4 = 3 business days
- Support Requests: Unlimited
- Priority Queing: Yes
|
|
|
Design & Deploy
|
|
|
|
|
|
|
General |
|
|
|
Solution Environment Scope
Details
|
On-prem to on-prem, same hypervisor
On-prem to VMware Cloud on AWS
VMware Cloud on AWS to on-prem
VMware Cloud on AWS to VMware Cloud on AWS
|
On-prem to on-prem Hyper-V
On-prem to Microsoft Azure
Microsoft Azure to Microsoft Azure
On-prem to on-prem for VMware vSphere or Physical Servers has been announced end-of-life (EOL). Since August 2018 these scenarios cannot be configured anymore in new deployments; only existing deployments are supported until December 31 2020.
|
On-prem to on-prem, same hypervisor
On-prem to on-prem, cross hypervisor
On-prem to public cloud
Public cloud to on-prem
Public cloud to public cloud, same provider
Public cloud to public cloud, cross provider
|
|
|
Solution Protection Scope
Details
|
Virtual Machines (VMs)
From the outset VMware Site Recovery Manager (SRM) has been designed for protecting virtualized environments only. This means the SRM platform currently cannot be used to protect physical servers for Disaster Recovery purposes.
VMware SRM can be leveraged for protecting Virtual Machines (VMs). Currently VMware SRM is unable to recognize individual containers.
|
Virtual Machines (VMs)
Physical Servers
Currently Azure Site Recovery (ASR) does not support protection of Docker disks. Also ASR does not support Windows Server 2016 Nano Server.
|
Virtual Machines (VMs)
From the outset Zerto IT Resilience Platform (IRP) has been designed for protecting virtualized environments only. This means the Zerto platform currently cannot be used to protect physical servers for Disaster Recovery purposes.
Zerto IRP can be leveraged for protecting Virtual Machines (VMs). Currently Zerto IRP is unable to recognize individual containers.
|
|
|
Evaluation Methods
Details
|
Free Trial (60-days)
Online Lab
Proof-of-Concept (POC)
A 60-day evaluation copy of SRM Standard is freely downloadble from the Product Evaluation Center after registering online. Only the latest GA version of SRM is available for free evaluation. SRM Standard evaluation is not for production environments.
vSphere Replication (VR) is a feature of the VMware vSphere platform. As such, it can be evaluated as part of the 60-day evaluation copy VMware vSphere.
VMware also offers a SRM hosted hands-on lab (HOL-1405) that lets you deploy, configure and manage SRM in a contained environment, after registering online.
|
Free Trial (31-days)
Every instance (VM) that is protected with Azure Site Recovery (ASR) is free for the first 31 days.
|
Free Trial (14-days)
Proof-of-Concept (PoC)
Zerto IT Resilience Platform (IRP) is freely downloadble after registering online and offers full platform support (complete Enterprise feature set) but is time (14 days) restricted. The free trial version of Zerto IRP can be installed on all commodity hardware platforms that meet the hardware requirements.
|
|
|
|
Architecture |
|
|
|
Deployment Architecture
Details
|
Array-based On-premises:
1 Replication adapter (SRA) per site
VR On-premises/Public cloud:
1 Manager (VRAp) per site
1 Replication agent (VRAg) per source host
1 Filter driver per source host
x Replication Servers (VRR)
Array-based On-Premises:
Storage Replication Adapter (SRA) software specific to each storage array that is used with SRM must be installed on the SRM host at both the protected site and the recovery site. SRM supports the use of multiple SRAs. However, virtual disks from a single VM cannot be spanned across multiple storage arrays from different manufacturers.
vSAN does not require a Storage Replication Adapter (SRA) to work with Site Recovery Manager (SRM).
VR On-Premises/Public Cloud:
vSphere Replication (VR) requires 1 Appliance (VRAp) to be deployed at both the source and target sites for management and coordination.
VR also requires an Agent (VRAg) as well as a vSCSI Filter driver to be deployed on each physical server that is part of a cluster hosting protected VMs (source site). The filter driver is used for tapping into the VMs Input/Output (IO) stream.
VR also requires one or more Replication Servers (VRR) to be deployed on the target site for processing and storing the incoming replication data. The vSphere Replication Appliance (VRAp) at the target site had a VRR embedded.
|
On-premises VMware/Physical Servers:
1 Configuration Server Machine (CSM) per site
x Process Servers
x Master Target Servers
1 Mobility Service per VM
On-premises Microsoft Hyper-V:
1 Site Recovery Provider (SRP) per site
1 Recovery Services Agent (RSA) per host
Azure Public cloud:
None
On-premises VMware vSphere / Physical Servers:
Microsoft recommends running the Configuration Server Machine (CSM) as a VMware VM that can be deployed from a downloaded OVF template. The CSM runs all on-premises ASR components, which include the configuration server, process server, and master target server.
Configuration server: Coordinates communications between on-premises and Azure, and manages data replication.
Process server: Installed by default on the configuration server. It receives replication data, optimizes it (caching, compression, encryption), and sends it to Azure Storage. The process server also performs automatic discovery of on-premises machines (VMs and/or Physical Servers) and installs ASR Mobility Service on VMs that require protection. Additional, separate process servers can be added to handle larger volumes of replication traffic.
Master target server: Installed by default on the CMS. It handles replication data during failback from Azure. Additional, separate master target servers can be added for failback of larger environments.
The Mobility Service needs to be installed on each VM/Physical Server that requires protection. Microsoft recommends allowing automatic installation of the Mobility Service to be performed from the Process Server.
On-premises Microsoft Hyper-V:
The Site Recovery Provider (SRP) is installed on the System Center Virtual Machine Manager (VMM) server where replication is then orchestrated. In addition a Recovery Services Agent (RSA) needs to be installed on each Hyper-V host.
Microsoft Azure public cloud:
|
On-premises:
1 Manager (ZVM) per site
1 Replication appliance (VRA) per host
1 Kernel module per host
Public cloud:
1 or more Cloud appliances (ZCA) per public cloud
On-premises:
Zerto requires 1 Zerto Virtual Manager (ZVM) to be deployed at both the source and target sites. The ZVM components need to be installed on a (virtual) Windows Server.
Zerto also requires a Virtual Replication Appliance (VRA) as well as a kernel module (provided as vSphere Installation Bundle or VIB) to be deployed on each physical server that is part of a cluster hosting protected VMs (source site) and on each physical server that is used to process and store incoming replication data (target site). The kernel model is used for tapping into the VMs Input/Output (IO) stream.
Public cloud:
In Microsoft Azure and AWS one or more Zerto Cloud Appliances (ZCAs) need to be deployed. The ZCA is a combination of a ZVM and a VRA.
AWS: The ZCA must be installed on an AWS EC2 instance running the Windows Server OS. For Cloud Service Providers (CSPs) one ZCA is required per end customer.
|
|
|
Replication Method
Details
|
Array-based: Continuous (synchronous); Snapshot-based (asynchronous)
VR: Changed Block Tracking
Array-based: VMware SRM support both synchronous (continuous) and asynchronous (snapshot-based) storage replication mechanisms. It depends on the storage hardware manufacturer which of these are supported in the vendor-specific Storage Replication Adapter (SRA).
vSphere Replication (VR): VMware developed the vSphere Replication engine. The method vSphere Replication uses to track changes to a VM is very similar to the CBT mechanism that is part of VMware vSphere Storage APIs – Data Protection. However, it is not CBT, preventing interference with other solutions that utilize CBT. VM snapshots are not
used at the source unless Microsoft Volume Shadow Copy Service (VSS) quiescing is enabled when configuring replication.
|
Log-based CBT (VMware/Hyper-V/Physical)
Snapshot-based (Azure IaaS)
VMware vSphere / Physical Servers: The ASR Process Server writes replication logs to a cache storage account in the Azure target region. For every protected disk, log data is replicated to a Managed Disk in Azure. This disk has the prefix of asrseeddisk. It stores the copy of protected disk and all the recovery point snapshots.
Microsoft Hyper-V: The Hyper-V Replica Replication Tracker (HRRT) tracks all changes as Hyper-V replication logs (.hrl). These log files are located in the same folder as the disks. Each disk has an associated .hrl file that is sent to the end-user organizations Azure Storage Account on delta replication. When a log is in transit to Azure, the changes in the primary disk are tracked in another log file, in the same folder.
Azure IaaS: Recovery points are created from snapshots, and stored in accordance with retention settings in the replication policy. ASR takes crash-consistent snapshots of data by default, and app consistent snapshots if you specify a frequency for them.
CBT = Changed Block Tracking
|
Journal-based (near synchronous)
Zerto proprietary always-on block-level replication technology is a Continuous Data Protection (CDP) solution that uses a journal. As such there is no snapshot mechanism involved.
|
|
|
|
Array-based: Continuously (synchronous); Every x minutes/hours (asynchronous)
VR: Every x minutes/hours
|
VMware/Physical: Continuously
Hyper-V: Every 30/300/900 seconds
Azure IaaS: Every 5 minutes
VMware vSphere / Physical: In the Replication Policy an RPO threshold is configured. Alerts are generated when continuous replication exceeds this limit.
Hyper-V: In a Replication Policy the replication frequency can be configured to 30, 300 (default) and 900 seconds.
Azure IaaS: ASR creates crash-consistent recovery points every five minutes by default. This setting cannot be modified.
|
Every x seconds
If possible, Zerto creates a recovery checkpoint in the Zerto journal every few seconds.
|
|
|
Site Connectivity
Details
|
On-premises to on-premises:
Private network, Public internet, VPN
On-premises to VMware Cloud on AWS:
IPSec VPN, VPN over Direct Connect, L2 VPN
|
On-premises to on-premises:
Private network, Public internet, VPN
On-premises to Microsoft Azure:
Public internet, ExpressRoute (Microsoft peering)
Azure Site Recovery (ASR) replicates data to an Azure storage account or managed disks, over a public endpoint. Thus protected data can only be replicated over the public internet with ExpressRoute (Microsoft peering). Replication over a site-to-site VPN isnt supported.
When failing back from Azure to VMware vSphere, data from Azure is copied back to the on-premises VM for whoch private access is required. This means for failback a VPN or ExpressRoute is required.
|
On-premises to on-premises:
Private network, Public internet, VPN
On-premises to AWS:
AWS Direct Connect, VPN
On-premises to Azure:
Public internet, ExpressRoute
|
|
|
|
Array-based: Solution dependent
VR: Data Compression
Array-based: Deduplication and compression techniques aimed at reducing remote replication traffic is entirely dependent on what the specific storage solution or what a 3rd party WAN acceleration solution can provide.
vSphere Replication (VR): Data compression can be enabled to save network bandwidth between sites. For this VR utilizes the FastLZ compression library. Bandwidth is not monitored, and there is no way to configure bandwidth throttling. The data replicated is not encrypted, enabling 3rd party WAN acceleration solutions to provide some benefit.
|
Data Compression (VMware/Physical)
Bandwidth throttling
Data Compression: The Process server acts as a replication gateway. It receives replication data and optimizes it with caching, compression, and encryption.
Compression isnt used when replicating Hyper-V VMs to Azure. For compression a third-party appliance (eg. Riverbed) needs to be used.
Bandwidth Throttling: Bandwidth used for remote replication traffic can be limited. A maximum bandwidth applies to remote replication traffic from the Process Server in protection site to the recovery site (Kbps/Mbps). Minimum bandwidth is 512 Kbps; Maximum bandwidth is 1,023 Mbps. Throttling can be time-based by specifying time windows for Work Hours (24 hour clock) and Work Days.
In addition bandwidth can be throttled for a specifc VM by adjusting the UploadThreadsPerVM in the VMs registry. Default value is 4; Maximum value is 32.
WAN = Wide Area Network
|
Data compression
Signature matching
Bandwidth throttling
Data compression: WAN Traffic Compression can be enabled per Virtual protection group (VPG) to save network bandwith in between sites. The VRA automatically adjusts the compression level according to CPU usage, including totally disabling it if needed. Zerto recommends enabling WAN compression. WAN Traffic Compression is enabled by default when replicating to VMware vCloud Director (vCD).
Signature matching: Reduces the amount of data sent across the WAN. During synchronization of the protected site and recovery site for every VM in a VPG, Zerto maintains a map of disk sectors so that if there is a need to resynchronize sites, the map signatures can be used to ensure that only data where changes occurred are passed over the WAN.
Bandwidth Throttling: Bandwidth used for remote replication traffic can be limited. A maximum bandwidth applies to remote replication traffic from the protection site to all peer recovery sites (MB/sec). Throttling can be time-based by specifying time windows using a 24 hour clock.
WAN = Wide Area Network
|
|
|
|
Scaling |
|
|
|
Solution Scalability
Details
|
Array-based: 5,000 VMs
VR: 2,000 VMs
|
Unknown
There is no documented maxmimum number of VMs that can be protected by Azure Site Recovery (ASR).
|
10,000 VMs
A single Zerto Virtual Manager (ZVM) can protect up to 10,000 on-premises VMs (VMware or Hyper-V). One ZVM can be deployed per vCenter/System Center environment.
|
|
|
Host/Server Scalability
Details
|
Array-based: N/A
VR: Unknown (VRAg,VFD); 200 VMs (VRR)
The vSphere Replication Agent (VRAg) and the vSCSI Filter Driver that are installed at the source site do not have any documented maximums.
However, each of the vSphere Replication Servers (VRR) installed at the target site can protect a maximum of 200 VMs.
|
85-225 VMs; 2TB Change Rate (Process Server)
NEW
VMware vSphere: A Process Server can be scaled-up by adding CPUs and memory or scaled-out by adding additional Process Servers. There are currently three Process Server sizes:
- 4vCPU, 8GB RAM, 300GB Cache Disk,
|
1,500 VMs; 96TB (VRA)
A single Zerto Virtual Replication Appliance (VRA) can protect up to 1,500 on-premises VMs (VMware or Hyper-V) and up to 96TB of storage (sum of all protected disks). One VRA can be deployed per virtualization host.
|
|
|
Multi-site Support
Details
|
Yes (1:1, N:1)
VMware SRM supports 1:1 and N:1 topologies. VMware SRM does not support 1:N and N:N topologies.
1:1 = site-to-site replication with the same hypervisor on both sides (VMware to VMware). This include bi-directional replication support.
N:1 = VMware SRM supports a maximum of 10 paired remote sites. Concurrent recoveries can be run from multiple sites.
1:N, also known as fan-out, is defined as the same protected VM that can be replicated to multiple recovery sites.
N:1, also known as fan-in, is defined as protected VMs in multiple sites being replicated to a single recovery site.
|
Yes (1:1, N:1)
Azure Site Recovery (ASR) supports 1:1 and N:1 topologies. ASR does not support 1:N and N:N topologies.
1:1 = site-to-cloud replication.
N:1 = sites-to-cloud replication.
1:N, also known as fan-out, is defined as the same protected VM that can be replicated to multiple recovery sites.
N:1, also known as fan-in, is defined as protected VMs in multiple sites being replicated to a single recovery site.
|
Yes (1:N, N:1, N:N)
Zerto IRP Enterprise supports 1:1, 1:N, N:1 and N:N topologies.
1:1 = site-to-site replication with the same hypervisor on both sides (VMware to VMware; Hyper-V to Hyper-V) or different hypervisors on both sides (VMware to Hyper-V; Hyper-V to VMware. Both include bi-directional replication support.
1:N = Zerto IRP Enterprise supports replication of a VM to up to three targets, either local (same datacenter or public cloud) or remote (other datacenter or public cloud).
1:N, also known as fan-out, is defined as the same protected VM that can be replicated to multiple recovery sites.
N:1, also known as fan-in, is defined as protected VMs in multiple sites being replicated to a single recovery site.
|
|
|
Multi-tenancy Support
Details
|
Yes (limited)
VMware SRM supports multi-tenancy in private cloud scenarios.
VMware SRM does not support VMware vCloud Director (vCD).
|
Yes
Azure Site Recovery (ASR) supports VMware vSphere multi-tenant environments for
- tenant subscriptions;
- tenant subscriptions that are created and managed through the Microsoft Cloud Solution Provider (CSP) program.
|
Yes
Multi-tenancy support requires Zerto IT Resilience Platform (IRP) Enterprise edition.
|
|
|
Source/Target Support
|
|
|
|
|
|
|
On-premises |
|
|
|
|
No
Physical Servers are not supported by SRM.
|
Yes
Azure Site Recovery (ASR) supports physical (bare metal) Windows servers and Linux servers.
Once a Physical Server has failed over to Azure, it can only be failed back to a VMware VM.
|
No
Physical Servers are not supported by Zerto IRP.
|
|
|
Physical Server Storage Types
Details
|
N/A
|
Local, SAN (iSCSI/FC)
NEW
Local storage is supported.
Host SAN (iSCSI/FC) is supported.
Host NFS is not supported.
Host multipath (MPIO) is supported.
Azure Storage currently does not support:
- OS disk sizes greater than 2TB
- data disk sizes greater than 8TB
UR39 increased data disk size support from 4TB to 8TB.
|
N/A
|
|
|
VMware vSphere/ESXi
Details
|
Yes
SRM currently supports VMware ESXi 6.0U3 - 6.7U2.
SRM is supported with any edition of VMware vSphere, except for VMware vSphere Essentials.
|
Yes
ASR currently supports VMware ESXi 5.5 - 6.7U2.
|
Yes
NEW
Zerto IT Resilience Platform (IRP) 7.5 supports VMware ESXi 5.5 - 6.7U3. VMware ESXi 5.1 is no longer supported.
|
|
|
vSphere Storage Types
Details
|
Array-based: VMFS, NFS, vSAN, RDM
VR: VMFS, NFS, vSAN, VVOL, RDM (partial)
VMware SRM with Array-based replication supports RDM devices in physical compatibility mode (pRDM) and in virtual compatibility mode (vRDM).
VMware SRM with vSphere Replication (VR) supports RDM devices in virtual compatibility mode (vRDM) only, for both the source and target device.
VVOL support is only provided when using VMware SRM with vSphere Replication (VR).
VMware SRM does not support NFS v4.1 datastores.
VMware SRM does not support Array-based replication for VMs of which disks are spanned across multiple storage arrays. SRM can only protect the disks in one storage system; disks located in another storage system will remain unprotected.
Resizing a virtual disk while it is being replicated with VR is not supported. Replication needs to be temporarily stopped to allow resizing both protected and recovery disks. Resizing also requires deletion and reseeding the protected VM. All steps have to be performed manually.
RDM = Raw Device Mapping
VVOL = VMware Virtual Volumes
|
VMFS, NFS, vSAN, VVOL, RDM
NEW
ASR supports dynamic disks. However, the OS must be on a basic disk.
Resizing a disk on the protected VM is supported.
For every protected disk, data is replicated to a Managed Disk in Azure.
Azure Storage currently does not support:
- OS disk sizes greater than 2TB
- data disk sizes greater than 8TB
UR38 increased data disk size support from 4TB to 8TB. This is applicable only when writing directly to managed disks.
|
VMFS, NFS, vSAN, RDM
Virtual Machine Disks (VMDKs) on VMFS, NFS and vSAN datastores can be protected by Zerto, as are Raw Device Mappings (RDMs). Datastores can be either direct attached or served from a SAN/NAS solution.
VVOL is currently not supported by Zerto.
RDM = Raw Device Mapping
VVOL = VMware Virtual Volumes
|
|
|
Microsoft Hyper-V
Details
|
No
|
Yes
ASR currently supports Windows Server 2012 R2 and 2016 (including server core installation) running Hyper-V.
ASR does not support Windows Server 2019 running Hyper-V at this time.
|
Yes
Zerto IRP currently supports Microsoft Hyper-V hosts running Windows Server 2012R2 - 2016
|
|
|
Hyper-V Storage Types
Details
|
N/A
|
SMB 3.0, SAN (iSCSI)
ASR supports Multipath IO (MPIO).
ASR does not support resizing a disk on a replicated Hyper-V VM. Disable replication, make the change, and then reenable replication for the VM.
Azure Storage currently does not support:
- OS disk sizes greater than 2TB
- data disk sizes greater than 4TB
|
Supported: Direct Attached, CSV
Not Supported: Pass-through disks
Virtual Hard Drives (VHD/VHDX) on Direct Attached storage or Cluster Shared Volumes (CSV) can be protected by Zerto.
The VHD in a virtual machine can be mapped directly to a physical disk or logical unit number (LUN), instead of to a VHD file. A Hyper-V host with even one pass-through disk is ignored by Zerto Virtual Replication.
|
|
|
Stretched Storage Support
Details
|
Yes
SRM stretched storage cluster support includes VMware vSAN Stretched Clusters.
Stretched storage cluster support is only provided by VMware SRM Enterprise.
|
Yes (limited)
Stretched clusters cannot be managed by Azure Site Recovery (ASR). However, VMs running on a stretched cluster can be replicated to Azure.
|
No
Zerto IT Resilience Platform (IRP) does not support VMs on stretched storage clusters.
|
|
|
Stretched Network Support
Details
|
Yes
On-premises: L2/L3 and NSX network configurations are supported for the SRM management network and the VM network. NSX support requires VMware SRM Enterprise.
VMware Cloud on AWS: Stretched L2 VPN connections are supported.
On-premises/VMware Cloud on AWS: VMware HCX provides transport, WAN Optimization, Secure VPN and L2 extensibility. Integration with VMware HCX requires separate VMware HCX Enterprise licenses. HCX integration requires VMware SRM Enterprise licensing.
With the combined SRM/HCX solution, DR backup and recovery can leverage the HCX hybrid interconnect to optimize bandwidth and connectivity, secure VMs in transit and stretch networks to simplify IP address management for recovered VMs. HCX accelerates replication processes by eliminating incompatibility issues across networks and storage.
|
No
Stretched L2 network configuration is not supported when leveraging Azure as the recovery site. Moving an entire L2 subnet from on-premises to Azure is possible, but involves manual interaction.
|
Yes
|
|
|
Data Center Mobility
Details
|
Yes
When performing a data center migration, VMware SRM first forces a final sync to get a VM to a state of zero data loss. It waits for this sync to complete before it shuts down the VM on the protected site and powers on the VM at the recovery site.
|
Yes (Hyper-V)
Azure Site Recovery (ASR) only supports on-prem to on-prem migrations when using Hyper-V as the hypervisor.
|
Yes
Zerto IT Resilience Platform (IRP) provides the 'Move' operation to transfer protected VMs from the Source site to the DR site in a planned migration scenario.
|
|
|
|
Public Cloud |
|
|
|
Amazon Web Services (AWS)
Details
|
No
Native Amazon Web Services (AWS) is currently not supported by VMware SRM.
|
No
Amazon Web Services (AWS) is currently not supported by Microsoft ASR.
|
Yes (partial)
VMs from either VMware vSphere, Microsoft Hyper-V or Microsoft Azure can be protected to an AWS recovery site. AWS can be configured as both a protected site and a recovery site. However, protection of AWS VMs to another AWS site is currently not supported.
Failover to AWS includes the option to configure Reverse Protection during or after Failover, allowing for automated reverse replication and failback from AWS.
Zerto IT Resilience Platform (IRP) is supported for and has been tested in the following AWS Regions:
- US East (North Virginia, Ohio)
- US West (Oregon, North California)
- AWS Gov Cloud (US West)
- Canada (Central)
- South America - East (Sao Paulo)
- EU Central (Frankfurt)
- EU West (Ireland)
- Europe (London)
- Asia Pacific - North East (Seoul, Tokyo)
- Asia Pacifc - South East (Singapore, Sydney)
- Asia Pacific - South (Mumbai)
- China (Bejing)
|
|
|
AWS Storage Types
Details
|
N/A
|
N/A
|
S3
When creating a VPG to AWS the data is stored in S3 and all replicated data from protected VMs to AWS is encrypted in S3. All recovery operations bring up the recovered VMs in EC2.
S3 = Amazon Simple Storage Service
EC2 = Amazon Elastic Compute Cloud
|
|
|
|
No
Microsoft Azure is currently not supported by VMware SRM.
|
Yes
NEW
Azure Site Recovery (ASR) supports replication and recovery of Azure IaaS VMs between any two regions within the same geographic cluster. Geographic clusters are defined keeping data latency and sovereignty in mind.
Azure Site Recovery (ASR) is available in the following Azure Geographic clusters and regions:
America
- Central US
- East US, East US 2
- North Central US
- South Central US
- West Central US
- West US, West US 2
- Canada (Central, East)
VMs in Brazil South can be replicated and failed over to these regions: South Central US, West Central US, East US, East US 2, West US, West US 2, and North Central US.
Azure Government
- US DoD (Central, East)
- US Gov (Arizona, Iowa, Texas, Virginia)
Europe
- North Europe
- West Europe
- France (Central, South)
- UK (South, West)
Germany
- Germany Central
- Germany Northeast
Asia
- West India
- Central India
- South India
- East Asia
- Southeast Asia
- Japan East
- Japan West
- Korea Central
- Korea South
China
- China East, China East 2
- China North, China North 2
Australia
- Australia Central, Australia Central 2
- Australia East
- Australia Southeast
Africa
- South Africa North
- South Africa West
Middle East
- UAE Central
- UAE North
|
Yes
VMs from either VMware vSphere, Microsoft Hyper-V, Microsoft Azure or Amazon Web Services (AWS) can be protected to an Azure recovery site. Azure can be configured as both a protected site and a recovery site. Protection of Azure VMs to another Azure site/region is supported.
Failover to Azure includes the option to configure Reverse Protection during or after Failover, allowing for automated reverse replication and failback from Azure.
Zerto IT Resilience Platform (IRP) is supported for the following Azure Regions:
- Azure Government regions
- Germany (all)
- China
- All other regions
|
|
|
Azure Storage Types
Details
|
N/A
|
Managed Disk (Standard; Premium), S2, S2D
NEW
ASR supports Storage Spaces (S2).
ASR supports Storage Spaces Direct (S2D) for crash consistent recovery points.
ASR supports Scale-out File Server for crash consistent recovery points.
ASR supports LRS, GRS and RA-GRS.
ASR does not support ZRS.
ASR does not support VM disks on Cool and Hot Storage.
The replication data logs with tracked changes first land in a cache storage account in Azure. These logs are processed and the data is stored in an Azure Managed Disk (called as ASR seed disk). The recovery points are created on this disk. Azure Managed Disks are stored as Storage blobs.
UR39 enables support for the latest release of Azure Disk Encryption (Managed Disk, Windows).
UR39 increased data disk size support from 4TB to 8TB.
LRS = Local Redundant Storage
GRS = Geo-Redundant Storage
RA-GRS = Read Access Geo-Redundant Storage
ZRS = Zone Redundant Storage
|
Supported: Standard and Premium Managed Disk
Unsupported: Blob Storage
Zerto IRP currently only supports General-purpose v1 (GPv1). This is the legacy storage account type for blobs, files, queues, and tables.
Protected virtual disks are recovered in Azure as Virtual Hard Disks (VHD), also known as Azure Managed Disks, which are stored as page blobs.
VPGs can be recovered to either Standard Managed disks and/or Premium Managed disks. However, after live failover VMs that are recovered to Premium Managed disks cannot be protected. A conversion tool must be used to convert them into Standard Storage account VMs for them to be protected.
In addtition the following restrictions apply:
- VMs that have disks larger than 4TB cannot be protected.
- Resizing protected disks on Azure is not supported.
|
|
|
Google Cloud Platform (GCP)
Details
|
No
Google Cloud Platform (GCP) is currently not supported by VMware SRM.
|
No
Google Cloud Platform (GCP) is currently not supported by Microsoft ASR.
|
No
Google Cloud Platform (GCP) is currently not supported by Zerto IRP.
|
|
|
GCP Storage Types
Details
|
N/A
|
N/A
|
N/A
|
|
|
VMware Cloud on AWS
Details
|
Array-based: No
VR: Yes
VMware has integrated SRM and VR in the VMware Cloud on AWS (VCA) proposition in order to provide Disaster Recovery as a Service (DRaaS). Enabling SRM/VR in VCA is literally a one-click operation.
VCA can be configured as both a protected site and a recovery site. Protection of VCA VMs to another VCA site is supported.
SRM/VR is available in the following AWS regions:
- US East (North Virginia, Ohio)
- US West (Oregon, North California)
- AWS Gov Cloud (US West)
- Canada (Central)
- EU Central (Frankfurt)
- EU West (Ireland)
- Europe (London, Paris)
- Asia Pacific - South East (Singapore, Sydney)
|
No
VMware Cloud on AWS (VCA) is currently not supported by Microsoft ASR.
|
No
VMware Cloud on AWS VCA) is currently not supported by Zerto IRP.
|
|
|
VCA Storage Types
Details
|
vSAN
VMware Cloud on AWS is built on VMware vSphere, VMware vSAN and VMware NSX.
|
N/A
VMware Cloud on AWS (VCA) is currently not supported by Microsoft ASR.
|
N/A
VMware Cloud on AWS VCA) is currently not supported by Zerto IRP.
|
|
|
Public Cloud Mobility
Details
|
No
|
No
Azure Site Recovery (ASR) only supports one public cloud offering.
|
Yes
Public Cloud mobility requires the Zerto IT Resilience Platform (IRP) Enterprise edition.
|
|
|
Protection Support
|
|
|
|
|
|
|
Configuration |
|
|
|
|
Array-based: per volume
VR: per VM
|
Per VM
|
Per VM
Protection is configurable on a VM-by-VM basis.
|
|
|
|
Array-based: No
VR: Yes (limited)
vSphere Replication (VR): When configuring a VM for replication individual disks can be excluded by choosing 'Disable replication for this disk'. In order to keep the Protection Group in a healthy state in SRM, the non-replicated disks should also be detached in the VM Protection Properties.
However, excluding a disk like this means that the disk will not exist at all in the target site, so will be missing from the VM on recovery. Therefore this is not an end-to-end solution for eg. Swap disks and Temp DB disks, as these do need to exist in the recovery site and need to be recreated manually.
|
Yes (limited)
Azure Site Recovery (ASR) supports exclusion of specific disks from replication when protecting either VMware VMs and/or Hyper-V VMs to Azure, using the Azure portal.
Protecting Azure VMs (Azure-to-Azure) does not support the exclusion of disks.
However, excluding a disk like this means that the disk will not exist at all in the target site, so will be missing from the VM on recovery. Therefore this is not an end-to-end solution for eg. Swap disks and Temp DB disks, as these do need to exist in the recovery site and need to be recreated manually.
|
Yes
If the protected VM includes one or more Temp data disks as part of its configuration, these disks can be marked as 'temp data disk' during configuration. The disk will be synchronized to the target site initially to ensure it exists there, however data is not replicated from the 'temp data disk' any time after the initial synchronization.
Zerto cannot protect AWS Instance Store disks (Temp disks) nor Azure temp drives.
|
|
|
|
Array-based: Yes
VR: No
Arrray-based: Both data from powered-on and powered-off VMs are replicated to the target recovery site when using array-based replication.
vSphere Replication (VR): Although VR can be configured for a VM that is powered off, data is
replicated only when the VM is powered on.
|
No
VMware vSphere / Physical: The Mobility Service that is installed within the protected VM must be running in order to replicate changed data to Azure.
|
Yes (limited)
A VM needs to be powered on during the initial sync. Once completed, the VM can be powered off without hampering replication. Checkpoints will continue to be sent but they will contain no data as the disks of the VM aren’t changing. Also a powered-off VM can be vMotioned to a new physical host as long as the physical host you are migrating to has a VRA on it.
Although Zerto IRP doesn’t directly monitor the power states of VMs, if a VM is powered off during a sync this will trigger an alert to be generated.
|
|
|
|
Array-based: Solution dependent
VR: In-transit
Array-based: Encryption techniques aimed at securing replication traffic is entirely dependent on what the specific storage solution or what a 3rd party WAN solution can provide.
vSphere Replication (VR): Data can be protected in-transit using built-in network traffic encryption. The VR appliance automatically installs an encryption agent on the source ESXi hosts. When the network encryption feature is enabled, the agent encrypts the replication data on the source ESXi host and sends it to the VR appliance on the recovery site. The VR server on the recovery site decrypts the data and sends it to the target datastore.
Replication and protection of Encrypted VMs is also supported when using VMware vSphere 6.7 Update 1 or later. When protecting an encrypted VM, network encryption is automatically turned on and cannot be disabled.
|
In-transit (Hyper-V to Hyper-V)
In-transit and at-rest (to Azure)
For VMs and Physical servers replicating to Azure, both encryption in-transit and encryption at-rest are supported.
For Hyper-V VMs replicating between on-premises sites encryption-in-transit is supported.
|
At-rest (AWS/Azure)
Zerto does not natively encrypt data across the WAN. Communication across networks can be encrypted using network encryption software such as VPN and Ipsec.
AWS: Elastic Block Storage (EBS) encryption is enabled by default.
Azure: Every block blob, page blob and Managed disks that are created by Zerto, are Encrypted at-rest on the Microsoft Azure platform, using the Microsoft-managed default key.
|
|
|
|
Consistency |
|
|
|
VM Consistency Groups
Details
|
Array-based: Yes (limited)
VR: No
Array-based: Write order fidelity is maintained across VMs that reside on the same volume/LUN.
VR: Write order fidelity across VMs cannot be maintained. SRM Protection Groups are containers that were only designed for grouping VMs that need to be recovered together.
|
Yes (limited)
If VMs should replicate together, they can be configured as part of the same Replication Group. Multi-VM consistency impacts workload performance, and should only be used for VMs running workloads that need consistency across all machines. Up to 16 VMs can be part of the same Replication Group when protecting Azure VMs.
|
Yes
Write order fidelity is maintained across VMs that reside in the same Virtual Protection Group (VPG).
|
|
|
Default Data Consistency Level
Details
|
Crash-consistency and write order fidelity
Array-based: The checkpoints created ensure write order fidelity for all VMs that reside on the same Volume/LUN as well as write order fidelity and crash-consistency for every individual VM.
vSphere Replication (VR): The checkpoints created ensure write order fidelity and crash-consistency for every individual VM.
|
Crash-consistency and write order fidelity
The checkpoints created ensure write order fidelity and crash-consistency for every individual VM.
|
Crash-consistency and write order fidelity
The checkpoints created ensure write order fidelity for all VMs inside the same Virtual Protection Group (VPG) as well as write order fidelity and crash-consistency for every individual VM.
|
|
|
Application Data Consistency
Details
|
Microsoft Applications (optional)
Microsofts Volume Shadow Copy Service (VSS) can be leveraged when using either array-based replication or vSphere Replication (VR). VSS operates at the block-level. The aim of VSS is to create consistent reliable snapshots by temporarily halting new writes and letting ongoing writes finish. Microsoft applications that support VSS are Active Directory, MSSQL, Exchange and SharePoint. VSS is also leveraged to create file system consistent snapshots of Microsoft NTFS volumes.
|
Microsoft Applications (optional)
VMware vSphere / Physical: App-consistent snapshots can be taken every 1 to 12 hours. Snapshots are standard Azure blob snapshots. The Mobility agent running on a VM requests a VSS snapshot in accordance with this setting, and bookmarks that point-in-time as an application consistent point in the replication stream.
Hyper-V: App-consistent snapshots can be taken every 1 to 12 hours. Dynamic disks are not supported for app-consistent snapshots
Azure IaaS: An App-consistent snapshots can be created every 60 minutes.
Microsofts Volume Shadow Copy Service (VSS) is leveraged for achieving application consistency. VSS operates at the block-level. The aim of VSS is to create consistent reliable snapshots by temporarily halting new writes and letting ongoing writes finish. Microsoft applications that support VSS are Active Directory, MSSQL, Exchange and SharePoint. VSS is also leveraged to create file system consistent snapshots of Microsoft NTFS volumes.
|
Microsoft Applications (optional)
Microsofts Volume Shadow Copy Service (VSS) can be leveraged by installing the ZertoVssAgent inside the proteced Windows VM. VSS operates at the block-level. The aim of VSS is to create consistent reliable snapshots by temporarily halting new writes and letting ongoing writes finish. Microsoft applications that support VSS are Active Directory, MSSQL, Exchange and SharePoint. VSS is also leveraged to create file system consistent snapshots of Microsoft NTFS volumes.
Zerto 7.0 requires end-users to install the Zerto VSS agent. The use of Microsoft VSS agents is no longer supported.
|
|
|
|
Objectives |
|
|
|
|
Array-based: 0 (synchronous) or 10-15 minutes (asynchronous)
VR: 5 minutes (limited) or 15 minutes
Array-based: With most storage systems that leverage asynchronous replication an RPO of 10 or 15 minutes can be configured.
vSphere Replication (VR): Minimum RPO that can be configured in all scenarios is 15 minutes. An RPO of 5 minutes can be configured only when the target and the source site use VMFS 6.0, VMFS 5.x, NFS 4.1, NFS 3, VVOL, or vSAN 6.2 Update 3 storage and later. Even if the source and target sites use different datastore types the 5 minute RPO setting can be used.
The 5 minute RPO can be applied to a maximum of 100 VMs on VMFS 6.0, VMFS 5.x, NFS 4.1, NFS 3, and vSAN 6.2 Update 3 storage and later. The maximum for VVOL datastore is 50 VMs.
An RPO lower than 15 minutes is not supported when the OS quiescing option is leveraged.
|
vSphere/Physical: 5-10 seconds (near-synchronous)
Hyper-V: 30 seconds (asynchronous)
Azure IaaS: 5-10 seconds (near-synchronous)
|
5-10 seconds (near-syncrhonous)
Zerto IT Resilience Platform (IRP) journal based protection creates recovery point every few seconds. With Azure the minimum RPO is 1 minute.
|
|
|
RPO Configurability
Details
|
Array-based: No (synchronous); Yes (asynchronous)
VR: Yes (5 minutes to 24 hours)
Array-based: The replication schedule for a VM is determined by the storage snapshot frequency configured for a particular volume when using asynchronous replication, resulting in a RPO that can range from minutes to hours.
vSphere Replication VR): The replication schedule for a VM is determined by the recovery point objective (RPO) set when configuring replication for that VM. The possible value for RPO can be any
number of minutes from 5 to 1,440 (24 hours). There is currently no way to schedule replication at
specific times VR generates its own replication schedule internally by factoring all replicated VMs on each VMware vSphere host.
|
vSphere/Physical: No
Hyper-V: Yes (30 seconds, 5 or 15 minutes)
Azure IaaS: No
Hyper-V: 30 second copy frequency is not supported when replicating to Azure premium storage.
|
Yes (limited)
The outset is that Zerto always tries to achieve the lowest RPO possible. Zerto does allow you to set a target RPO. This target RPO is used for reporting and alerting but is also taken into consideration with regards to Zertos Quality-of-Service (QoS) mechanism. This means that Virtual Replication Groups (VPGs) configured with a lower Target RPO will get more replication priority when scenarios are encountered where RPO is impacted.
|
|
|
|
Array-based: 1 to x restore points
VR: 1 to 24 restore points
Array-based: Multiple point-in-time hardware snapshots or rollback is supported by some storage manufacturers. Also, VM software snapshots are replicated to the target site where the snapshot tree is maintained.
vSphere Replication (VR): VR 5.5 introduced Multiple Point In Time (MPIT) recovery. MPIT recovery enables an administrator to recover a VM to the latest replicated copy at the target site and then revert, or “roll back”, that VM to a previous point in time. MPIT recovery points appear as VM software snapshots at the target location. There are no dependencies between VM software snapshots at the source location and recovery points at the target location. VR does not replicate a VM software snapshot hierarchy from the source location to the target location.
VR Point-in-Time snapshots are not supported for configurations where the replication target is a VVOL datastore.
|
Up to 24/72 hours
Up to 24 hours of retention is supported for VMs/Physical Servers replicated to Premium storage. Up to 72 hours is supported for Standard storage.
|
1 hour to 30 days
The Zerto journal can be configured with a minimum retention of 1 hour and a maximum retention of 30 days. Bear in mind that longer retentions may require (much) more disk space on the target site, because almost every change that historically occured during the configuration retention period has to be preserved in the journal at the target site.
|
|
|
Recoverability
|
|
|
|
|
|
|
Orchestration |
|
|
|
|
VM Groups
VMs
VM Groups: The boot order of groups of VMs is based on the priority level assigned to every individual VM. VMware SRM starts Priorty 1 VMs first, then Priority 2 VMs next, and so on. By default priority level assigned to a protected VM is Level 3. The lowest priority is 5.
VMware SRM uses VMware Tools heartbeat to discover when a VM is running on the recovery site. This way SRM can ensure that all VMs of a given priority are running before it starts the VMs of the next priority. For this reason VMware Tools must be installed inside all protected VMs.
VMs: The boot order between different VMs can be manipulated by configuring 'VM Dependencies' for individual VMs. The VM will not start unless another VM has already been started.
|
VM Groups
VMs
An Recovery Plan gathers machines into Recovery Groups. Plans can be customized by adding order instructions and tasks to it.
Multiple Groups can be created within the same Recovery Group and placed in a sequential order. VMs/machines can be added to such a Group. VMs/machines within the same Group fail over in parallel.
|
VMs
The boot order of virtual machines (VMs) can be defined in each individual Virtual Protection Group (VPG).
Currently the boot order of VPGs cannot be specified. The recovery of a VPG has to be initiated manually.
|
|
|
|
Yes
One or more steps can be added to the Recovery Plan that are defined to run a 'Command on SRM Server' at the recovery site. The command will be run from Windows so it is by default not run as a Powershell command.
In addition scripts can be assigned to an individual VM by configuring 'Pre Power On Steps' and/or 'Post Power On Steps' in the VM Recovery Properties. These scripts can be run as a 'Command on Recovered VM' or as a 'Command on SRM Server' at the recovery site.
|
Yes
One or more steps can be added to the Recovery Plan to automate actions. These actions van be defined in Azure Automation runbooks or PowerShell scripts.
Types of automated tasks:
- Tasks on the Azure VM after failover
- Tasks inside the Azure VM after failover
For tasks that can’t be automated, pauses can be inserted to allow manual actions.
|
Yes (limited)
Windows batch (.bat) files and Windows PowerShell scripts can be configured as part of a Virtual Protection Group (VPG).
|
|
|
Recovery Granularity
Details
|
Per VM Group
A Protection Group is a collection of VMs that SRM protects together. One or more Protection Groups can be configured to be part of a Recovery Plan. A Recovery Plan specifies how SRM recovers the VMs in the Protection Groups that it contains.
|
Per VM Group
Per VM
A Group is a collection of VMs/machines that ASR protects together. One or more Groups can be configured to be part of a Recovery Plan.
In Azure Site Recovery (ASR) a test or live failover can be initiated on the VM/machine level or the Recovery Plan level involving at least one Group of VMs/machines.
|
Per VM
Per VM Group
When performing a Test Failover or Live Failover, with Zerto IT Resilience Platform (IRP) specific Virtual Protection Groups (VPGs) and specific VMs within those VPGs can be selected for recovery.
|
|
|
Turn Off VMs at Source Site
Details
|
Yes
VMware SRM provides the option to shut down the guest OS of a VM before it powers off on the protected site. It also provides the option whether or not to power on a VM on the recovery site.
|
Yes
A Shutdown step can be added to a Recovery Plan so an attempt is made to turn off the VMs/machines on the protected site. The exception is when running a test failover, in which case the protected site continues to run.
|
Yes
|
|
|
Turn Off VMs at DR Site
Details
|
Yes
VMware SRM can suspend VMs on the recovery site during a live failover and a test failover.
Suspending VMs on the recovery site is useful in active-active datacenter environments and where non-critical workloads run on recovery sites. By suspending any VMs that host non-critical workloads on the recovery site, SRM frees capacity for the recovered VMs.
|
No
Because Azure Site Recovery (ASR) is mostly a public cloud offering, there is no need to shutdown VMs/machines at the recovery site. The exception here would be the on-premises to on-premises Hyper-V configuration.
|
Yes
|
|
|
|
Yes
Array-based: When testing a recovery plan, the VMs on the protected site are still replicated to the replica VMs disk files on the recovery site. During test recovery, the array creates a snapshot of the volumes hosting the VMs disk files on the recovery site. Array replication continues normally while the test is in progress. When performing cleanup after running a test, the array removes the snapshots that were created earlier as part of the test recovery workflow.
vSphere Replication (VR): When testing a recovery plan, the VM on the protected site can still synchronize with the replica VM disk files on the recovery site. The VR Server creates redo logs on the VM disk files on the recovery site, so that synchronization can continue normally. When performing cleanup after running a test, the VR Rerver removes the redo logs from the disks on the recovery site and persists the changes accumulated in the logs to VM disks.
|
Yes
Azure Site Recovery (ASR) provides test failover functionality to validate the disaster recovery strategy and configuration, without any data loss or downtime. A test failover does not impact ongoing replication and/or the protected environment. Test failovers can be performed on a specific VM/machine or on a Recovery plan containing multiple VMs/machines.
|
Yes
Zerto provides two failover options:
- Test Failover
- Live Failover
A Test Failover creates virtual machines in a sandbox, using the test network specified in the Virtual Protection Group (VPG) definition, as opposed to creating virtual machines in a production network. All data changes that are performed during the Test Failover are written to separate scratch volumes. These scratch volumes reside on the storage defined for the journal.
During a Test Failover any changes to the protected virtual machines at the protected site are still sent to the recovery site and new checkpoints continue to be generated throughout the failover test.
|
|
|
|
No
|
No
|
Yes
Zerto IT Resilience Platform (IRP) provides a Clone operation that creates a copy of all the VMs that are part of a Virtual Protection Group (VPG) on the DR site in the production network. The cloned VMs are named after the protected VM name along with the timestamp of the checkpoint used for the clone. The cloned virtual machines are not powered on. The VMs on the source site remain protected and live.
|
|
|
|
Yes
After a recovery, the recovery site becomes the primary site, but the VMs are not protected yet. If the original protected site is operational again, you can have SRM reverse the direction of protection in an automated fashion to use the original protected site as a new recovery site to protect the new protected site.
|
Yes (VMware/Azure IaaS)
NEW
VMware vSphere: Both Reprotect and Failback require a site-to-site VPN to replicate data to the on-premises datacenter. ASR Reprotect assumes that the on-premises datacenter is up and running and is ready to receive the replication data from Azure.
Azure IaaS: Azure VMs can be reprotected after failover, so that data replicates back from the secondary to the primary Azure region.
Reprotect does not apply to Hyper-V VMs and Physical machines.
UR40 introduces the following enhancement: Machines in the DR region are now cleaned up automatically after failback is complete and when the VMs are re-protected. There is no need to manually delete VMs and NICs.
|
Yes
Protecting the DR site after a successful failover (Reprotect) is available through Zertos 'Reverse Protection' option.
Reverse Protection can be leveraged for all supported platforms: VMware vSphere (vCenter), VMware vCloud Director (vCD), Microsoft Hyper-V (SCVMM), Microsoft Azure, Amazon Web Services (AWS).
|
|
|
|
Yes
When the original protected site is back up and running, the recovered VMs can be migrated back to the original protected site performing a 'Failback' operation.
Failback in SRM follows the following sequence:
1. Perform a reprotect from the recovery site.
2. Perform a planned migration from the recovery site to the original protected site.
3. Perform a reprotect from the original protected site.
|
Yes
On-premises: Both Reprotect and Failback require a site-to-site VPN to replicate data to the on-premises datacenter.
Failback pre-requisites:
- The on-premises Proces Server can be resused when leveraging Azure ExpressRoute.
- Optionally, a Process Server can be deployed in Azure.
- Windows Master Target Server is pre-deployed.
- Linux Master Server is required for VMs.
A physical machine, once failed over to Azure, can only be failed back as a VMware virtual machine (VM).
|
Yes
When the original Source site is back up and running, the recovered VMs can be migrated back to the original Source site using the 'Move' operation.
|
|
|
|
Networking |
|
|
|
Automatic IP Renumbering
Details
|
Yes
VMware SRM allows customization of IP settings for protected VMs. Customizing the IP properties of a VM overrides the default IP settings when the recovered VM starts at the destination site.
SRM supports different types of IP customization:
- Use IPv4 and IPv6 addresses.
- Configure different IP customizations for each site.
- Use DHCP, Static IPv4, or Static IPv6 addresses.
- Customize addresses of Windows and Linux VMs.
- Customize multiple NICs for each VM, restricted to one IP address per NIC.
For a list of supported guest OS:
http://partnerweb.vmware.com/programs/guestOS/guest-os-customization-matrix.pdf
|
Yes
NEW
Azure Site Recovery (ASR) provides the option to use a different IP address range for the replicated Azure VM network. In this scenario the VM gets a new IP address after failover, and a DNS update is required.
UR40 introduces support for static IP settings during a Test Failover. Earlier, when end-users performed test failover on to actual DR network, the original IP was not used to ensure that the IP was available for an actual DR. However, because end-users want to retrieve the same IP address during a DR drill to validate networking settings, end-users are now allowed to pick static IPs during a Test Failover.
|
Yes
Zerto supports automatic Re-IP as well as automatic change of the MAC Address when recovering VMs on the DR site.
In VMware vSphere environments Re-IP is supported for the following Guest Operating Systems:
- MS Windows Server 2003, 2008, 2012, 2016 (all versions), 2019
- RHEL 5-7.x
- SUSE 10-11.x
- Ubuntu 14.10, 15.04
- CentOS 5-7x
- Oracle Linux 6.x RHCK/UEK, 7.3
In Microsoft Hyper-V environments Re-IP is supported for the following Guest Operating Systems:
- MS Windows Server 2008, 2012, 2016
- RHEL 7.3
- CentOS 7
- Oracle Linux 7, 7.3
Re-IP is supported when recovering to AWS. However, this requires the installation of ZertoTools inside a protected Windows VM running in a VMware vSphere environment.
|
|
|
Isolated Network for Test Failover
Details
|
Yes
Test networks can be explicitly assigned. If VM network assignment is 'Isolated network' (auto created) and there are no site-level mappings, SRM assigns VMs to temporary networks that are not connected to any physical network.
|
Yes
An Azure virtual network can be selected when initiating a test failover. ASR attempts to create test VMs in a subnet with the same name and same IP address as that provided in the Compute and Network settings of the VM.
If a subnet with the same name isnt available in the Azure virtual network used for test failover, then the test VM is created in the first subnet alphabetically. If the same IP address isnt available in the subnet, then the VM receives another available IP address in the subnet.
|
Yes
A pre-defined network must be configured. Also routing must be provided eg. by pre-configuring a Linux VM for this purpose inside the isolated network.
|
|
|
Management
|
|
|
|
|
|
|
Interfaces |
|
|
|
GUI Functionality
Details
|
Centralized
A single VMware SRM environment consisting of one or multiple sites can managed through the SRM Management GUI.
|
Centralized
The Azure Site Recovery (ASR) service is managed from a centralized online console.
|
Centralized
A single Zerto environment consisting of one or multiple sites can managed through the Zerto Management GUI.
Next to this Zerto provides an Analytics Web GUI for monitoring and reporting on one or multiple Zerto environments.
Zerto IT Resilience Platform (IRP) 7.0 introduces a brand new ZVM Graphic User Interface (GUI) which is simpler and more accessible. In addition, as part of the new user experience, users are now able to launch Zerto Analytics from within the new ZVM interface.
|
|
|
|
Single-site and Multi-site
A single VMware SRM environment consisting of one or multiple sites can managed through the SRM Management GUI.
|
Single-site and Multi-site
A single Azure Site Recovery (ASR) environment consisting of one or multiple protected sites can managed through the centralized ASR online console.
|
Single-site and Multi-site
A single Zerto environment consisting of one or multiple sites can managed through the Zerto Management GUI.
Next to this Zerto provides an Analytics Web GUI for monitoring and reporting on one or multiple Zerto environments.
|
|
|
GUI Performance Monitoring
Details
|
Basic
Array-based: Depending on the storage manufacturer remote replication can either be monitored using the Storage Array GUI or from within the vSphere Web Client GUI if a extensive plugin is provided.
vSphere Replication (VR): Administrators can monitor some basic metrics from within the vSphere Client GUI (collection happens at 5 minute intervals):
- Transferred Bytes
- Replications Count
- RPO Violation Count
- Target Sites Count
- VR Sites Count
In addition administrators can monitor network bandwidth and CPU usage of the VR Servers.
|
N/A
Monitoring in Azure Site Recovery (ASR) is almost entirely health-oriented. Performance monitoring is limited to current RPO readings for every individual VM/machine.
|
Advanced
The Dashboard tab in the Zerto GUI displays the aggregated storage throughput (IOPs), storage bandwidth (MBps) and WAN Traffic (MBps) statistics of all Virtual Protection Groups (VPGs) combined together for the past 4 hours.
The Monitoring tab in the Zerto GUI shows the actual RPO (sec), storage throughput (IOPs), storage bandwidth (MBps) and WAN Traffic (MBps) statistics of the selected Virtual Protection Group (VPG) for the past 4 hours.
|
|
|
GUI Storage Statistics
Details
|
None
Storage usage statistics need to be either observed from the vSphere Web GUI and/or the Storage Array GUI.
|
N/A
Storage usage statistics need to be either observed from outside the ASR online console.
|
Advanced
The Zerto Analytics website (analytics.zerto.com) displays the storage statistics on both Source site and DR site.
A Source site shows the following stats for every individual datastore:
- storage space used for protected volumes
- storage used for Zerto Virtual Appliances (VRAs)
- storage used for other purposes
- free storage space
A DR site shows the following stats for every individual datastore:
- storage space used for recovery volumes
- storage space used for journals
- storage used for Zerto Virtual Appliances (VRAs)
- storage used for other purposes
- free storage space
Drilling down into a datastore shows the following stats for every protected invividual disk:
- Path and name
- storage space used
- storage space provisioned
- Thin provisoned yes/no
- Parent VM name
- Parent VPG name
|
|
|
|
vSphere: Web Client (plugin)
VMware SRM 8.1 introduced the new HTML5 based web interface. During the installation of SRM, a plugin labeled “Site Recovery” is installed in the vSphere Web Client and an icon labeled “Site Recovery” is displayed.
The new interface merges SRM and vSphere Replication interfaces to allow for easier navigation and improved management. Work has also gone into improving workflows and making the interface easier to use. For example, when configuring VMs for replication with vSphere Replication (VR), as part of the same protection workflow the VMs can be added to a new or existing Protection Group and a new or existing Recovery Plan.
|
N/A
There are no integration points between Azure Site Recovery (ASR) and VMware vSphere Web Client and/or Hyper-V Virtual Machine Manager (VMM).
|
vSphere: Web Client (plugin)
Hyper-V: None
The Zerto User Interface is embedded in both the vSphere Web Client as a plug-in. When accessing the Zerto User Interface from within vSphere the interface is available via a tab. This allows virtualization admins for example to add a VM that is not already protected to a Virtual Protection Group (VPG).
There is currently no plug-in support for the vSphere Web (FLEX) Client 6.7.
There is currently no plug-in support for the vSphere HTML5 Web Client.
There is currrently no SCVMM Zerto Management Provider available for Hyper-V environments.
|
|
|
Role-based Access Control
Details
|
Yes
VMware SRM supports Role-based Access Control (RBAC) by providing multiple roles out-of-the-box:
- SRM Administrator
- SRM Protection Groups Adminisrator
- SRM Recovery Administrator
- SRM Recovery Plans Administrator
- SRM Recovery Test Administrator
SRM roles can be assigned to a user or user group. Although individual users and user groups can be assigned only one role, roles can be combined by assigning a user to multiple user groups.
|
Yes
Azure Site Recovery (ASR) provides 3 built-in roles to control Site Recovery management operations:
- Site Recovery Contributor > manage Azure Site Recovery operations in a Recovery Services vault.
- Site Recovery Operator > execute and manage Failover and Failback operations.
- Site Recovery Reader > view all Site Recovery management operations.
Custom roles can be defined for more control.
|
vSphere: Yes
Hyper-V: No
Zerto IT Resilience Platform (IRP) supports Role-based Access Control (RBAC) when using the vCenter Server plug-in. The following privileges can be assigned:
- Manage sites
- Manage Virtual Protection Groups (VPG)
- Manage VRA
- Live Failover / Move
- Test Failover
The Zerto Virtual Manager (ZVM) does not support RBAC.
|
|
|
|
Programmability |
|
|
|
|
REST-APIs
PowerCLI cmdlets
VMware SRM provides a full set of RESTful APIs as well as PowerCLI cmdlets so that most operational tasks can be scripted and thus automated.
There are no supported means of programmatically interacting with vSphere Replication (VR).
|
Rest API
PowerShell
Azure SDK
Azure Site Recovery (ASR) workflows can be automated using the Rest API, PowerShell, or the Azure SDK.
|
REST-APIs
PowerShell cmdlets
Zerto IT Resilience Platform (IRP) provides a full set of RESTful APIs as well as Microsoft Powershell cmdlets so that all operational tasks can be scripted and thus automated.
APIs are available both to return status information and to perform actions, such as a failover. All APIs are exposed over HTTPS. Data returned is formatted either as JSON or as XML as set by the consumer. By default, data that is returned for the v1 APIs is
formatted as JSON.
Detailed information including examples are provided in PDF formatted guides.
|
|
|
|
Multi-tenancy |
|
|
|
VMware vCloud Director
Details
|
No
VMware SRM does not provide support for any version of VMware vCloud Director (vCD).
vCloud Availability for Cloud-to-Cloud (vCAv-C2C) is VMware’s product offering for vCloud Director (vCD) instance to instance disaster recovery and migration.
VMware vCloud Director (vCD) is deployment, automation and management software for virtual infrastructure resources in multi-tenant cloud environments. VMware vCD enables cloud service providers to convert physical data centers into highly elastic virtual data centers (VDCs).
|
No
Azure Site Recovery (ASR) does not provide support for any version of VMware vCloud Director (vCD).
VMware vCloud Director (vCD) is deployment, automation and management software for virtual infrastructure resources in multi-tenant cloud environments. VMware vCD enables cloud service providers to convert physical data centers into highly elastic virtual data centers (VDCs).
|
Yes
NEW
Zerto IT Resilience Platform (IRP) 7.5 supports VMware vCloud Director (vCD) 9.0, 9.1, 9.5 and 9.7. vCD 8.10 and 8.20 are no longer supported. vCD support requires Zerto IRP Enterpise edition.
Protected machines are protected as a vCD vApp in the recovery site vCD.
VMware vCloud Director (vCD) is deployment, automation and management software for virtual infrastructure resources in multi-tenant cloud environments. VMware vCD enables cloud service providers to convert physical data centers into highly elastic virtual data centers (VDCs).
|
|
|
|
Reporting |
|
|
|
|
N/A
VMware SRM does not provide insight into SLA compliance for DR purposes by providing native reporting capabilities.
|
N/A
Azure Site Recovery (ASR) does not provide insight into SLA compliance for DR purposes by providing native reporting capabilities.
|
Medium
The Zerto Analytics website (analytics.zerto.com) provides medium SLA reporting capabilities:
- RPO statistics are available for the last month.
- RPO SLA Status is reported on every minute.
- Statistics of a single VPG can be shown at any one time.
- GUI allows zooming in on a specifc time window ranging from a month to week(s), day(s), hour(s) and minute(s).
- VPG RPO diagram graphically displays RPO, max RPO and configured RPO.
- VPG RPO SLA Status (percentage meeting SLA) is displayed in a slider bar.
- VPG RPO SLA Breach showing start time, end time, duration, max RPO and configured RPO for every individual breach observed.
- VPG on-screen diagrams and information can be exported in PDF, Excel and CSV format.
Alternatively ZVM RESTfull APIs as well as Zerto Analytics RESTfull APIs can be leveraged to programmatically pull the desired RPO information from the system to create custom RPO reports.
|
|
|
Storage Used for DR
Details
|
N/A
VMware SRM does not provide insight into storage usage for DR purposes by providing native reporting capabilities.
|
N/A
Azure Site Recovery (ASR) does not provide insight into storage usage for DR purposes by providing native reporting capabilities.
|
Medium
The Zerto Analytics website (analytics.zerto.com) provides medium Journal reporting capabilities:
- Journal statistics are available for the last month.
- Journal statistics are reported on every minute.
- Statistics of a single VPG can be shown at any one time, or total combining all journals.
- GUI allows zooming in on a specifc time window ranging from a month to week(s), day(s), hour(s) and minute(s).
- VPG Journal History diagram graphically displays min journal history, journal history and configured journal history.
- VPG Journal Size diagram graphically displays journal size and max journal size.
- VPG Journal History SLA Status (percentage meeting SLA) is displayed in a slider bar.
- VPG Journal Breach showing start time, end time, duration, min journal history and configured journal history for every individual breach observed.
- VPG on-screen diagrams and information can be exported in PDF, Excel and CSV format.
Alternatively ZVM RESTfull APIs as well as Zerto Analytics RESTfull APIs can be leveraged to programmatically pull the desired journal information from the system to create custom RPO reports.
|
|
|
Network Used for DR
Details
|
N/A
VMware SRM does not provide insight into network usage for DR purposes by providing native reporting capabilities.
|
N/A
Azure Site Recovery (ASR) does not provide insight into network usage for DR purposes by providing native reporting capabilities.
|
Medium
The Zerto Analytics website (analytics.zerto.com) provides medium Network reporting capabilities:
- Network statistics are available for the last month.
- Network statistics are reported on every minute.
- Statistics of a single VPG can be shown at any one time, or total combining all VPGs or total going between 2 sites.
- GUI allows zooming in on a specifc time window ranging from a month to week(s), day(s), hour(s) and minute(s).
- VPG Network Performance diagram graphically displays avg bandwidth, max bandwidth, avg WAN traffic and max WAN traffic.
- VPG IOPs diagram graphically displays avg IOPs and max IOPs.
- VPG on-screen diagrams and information can be exported in PDF, Excel and CSV format.
Alternatively ZVM RESTfull APIs as well as Zerto Analytics RESTfull APIs can be leveraged to programmatically pull the desired network information from the system to create custom RPO reports.
|
|
|
|
Advanced
Reports about each run of a recovery plan, test of a recovery plan, or test cleanup can be viewed and exported from 'Recovery Plans History' in the SRM GUI. The history contains information about the result and the start and end times for the whole plan and for each step in the plan. SRM preserves history for deleted recovery plans.
|
Basic
In Azure Site Recovery (ASR) the Job tab shows a history of all executed recovery steps status, start time, duration) and an Export option for reporting purposes.
|
Advanced
Information about recovery operations (failover tests, moves, and failovers) can be displayed in Recovery Reports under the Reports tab inside the Zerto Management GUI. The information includes the name of the user who initiated the report, which recovery operation, the point in time, protected and the recovery sites involved, when the recovery operation was started, when it ended, the time it took to bring up the VMs in the recovery site, the RTO, whether the operation succeeded or not, the VPG recovery settings, the VM recovery settings, and detailed recovery steps, and any notes added during a failover test. Recovery Reports are always kept, and never deleted. Recovery Reports can be exported to either PDF or Zip.
|
|
|
|
|
|
|
|
|
