Update September 2012: With the introduction of vSphere 5.1, vSphere Replication is an integral part of VMware vSphere. vSphere replication can be used for free, although SRM is still a seperate add-on product.
Also read: Comparing Disaster Recovery options for VMware vSphere – About VR, ABR, SRM, Veeam & Zerto
With the introduction of VMware Site Recovery Manager 5 (SRM), VMware also released a new replication option: vSphere Replication.
With previous versions of SRM, it was mandatory to use the replication and snapshot technology provided by your storage vendor. E.g. when using NetApp, you had to use snapmirror (for replication) and flexclone (for failover testing).
vSphere Replication is a new option, which enables storage replication through the ESXi hypervisor. vSphere Replication is part of SRM and available at no extra cost.
Although vSphere Replication looks the same at first sight, there are some differences between vSphere Replication and Array Based replication. For reference I have summed up the differences in the following table:
| vSphere Replication | Array Based Replication |
| Replication using the vSphere/hypervisor layers. | Replication using the storage layer. |
| Incoporated in the SRM license, available at no additional costs. | A replication and snapshot license is mandatory. Costs depend on the storage vendor. |
| A different storage solution (e.g. Netapp & HP) on both locations is no problem. vSphere replication can replicate between these solutions. | You have to use the same storage solution, at least it should be the same brand. |
| Replication of local or direct attached storage is possible. | You can only replicate the data on the centralized storage solution (SAN) |
| RPO of 15 minutes – 24 hours | RPO of 0 minutes is possible (synchronous replication) till 24 hours, depending on the scheduling options of your storage solution. |
| A maximum of 500 virtual machines can be replicated. | ‘Unlimited’ number of virtual machines can be replicated depending on the capacity, distance between the locations and available bandwith. |
| You cannot replicate physical servers. | You can replicate physical servers. |
| Replication can be configured per virtual machine. | Replication is configured per LUN/VMFS or NFS volume. |
| Configured by the VMware vSphere administrator | Configured by the storage administrator |
| Raw device mapping are not supported | Raw device mapping are supported |
| Virtual machines using Fault Tolerance cannot be replicated | Virtual machines using Fault Tolerance can be replicated |
| Linked cloned virtual machines (View, Cloud Director) cannot be replicated | Linked cloned virtual machines (View, Cloud Director) can be replicated |
| Clustered virtual machines (e.g. Microsoft Clustering Services) cannot be replicated | Clustered virtual machines (e.g. Microsoft Clustering Services) can be replicated |
| Automatic reprotection and a failback is not available. Note: In SRM 5.1 reprotection and failback is supported. See this article for more information. | Automatic reprotection and a failback is available. |
| vApp consistency (or consistency groups) are not available. | Consistency groups are available through your storage solution. |
| Application consistency can be achieved through VSS. | No application consistency options is available. |
I hope this table will help you to decide which replication technology to use.
2 Comments
Almero
Hi Viktor , nice article . Do you know if the SRM side ( or any other vSphere tool ) can help me replicate the actual RDM’s in physical mode ? Not just the symbolic / pointer record on the VMFS , the actual pass-through disk lun. Planning to make a new DR site , and we have V7000 IBM storage , that supports array based Metro mirror . We have many Microsoft clusters in a Quorum based configuration on esxi5.1u1 ., but currently no SRM .
viktorious
Hi Alemro! Good question. Both physical and virtual RDMs are supported in a SRM configuration (http://www.viktorious.nl/2013/07/08/comparing-disaster-recovery/).
I’ve also learned that:
“You can run a cluster of MSCS virtual machines in the following possible configurations.
Cluster-in-a-box: The MSCS virtual machines in the cluster run on a single ESXi Server. You can have a maximum of two MSCS virtual machines in the cluster.
Cluster-across-boxes: You can spread the MSCS cluster across a maximum of two ESXi Server instances. You can protect only one virtual machine node of any MSCS cluster on a single ESXi Server instance. You can have multiple MSCS node virtual machines running on an ESXi host, as long as they do not participate in the same MSCS cluster. When running MSCS in a cluster-across-boxes configuration, SRM only supports two-node MSCS clusters.”
So yes, with some limitations this configuration is supported. Additional details here:
http://pubs.vmware.com/srm-51/index.jsp?topic=%2Fcom.vmware.srm.admin.doc%2FGUID-3EBBD9DA-CD14-45BB-9F4F-2C749881B117.html