Array-based or vSphere Replication for VMware SRM?

Opinion

Array-based or vSphere Replication for VMware SRM?

Paul Grimwood, GlassHouse Technologies (UK)

VMware Site Recovery Manager (SRM) is a disaster recovery orchestration product that protects virtual machines by duplicating them to a secondary site. This is achieved using storage array-based replication or vSphere Replication network-based replication. 

The decision about which replication technology to use should be determined by business requirements; specifically the Recovery Point Objectives (RPO) defined in the disaster recover service level agreement. These requirements should be matched to the capabilities and scalability of the replication technology and balanced against costs and other considerations.

GlassHouselogo.jpg

Array-based replication uses an SRM storage adapter to leverage the replication and snapshot capabilities of the array. This allows for high performance, synchronous or asynchronous replication of large amounts of data.

Where an SLA demands a low RPO, and a minimal loss of data, array-based replication remains the preferred option due its synchronous replication capability. However, this performance comes at a cost. Storage hardware from the same maker is needed at both sites and usually features such as replication and snapshots incur additional licensing costs.

Alternatively, SRM can leverage the vSphere Replication feature, incorporated into vSphere5.1, which utilises the hypervisor to replicate across the network on a per VM basis. This approach offers more flexibility as it allows replication between different storage hardware and is storage protocol independent.

With vSphere Replication, low end, direct-attached, storage or cloud infrastructure can be used at the failover site to reduce costs.  SRM with vSphere Replication supports features such as failback and re-protect which were previously only available with array-based replication.

Microsoft VSS can be used to quiesce applications during replication passes to ensure data consistency. Also, multiple point-in-time recovery allows roll-back to a known consistent state.

A disadvantage of using vSphere Replication is poorer performance compared to array-based replication. At best, a 15 minute RPO is possible. Due to this limitation vSphere Replication is not suitable in situations that require minimal data loss.

Instead, vSphere Replication is suited for use with more static systems, such as a web application server tiers. There is also a performance impact on the host whilst running replication as well as limits on the total number of replica VMs that can be supported (500 as opposed to 1,000 with ABR). Certain features such as linked-clones, physical mode raw device mapping (RDM) and Fault Tolerance are not supported but this may be addressed in the future.

It is possible to combine the two technologies. For example, small branch sites could use vSphere Replication replication to a main site which is then protected using array-based replication. Or, certain VMs could be replicated, using vSphere Replication, to a cloud provider as well as to an array-based replication linked site.

To summarise, vSphere Replication is simpler, more flexible and cheaper than array-based replication but at the expense of reduced performance, scalability and feature support. The decision about which technology to use, or whether to combine the two, should be determined by business requirements as well as any existing investments.

Paul Grimwood is technical consultant with GlassHouse Technologies (UK).

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

This was first published in October 2013

 

COMMENTS powered by Disqus  //  Commenting policy